On Sun, Apr 01, 2018 at 09:22:10AM -0700, Stephen Satchell <l...@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.
