On Mon, Jun 1, 2015 at 12:25 PM, Ryan S. Brown <ryansb@xxxxxxxxxx> wrote: > On 06/01/2015 01:55 PM, Jason L Tibbitts III wrote: >>>>>>> "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. >> >> 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. > > I don't think so -- when I pull a fresh server image I expect there to > be very little running on it. > > A local DNS resolver would certainly be a surprise to me. Again, this > comes back to the expectation that a server isn't hopping networks or > running somewhere un-trusted where there's a high risk of bad actors. It's not just bad actors. Sometimes things break or you need to reconfigure your upstream resolvers. With a local caching resolver, this Just Works (tm). With the status quo, it requires restarting everything. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
