Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski:
On Mon, Jun 1, 2015 at 11:02 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
>
> Am 01.06.2015 um 19:55 schrieb Jason L Tibbitts III:
>>>>>>>
>>>>>>> "RSB" == Ryan S Brown <ryansb(a)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