4 ms·

If the root servers and major .tlds would support dns-over-tls every home router could just run a full recursive dns resolver by itself, and we could be done wi

If the root servers and major .tlds would support dns-over-tls every home router could just run a full recursive dns resolver by itself, and we could be done with it. There would be no need for complicated architectures with proxies and stub resolvers, and nobody could see your queries. The root server would just see your NS lookup for .com, the .com would just see your NS query for google.com and the google.com NS would see your query for maps.google.com - but here you are in googles domain anyway, so it does not matter. dns-over-tls would prevent your isp from snooping your queries to the .com/.org/.net/.club/... nameservers and we could close the case.

kbenson 9y ago
Wouldn't that quickly overload all the root servers?
- anon892375 9y ago
  Resolvers should aggressively cache the root zone. And the traffic shouldn't be any worse than what google or cloudflare resolvers are seeing.
  - kbenson 9y ago
    > the traffic shouldn't be any worse than what google or cloudflare resolvers are seeing. 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.
- JdeBP 9y ago
  No. The volume of traffic to the . content DNS servers would be largely unchanged. 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.
  - kbenson 9y ago
    Every ISP offers DNS servers. Those DNS servers cache the requests, usually for hours if not a day, for all the requests they get. 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.
    - JdeBP 9y ago
      That is not the scenario that y0ghur7_xxx proposed. The scenario that y0ghur7_xxx proposed related to the headlined mechanism. What you describe does not.
      - kbenson 9y ago
        > If the root servers and major .tlds would support dns-over-tls every home router could just run a full recursive dns resolver by itself 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?
anon892375 9y ago
That would certainly be an improvement, but not the end of the story. > 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.
- y0ghur7_xxx 9y ago
  That could be a next step. 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.
jiveturkey 9y ago
> The root server would just see your NS lookup for .com, ... That's not how DNS works today so you're asking for a major re-architecture.
- publicarray 9y ago
  >> The root server would just see your NS lookup for .com, ... > 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 https://tools.ietf.org/html/rfc7816 unbound has some nice slides: https://ripe72.ripe.net/presentations/120-unbound_qnamemin_ripe72.pdf https://ripe72.ripe.net/presentations/120-unbound_qnamemin_r...

kbenson 9y ago

Wouldn't that quickly overload all the root servers?

anon892375 9y ago
Resolvers should aggressively cache the root zone. And the traffic shouldn't be any worse than what google or cloudflare resolvers are seeing.
- kbenson 9y ago
  > the traffic shouldn't be any worse than what google or cloudflare resolvers are seeing. 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.
JdeBP 9y ago
No. The volume of traffic to the . content DNS servers would be largely unchanged. 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.
- kbenson 9y ago
  Every ISP offers DNS servers. Those DNS servers cache the requests, usually for hours if not a day, for all the requests they get. 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.
  - JdeBP 9y ago
    That is not the scenario that y0ghur7_xxx proposed. The scenario that y0ghur7_xxx proposed related to the headlined mechanism. What you describe does not.
    - kbenson 9y ago
      > If the root servers and major .tlds would support dns-over-tls every home router could just run a full recursive dns resolver by itself 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?

anon892375 9y ago

That would certainly be an improvement, but not the end of the story. > 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.

y0ghur7_xxx 9y ago
That could be a next step. 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.

jiveturkey 9y ago

> The root server would just see your NS lookup for .com, ... That's not how DNS works today so you're asking for a major re-architecture.

publicarray 9y ago
>> The root server would just see your NS lookup for .com, ... > 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 https://tools.ietf.org/html/rfc7816 unbound has some nice slides: https://ripe72.ripe.net/presentations/120-unbound_qnamemin_ripe72.pdf https://ripe72.ripe.net/presentations/120-unbound_qnamemin_r...