default local DNS failover solution needed, nscd?

Chuck Anderson cra at WPI.EDU
Fri Apr 25 22:51:26 UTC 2014


I'm starting a new thread to clarify and emphasize the problem I'm
actually trying to solve.  Here is the problem restated as I posted it
to the dns-operations list:

-----
Is it really expected that the first DNS server listed in
/etc/resolv.conf should never go down?  Operationally speaking, who
can actually rely on listing multiple nameservers in /etc/resolv.conf
and using libc's failover mechanism in any kind of production server?
Because the failover behavior in libc is atrocious--each new or
existing process has to re-do the failover after timing out, and even
long-running processes have to call res_init() to re-read resolv.conf.
It seems that the only sensible way to run a datacenter (or a network
full of Linux workstations for that matter) is to either:

1. Make sure the first nameserver listed in resolv.conf never goes
   down by using Anycast DNS or some other failover mechanism like
   VRRP or CARP on the DNS server side.

or:

2. Use a local DNS daemon on every server with forwarders configured
   to the network's nameservers, and fix resolv.conf to 127.0.0.1.
-----

(I've since learned that nscd can be a third option)

On Fri, Apr 25, 2014 at 07:19:17PM +0200, Petr Spacek wrote:
> On 25.4.2014 18:19, Simo Sorce wrote:
> >On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote:
> >>On Thu, 10 Apr 2014 10:41:54 -0400
> >>Chuck Anderson <cra at WPI.EDU> wrote:
> >>
> >>>[...]  We need an independent,
> >>>system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
> >>>solve this fundamental design problem with how name resolution works
> >>>on a Linux system.  Windows has had a default system-wide DNS cache
> >>>for over a decade.  It is about time that Linux catches up.
> >>
> >>I observe you pointedly ignore the existence of nscd (which does not
> >>require any changes to resolv.conf). Why is that?

Ignorance about nscd on my part.  Please tell me more.  What are the
honest pros/cons to using nscd?  Are there still big enough problems
with nscd to warrant its poor reputation?

> >nscd is ... bad

I've since learned more about nscd.  Apparently its reputation may be
undeserved, at least the newer versions in glibc.  I have no direct
experience, but I finally found a good thread about fixing the stub
resolver that addresses people's unwillingness to use nscd as well as
some other things that could be done, such as a patch apparently
carried by Debian and Ubuntu that improves detection of changes to
resolv.conf:

https://sourceware.org/ml/libc-alpha/2012-12/msg00416.html

> Main goal is to have local DNSSEC-validating resolver.

I, as the OP, did not intend that as the goal, although I have no
problem with that as a different goal.  My intent was to fix the
atrocious failover behavior of the glibc resolver.  I also don't mind
using a caching resolver BUT there should be a better stub resolver
that can be widely deployed in a default configuration that doesn't
require a local caching resolver to paper over its deficiencies.
Maybe nscd (and some of the other ideas in the link I posted) are part
of the solution.

Basically, we aren't going to win the war by suggesting that everyone
should run a DNSSEC-validating resolver everywhere.  But maybe we can
get widespread consensus for having a lightweight daemon that just
does failover correctly and nothing else fancy so that people won't
mind it running by default on Server, Workstation, Cloud, etc.  Maybe
nscd can be that daemon, or maybe something else needs to be written.

Whatever the solution to DNS failover, we should be sure it works
correctly in combination with/doesn't get in the way of full
caching/DNSSEC-validating resolvers, both local and remote, whether
they are installed/enabled by default in various Fedora products or
not.


More information about the devel mailing list