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

Tue Jan 25 07:16:58 UTC 2022

Hi Mark!!! 

Thanks again!!!. Very very thankful really. Please allow me to answer
you something more as we found a guru here :) :) 

But then Mark, what does a key deletion time of a key mean?. I
understood that when the deletion time was overtaken in a ZSK, the key
dissapeared from the DNSKEY and so... it should not exist RRSIGs with
that ZSK (because that RRSIG could not become validated with a valid/in
effect ZSK) key because all should have been renewed between the key
inactive time and the delete time. I assume I am wrong then. I read the
ARM and understood that. What I'm missing or what I have misunderstood
if you are so kind as to clarify me?. 

By the way, when you say "sig-validity-interval and re-signing is
independent of inactive and delete dates" I understand but I assume,
then I don't have clear the concept of "key delete time", because I
thought that sig-validity-interval and the fact of re-signing, was just
applied to in effect keys. 

I would be very thankful if you could help me clarifying the delete time
of a key then... I'm going to try to do it by my own, reading the ARM
relevant parts again too... 

As said before, extremely thankful Mark :) 

Regards,

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/20220125/a29a2079/attachment.htm>