On Mon, Jun 1, 2015 at 12:25 PM, Ryan S. Brown
<ryansb(a)redhat.com> wrote:
> On 06/01/2015 01:55 PM, Jason L Tibbitts III wrote:
>>>>>>> "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.
>>
>> 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.