default local DNS caching name server

Chuck Anderson cra at WPI.EDU
Sat Apr 12 15:53:59 UTC 2014

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

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

dnslookupd listens on

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

More information about the devel mailing list