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

[Andrew Boling]

On Thu, Dec 28, 2017 at 4:59 PM, Robert Edmonds <edmonds at mycre.ws> wrote:

> 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.
>
>
I'm not in a position to disclose specifics, but the last time I ran into
this it was a major impact to the company in question and a long lived
process that had to be restarted to pick up the changes. My personal
impression is that such software tends to be written with the assumption
that 10s+ for a DNS lookup is "too long" regardless of reason (i.e.
scenario where glibc might eventually move on to a working DNS server is
not considered), and no special effort is made to leverage resolver
libraries outside of the glibc space. It's also my impression that there is
more software like it out there than not, at least where threads are
available. Software that is mission critical to a company without being
designed to be *performance *critical is the problem space in question, as
those developers tend to expect the OS to handle the DNS magic for them
without special handling. I think we can all agree that it's badly written
software from a *DNS perspective*, but the problem again stems from the
fact that the developers in question have the wrong expectations with
regard to the massive delays that can be encountered before a second server
is ever attempted.

I'm aware that personal anecdotes without specific examples aren't terribly
useful, but they're all I have available at the moment. Apologies to Robert
for the second (heavily edited) copy of this, I left the list off of the
last one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20171228/8a0d1e2f/attachment.html>