[Bug libc/984] Respond to changed resolv.conf in gethostbyname

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=984

--- Comment #9 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #8)
> (In reply to Carlos O'Donell from comment #7)
> 
> > How is that a problem in glibc if sendmail caches the resolver? Or are you
> > saying something else? That libc.so.6 caches the resolvers and fails to call
> > out to nscd? That would be a real bug, and we'd like to see some kind of
> > reproducer for that if possible, so we can fix the issue.
> 
> sendmail needs to do MX lookups, so it uses res_query (and res_search,
> depending on the context) and not one of the getaddrinfo/get*by* functions. 
> It's also a forking daemon.  It initializes the glibc resolver before
> forking, and I assume all the child processes inherit the cached list of
> name servers.

Correct, the res_* functions are designed specifically to talk directly to
Internet domain name servers, and as such bypass nscd and sssd.

You are also correct, that once you initialize the resolver state the state is
static, this is all well known. All children and threads will have the same
resolver state if created after initialization.

It is also well known that calling res_init() again will cause any underlying
configuration files to be reloaded (atomic increment of __res_initstamp does
this).

Therefore the bug is entirely in sendmail. If you use this API you must have a
side-channel to notify the application that it should call res_init again. This
is a push process. For example it might be with systemd integration that you
discover the network has changed and call res_init() again.

There have been patches floated that add stat() calls to *all* of the res_*
functions, but the performance implications of that change have never been
analyzed and that's why the patch keeps getting rejected. Is it within the
noise to do stat() on /etc/resolv.conf to reload the resolvers if they change?
It seems a heavy handed approach for systems which are less dynamic and have
more stable configurations. At first blush it seems the stat has to be less
costly than the upcoming network traffice, but it's still a non-zero cost paid
in the hot-path of all these functions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.