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

[egoitz at ramattack.net]

Hi Mark! 

Very thankful again for your time. Sorry for answering so late, but I
was not at the office yesterday. I answer below in blue for instance...

El 2022-01-27 02:56, Mark Andrews escribió:

> 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. 
> 
> But as I have read in Michael Lucas book, it's recommended to refresh at least ZSK keys from time to time. For that purpose... it's required to set the needed date and times... isn't it?. 
> 
> 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.   
> 
> I see, so first and required value of sig-validity-interval <= deletion time - inactivation time then ?. 
> 
> As I said earlier about 30 days with default values for sig-validity-interval. 
> 
> This is the reason by which I have deduced the formula written above... 
> 
> Thanks again Mark!!!!
> Cheers!!!! 
> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220128/3241db43/attachment-0001.htm>