after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

Matthijs Mekking matthijs at isc.org
Wed Oct 26 08:10:10 UTC 2022


On 24-10-2022 15:14, PGNet Dev wrote:
>> The good news it is not stuck.
> 
> What indicator flags that it IS 'stuck'?  Is it explicitly logged?

Because the keymgr logs says it is just waiting time?

2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: time says no to KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT (wait 93600 seconds)


>> BIND is waiting to make sure the new DS is also known to the 
>> validators. The time being evaluated here is the DS TTL, plus 
>> parent-propagation-delay, plus retire-safety. All these three values 
>> are configurable within dnssec-policy.
> 
> my current config has
> 
>      parent-ds-ttl              PT1H;
>      parent-propagation-delay   PT1H;
>      retire-safety              PT1H;
> 
> @ parental-agents, the DS is cached; ttl appears spec'd other than my 
> set ttl. e.g., @ cloudflare, it's 1 day ...
> 
> in any case, all of my domains still returned "DSState: rumoured" at < 4 
> days.
> since then, about 1/4 of the domains have flipped from "rumoured" -> 
> "omnipresent", with no manual intervention; the rest are still unchanged.
> 
> again, i've noticed no actual operational problems -- e.g., queries 
> failing, etc -- other than these delays.
> 
> seems, tho, i've still got a likely misconfig somewhere in here.

I am happy to look into it, if you are willing to share the key 
**state** file in question (off-list), and dnssec-policy configuration.

A full excerpt of the debug logs around 2022-10-21T16:55:22 can also be 
useful.

Best regards,

Matthijs


More information about the bind-users mailing list