On Sun, Apr 01, 2018 at 09:22:10AM -0700, Stephen Satchell <list@satchell.net> wrote a message of 39 lines which said:
Recursive lookups take bandwidth and wall time. The closer you can get your recursive DNS server to the core of the internet, the faster the lookups.
I think the exact opposite is true: many DNS requests hit the cache, so the important factor is the latency between the end user and the cache. So, local resolvers win.
This is particularly true of mobile and satellite.
Yes, because they have awful latency, it is important to have a local resolver.
(I wonder if the Internet Systems Consortium has considered adding a cache-hit counter, or even a very coarse heat map (say, four 16-bit counters cycled every five minutes), to DNS entries, to figure out the best ones to drop? It would increase the complexity of BIND, but the benefit for a BIND server serving a largish customer population could be significant.
Making the largest and richest services even faster and so increase centralisation? It does not strike me as a good strategy.
I've not personally measured the number of times a look-up could be satisfied from a cache in a production environment;
For instance, at my home: % cache.stats() [hit] => 276089296 [delete] => 5 [miss] => 423661208 [insert] => 18850452
The main reason for *not* implementing recursion exclusively in CPE is that a recursive lookup is a complex operation, and I have my doubts if BIND or equivalent could be maintained properly in, say, a wireless access point (router) -- how would you update a hints table?
There is nothing DNS-specific here: routers/CPE with automatic updates exist for several years (I use the Turris Omnia <https://omnia.turris.cz/en/>). The hints file is the *last* problem: most IP addresses of the root name servers didn't change for more than ten years.