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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
