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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
