Yes, the ZSK rollover got weird when the DS had not reach omnipresent state yet. Why is that? -----Original Message----- From: bind-users <bind-users-boun...@lists.isc.org> On Behalf Of Matthijs Mekking Sent: Friday, February 21, 2025 2:30 PM To: bind-users@lists.isc.org Subject: Re: Policy-dnssec timeline step by step
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 -- 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
