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
Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
Anand, there are two layers- Google certainly doesn’t do anything wrong, but they would do a world a favor if there was a stronger push towards compliance with DNS protocol. On the authoritative side - it’s certainly true that neither DNS Cookies nor NSID is mandatory, but the part that is mandatory (**MUST**) is correct handling of the unknown EDNS0 option. It’s kind of chicken-egg problem - resolver operators won’t enable DNS Cookies because there are some broken domains and the broken domains won’t fix it because it works with “big tech”. And the security suffers and everybody loses in the end. Somebody needs to make the first step, so we did it. It’s documented in the troubleshooting section, it can be disabled, and if anybody feels there could be more or better documentation, we do accept external Merge Requests, and we do appreciate improvements to the documentation as well as to the code. The documentation is equally important as correct code, and we are not operator ourselves, so we might miss few things. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 21. 10. 2022, at 14:26, Anand Buddhdev wrote: > > On 21/10/2022 14:04, Hugo Salgado wrote: > >> But wasn't it exactly the idea with the 2019 DNS Flag Day campaign? >> http://www.dnsflagday.net/2019/ >> I see Google's name there, so I would expect their commitment to refuse >> to solve incorrect domains. They do a skinny favor to all the Internet >> by returning to the workarounds, and blaming those who do well (as >> Bind 9.18) > > I wouldn't blame Google so quickly. The servers we're discussing in this > thread return FORMERR when the query has the COOKIE or NSID options. DNS > cookies are recommended (RFC uses "should") rather than mandated. Now, if the > Google resolver simply isn't sending these options, then it is not affected. > Similarly, a resolver like Unbound (which as far as I know doesn't send > cookies yet), will also not be affected. > > While DNS cookies are not mandatory, it's not fair to point a finger at a > resolver that doesn't use this feature yet. > > Regards, > Anand > -- > 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 -- 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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
Am Fri, Oct 21, 2022 at 01:21:36PM +0200 schrieb Borja Marcos:
> But tell your customer that their email message didn’t arrive on time because
> the recipient has a misconfigured DNS server and
> try to explain to them that, yes, Google resolved it successfully but you are
> working for the common good.
+1
While it's possible to enter those bad apples with a server{} statement in
named.conf, this reactive approach is not always feasible. In our cases this
week some mail bounced, since our MTAs could not resolve some domainnames and
customers obviously don't like that, which triggered some support cases etc.
After further analysis of our logs the problem probably really is not all that
big, just very few names where not resolvable. Nonetheless, we've decided to
leave one of resolvers at 9.16 for now as a "last resort" for those faulty
names, and the other resolvers continue to run fine with 9.18.
If I can find a few definite way to easily identify these bad apples from our
resolver logs, I might notify the operators. I guess https://ednscomp.isc.org/
already has a way more comprehensive view on the issue and therefore better
data for such notifications though ;-)
--
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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
On 21/10/2022 14:04, Hugo Salgado wrote: But wasn't it exactly the idea with the 2019 DNS Flag Day campaign? http://www.dnsflagday.net/2019/ I see Google's name there, so I would expect their commitment to refuse to solve incorrect domains. They do a skinny favor to all the Internet by returning to the workarounds, and blaming those who do well (as Bind 9.18) I wouldn't blame Google so quickly. The servers we're discussing in this thread return FORMERR when the query has the COOKIE or NSID options. DNS cookies are recommended (RFC uses "should") rather than mandated. Now, if the Google resolver simply isn't sending these options, then it is not affected. Similarly, a resolver like Unbound (which as far as I know doesn't send cookies yet), will also not be affected. While DNS cookies are not mandatory, it's not fair to point a finger at a resolver that doesn't use this feature yet. Regards, Anand -- 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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
> > On 21 Oct 2022, at 12:23, Ondřej Surý wrote: > > > > What you are really saying that we should dance how tech giants whistle, > > and I don’t think succumbing to tech giants is a good strategy long term. > > Not at all and I agree with you. > > But tell your customer that their email message didn’t arrive on time because > the recipient has a misconfigured DNS server and > try to explain to them that, yes, Google resolved it successfully but you are > working for the common good. > > But wasn't it exactly the idea with the 2019 DNS Flag Day campaign? http://www.dnsflagday.net/2019/ I see Google's name there, so I would expect their commitment to refuse to solve incorrect domains. They do a skinny favor to all the Internet by returning to the workarounds, and blaming those who do well (as Bind 9.18) Hugo signature.asc Description: PGP signature -- 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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
> On 21 Oct 2022, at 12:23, Ondřej Surý wrote: > > What you are really saying that we should dance how tech giants whistle, and > I don’t think succumbing to tech giants is a good strategy long term. Not at all and I agree with you. But tell your customer that their email message didn’t arrive on time because the recipient has a misconfigured DNS server and try to explain to them that, yes, Google resolved it successfully but you are working for the common good. I know! Borja. -- 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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
What you are really saying that we should dance how tech giants whistle, and I don’t think succumbing to tech giants is a good strategy long term. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 21. 10. 2022, at 10:50, Borja Marcos wrote: > > A wider consensus is needed. -- 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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8
> On 21 Oct 2022, at 03:51, Mark Andrews wrote: > >> >> Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be able to find all EDNS0 incompatible servers and loosing customers to 8.8.8.8 - which is able to resolve these names.. >>> This is kind of moot argument - the DNS needs to evolve, and it can't >>> evolve if we keep supporting broken stuff. This needs to be fixed on the >>> authoritative operator side, not in BIND 9. >> >> You're absolutely right. I guess I've just kind of given up on convincing >> other people the fix their stuff (dayjob trauma). Sorry about that. > > It’s also a very small percentage of servers that are broken. If you look at > the time series > on https://ednscomp.isc.org/ you can drill done and see the values. For > example there are a > little over 10 servers for all zones in .GOV that exhibit this broken > behaviour. It’s gone > from ~11% in 2014 to 0.26% currently. We are at the mop up stage. For some > other populations > we are at 0%. > > The EDNS specification was updated in April 2013 to specify some unspecified > behaviour. In > particular this was added. While I hearfully agree with the need to polish the network, some measures can be a problem unless there is a really big commitment from the Big Guns. In my case I had to abort an upgrade to 9.18 on our recursive servers because, well, “Google DNS worked better than ours” going back to 9.16. I know it´s the same situation that happened when Internet Explorer “successfully” rendered all kinds of abominations while proper web clients barfed (with good reason!) and I also know that lousy formats and lack of respect for standars are the breeding ground of serious security incidents. End of rant: A wider consensus is needed. Borja. -- 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
