F23 System Wide Change: Default Local DNS Resolver

[Andrew Lutomirski]

On Mon, Jun 1, 2015 at 1:42 PM, drago01 <drago01 at gmail.com> wrote:
> On Mon, Jun 1, 2015 at 9:28 PM, Andrew Lutomirski <luto at mit.edu> wrote:
>> On Mon, Jun 1, 2015 at 12:25 PM, Ryan S. Brown <ryansb at redhat.com> wrote:
>>> On 06/01/2015 01:55 PM, Jason L Tibbitts III wrote:
>>>>>>>>> "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.
>>>>
>>>> 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.
>>>
>>> I don't think it's essential for either the server or the cloud product.
>>> Servers run in a much more reliable network than your average SOHO or
>>> coffee shop setup, and their behavior with regard to DNS doesn't need a
>>> local caching resolver. LAN DNS (probably with split horizon for
>>> DC-internal services) is plenty fast and reliable, there isn't a need to
>>> run a zillion instances of Unbound.
>>
>> I agree it's not essential for a server, but it can be quite helpful
>> to work around glibc bugs.  For example, I've hit
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17802 several times in
>> production.  Yes, that's a glibc bug, and glibc should fix it.
>> Nonetheless, bugs like that wouldn't matter as much if there were a
>> local resolver.
>
> That's not how bugs should be dealt with ... if there is a bug it
> should be fixed where it is not duct taped this way.

This is glibc we're talking about, though.  Have you tried to get a
glibc bug fixed?  It's not a pleasant experience.

For example, the bug I reported has a candidate patch.  That patch
isn't applied, and the patch looks like the bug might be a security
issue.  It's been in that state for months.  This is not unusual for
glibc.

Anyway, even on a LAN, the overhead of a network round trip per
cacheable DNS query may be non-negligable for some use cases.  A local
caching resolver fixes that, too.

--Andy