default local DNS caching name server

[Paul Wouters]

On Sat, 12 Apr 2014, Chuck Anderson wrote:

> Okay, so here is where you and I differ then.  We need a solution to
> run everywhere, on every system, in every use case.

Sounds like wanting ponies? Obviously I fully agree with a solution that
works everywhere, all the time, for everyone, however the want it :)

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

Handling failover requires keeping state of previous queries and
outstanding requests to determine which servers are bad or not. Mind
you, unbound allows you to set a max TTL on any record received using
cache-max-ttl=0, so you can very easilly implement this idea. I think
it is a bad idea, because your solution violates your own principle
above: it interferes with my use case of optimising DNS caches, reducing
unneccessary latency, and doing things like pre-fetching of low TTL
records.

In DNS, the publisher of data tells you how long the data should be valid
for. If they want the record not to be cached at all, they can set the TTL
to 0. Why should we deploy a daemon that does not provide the very useful
feature of caching in general (especially when doing DNSSEC validation)
when people who wish to not get cached already have a means out, publish
records with TTL=0? If you want to be Akamai, you can!

> dnslookupd keeps track of up/down DNS servers via some health check
> mechanism, and switches between them appropriately.

I tend to call heartbeats/keepalives "make deads". They often do the
opposite. Why invent a whole new health check protocol when you can
simple send DNS queries and use strategies to prefer the nearest/fastest
servers already. These kind of selection/preference protocols are part
of any decent DNS implementation. There is no need to re-invent the
wheel.

Paul