[dns-operations] some advice on configuring the dns resolver inside "systemd"
paul at redbarn.org
Thu Dec 28 20:00:40 UTC 2017
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.
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".
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.
More information about the dns-operations