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

[Nick Tait]

On 16/05/22 21:34, Matthijs Mekking wrote:
> 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 so much for the explanation. Makes perfect sense now. :-)

Nick.