default local DNS caching name server

[Chuck Anderson]

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