On Mon, Jun 1, 2015 at 12:29 PM, Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Andrew Lutomirski <luto(a)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).
Glibc caches *something* that enabled the bug I hit. I don't know
exactly what it's trying to cache, but it's certainly stateful.
--Andy