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).