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