[dns-operations] ag.gov not providing NXDOMAIN responses

[David Zych]

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 <dmrz at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20240412/a3f62353/attachment.html>