dns-over-tls would prevent your isp from snooping your queries to the .com/.org/.net/.club/... nameservers and we could close the case.
dns-over-tls would prevent your isp from snooping your queries to the .com/.org/.net/.club/... nameservers and we could close the case.
> the .com would just see your NS query for google.com
This would still create chokepoint for countries or generic TLDs where law enforcement could harvest data. For example they might be interested who visits say eff.org or stormfront.org
We still need to either blind or distribute the TLD NS servers to avoid presenting a singular target.
Having only the nameservers responsible for that zone see the query would already be a huge improvement to what we have now. And with tech that is already available and standardized.
What are you basing that on? How many people do you think are really using Google DNS or Cloudfare DNS? I think even if just Comcast changed their defaults, the root servers would see a order of magnitude more traffic than Google or Cloudfare see.
One of the reasons DNS is hierarchical is for load distribution (and performance). Taking this design principle and all of a sudden throwing it out the window would likely have major consequences for a system that was originally designed and scaled with it in mind.
In the existing system, each cache miss at a caching resolving proxy DNS server begins with a transaction with the . content DNS servers (and thence with each content DNS server for further domains as a series of delegations is followed).
In the proposed system, each cache miss is still only one transation to the . content DNS servers, the difference being that that transaction is encrypted.
For example, at the ISP I worked at for many years, we had ~30,000 customers. As an exmaple, Google specifies a SOa timeout of 10800 seconds (3 hours). Across the 4 resolving nameservers at the ISP, the most times they would request google.com in a day is (24 hours/day / 3 hours cached) * 4 servers. That's 42 requests a day, to service 30,000 people.
If all the customers were requesting it directly, it's a different story entirely. Say 80% of the customers access google regularly through email, or their phones, or whatever. Let's say they do it for an average of 8 hours a day (before work, after work, while sleeping and some random update/email comes in). In this case, the math is (8 hours/day / 3 hours cached) * (30,000 * 0.80). That's 64,000 requests a day to service 30,000 people (even though only 80% are actually visiting that domain).
That's over a thousand-fold increase, but it only gets worse if you look at larger ISPs, like Comcast and AT&T. Now, this is a pretty bad case, but there's plenty of very popular sites that are used by our devices on a regular basis, all day long. Doing direct requests from customer networks instead of using intermediary caching DNS servers is a horrible idea and would cripple the internet as the root servers fell over from massive load.
Emphasis mine. Every home router running its own recursive resolver instead of asking a large shared recursive resolver is exactly what I outlined.
If you interpreted it differently, perhaps you can provide some details as to how you did interpret it rather than just saying I'm wrong?
That's not how DNS works today so you're asking for a major re-architecture.
> That's not how DNS works today so you're asking for a major re-architecture.
Actually that is how QNAME minimisation (on the resolver) works https://tools.ietf.org/html/rfc7816
unbound has some nice slides: https://ripe72.ripe.net/presentations/120-unbound_qnamemin_r...