why did it take 26 hours for DSState to change to omnipresent?

[Matthijs Mekking]

Hi Nik,

On 16-05-2022 07:49, Nick Tait via bind-users wrote:
> Hi there.
> 
> Ever since I updated my BIND configuration to use the new dnssec-policy 
> feature (a year or so ago) my KSK/CSK rollovers have been a complete 
> shambles. My problems stem from the inference (based documentation and 
> examples) that running "rndc dnssec -checkds published" tells BIND that 
> the DS record is now published in the parent zone? Based on that 
> predicate, it would be my expectation that after running this command 
> above, the DSState should immediately transition from "rumoured" to 
> "omnipresent".

This assumption is incorrect. Once the DS is in the parent, validators 
do not immediately know about the new DS record. That why it is rumoured.

Being omnipresent means that every resolver will use the new DS record 
for validation purposes, whether they have it in the cache, or retrieve 
it from the parent zone. More importantly this means that any previous 
versions of the DS RRset are not known anywhere.

> In past rollovers, the DSState hasn't transitioned from "rumoured". And 
> then I've thought "oh it must be a bug" and so I've set about trying to 
> force the DSState to change to "omnipresent". And suffice to say that 
> the shambles followed on from there...
> 
> So anyway, since I'd recently upgraded to BIND 9.18.1 (as part of Ubuntu 
> 22.04 upgrade), and thinking maybe these 'bugs' might now be fixed, I 
> thought I'd have another look at it, but this time I'll pay more 
> attention to what is going on, and try to be less impatient...
> 
> Before I did anything the key state file looked like this:
> 
> Algorithm: 15
> Length: 256
> Lifetime: 0
> KSK: yes
> ZSK: yes
> Generated: 20211024221429 (Mon Oct 25 11:14:29 2021)
> Published: 20211024221429 (Mon Oct 25 11:14:29 2021)
> Active: 20211024221429 (Mon Oct 25 11:14:29 2021)
> PublishCDS: 20211025231929 (Tue Oct 26 12:19:29 2021)
> DNSKEYChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
> ZRRSIGChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
> KRRSIGChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
> DSChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
> DNSKEYState: omnipresent
> ZRRSIGState: omnipresent
> KRRSIGState: omnipresent
> DSState: rumoured
> GoalState: omnipresent
> 
> As you can see the DSState was "rumoured" before I started. So the first 
> thing I did was run "rndc dnssec -checkds published", and this added the 
> following line to the state file:
> 
> DSPublish: 20220515001647 (Sun May 15 12:16:47 2022)
> 
> However the DSState value remained "rumoured". So then I thought, I'll 
> wait a TTL or two (TTL for DS and DNSKEY are both 1 hour -- although I 
> wouldn't expect BIND to know the DS TTL). But still nothing changed. So 
> then I decided I'd leave it alone until the next day. When I checked 
> after ~20 hours elapsed time, still nothing had changed.
> 
> I checked again just now, and finally the DSState has changed to 
> "omnipresent". Here are the lines in the state file that have changed:
> 
> DSChange: 20220516021647 (Mon May 16 14:16:47 2022)
> DSState: omnipresent
> 
> So my big question is this: Is it expected that the DSState won't change 
> until 26 hours after the "rndc dnssec -checkds published" command is 
> run? And if so why does it take so long?

That depends on your dnssec-policy. BIND will/should move the DSState to 
omnipresent after an x amount of time, where:

     x =  parent-ds-ttl + parent-propagation-delay + retire-safety


By default these values are

     parent-ds-ttl: 24h
     parent-propagation-delay: 1h
     retire-safety: 1h

So the 26 hours add up.

Now these may be very conservative values, but for the default policy we 
rather wait a little longer than too short.

Best regards,

Matthijs


> 
> Thanks,
> 
> Nick.
> 
>