F23 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski:
> On Mon, Jun 1, 2015 at 11:02 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>>
>> Am 01.06.2015 um 19:55 schrieb Jason L Tibbitts III:
>>>>>>>>
>>>>>>>> "RSB" == Ryan S Brown <ryansb at redhat.com> writes:
>>>
>>>
>>> RSB> I disagree; for server & cloud deployments it doesn't make sense to
>>> RSB> duplicate a DNS server on *every* host, and if you care about
>>> RSB> DNSSEC you likely already run a trusted resolver.
>>>
>>> I disagree generally in the case of server deployments.
>>>
>>> Having a local caching resolver is pretty much essential, even though we
>>> all know it's just a workaround for glibc.
>>
>> no it is not in case of a serious server setup - period
>
> 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

i never saw glibc caching any dns response, at least on Fedora, new 
subdomains are working from the moment they are provisioned even if they 
are tried a few seconds before

on Apple clients you need to flush the local cache

so with setup a dns cache on each and every machine you fuckup your 
network because you introduce the same negative TTL caching affecting 
OSX clients for years now

no, thanks, not for static configured servers and even not for 
workstations running inside a relieable company network

and for "avoiding a single point of failure (your LAN
nameserver)" - in a proper network it don't fail - never

-------------- 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/276e5faa/attachment-0001.sig>