On 21.4.2015 16:32, Dan Williams wrote: > 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.
Exactly this is planned for Fedora 23: https://fedoraproject.org//wiki/Changes/Default_Local_DNS_Resolver Stay tuned! Petr^2 Spacek > > 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 >> >> >> >> > > -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
