On Apr 20, 2015, at 12:23 AM, Siddhesh Poyarekar <siddhesh(a)redhat.com> wrote:
On Sat, Apr 18, 2015 at 01:49:57PM -0600, Philip Prindeville wrote:
> If you go back through the previous glibc bugs, you'll find:
>
>
https://sourceware.org/bugzilla/show_bug.cgi?id=984
>
> from 2005 which was closed out as "RESOLVED, WONTFIX" with the text:
>
> There is a solution, already implemented.
> Use nscd and nscd -i hosts in the script that rewrites your resolv.conf
> (or nsswitch.conf etc.).
Yes, that has been the upstream stance since quite some time now, so I
don't know if filing a fresh bug would change that. You could however
start a discussion upstream (libc-alpha at sourceware dot org) and
make a case for the resolver to watch for changes in resolv.conf.
Yeah… I think inotify() might be the cleanest fix for that, but it’s not particularly
portable.
stat() would work everywhere else.
Threading complicates things a bit, though.
> Problem with that is that no one seems to have gravitated towards
> this solution, and I don't blame them. It adds an extra layer of
> complexity and makes debugging issues that much more murky.
>
> A simpler fix is to grab mtime from stat()ing _PATH_RESCONF each
> time through res_query() and see if it's changed since the last
> time. Perhaps caching the inode # also and checking that, since an
> older version of the file might have been renamed as
> /etc/resolv.conf.
That is conceptually simple, but expensive, since you'll be adding
syscalls to every lookup. One may argue that it is not much overhead
for a network lookup since the latter will still take up a bulk of the
time, but it is an added cost nevertheless.
Siddhesh
syscalls are a lot cheaper than network round-trips. At least in 99% of the cases.
How often does name resolution happen, anyway? Not very often. You typically take call
it before opening a socket, and then that socket persists a long time…
In the case of split-horizon DNS service in a corporate environment, this problem still
wouldn’t be solved, at least not directly.
What might happen is you resolve
imap.mycorp.com to some inside-the-firewall 10.x.x.x
address, and connect to that. Then you roam off the network, but of course Thunderbird
(for instance) knows nothing about this… it just eventually drops the connection because
that address becomes unreachable (or points a new host with no knowledge of this TCP
connection and it promptly RESETs). TB then tries to reopen a connection… I’ve not looked
at TB source in about 8 years so I don’t know if it would redo the name resolution or not…
if yes, then it might point to a new exterior name server and get the external
(public-facing) address of
imap.mycorp.com and things work again… But that’s being
optimistic.
The behavior I’ve seen implies that it caches the address from the original resolution and
keeps trying to reconnect to that.
But having libresolv transparently relearn the /etc/resolv.conf settings is the first step
toward doing the right thing.
-Philip