--- Begin Message ---
On Fri, Apr 12, 2024 at 3:10 PM David Zych <d...@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 <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).
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@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
--- End Message ---
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
