F23 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 01.06.2015 um 21:38 schrieb Andrew Lutomirski:
> On Mon, Jun 1, 2015 at 12:29 PM, Chris Adams <linux at cmadams.net> wrote:
>> 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).
>
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150601/ec3ffebd/attachment.sig>