Thaths,
* Thaths ([email protected]) [120327 11:37]: > On Tue, Mar 27, 2012 at 11:21 AM, Jon Cox <[email protected]> wrote: > > > If a few 100ms delays end up being done > > serially it can be a pretty big deal. > > > > Yes. But most OS resolvers are smart enough to cache DNS lookups, if not > the record's full TTLs, at least enough to not have to look up the same > host multiple times when downloading IMG and SCRIPT SRCes. There are a few places where DNS values records can be cached; some of these caches are rather small by default, which means stuff gets kicked out before the TTL is over. These "extra" caches include: o browsers - On some versions of firefox, you get around 20 by default. See about:config and look at Network.dnsCacheEntries o OS - On various flavors of Windows, see registry values under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters (default hash table size: 384) - On linux, you might be using nscd, pdnsd, or whatever else. o Proxy servers > > Rather than use someone else's server for > > recursive resolution, I prefer to just > > run tinydns+dnscache locally. > > > > Quis custodiet ipsos custodes? > > Even with tinydns and dnscache, your upstream DNS might be brain dead? > Verizon and Comcast (two large, popular ISPs hereabouts) have gotten into > the annoying habit of trying to monetize NXDOMAINs. No -- that's part of the beauty of using dnscache ! Rather than have your ISP do the recursive resolution, dnscache handles it. For dnscache to fail, *all* the root servers would need to be down, in which case everybody on the net would be completely hozed anyway. Using dnscache makes DNS failures & brownouts at your ISP completely irrelevant! By default dnscache gives you a 1M cache, which is configurable via /service/dnscache/env/CACHESIZE and even gives you tools to see how effective it is (see: http://cr.yp.to/djbdns/cachesize.html ). I hope this helps, -Jon -Jon
