F23 System Wide Change: Default Local DNS Resolver

[Chuck Anderson]

On Mon, Jun 01, 2015 at 09:31:14PM +0200, Reindl Harald wrote:
> 
> Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski:
> >I would think that avoiding a single point of failure (your LAN
> >nameserver) would be a *good* thing
> 
> and your holy one and only resolver on localhost is not a single
> point of failure? in fact it would take much longer to recognize a
> failing and exclusive local resolver on 2 out of 1000 servers why it
> gets visible from the first second if your central nameservers have
> problems
> 
> and BTW glibc has no problem with the first nameserver in
> /etc/resolv.conf failing as long as the slave responds, it may take
> a little time but that don't matter as long as we are not talking
> about a incoming mail exchanger

I'm sorry, but saying that "it may take a little time" is a
non-starter.  For anyone who says this, I challenge you to set your
system's resolv.conf so that the first listed nameserver is a
completely offline IP address, and the second/third listed ones are
your normal nameservers.  Note that the first one must be completely
offline, not an IP that is "up" but just doesn't have a listening
nameserver, but an IP that is non-existent on your local network.
E.g. if your local network is 192.168.1.0/24, set it to
192.168.1.<unassigned-to-any-host>.  Make sure you can't ping the
unassigned IP.

There are many services that will choke in this sort of configuration.
Not just mail servers, but RADIUS servers, LDAP servers, Samba
servers, web servers depending on the configuration, SSH servers and
clients, etc.  Sure, if you test everything in this exact failure
scenario, you may be able to work around this problem (e.g. turn off
reverse DNS lookups in Apache and sshd, etc.) but if you run a LAN or
data center with many different groups maintaining different systems,
you can't guarantee that everyone has done this sort of rigorous
testing and configurations to avoid problems, if it is even possible
for some services which it may not be.

Of course a localhost resolver is also a single point of failure.  But
the important property is that it is very much FATE SHARED with the
rest of the system.  So when you reboot the system to apply a security
update, it doesn't matter that the localhost resolver is offline,
because the services on that box are offline too.