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