On Mon, Jun 1, 2015 at 1:42 PM, drago01 <drago01@xxxxxxxxx> wrote: > On Mon, Jun 1, 2015 at 9:28 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: >> 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. > > 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. This is glibc we're talking about, though. Have you tried to get a glibc bug fixed? It's not a pleasant experience. For example, the bug I reported has a candidate patch. That patch isn't applied, and the patch looks like the bug might be a security issue. It's been in that state for months. This is not unusual for glibc. Anyway, even on a LAN, the overhead of a network round trip per cacheable DNS query may be non-negligable for some use cases. A local caching resolver fixes that, too. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
