[dns-operations] *nix stub resolver as a stateful daemon (was: ...dns resolver inside "systemd")

[Robert Edmonds]

Andrew Boling wrote:
> On Wed, Dec 27, 2017 at 1:58 PM, Robert Edmonds <edmonds at mycre.ws> wrote:
> >
> >
> > I've always found the application-embedded DNS stub resolver to be the
> > least debuggable part of the DNS stack. The glibc 'getent' utility is as
> > close as it comes to being able to debug it on Linux systems, and that's
> > little more than a driver for getaddrinfo().
> >
> > I would think putting the bulk of the stub resolver logic into a daemon
> > would enhance debuggability, since you have a persistent process that
> > can generate logs, and state doesn't disappear when a client process
> > exit()'s.
> >
> 
> I agree, and implementing the daemon interface into a separate NSS module
> is a way to solve some of the state problems without forcing the
> significant methodology changes into glibc's (somewhat) well-understood
> implementation.
> 
> Rather than reinvent the wheel (or let the systemd folks plot our destiny),
> I've been meaning to talk to the stubby developers more about this ever
> since their presentation at OARC 27. I don't speak for their team, but from
> casual conversation I got the impression that they were toying with the
> idea of their own NSS module interface to sidestep having to put 127.0.0.1
> in /etc/resolv.conf. This could potentially be an extension of that effort.
> 
> If a methodology shift toward stateful were to occur, I think this is
> probably the best direction for it to take. It concentrates the effort on
> an existing implementation that many of us already have a vested interest
> in (getdns), and avoids systemd-esque pitfalls of fragmentation in the
> resolver library space.
> 
> (apologies to the stubby folks in advance for armchair scope creep)

I don't see a big advantage to producing new NSS modules for the DNS
protocol (e.g., see the fate of nss-lwres) versus putting "nameserver
127.0.0.1" (and nothing else) in /etc/resolv.conf, and running a nice
DNS server on 127.0.0.1:53, either in full recursive mode or forwarding
to your preferred recursive DNS service.

However, having an alternate DNS stub resolver at the level of the NSS
interface may provide some insurance against a vulnerability like
CVE-2015-7547, though thankfully there were mitigating factors for that
particular CVE.

If I understand correctly, one of the big selling points for getdns(api)
is that it provides a DNS-centric interface to application developers,
so they can e.g. retrieve DNS records of arbitrary type, determine
whether the data is DNSSEC-secure or not, etc. Basically, the stuff that
getaddrinfo() doesn't let you do beyond looking up A/AAAA records, you
can do with getdns(api). It doesn't make a whole lot of sense to me to
shim all that functionality behind the NSS interface, at which point
you're mostly just providing an alternative getaddrinfo() backend, and
if the goal is to provide an alternative getaddrinfo() backend then
there are a few other implementations that are worth considering like
c-ares and maybe stripped down builds of ldns or perhaps BIND9's DNS
library.

-- 
Robert Edmonds