Hi, did you try writing to elbrev.com <http://elbrev.com/> operators to fix their servers to stop breaking DNS protocol? It often helps. (I'm ccing the contact in their SOA records, so let's see if anything happens.)
It's not lack of EDNS0 support, but they fail to properly process unknown EDNS0 options - DNS Cookie in this specific example: ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 57723 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: ec9c994f850fe500 (echoed) vs ondrej@howl:~/Projects/bind9 (v9_18 $%=)$ bin/dig/dig +norec +noall +comments +nocookie bemacom.se @dns1.elbrev.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16277 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 Their servers are clearly violating existing DNS standards: https://ednscomp.isc.org/ednscomp/11fd9e2e46 <https://ednscomp.isc.org/ednscomp/11fd9e2e46> > 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. Cheers, Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 20. 10. 2022, at 13:09, Andreas S. Kerber <a...@ag-trek.de> wrote: > > I've just finished upgrading our last resolver from 9.16 to 9.18.8 a few days > ago. > As it turn out a number of zones are no longer resolveable with 9.18. Some > nameservers out there don't seem to support EDNS0 and the number of FORMERR > responses in our resolver logs went up quite a bit. Here's an example: > > > zone bemacom.se when querying a 9.18.8 resolver (status: SERVFAIL): > > # dig bemacom.se @213.182.0.X > > ; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25874 > > > zone bemacom.se when querying a 9.16.34 resolver: > > # dig bemacom.se @213.182.0.X > > ; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5496 > > > > The NS for bemacom.se seem to be dnsX.elbrev.com and I'm seeing FORMERR > messages in the BIND 9.18.8 logs: > > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns2.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns2.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns1.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns2.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns1.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns1.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns2.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving > 'dns1.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving > 'dns.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving > 'dns1.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving > 'dns.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving > 'dns1.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving > 'dns2.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving > 'dns.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving > 'dns.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving > 'dns2.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving > 'dns1.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving > 'dns.elbrev.com/AAAA/IN': 92.33.14.98#53 > Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving > 'dns1.elbrev.com/AAAA/IN': 194.17.14.66#53 > Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving > 'dns.elbrev.com/AAAA/IN': 194.17.14.66#53 > > > According to dnscheck.ripe.net the zones NS don't support EDNS0: > https://dnscheck.ripe.net/result/93ee1d56756536dd > > I could manually fix this by adding those IP adresses with a server statement > to named.conf like this: "server x.x.x.x { edns no; };" > Since this is only one a example of about 10 so far, I chose to downgrade one > of my resolvers back to 9.16.X, to catch those faulty zones. > > 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.. > > > > -- > 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
