I'm a little confused by the "sky is falling" tone of all this. I'm pretty sure that the browser fetish for "search and URLs in the same box!" is pretty high up on the root server pain scale; on any given day .belkin/.cisco can be one of the top 10 NXDOMAIN TLDs (at least as of a couple of years ago); search lists are another source of noise (which doesn't always make it to the roots).
It's not just quantity, there is also leakage occurring. My recent brain fart regarding how to turn off the real queries in BIND when something (typically generated because of a search list) is caught by an RPZ is a case in point. (This particular use case is to catch noise from stuff which could be generated from search lists; it's a good use case IMO for RPZ to generate NXDOMAIN responses locally.) Or, look in your passive DNS for 127.0.53.53. I use DNS, the technology, as a distributed key/value store occasionally; there is no reason I should have to point it at a tree with ICANN's roots whatsoever, but for applications which need to be connected to ICANN's world that can be the past of least resistance. Seems to me that if some datacenter is doing beellions of DNS lookups to DNS as a K/V store some caching for hits as well as NX must be occurring, seems insane for that not to be the case. I'm trying to imagine scenarios where those beellions of queries would leak out to the root servers, or to any servers and none of them look sane to me (transport ain't free at scale). My biggest concern for the sane cases would be information leakage, such as the fingerprinting of machines via AV software doing hash lookups via The DNS; just an example. There are too many borked configurations to enumerate them all. The most plausible architecture I come up with, perhaps unsurprisingly the one I would suggest in the absence of explicit mitigating factors, would be a caching resolver running on the same switch, if not the same machine, as the application generating the queries. I might secondary the zone there. Or I might just set it up as a static-stub or forward. What are the possible failure modes in this scenario? The application is configured to use the wrong DNS server: this is not a simple failure, it has to be configured to use a resolver or nothing resolves; if it's an authoritative then queries for what's not in bailiwick there are (hopefully) refused or referred back to the stub resolver (which won't follow them because it's RD not recursing itself), all of them, not just ones from the K/V store and it's going to look really really broken; if it's 8.8.8.8 then surely gmrgle caches the NX response from the root for the bogus TLD; if it's the corporate caching resolver the same (plus I expect the phone to ring). The query generates a legitimate NX response from the zone: that should be the end of it (that's how DNSBLs work); if search list processing occurs, I'm wondering how one got configured but more than that how this solution made it into production (if I was writing the app, I'd probably eschew reliance on the operating system stub resolver for this particular use case entirely). The app is misconfigured not to use the correct domain (for the K/V domain): if it's the wrong domain (or none at all) it doesn't matter whether the "correct" domain is legitimate or locally concocted. Any others? I just don't see how beellions of queries are going to get directed at the roots or any auth server, regardless of what the TLD is, or if that occurs that the choice of TLD mitigates in any fashion whatsoever. There's always a way to make it happen, I just can't imagine it making it sanely into production even by accident. (This applies to DLV.ISC.ORG too, which returns an SOA, but they could make it NX if it suited their purposes.) Quizzically... -- Fred Morris On 9/10/20 10:57 PM, Rob McEwen wrote: > Mark, > > You gave me the "let them eat cake" answer I anticipated. Also, this > isn't fixing a problem that my services produce - it is preventing a > problem that a potential MISTAKE from a large customer would cause - > the type of mistake that is inevitable at some point, but likely > short-lived. That's on them, not me. But I can sleep well at night > knowing that such MISuse of my service isn't going to take out an > entire datacenter for hours (with MANY innocent bystanders taken out, > too!) with a DOS attack due to those queries NOT ending with a > valid/public domain name, thus making such an attack impossible. > (again, just referring to our very largest customers' DNSBL queries). > [...] > > On 9/11/2020 1:32 AM, Mark Andrews wrote: >>> On 11 Sep 2020, at 15:04, Rob McEwen <r...@invaluement.com> wrote: >>> >>> Mark, >>> >>> The whole usage of DNS by the anti-spam industry in our DNSBLs - is >>> somewhat a hack on the DNS system from the start - I guess if you >>> think that is wrong, maybe you should take that up with Paul Vixie? >> And Paul will tell you to use a name you control. We did that with >> DLV.ISC.ORG. We are still absorbing that traffic despite there being >> no entries in the zone for several years now. We knew we would have >> to do that going in. >> >>> And the whole purpose for MANY of us DNSBLs using ".local" in the >>> first place - was precisely to PREVENT the queries from possibly >>> leaking out of our largest customers LANs - because in many cases, >>> that would an essential denial of service attack against us (and our >>> hosters, etc). [...] _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users