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

[Andrew Boling]

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20171228/1ef69f4c/attachment.html>