[dns-operations] some advice on configuring the dns resolver inside "systemd"

[Robert Edmonds]

Paul Vixie wrote:
> Robert Edmonds wrote:
> > He also spends a lot of time complaining about "implementing state
> > tracking against a stateless protocol" (he appears to think that that's
> > bad), yet the recursive DNS server he recommends implements exactly that
> > (https://www.unbound.net/documentation/info_timeout.html), and much more
> > (e.g., RTT tracking).
> 
> the article seemed clear that systemd's state tracking could turn into an
> infinite holddown. unbound doesn't have that. perhaps systemd doesn't
> either.

He's not just complaining about a particular allegedly buggy behavior,
which is a fine genre of blog post, he's taking a particular behavior
which he considers buggy and escalating it into a full blown polemic
about a "fundamental design" flaw. My point is that the claimed
fundamental design flaw (remembering things about recently contacted
servers, or, more pedantically, "implementing state tracking against a
stateless protocol") is widely used in recursive DNS servers, even
recommended in STD 13 (search for "batting averages") and it seems
strange to ban a particular type of DNS server (stub resolver daemons)
from using those techniques.

Arguably the nss-resolve + systemd-resolved combination is a brand new
kind of stub resolver (for the Linux world, anyway) and the systemd
folks shouldn't have tried to imply any sort of compatibility with
glibc's nss-dns + libresolv by parsing servers from /etc/resolv.conf.
But then you'd have a different and probably much larger and angrier
crowd of pitchfork wielding bloggers complaining that systemd-resolved
ignores the servers configured into /etc/resolv.conf, and that DNS
servers have always been configured via /etc/resolv.conf (it's
tradition).

> > I'm not entirely sure what point he's trying to make other than that he
> > prefers the glibc nss-dns stub resolver when configured in a particular
> > way to the nss-resolve + systemd-resolved stub resolver.
> 
> my read is, he doesn't want to have to choose his dns stub logic as a side
> effect of having chosen his OS boot vehicle. and, i agree.

It looks like we're all in agreement. As Paul Wouters pointed out up
thread (and as pointed out every time someone complains about
nss-resolve + systemd-resolved), if your Linux distro shipped
nss-resolve + systemd-resolved enabled by default, it's easy to remove.
But most (almost all?) Linux distros are still shipping the traditional
nss-dns as the default stub resolver and will probably ship it as the
default for some time.

Most OSes don't even include the ability to switch out the DNS stub
resolver; that facility seems to be limited to the subset of OSes with
significant Unix/Unix-like heritage (e.g., Linux and BSD, and notably
excluding OS X, I believe). So the vast majority of computer users are
already choosing their DNS stub logic as a side effect of choosing their
OS.

> for most of my systems, resolv.conf is managed by DHCP, and every
> application can be debugged with the libc or glibc logic in mind.

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.

Not all applications use the C runtime's resolver, either. E.g., Chrome
notably has its own DNS stub implementation, and the Go language runtime
usually uses its own pure Go implementation in preference to its cgo
getaddrinfo() implementation
(https://golang.org/pkg/net/#hdr-Name_Resolution).

-- 
Robert Edmonds