Once upon a time, Andrew Lutomirski <luto@xxxxxxx> 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@xxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
