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

[Mark Andrews]

> 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