On Mon, 2015-04-20 at 16:27 -0600, Philip Prindeville wrote: > On Apr 20, 2015, at 12:23 AM, Siddhesh Poyarekar <siddh...@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 > > > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
