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