[bind10-dev] resolver performance research, take 2

Robert Edmonds edmonds at isc.org
Tue Jul 17 17:48:36 UTC 2012


JINMEI Tatuya / 神明達哉 wrote:
> At Tue, 17 Jul 2012 09:45:51 +0200,
> Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:
> 
> > Currently, does any stub resolver keep a cache or something?
> 
> MacOS X (apparently) does.  I guess it's the same for iOS.  I don't
> know about Windows, which probably matters most in this context.  So
> reducing it too aggressively is probably a bad idea.

google chrome will probably account for a significant amount of stub
resolver traffic in the near future:

    https://plus.google.com/103382935642834907366/posts/FKot8mghkok

    So what is Chromium doing about the various issues? After a long
    time of being unwilling to sink our time into it, we're going to
    implement our own DNS stub resolver. It sucks that we have to write
    this code and get it to work on all platforms and lose OS caching,
    but the browser is an increasingly important application, almost its
    own OS (especially with ChromiumOS), so it makes sense to do it.
    We've got an experimental DNS stub resolver implemented and are
    working on implementing features and flushing out bugs with it right
    now (--enable-async-dns).

i think with an integrated stub resolver and its existing DNS caching,
chrome would count as a caching stub resolver.  there are also odd
things like nscd or nss-ubdns <https://github.com/edmonds/nss-ubdns>
that might qualify as caching stub resolvers, but their userbases are
comparatively tiny ;)

-- 
Robert Edmonds
edmonds at isc.org


More information about the bind10-dev mailing list