F23 System Wide Change: Default Local DNS Resolver

Andrew Lutomirski luto at mit.edu
Mon Jun 1 18:30:53 UTC 2015


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.

>
>> Basically, if you have properly functioning DNS on multiple local
>> servers but not having anything fancier like heartbeat-based IP handoff
>> or a load balancing appliance or something, and the first resolver in
>> resolv.conf goes offline, your hosts are screwed.  glibc's resolver code
>> is simply horrible.  This is completely exclusive of DNSSEC issues.
>
>
> if your *LAN* nameservers are going offline you need to solve that problem
> and ask you why....

I would think that avoiding a single point of failure (your LAN
nameserver) would be a *good* thing.

--Andy


More information about the devel mailing list