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

[Puneet Sood]

On Fri, Apr 12, 2024 at 3:10 PM David Zych <dmrz at illinois.edu> wrote:
>
> 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).

Per nameserver IP settings are convenient and can provide tactical
fixes to a resolution problem.

However they suffer from a big maintenance problem as nameserver IPs
for zones change over time. Also when making a per nameserver config,
did the operator configure it for all the relevant IPs?


>
> 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 at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations