FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Ondřej Surý]

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 at 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)
ondrej at 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 <ask at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221020/935349a2/attachment.htm>