<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 4/12/24 05:13, Petr Špaček wrote:<br>
<blockquote type="cite" cite="mid:a8ab7ded-cfae-49cd-95e6-16339556729a@isc.org">On 11. 04.
24 6:15, Stephane Bortzmeyer wrote:
<br>
<blockquote type="cite">On Tue, Apr 09, 2024 at 01:09:20PM -0500,
<br>
David Zych <a class="moz-txt-link-rfc2396E" href="mailto:dmrz@illinois.edu"><dmrz@illinois.edu></a> wrote:
<br>
<br>
<blockquote type="cite">The problem: when queried for a record
underneath ag.gov. which does
<br>
not exist, these nameservers do not return a proper NXDOMAIN
<br>
response; instead, they don't answer at all.
<br>
</blockquote>
<br>
Funny enough, it depends on the QTYPE.<br>
</blockquote>
</blockquote>
<br>
Answering QTYPE=NS queries may be a new development; thanks to
Victor's suggestion I was able to reach someone using the SOA RNAME
address, and their first reply on Apr 10 was "The reported issue of
the domain "www.[.]tucson[.]ars[.]ag[.]gov" (formatted to avoid url
protection) not resolving has been corrected." It might be that
this is the thing they changed; I'm not sure.<br>
<br>
Our continued back-and-forth discussion about the importance of
NXDOMAIN responses in general is ongoing.<br>
<br>
It's also funny to me that the exact same nameservers do answer `dig
+norec @ns1.usda.gov thissubdomaindoesnotexist.usda.gov a` (for
usda.gov instead of ag.gov)<br>
<br>
<blockquote type="cite" cite="mid:a8ab7ded-cfae-49cd-95e6-16339556729a@isc.org">
<blockquote type="cite">
<blockquote type="cite">The practical trouble this causes has to
do with an increasingly popular DNS privacy feature called
QNAME Minimization, which depends upon authoritative DNS
servers like yours responding in a standards-compliant way to
queries like
<br>
<br>
_.ag.gov IN A
<br>
_.ars.ag.gov IN A
<br>
_.tucson.ars.ag.gov IN A
<br>
</blockquote>
<br>
More fun: the previous version of QNAME minimisation used
QTYPE=NS. It
<br>
then changed to QTYPE=A precisely to work around broken
<br>
middleboxes. (And also to avoid sticking out.)
<br>
</blockquote>
<br>
This is not only in violation of
<br>
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/rfc8906">https://datatracker.ietf.org/doc/html/rfc8906</a> but it is an
outright security issue because it allows attackers to mess up
load balancing in resolvers. See
<br>
<a class="moz-txt-link-freetext" href="https://indico.dns-oarc.net/event/47/contributions/1018/attachments/959/1802/pre-silence-not-golden-dns-orac.pdf">https://indico.dns-oarc.net/event/47/contributions/1018/attachments/959/1802/pre-silence-not-golden-dns-orac.pdf</a><br>
I predict you have much better chance getting this fixed if you go
through respective CERT team and point them to this presentation.</blockquote>
<br>
Thanks, that's a great link and I will be sure to include it in my
next reply to the authoritative nameserver operator. (It does
appear that someone considers the status quo posture a "security
protocol", so hopefully they will see this as a compelling
argument.)<br>
<br>
<blockquote type="cite" cite="mid:a8ab7ded-cfae-49cd-95e6-16339556729a@isc.org">
Answering before some asks: No, we are not going to workaround
this in BIND resolver. It has to be fixed on the auth side. This
is not a security bug in BIND. See
<br>
<a class="moz-txt-link-freetext" href="https://bind9.readthedocs.io/en/latest/chapter7.html#dns-resolvers">https://bind9.readthedocs.io/en/latest/chapter7.html#dns-resolvers</a><br>
</blockquote>
<br>
I certainly would never suggest that it was a bug in BIND, but FWIW:
I would see some value in being able to configure `<code class="docutils literal notranslate"><span class="pre">qname-minimization`
within a `server` block.</span></code><br>
<br>
Suppose I as the recursive nameserver operator hypothetically found
myself under pressure from non-technical people to "just make it
work so we can get to the website, this is embarrassing"
(fortunately not the case right now, but it's not hard to imagine in
a higher profile scenario). I could accomplish that right now using
either `<code class="docutils literal notranslate"><span class="pre">qname-minimization</span>
<span class="pre">disabled;` or in this case also (ironically) `</span></code><code class="docutils literal notranslate"><span class="pre">qname-minimization</span>
<span class="pre">strict;</span></code><code class="docutils literal notranslate"><span class="pre">`.
However, a global setting of strict might cause problems
resolving other domains, so realistically my best unilateral
recourse would be to disable minimization completely, even
though that feels like a step backward. Given the choice, I'd
much rather disable it just for two known misbehaving servers
and leave it on for everything else (while in parallel still
reaching out to the authoritative server operator to address the
root cause).<br>
<br>
It seems to me that such a feature would likely also be helpful
when strict eventually does become the default, if a few
authoritative nameservers in the wild still aren't ready
(preferable at that point for recursive server operators to set
relaxed or disabled just for problem cases vs globally).<br>
<br>
Thanks,<br>
David<br>
</span></code>
<pre class="moz-signature" cols="72">--
David Zych (he/him)
Lead Network Service Engineer
University of Illinois Urbana-Champaign
Office of the Chief Information Officer
Technology Services
Under the Illinois Freedom of Information Act any written communication to or from university employees regarding university business is a public record and may be subject to public disclosure.</pre>
</body>
</html>