DNS Cookies Causing FORMERR

[Justin Krejci]

Sounds good. I will just buckle down and stay the course. As I encounter these servers, I have been attempting to reach out to all of the organizations whose DNS servers exhibit this behavior. Some are less responsive than others, as in completely ignored. :/



Thanks for the feedback.



________________________________
From: Mark Andrews <marka at isc.org>
Sent: Friday, January 6, 2023 2:57 PM
To: Justin Krejci
Cc: bind-users at lists.isc.org
Subject: Re: DNS Cookies Causing FORMERR

Really there are very few servers that are broken and the numbers are decreasing.  They are well under 1%. Just contact the few remaining server operators and inform them that they are broken.  It should just be an upgrade to the current version to fix.

The behavior for unknown EDNS options was tightened nearly 10 years ago (April 2013). It was unspecified in the original EDNS RFC and made ignored in in the updated RFC which every vendor should have picked up. At the time some vendors ignored unknown options and others returned FORMERR or NOTIMP or REFUSED. Others just dropped the request. Some returned BADVER.  It was a mess.

There are also implementations that don’t know how to return FORMERR properly.  You don’t echo back the request with rcode set to FORMERR and QR to 1 as that produces broken responses but some implementations do that. Why would you send a message that you don’t understand?  Nowhere is there any instructions to do this.

To send a FORMER you send a DNS message header with rcode set to FORMERR. If you can parse the question section for QUERY copy that into the response. If you understand EDNS you can add an OPT record. Similarly TSIG if appropriate and you support it  Yes you can sign a FORMERR.
--
Mark Andrews

On 7 Jan 2023, at 06:50, Justin Krejci <JKrejci at usinternet.com> wrote:



DNS Servers that do not properly support or properly ignore DNS cookies and instead return FORMERR is annoying. This is not new. However I have been seeing more or perhaps just have more users that are finding more domains that are hosted on authoritative servers with this unfortunate behavior.

Example progrowth.com name severs.

Individual work arounds on caching BIND servers are not difficult to implement, like this

server  47.206.74.18 {
        send-cookie no;
};
server  209.131.228.178 {
        send-cookie no;
};


However this workaround is problematic in terms of ongoing upkeep of this list and the increasing need to add new entries to the list. I'd like to be able to start sending cookies again if the servers begin to operate compliant to the EDNS RFC and I would like to not have to write any tools to remove entries from this list or schedule some regular calendar reminder to check or add to Nagios or whatever. I'd also rather not just globally disable sending of DNS cookies but it is something being considered.

In this article @ https://kb.isc.org/docs/aa-01387 it states near the bottom

"Nevertheless, mishandling of the COOKIE option has been known to cause errors that are fatal to name resolution when the resolver is validating responses coming from a signed zone, and the authoritative server returns either FORMERR or BADVERS, or fails to respond to the query. named treats these answers as if the server does not support EDNS (which it doesn't) so it stops sending any EDNS queries at all, which makes it impossible to get a DNSSEC response back."

This statement indicates this fall-back method is only applicable to signed domains. Is there a knob in BIND to apply this behavior to all domains? Basically, if the authoritative server is behaving incorrectly in this way then enable no-EDNS or no-COOKIE mode in the interest of allowing DNS queries to continue to be answered for the end users.

My caching servers are running the BIND 9.18 branch

Thanks for any pointers or suggestions.

-Justin

--
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/20230116/11cbadd0/attachment-0001.htm>