Re: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?
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? -- 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
Re: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?
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
Re: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?
The good news it is not stuck. What indicator flags that it IS 'stuck'? Is it explicitly logged? 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. -- 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
Re: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?
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 -- 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