Roaming, and libresolv being stuck in the 1980's mindset

[Dan Williams]

On Mon, 2015-04-20 at 16:27 -0600, Philip Prindeville wrote:
> On Apr 20, 2015, at 12:23 AM, Siddhesh Poyarekar <siddhesh at 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.

We tried to push inotify() style watching in glibc in the past, and I
think even Debian ships a patch for that.  But the response was always
"use a local caching nameserver" because glibc cannot be all things to
everyone.  And honestly, that's not an unreasonable answer.  If you use
a local caching nameserver then you get split DNS too, which libresolv
cannot give you.  You may encounter this same argument from upstream.

However, when we last tried in NetworkManager land, that was like 2
glibc maintainers ago, and current maintainers might have softened their
stance.  In any case, I think it makes sense to just go with a local
caching nameserver anyway, for the split DNS.  Then the network
management daemon (or whatever you use to switch networks) can forward
the DNS+domain info to the caching nameserver and everything is happy.

Obviously, this doesn't excuse apps like Evolution/Thunderbird/etc from
the equation, since they should really be smart enough to know that if
they are not connected to the corporate VPN, they can't pull mail from
it.  But that's between the network management daemon and the app, and
doesn't involve the resolver at all.

Dan

> > 
> >> 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
> 
> 
> 
>