Hi,
The timings are based on RFC 7583 and "Flexible and Robust Key Rollover
in DNSSEC". They may help a great deal in understanding the time states.
https://datatracker.ietf.org/doc/html/rfc7583
https://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf
See below for inline answers.
Best regards,
Matthijs
On 20-02-2025 21:46, Nguyen Thi Minh Tam via bind-users wrote:
Hi,
I'm trying out DNSSEC policy for the first time, and I am so confused
about the time states—how they calculate the time for the state of the
records to change. I really need help because I have a ton of questions
(I'm using BIND 9.18.31, btw). I want to understand how it works step by
step, so I'm checking out everything.
*1. When BIND 9 first starts signing DNSSEC, the record states go
like this:*
*DNSKEY (KSK):*
* *publish = rumoured*
* *rumoured → omnipresent* = |dnskey-ttl + zone delay + publish
safety| (1)
*DS:*
* *publish = hidden*
* *hidden → rumoured* = ??? (2) (3)
* *rumoured (DSpublish) → omnipresent* = |ds-ttl + parent-zone-delay +
retire safety| (4)
*Key RRSIG:*
* *publish = rumoured*
* *rumoured → omnipresent* = |dnskey-ttl + zone delay + publish
safety| (1)
*DNSKEY (ZSK):*
* *publish = rumoured*
* *rumoured → omnipresent* = |dnskey-ttl + zone delay + publish
safety| (1)
*Zone RRSIG:*
* *publish = rumoured*
* *rumoured → omnipresent* = ?? (5)
*Here are my questions:*
(1) Since this is the first key, I guess the formula should be |zone
delay + publish safety|?
We don't make an exception for that (we could, I guess).
(2) I have no idea how this works.
The DS cannot be introduced automatically. So only after seeing the DS
in the parent, the DSPublish will be set. This can be done with a 'rndc
dnssec -checkds' command, or you can configure parental agents.
In 9.20, there is a 'checkds yes' option that will lookup the NS records
of the parent zone to see if the DS is already published. If configured,
this will move the DS to rumoured automatically.
(3) Same with |PublishCDS|. What is the formula, and why? Must I wait
for |CDS| to be published before submitting |DS| to the parent zone?
The PublishCDS is the time that the CDS and CDNSKEY can be published. At
this time it is safe to publish the DS. You can submit it to the parent
earlier, but at the risk of your zone being validated as bogus by some
resolvers.
(4) This only makes sense when rolling a key. Should the formula be
|parent-delay + publish safety (of the parent zone)|?
For the first key yes, but we don't make exceptions for the first key.
(5) I have absolutely no idea, but it looks like it changes at the same
time as when the DS goes from hidden to rumoured.
max-zone-ttl + zone-propagation-delay + retire-safety.
------------------------------------------------------------------------
*2. Then I tried a ZSK rollover, which turned out to be a bit weird.*
* If the KSK is *omnipresent*, ZSK will roll using the *pre-publish*
method.
* If the KSK is *not omnipresent*, ZSK will roll using the
*double-signing* method.
* The new ZSK is *published and starts signing at the same time*, but
it initially *only signs the SOA record*.
* When I query the SOA record, *two RRSIGs (from both ZSKs) are returned*.
* The rest of the zone *remains signed with the old ZSK*.
* After a while, the entire zone *switches to the new ZSK RRSIGs*.
* Then, |named| *removes the old ZSK DNSKEY*.
The timeline is even *weirder* than I expected.
Is this normal? Should i avoid this situation in reality?
Please provide a reproducer because this does not sound normal. ZSK
rollovers will always do "pre-publish". There should be a smooth
rollover, so using one signature from one of the keys at the time.
Things may be different when the DS is considered not public though.
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
