Am 01.06.2015 um 21:38 schrieb Andrew Lutomirski:
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
it don't cache dns respones - try it out in your local network
*client applications* may cache respones
try it out in your local network
* enter a non existing subdomain in firefox
* add the hostname to your LAN nameserver
* try again: firefox refuses
* restart just firefox
* it resolves without any delay
a) that proves no systemwide cachae
b) it proves with introduce a local systemdwide cache
you introduce a problem not existing before