On Mon, Jun 1, 2015 at 11:02 AM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: > > Am 01.06.2015 um 19:55 schrieb Jason L Tibbitts III: >>>>>>> >>>>>>> "RSB" == Ryan S Brown <ryansb@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
