On Sat, Apr 12, 2014 at 11:05:21AM -0400, Paul Wouters wrote: > On Sat, 12 Apr 2014, Reindl Harald wrote: > > >nonsense - there are so much ISP nameservers broken out there > >responding with wildcards and so on that you can not trust them > >and you will realize that if not before after you started to run > >a production mailserver which relies on NXDOMAIN responses for > >proper operations > > That's not what the http://atlas.ripe.net/ data set indicates. Your > story seems anecdotal and incidental. > > Yes, there are a few bad players out there (like Rogers in Canada) but > those are in a minority. That said, I agree that using unbound on your > servers will reduce upstream DNS outage problems on your servers. I > wouldn't run unbound on every VM though. Okay, so here is where you and I differ then. We need a solution to run everywhere, on every system, in every use case. The local DNS daemon (note that I didn't say "cache" this time) should be a part of the Base OS like init/systemd is. It should be small, unobtrusive, and do very little, namely the one thing we need: handle failover between multiple DNS servers. I would use the term "DNS proxy" but that term is too overloaded with other connotations and preconceived ideas. All the other stuff is great, but it should run at a higher level and perhaps be optional like you say. You may not want DNSSEC validation in every VM, or indeed on every server in a corporate datacenter. But you still do need the local DNS daemon to handle failover ONCE for the entire system, rather than the way glibc does it now PER PROCESS. I omitted "cache" from my description of the local DNS daemon this time around, because after thinking about it more, once you introduce a cache you have to deal with flushing that cache and that complicates things perhaps more than people are willing to accept. Having a cache is not required to handle the most basic failover functionality. This local non-caching, non-recursive stub DNS daemon could sit in front of, behind, or beside (in place of) other optional full DNSSEC/caching/VPN-aware solutions. For the purposes of this example, lets call this theoretical daemon "dnslookupd": resolv.conf is configured with 127.0.0.1. dnslookupd listens on 127.0.0.1:53. dnslookupd is configured with one or more DNS servers (which could be local daemon(s) on other loopback addresses or ports). dnslookupd keeps track of up/down DNS servers via some health check mechanism, and switches between them appropriately. dnslookupd does not cache any results--it simply forwards the queries to one chosen DNS server. dnslookupd provides an API for other components to configure the list/order of DNS servers (perhaps dbus). -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
