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

[Robert Edmonds]

Paul Vixie wrote:
> Andrew Boling wrote:
> > ...
> > To avoid a philosophical debate over whether glibc's behavior is the
> > "right" one, I'll simply say ...
> 
> stub behaviour has suffered from older unix's inability to behave
> asynchronously. by now every system we use has something like kqueue,
> libevent, threads, or whatever. we could come up with a nigh-standard
> stub behaviour, put that into getdnsapi, and then put a lot of pressure on
> the glibc team and other libc teams as well as apple and google and
> microsoft, to behave the same way.

Counting by the number of installed instances, approximately 100% of the
applications that have high performance DNS client needs are web
browsers, and with the exception of Microsoft's web browsers (after the
retirement of IE for UNIX and IE for Mac), web browsers are
cross-platform pieces of software. So it's not surprising that the
solution the most popular web browser has chosen is to embed its own
implementation of a high performance stub resolver.

In contrast, the kinds of applications that rely on the glibc stub
resolver are mostly command-line applications (e.g., ssh, wget) which do
perhaps a handful of DNS lookups at startup. They don't need a high
performance or async DNS resolver. A big exception is Firefox, which I
think ultimately does rely on getaddrinfo() on Linux systems.

glibc (and, I would imagine, every other platform's C runtime library)
has a very high barrier to introducing new interfaces, particularly ones
that "just" implement network protocols. If an application has a
specific need for a high performance DNS client, the best answer is
probably: use a high performance DNS-specific client library, not glibc.

A lot of new systems code is being written in the Go language, which
already has its own concurrent resolver implemented in Go. So to a
certain extent what you are proposing already exists, just not for the C
language.

> of particular interest is some kind of trampoline at the process level, sort
> of like the unix-domain socket that syslog() uses to talk to syslogd().
> modern windows and unix-like (apple, android, linux, BSD) all have the means
> for a message receiver to securely inspect the credentials of the sender. a
> validating caching but not "full" resolver sitting at the gate in the wall
> could really help with dnssec deployment. yes, i know that this is what
> systemd-resolvething tries to be, but they were solving a very limited and
> non-portable subset of the problem, and doing so in a way that made no sense
> to "real dns people".

This is toxically dismissive ("systemd-resolvething", "real dns
people"). As far as I can tell, the people developing nss-resolve and
systemd-resolved are professional software developers who are studying
the DNS RFCs and producing a (mostly good, or at least better than what
existed before, in my opinion) DNS client implementation, but unlike the
developers of DNS server software who for the most part toil away in
obscurity, they are also subject to frequent drive by harassment every
time one of their bug reports or someone's blog post goes viral. Perhaps
it would be more helpful to review their code and offer useful
suggestions rather than rant on blogs and mailing lists.

> if IETF DNSOP decides to take this on (which would occur on a different
> mailing list) i'd be very happy to join as a discussant and reviewer.

I don't see why DNSOP would want to take on designing a new DNS stub API
or implementation. It would probably be more helpful for the IETF to
produce a modern successor to STD 13 for the existing baseline protocol
(much like the RFC 723X documents did for HTTP/1.1) so that future DNS
implementers don't have to start out by learning to interpret a
patchwork of decades old documents.

-- 
Robert Edmonds