Other than some small edge cases, this is pretty much the most secure and fastest DNS performance you will have, in most instances getting about 1 or <1ms speed. Depending on DNS server you can even have both root servers and resolver configured.
I have been using unbound for at least 4 years. Simple and fast.
It is also very easy to do this with dnsmasq or powerdns, djbdns, etc.
I'm increasingly beginning to think that every node should be it's own dns so it's cache blacklist can be verified (checksums?) per node instead of per request to the dns provider.
BIND is the industry standard - but insanely overkill for your use case. Unbound is very easy and lightweight. Dnsmasq is another option, but I don't think you can setup root server with it.
There is 2 main different ways, one which does what you say - the other i'd say is pretty much OK.
If your local DNS server is merely querying an upstream resolver (like 1.1.1.1 / 8.8.8.8) on your behalf, then yes - it is no different.
If however, you query the root nameservers for the glue record for a domain and query the domain's own nameservers directly, then it is pretty good... As you are neither querying your ISP or TheMan.. which means that logically only the domain nameserver owner knows what queries you made (and you are probably hitting that domain in a moment anyway!). (The caveat is that some ISP's do transparent DNS proxying.. in which case, you have much larger trust issues with your ISP and need to take greater measures!)
> (The caveat is that some ISP's do transparent DNS proxying.. in which case, you have much larger trust issues with your ISP and need to take greater measures!)
I once had an ISP which did transparent http proxying. You could theoretically query an external DNS server and get back the correct result, but it would intercept your http connection, discard the ip address you were trying to connect to then do a new DNS lookup to the ISP's DNS server on the HOST header.
Took me ages to work out what was going on with the various issues it was causing.
I dumped that ISP like a rock after they refused to disable that caching proxy, which they claimed was only there to improve customer experience.
Virgin Media in the UK appear to do this for sites they are ordered to block. Even if you get the right DNS response, you get forwarded to http://assets.virginmedia.com/site-blocked.html (HTTPS requests get a connection reset).
They don't need to be doing DNS proxying, they can just inspect port 53 traffic -- unless the site you're visiting supports DNS over TLS, then you're not hiding anything from your ISP, since they'll see the DNS query packet hitting the www.porn-site.com nameserver.
However, if have a local TLS nameserver, you can set it up to query 1.1.1.1 over TLS, then your ISP can't see any of your DNS queries.
So you need to decide who you trust more -- your ISP or a DNS provider (or a VPN provider).
> only the domain nameserver owner knows what queries you made (and you are probably hitting that domain in a moment anyway!)
But these are different people, with different incentives. The NS owner may be logging everything, without the domain owner's knowledge, and the NS owner won't even be in the wrong, because they likely made no promise to not log.
With a single resolver, I can verify that they're trustworthy enough [for me], just once, and direct all my traffic to it. Cloudflare's "We committed to never writing the querying IP addresses to disk and wiping all logs within 24 hours" is something, I imagine, they very much wouldn't want to be caught violating or changing their mind about later.
In the meanwhile, with the root NS method, I can only hope that my queries will get lost in the "noise". And I'm putting noise in quotation marks because there isn't much diversity in the name server ownership: 75% of Alexa top 1M domains are hosted at Cloudflare, GoDaddy and Amazon. [0]
With QNAME minimalisation, RFC7129 (Authenticated denial of existence) and RFC8020 (NXDOMAIN: There really is nothing underneath), you should be sending almost nothing to the root servers of use.
QNAME minimalisation will only send <randomstring>.com to the root for them to give you the referral.
and RFC7129/RFC8020 mean that when you get a NXDOMAIN back from the root, you'll cache it and never try again for a large swath of possible names.
QNAME minimization just minimizes the name to one label under a delegation, there's no randomization. So root zone would only get 'com.' (and type NS). It's unfortunately easy for authoritative servers (below TLD level) to bypass it by returning NXDOMAIN. Resolver has to fall back on using a full name. The main reason is that a lot of authoritative DNS servers (notably Akamai) return NXDOMAIN when there's nothing under the minimized name, but there is something below it (aka empty non-terminal). So without workarounds the resolver would return NXDOMAIN early instead of retrying with the full name.
Okay, say, 1 year from now, somehow, 95% of internet users are sending their DNS queries to Cloudflare. What can go wrong? Malicious or not. Not rhetorical, actually curious.
