Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)

Thu Jan 27 01:56:53 UTC 2022

DNSSEC involves lots of timing / co-ordination points and if any of them get delayed for any reason the
following ones also need to be delayed.  While dnssec-keygen will allow you to set all of the timers for
all of a keys life, it is bad practice to do that. 

If you are going to set the timers like this there needs to be much more time between the inactivation time
and the deletion time.  As I said earlier about 30 days with default values for sig-validity-interval.

Mark

> On 25 Jan 2022, at 18:46, egoitz at ramattack.net wrote:
> 
> Hi!!
> 
> 
> 
> Don't really know if it could help, but I generate the ZSK keys this way :
> 
> 
> 
> /usr/local/sbin/dnssec-keygen -3 -a 8 -b 1024 -P now -A now -I +45d -D +47d _____________
> 
> 
> 
> Cheers!!
> 
>  
> 
> 
> El 2022-01-25 02:48, Mark Andrews escribió:
> 
>> 
>> 
>> 
>> 
>>> On 25 Jan 2022, at 11:55, egoitz at ramattack.net wrote:
>>> 
>>> Hi Mark!!
>>> 
>>> 
>>> 
>>> Thank you so much for your answer!! and your time!!.
>>> 
>>> 
>>> 
>>> I have a couple of questions. I ask them between your lines and in blue for instance... for emphasizing and being easier to see what I'm referring to. I'm talking about ZSK keys in the questions I am asking in blue.
>>> 
>>>  
>>> 
>>> 
>>> El 2022-01-25 00:36, Mark Andrews escribió:
>>> 
>>>> 
>>>> How 'named' manages DNSSEC is very different to how 'dnssec-signzone' manages DNSSEC.  When you tell named to
>>>> inactivate a DNSKEY it stops re-signing the zone with it and it stops signing new records added to the zone
>>>> with it.  
>>>>  
>>>>  
>>>> The fact is, I don't tell named nothing really. It maintains the zone signatures (I'm using inline-signing yes; auto-dnssec maintain; per zone). I just provide it keys and then I wait, until the ZSK key's delete time arrives, then I remove it's files (.key and .private). I don't wait until the inactive time. I wait until the delete time (not the inactive time). After the delete time of the key, can still records (rrsigs) exist signed with that key then?.
>> 
>> Yes.  
>> 
>>>> It DOES NOT immediately replace all RRSIGs generated using that key.  Those records will be replaced
>>>> over the sig-validity-interval as they fall due for re-signing.  Once all those RRSIG records have been
>>>> replaced and they have expired from caches, you can then delete the DNSKEY record.
>>>> 
>>>> With the default sig-validity-interval (30) that takes up to 22.5 days to which you have to add the record TTL.
>>>>  
>>>> Ok, but does sig-validity-interval affect too, after the key deletion date?. Or does it affect only from the inactivation date to the deletion date of a key?.
>> 
>> sig-validity-interval and re-signing is independent of inactive and delete dates.
>> 
>>>> Mark
>>>>  
>>>>  
>>>> Best regards
>>>> 
>>>>> On 25 Jan 2022, at 05:21, egoitz--- via bind-users <bind-users at lists.isc.org> wrote:
>>>>> 
>>>>> Hi!!
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks a lot for your answer!!
>>>>> 
>>>>> 
>>>>> 
>>>>> I tried before the fact of renaming back and rndc sign... but does not work.... just has removed the error from the log....
>>>>> 
>>>>> 
>>>>> 
>>>>> I have changed my key managing code, for not renaming to "-OLD"  the ZSK (.key and .private) until have passed at least 2 days from the deletion time... Let's see if this way works better....
>>>>> 
>>>>>  
>>>>> 
>>>>> 
>>>>> Any more ideas mates?.
>>>>> 
>>>>> 
>>>>> 
>>>>> Thank you so much for your time :)
>>>>> 
>>>>> 
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> El 2022-01-24 17:51, Tony Finch escribió:
>>>>> 
>>>>>> ATENCION
>>>>>> ATENCION
>>>>>> ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro.
>>>>>> 
>>>>>> egoitz--- via bind-users <bind-users at lists.isc.org> wrote:
>>>>>>> 
>>>>>>> These are the contents of a cat of the private file I have renamed to
>>>>>>> samename.private-OLD :
>>>>>>> 
>>>>>>> Created: 20211031230338
>>>>>>> Publish: 20211110220241
>>>>>>> Activate: 20211110220341
>>>>>>> Inactive: 20211215230338
>>>>>>> Delete: 20211217230338
>>>>>> 
>>>>>> Yes, it can be confusing when the state of the key files doesn't match the
>>>>>> state of the zone.
>>>>>> 
>>>>>> I think you said you have renamed all your key files back to their usual
>>>>>> non-OLD names. Good; that is necessary if named is still looking for a key
>>>>>> file even if it shouldn't need it any more.
>>>>>> 
>>>>>> Then, try running `rndc sign <zone>`, to make named reload the keys. I
>>>>>> think that should also get it to make whatever updates might be necessary.
>>>>>> 
>>>>>> Then look at the logs to see if there are errors, and look at the DNSKEY
>>>>>> RRset (with its RRSIGs) to make sure it matches what you expect.
>>>>>> 
>>>>>> If that doesn't get things straightened out then, um, dunno :-)
>>>>>> 
>>>>>> I guess it is possible to get into a muddle if you try to move a key out
>>>>>> of the way very soon after its delete time. By default, named does key
>>>>>> maintenance infrequently, so I guess if you move the key after its
>>>>>> deletion time but before the next key maintenance cycle, things will get
>>>>>> out of sync. But I have not checked whether my guess is right or not.
>>>>>> 
>>>>>> Tony.
>>>>> _______________________________________________
>>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>>>> 
>>>>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>>>>> 
>>>>> 
>>>>> bind-users mailing list
>>>>> bind-users at lists.isc.org
>>>>> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org