Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-23 Thread Sandro 

On 23-10-2022 01:18, Crist Clark wrote:

On Sat, Oct 22, 2022 at 3:20 PM Sandro  wrote:
[snip]



Doing favors for the better good does not seem to be in their
dictionary. Look at DNSSEC.



Do you mean signing their domains or their public resolver services?


I was referring to signing their own zones.


https://developers.google.com/speed/public-dns/faq
Does Google Public DNS support the DNSSEC protocol?

Google Public DNS is a validating, security-aware resolver. All responses
from DNSSEC signed zones are validated unless clients explicitly set the CD
flag in DNS requests to disable the validation.

https://developers.cloudflare.com/1.1.1.1/faq/#how-does--work-with-dnssec
How does 1.1.1.1 work with DNSSEC?

1.1.1.1 is a DNSSEC validating resolver. 1.1.1.1 sends the DO (DNSSEC OK)
bit on every query to convey to the authoritative server that it wishes to
receive signed answers if available. 1.1.1.1 supports the signature
algorithms specified in Supported DNSKEY signature algorithms
.



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

2022-10-22 Thread Crist Clark 
On Sat, Oct 22, 2022 at 3:20 PM Sandro  wrote:
[snip]


> Doing favors for the better good does not seem to be in their
> dictionary. Look at DNSSEC.
>

Do you mean signing their domains or their public resolver services?

https://developers.google.com/speed/public-dns/faq
Does Google Public DNS support the DNSSEC protocol?

Google Public DNS is a validating, security-aware resolver. All responses
from DNSSEC signed zones are validated unless clients explicitly set the CD
flag in DNS requests to disable the validation.

https://developers.cloudflare.com/1.1.1.1/faq/#how-does--work-with-dnssec
How does 1.1.1.1 work with DNSSEC?

1.1.1.1 is a DNSSEC validating resolver. 1.1.1.1 sends the DO (DNSSEC OK)
bit on every query to convey to the authoritative server that it wishes to
receive signed answers if available. 1.1.1.1 supports the signature
algorithms specified in Supported DNSKEY signature algorithms
.
-- 
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

2022-10-22 Thread Sandro 

On 21-10-2022 16:53, Ondřej Surý wrote:

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.


That's the conundrum with big tech. If it serves them well, they will 
force others to follow their/the standards.


Doing favors for the better good does not seem to be in their 
dictionary. Look at DNSSEC.





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.


Kudos for biting the bullet. I hope it will trickle down and get the 
mopping done. I'm certainly in favor of reporting over working around 
the issue. But I don't have customers breathing down my neck.


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

2022-10-21 Thread Ondřej Surý 
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

2022-10-21 Thread Andreas S. Kerber 
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

2022-10-21 Thread Anand Buddhdev 

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

2022-10-21 Thread Hugo Salgado 
> > 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

2022-10-21 Thread Borja Marcos 


> 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

2022-10-21 Thread Ondřej Surý 
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

2022-10-21 Thread Borja Marcos 


> 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

Re: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-20 Thread Mark Andrews 


> On 20 Oct 2022, at 22:49, Andreas S. Kerber  wrote:
> 
> Am Thu, Oct 20, 2022 at 01:23:47PM +0200 schrieb Ondřej Surý:
>> did you try writing to 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:
> 
> Hi Ondřej,
> 
> thanks for your quick reply and analysis regarding DNS cookies.
> Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
> regard?
> Honestly I haven't contacted the elbrev.com people (see below).
> 
> 
>>> 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.

   Any OPTION-CODE values not understood by a responder or requestor
   MUST be ignored.  Specifications of such options might wish to
   include some kind of signaled acknowledgement.  For example, an
   option specification might say that if a responder sees and supports
   option XYZ, it MUST include option XYZ in its response.


Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

2022-10-20 Thread Ondřej Surý 
https://bind9.readthedocs.io/en/v9_18_8/chapter9.html?highlight=cookie

--
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:49, Andreas S. Kerber  wrote:
> 
> Am Thu, Oct 20, 2022 at 01:23:47PM +0200 schrieb Ondřej Surý:
>> did you try writing to 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:
> 
> Hi Ondřej,
> 
> thanks for your quick reply and analysis regarding DNS cookies.
> Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
> regard?
> Honestly I haven't contacted the elbrev.com people (see below).
> 
> 
>>> 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.

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

2022-10-20 Thread Andreas S. Kerber 
Am Thu, Oct 20, 2022 at 01:23:47PM +0200 schrieb Ondřej Surý:
> did you try writing to 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:

Hi Ondřej,

thanks for your quick reply and analysis regarding DNS cookies.
Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
regard?
Honestly I haven't contacted the elbrev.com people (see below).


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

2022-10-20 Thread Ondřej Surý 
Hi,

did you try writing to 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 


> 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  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//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
> 'dns2.elbrev.com//IN': 194.17.14.66#53
> Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
> 'dns1.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
> 'dns.elbrev.com//IN': 92.33.14.98#53
> Oct 20 12:46:55

FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-20 Thread 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//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//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