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
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 ?
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 ?
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
after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?
with bind 9.18, config'd for dnssec-policy automated signing, I've a dnssec signed zone, rndc dnssec -status example.com IN external dnssec-policy: test current time: Fri Oct 21 16:14:06 2022 key: 47219 (ECDSAP256SHA256), ZSK published: yes - since Fri Oct 21 15:22:27 2022 zone signing: yes - since Fri Oct 21 17:27:27 2022 Next rollover scheduled on Thu Jan 19 14:22:27 2023 - goal: omnipresent - dnskey: rumoured - zone rrsig: rumoured key: 63917 (ECDSAP256SHA256), KSK published: yes - since Sat Oct 15 15:52:05 2022 key signing:yes - since Sat Oct 15 15:52:05 2022 No rollover scheduled - goal: omnipresent - dnskey: omnipresent - ds: rumoured - key rrsig: omnipresent key: 43175 (ECDSAP256SHA256), ZSK published: no zone signing: no Key has been removed from the zone - goal: hidden - dnskey: unretentive - zone rrsig: unretentive note for the KSK, it's ds state, - ds: rumoured I've verified externally that thhe zone's DS RECORD has been pushed to registrar->parent, it's fully propagated, and is passing all the external/online checks. reading @ https://kb.isc.org/docs/dnssec-key-and-signing-policy "Note: If you see the DSState stuck in rumoured after the migration, you need to run rndc dnssec -checkds published example.com to tell BIND that the DS is already published in the parent zone" I exec rndc dnssec -checkds -key 63917 published example.com IN external KSK 63917: Marked DS as published since 21-Oct-2022 16:19:36.000 rndc reload server reload successful and check again, rndc dnssec -status example.com IN external ... key: 63917 (ECDSAP256SHA256), KSK published: yes - since Sat Oct 15 15:52:05 2022 key signing:yes - since Sat Oct 15 15:52:05 2022 No rollover scheduled - goal: omnipresent - dnskey: omnipresent !!- ds: rumoured - key rrsig: omnipresent ... grep DSState Kexample.com.+013+63917.state !! DSState: rumoured ds state is still just "rumoured". What additional steps are needed to update that DSState correctly? -- 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
