Am 01.06.2015 um 21:38 schrieb Andrew Lutomirski:
On Mon, Jun 1, 2015 at 12:29 PM, Chris Adams <linux@xxxxxxxxxxx> wrote: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).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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
