[prev in list] [next in list] [prev in thread] [next in thread]
List: bind-users
Subject: Re: DNS Cookies Causing FORMERR
From: Justin Krejci <JKrejci () usinternet ! com>
Date: 2023-01-16 16:40:26
Message-ID: 6e326f5c08de4657967742eebe3b0f95 () usinternet ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
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@isc.org>
Sent: Friday, January 6, 2023 2:57 PM
To: Justin Krejci
Cc: bind-users@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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} \
--></style> </head>
<body dir="ltr">
<div id="divtagdefaultwrapper" \
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" \
dir="ltr"> <p>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. :/</p>
<p><br>
</p>
<p><br>
</p>
<p>Thanks for the feedback.</p>
<p><br>
</p>
<p><br>
</p>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" \
style="font-size:11pt"><b>From:</b> Mark Andrews <marka@isc.org><br> \
<b>Sent:</b> Friday, January 6, 2023 2:57 PM<br> <b>To:</b> Justin Krejci<br>
<b>Cc:</b> bind-users@lists.isc.org<br>
<b>Subject:</b> Re: DNS Cookies Causing FORMERR</font>
<div> </div>
</div>
<div>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. <div><br>
</div>
<div>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. </div> <div><br>
</div>
<div>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. </div> <div><br>
</div>
<div>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. <br>
<div dir="ltr">--
<div>Mark Andrews</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">On 7 Jan 2023, at 06:50, Justin Krejci \
<JKrejci@usinternet.com> wrote:<br> <br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; \
font-family:Calibri,Helvetica,sans-serif"> <p></p>
<div>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.</div>
<div><br>
</div>
<div>Example progrowth.com name severs.</div>
<div><br>
</div>
<div>Individual work arounds on caching BIND servers are not difficult to implement, \
like this</div> <div><br>
</div>
<div>server 47.206.74.18 {</div>
<div> send-cookie no;</div>
<div>};</div>
<div>server 209.131.228.178 {</div>
<div> send-cookie no;</div>
<div>};</div>
<div><br>
</div>
<div><br>
</div>
<div>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.</div> <div><br>
</div>
<div>In this article @ https://kb.isc.org/docs/aa-01387 it states near the \
bottom</div> <div><br>
</div>
<div>"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." </div> \
<div><br> </div>
<div>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.</div> <div><br>
</div>
<div>My caching servers are running the BIND 9.18 branch</div>
<div><br>
</div>
<div>Thanks for any pointers or suggestions.</div>
<div><br>
</div>
<div>-Justin</div>
<p></p>
</div>
<span>-- </span><br>
<span>Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from \
this list</span><br> <span></span><br>
<span>ISC funds the development of this software with paid support subscriptions. \
Contact us at https://www.isc.org/contact/ for more information.</span><br> \
<span></span><br> <span></span><br>
<span>bind-users mailing list</span><br>
<span>bind-users@lists.isc.org</span><br>
<span>https://lists.isc.org/mailman/listinfo/bind-users</span><br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>
--
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
--===============8362769771267832022==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic