On 4/12/24 05:13, Petr Špaček wrote:
On 11. 04. 24 6:15, Stephane Bortzmeyer wrote:
On Tue, Apr 09, 2024 at 01:09:20PM -0500,
David Zych <d...@illinois.edu> wrote:
The problem: when queried for a record underneath ag.gov. which does
not exist, these nameservers do not return a proper NXDOMAIN
response; instead, they don't answer at all.
Funny enough, it depends on the QTYPE.
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.
Our continued back-and-forth discussion about the importance of NXDOMAIN
responses in general is ongoing.
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)
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
_.ag.gov IN A
_.ars.ag.gov IN A
_.tucson.ars.ag.gov IN A
More fun: the previous version of QNAME minimisation used QTYPE=NS. It
then changed to QTYPE=A precisely to work around broken
middleboxes. (And also to avoid sticking out.)
This is not only in violation of
https://datatracker.ietf.org/doc/html/rfc8906 but it is an outright
security issue because it allows attackers to mess up load balancing
in resolvers. See
https://indico.dns-oarc.net/event/47/contributions/1018/attachments/959/1802/pre-silence-not-golden-dns-orac.pdf
I predict you have much better chance getting this fixed if you go
through respective CERT team and point them to this presentation.
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.)
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
https://bind9.readthedocs.io/en/latest/chapter7.html#dns-resolvers
I certainly would never suggest that it was a bug in BIND, but FWIW: I
would see some value in being able to configure `|qname-minimization`
within a `server` block.|
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
`|qname-minimization disabled;` or in this case also (ironically)
`||qname-minimization strict;||`. 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).
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).
Thanks,
David
|
--
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.
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
