F23 System Wide Change: Default Local DNS Resolver

Chris Adams linux at cmadams.net
Mon Jun 1 19:29:45 UTC 2015


Once upon a time, Andrew Lutomirski <luto at mit.edu> said:
> I'm with Jason here.  Glibc's resolver is amazingly buggy, and things
> break randomly and unreproducibly when this happens.  A good setup
> would have a local resolver and glibc would be configured to cache
> nothing whatsoever.  Then, if you need to perform maintenance on the
> local DNS cache, you can do it by flushing your local resolver rather
> than trying to figure out how you're going to persuade every running
> program to tell glibc to flush its cache.

glibc doesn't have a cache, except each process caching the settings in
/etc/resolv.conf.  That's part of the problem, because there's no way to
cache "first server in resolv.conf is not responding", so each lookup
has to figure that out for itself (many timeouts).

Running a local caching resolver helps in a number of ways.  I prefer to
run unbound, forwarding to the local network's preferred resolvers, with
a low cache-max-ttl (like 1-5 minutes, depending on the server).  That
smooths out the traffic (keeps from requesting the same thing a bunch in
a short time), but still generally keeps you from having to clear a
bunch of caches in an unplanned change situation.

This really helps with some types of servers, such as mail servers
running spam filtering.  They tend to look up the same thing a bunch in
a short period, so caching it locally helps (speeds up local DNS
resolution and keeps from causing load spikes on the network resolvers).

This is in addition to the DNSSEC benefits.
-- 
Chris Adams <linux at cmadams.net>


More information about the devel mailing list