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

[Matthijs Mekking]

Hi,

On 21-10-2022 23:05, PGNet Dev wrote:
>> I exec
>>
>>      rndc dnssec -checkds -key 63917 published example.com IN external
> 
> with dnssec loglevel -> debug, on exec, in logs
> 
>    2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022 
> 16:55:22.689 dnssec: debug 1: keymgr: examine KSK 
> example.com/ECDSAP256SHA256/63917 type DS in state RUMOURED
>    2022-10-21T16:55:22.690608-04:00 ns named[36683]: 21-Oct-2022 
> 16:55:22.689 dnssec: debug 1: keymgr: can we transition KSK 
> example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
> OMNIPRESENT?
>    2022-10-21T16:55:22.690615-04:00 ns named[36683]: 21-Oct-2022 
> 16:55:22.689 dnssec: debug 1: keymgr: dnssec evaluation of KSK 
> example.com/ECDSAP256SHA256/63917 record DS: rule1=(~true or true) 
> rule2=(~true or true) rule3=(~false or false)
>    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)
> 
> which certainly looks like a 'no'
> 
> reason is "time says no", after "dnssec evaluation".
> 
> which time is being evaluated here?

The good news it is not stuck. 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.

Best regards,

Matthijs