FORMERR responses after upgrading resolver from 9.16 to 9.18.8

[Andreas S. Kerber]

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..