<div dir="ltr">Hi Hoda,<div><br></div><div>Unfortunately that does not help either (tried).</div><div>And this is what the manual says about purge:</div><div>If <Purge> is present, keys marked as dead will be automatically purged from the database after this interval.<br></div><div><br></div><div>In my case the key is state retire and is not affected by Purge.</div><div><br></div><div>Thank you.</div><div><br></div><div>Emil</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 24, 2017 at 2:46 PM, Hoda Rohani <span dir="ltr"><<a href="mailto:hoda@nlnetlabs.nl" target="_blank">hoda@nlnetlabs.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Emil,<br>
<br>
I guess now decreasing the value 'Purge' in kasp will resolve the issue. Ods waits for Purge time before removing the<br>
key. It seems that your key is now in this state.<br>
<br>
Hope that works for you.<br>
<br>
Regards,<br>
Hoda<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 24-07-17 13:29, Emil Natan wrote:<br>
> Hi Hoda,<br>
><br>
> There are no signatures created/remaining in the signed zone with the<br>
> retired key and it's completely redundant it's kept in the zonefile for so<br>
> long.<br>
><br>
<br>
<br>
<br>
> Unfortunately the proposed fix does not work. It affects the active key,<br>
> but not the retired key which I want to remove from the DNSKEY RRset.<br>
><br>
> #### with original ZSK Lifetime value of 4 months<br>
> # ods-ksmutil key list -z <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> -v<br>
> Keys:<br>
> Zone: Keytype: State: Date of next<br>
> transition (to): Size: Algorithm: CKA_ID:<br>
> Repository: Keytag:<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> ZSK retire 2017-08-23<br>
> 13:50:48 (dead) 2048 8 6b5c0df9591dac52e2fdabbc7cf89b<wbr>89<br>
> Keyper 25365<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> KSK active 2018-07-23<br>
> 11:08:58 (retire) 2048 8 7e664b28619e580963c9fb6e0ee98a<wbr>96<br>
> Keyper 58744<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> ZSK active 2017-11-24<br>
> 13:48:48 (retire) 2048 8 096ace586ef8102d694cac0f586424<wbr>60<br>
> Keyper 19239<br>
><br>
> ### lifetime decreased to 2 months<br>
> Keys:<br>
> Zone: Keytype: State: Date of next<br>
> transition (to): Size: Algorithm: CKA_ID:<br>
> Repository: Keytag:<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> ZSK retire 2017-08-23<br>
> 13:50:48 (dead) 2048 8 6b5c0df9591dac52e2fdabbc7cf89b<wbr>89<br>
> Keyper 25365<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> KSK active 2018-07-23<br>
> 11:08:58 (retire) 2048 8 7e664b28619e580963c9fb6e0ee98a<wbr>96<br>
> Keyper 58744<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> ZSK active 2017-09-23<br>
> 13:48:48 (retire) 2048 8 096ace586ef8102d694cac0f586424<wbr>60<br>
> Keyper 19239<br>
><br>
> ### lifetime decreased to 1 month<br>
> Keys:<br>
> Zone: Keytype: State: Date of next<br>
> transition (to): Size: Algorithm: CKA_ID:<br>
> Repository: Keytag:<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> ZSK retire 2017-08-23<br>
> 13:50:48 (dead) 2048 8 6b5c0df9591dac52e2fdabbc7cf89b<wbr>89<br>
> Keyper 25365<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> KSK active 2018-07-23<br>
> 11:08:58 (retire) 2048 8 7e664b28619e580963c9fb6e0ee98a<wbr>96<br>
> Keyper 58744<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> ZSK active 2017-08-23<br>
> 13:48:48 (retire) 2048 8 096ace586ef8102d694cac0f586424<wbr>60<br>
> Keyper 19239<br>
><br>
> ### lifetime decreased to 10 days<br>
> Keys:<br>
> Zone: Keytype: State: Date of next<br>
> transition (to): Size: Algorithm: CKA_ID:<br>
> Repository: Keytag:<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> ZSK retire 2017-08-23<br>
> 13:50:48 (dead) 2048 8 6b5c0df9591dac52e2fdabbc7cf89b<wbr>89<br>
> Keyper 25365<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> KSK active 2018-07-23<br>
> 11:08:58 (retire) 2048 8 7e664b28619e580963c9fb6e0ee98a<wbr>96<br>
> Keyper 58744<br>
> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> ZSK active 2017-08-02<br>
> 13:48:48 (retire) 2048 8 096ace586ef8102d694cac0f586424<wbr>60<br>
> Keyper 19239<br>
><br>
> Emil<br>
><br>
> On Mon, Jul 24, 2017 at 12:52 PM, Hoda Rohani <<a href="mailto:hoda@nlnetlabs.nl">hoda@nlnetlabs.nl</a>> wrote:<br>
><br>
>> Hello Email,<br>
>><br>
>><br>
>> On 23-07-17 15:24, Emil Natan wrote:<br>
>>> I tried to decrease various values set in the kasp.xml file, most notably<br>
>>> validity default and denial, publish and retire safety, propagation delay<br>
>>> for the zone and the parent zone and TTLs. While that affected the key<br>
>>> state is some cases, it did not affect the ZSK in retire state which I<br>
>> want<br>
>>> to remove from the zone.<br>
>>><br>
>><br>
>> I think reducing the Life time value of ZSK would help you. You should run<br>
>> 'ods-ksmutil policy import' after decreasing<br>
>> the Life time to see the result.<br>
>> After the old ZSK is completely removed you can modify the ZSK Lifetime<br>
>> again to have the main value.<br>
>><br>
>><br>
>>> I also tried to force deletion of that key with ods-ksmutil key delete<br>
>> but<br>
>>> the action was rejected by the enforcerd since it considers the key to be<br>
>>> in use.<br>
>>><br>
>><br>
>> Actually it seems that this key is still being used for signatures and<br>
>> cannot be deleted.<br>
>><br>
>>> I believe it's possible to manually change the value of next transition<br>
>> for<br>
>>> that key in the database, but that I really consider last resort.<br>
>>><br>
>><br>
>> Please let us know if you still have the problem.<br>
>><br>
>>> Emil<br>
>><br>
>> Regards,<br>
>> Hoda Rohani<br>
>><br>
>>><br>
>>> On Sat, Jul 22, 2017 at 5:02 PM, Emil Natan <<a href="mailto:shlyoko@gmail.com">shlyoko@gmail.com</a>> wrote:<br>
>>><br>
>>>> Hello,<br>
>>>><br>
>>>> opendnssec version 1.4.13, kasp.xml attached.<br>
>>>><br>
>>>> We have all keys (KSK and ZSK) for the next 5 years pregenerated on the<br>
>>>> HSM.<br>
>>>><br>
>>>> <ManualRollover/> is set for the KSK.<br>
>>>><br>
>>>> Yet yesterday, on the day the KSK rollover was scheduled for, it just<br>
>>>> happened.<br>
>>>><br>
>>>> Jul 20 03:47:15 signer001 ods-enforcerd: Zone <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> found.<br>
>>>> Jul 20 03:47:15 signer001 ods-enforcerd: Policy for <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> set to<br>
>> 1.<br>
>>>> Jul 20 03:47:15 signer001 ods-enforcerd: Policy 1 found in DB.<br>
>>>> Jul 20 03:47:15 signer001 ods-enforcerd: Config will be output to<br>
>>>> /ods-data/var/opendnssec/<wbr>signconf/example.com.xml.<br>
>>>> Jul 20 03:47:15 signer001 ods-enforcerd: KSK key allocation for zone<br>
>>>> <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>: 1 key(s) allocated<br>
>>>><br>
>>>> The new KSK was introduced into the zone and DNSKEY signed with both new<br>
>>>> and old KSK. What makes it even more annoying is that the ZSK was<br>
>> rolled at<br>
>>>> the same time (as expected), so now we ended having pretty big DNSKEY +<br>
>>>> RRSIG response.<br>
>>>><br>
>>>> One of the checks on the signed zonefiles stopped it from being<br>
>> published<br>
>>>> and now we have to decide either to publish the zonefile that way or<br>
>> force<br>
>>>> the ZSK rollover to finish faster than it should if we wait for it to<br>
>>>> happen automatically and then publish the zonefile. Because of the<br>
>>>> signature validity set to 31 days, it's scheduled to happen on<br>
>> 2017-08-20.<br>
>>>> The DNSKEY RRset has a TTL of one hour and we publish the zone every day<br>
>>>> and it spreads instantly, so it's already safe to do so. I see the<br>
>>>> ods-ksmutil provides option to retire KSK (ksk-retire), but I do not see<br>
>>>> such option for ZSK. Any ideas if and how it can be done?<br>
>>>><br>
>>>> Thanks<br>
>>>> Emil<br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> Opendnssec-user mailing list<br>
>>> <a href="mailto:Opendnssec-user@lists.opendnssec.org">Opendnssec-user@lists.<wbr>opendnssec.org</a><br>
>>> <a href="https://lists.opendnssec.org/mailman/listinfo/opendnssec-user" rel="noreferrer" target="_blank">https://lists.opendnssec.org/<wbr>mailman/listinfo/opendnssec-<wbr>user</a><br>
>>><br>
>><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Opendnssec-user mailing list<br>
> <a href="mailto:Opendnssec-user@lists.opendnssec.org">Opendnssec-user@lists.<wbr>opendnssec.org</a><br>
> <a href="https://lists.opendnssec.org/mailman/listinfo/opendnssec-user" rel="noreferrer" target="_blank">https://lists.opendnssec.org/<wbr>mailman/listinfo/opendnssec-<wbr>user</a><br>
><br>
</div></div></blockquote></div><br></div>