You could just run a recursive resolver yourself by using the root hints. You don't need to delegate your DNS queries onto a third-party resolver like Quad9.
Thanks for that, appreciated. I'll be honest- I'm just a 'little guy' in the food chain so I always figured that doing something like that was for the ISP level folks <edit to clarify, I mean connecting to a Zone 1 Resolver. I wasn't aware that one could download the Root Hints File directly (Thanks!).
One quick question though - After taking a quick skim of it the list seems to be extremely 'Western-Centric' (reference link https://www.internic.net/domain/named.root)
The root servers are anycasted.
Each one of those root server IPs corresponds to N physical servers at diverse networks / locations all over the world.
> I'm just a 'little guy' in the food chain so I always figured that doing something like that was for the ISP level folks
A lot of people are running recursive resolvers at home (like pi-hole stuff, or most people running some custom openwrt router/modem). I'm running one on my laptop (my resolver is localhost) and it works great.
> After taking a quick skim of it the list seems to be extremely 'Western-Centric'
It is, but that's what the internet is. But by running your own recursive resolver you can control your cache and a lot of the data doesn't change often. If you're extra paranoid you can cache the record data (or even archive the history) for ccTLD (or even all TLDs). For stuff (domains) you're interested in you can also hard-code or otherwise program "non-standard" ways to resolve the ips (by somehow populating a local database that overrides recursive resolution), like pi-hole/safebrowsing blocklists, stuff from institutions or CDNs you trust.
They are western centric, and unfortunately, in this current state of the web they're still essentially the authority on DNS.
Alternatively, you can maintain the NSes for all the TLDs you are particularly interested in, and alert yourself if they change to something you don't recognize.
Finally, keep in mind that whatever you do, you need to have multiple vantage points to the internet. There's not a lot stopping your ISP from not delivering you to the right host when you try to talk to it. E.g. your ISP can fake the DNS responses.
Questioning why the distributed cluster runs on nodes 'a' and 'b' alone doesn't necessarily imply that nodes 'c', 'd' and 'e' are any better or worse, today or in future.
DNS[0] is only a decentralized hierarchy with caching, a class of system which pre-dates the digital era as the de-facto means of political and military organization in any human society larger than a village or town. DNS as a directory system for IP is could itself be viewed as a direct philosophical descendant of military insignia (perhaps via the then-popular branch-tangent of the telephone book, itself ex-telegraph, and postal system) and these could all be in effect traced back to at least Roman society[1], I don't think arguing this is a "western" invention is very convincing or useful. Any ancient army or polity of any size would have had an equivalent, which would then include ancient Egypt, China[2], India, Mesopotamia[3], Mesoamerica, etc. Actually, come to think of it, the comparative study of ancient postal systems would be pretty interesting.[4]
> I don't think arguing this is a "western" invention is very convincing or useful. Any ancient army or polity of any size would have had an equivalent, which would then include ancient Egypt, China[2], India, Mesopotamia[3], Mesoamerica, etc.
And yet, none of these other regions and cultures actually did invent it, and thus it remains a Western invention.
Of course. However, my point was the originality and claim to authorship is low, because if you look at store and forward networks with centrally agreed node identification and local caching using that for routing purposes, humans have literally done it globally for 3000+ years... that's clear prior art.
It's like "technology" being used to describe a bash script, or "invention" used to describe a standard algorithm.
By that same token the internet was invented by the first person to hand gesture to another one. You can’t dilute DNS down to a directory because there were/and are already other directory protocols.
The way I handle this is to run unbound on a server in the public cloud and then tunnel over TLS from my local unbound to the cloud instance. My local clients query a PiHole, which forwards to unbound on localhost:15353, which forwards everything over TLS to the fully recursive instance of unbound in the cloud, which uses root.hints.
How is the latency for such a setup? And how is the general browsing experience with said latency (I realize it also depends on which sites you frequently access)? I see some cloud providers/CDNs using a caching TTL as low as five minutes.
As you can see most of queries are completed in a way below 500ms. Adding another 20-40ms on top that doesn't change anything, because caching is a thing and with Unbound you can even ask to actually refresh the expiring records, so you would be served a fresh one from the cache every time, though I never bothered with it, it works fine even without it.
In addition to the root hints, you should also download the DNSSEC anchor key (available on the same site as the root hints). That will let you detect manipulations of records that are DNSSEC-signed.
Otherwise, you could spin up your recursive resolver on your cloud, VPS, or other hosting provider of choice, and then use that.
Right, DNSSEC will solve the "manipulate" problem, but it won't solve the "see" problem. But whether that's a concern is up to you. You could run your resolver on a VPS and speak DoT / DoH to that, which shifts the leak from your ISP to your VPS provider.
It doesn't solve the "manipulate" problem we're talking about here, either: nothing about DNSSEC prevents a DNS server (or middlebox) from denying results to a disfavored domain; it only (situationally) prevents them from redirecting it somewhere else. (And, of course, it only works if you're running your own recursive server; it does nothing whatsoever in the 8.8.8.8-type use case).
In theory if you got a resolver which could disable UDP queries, it would then default to TCP, and the ISP couldn't manipulate those. Don't know if any resolver supports disabling UDP though.
Unbound as a client will fall back to TCP automatically if the UDP response is too big. I'm uncertain if there is widespread support for TCP servers though.
One quick question though - After taking a quick skim of it the list seems to be extremely 'Western-Centric' (reference link https://www.internic.net/domain/named.root)