On Tue, 2008-09-16 at 13:19 +0200, Nils Philippsen wrote: > On Tue, 2008-09-16 at 11:05 +0100, Paul Howarth wrote: > > > Another problem with modifying resolv.conf is that most processes only > > read it once, usually shortly after starting up, so any changes that > > happen after that don't get picked up by existing processes. So for > > instance you could have a web browser that couldn't resolve names from a > > VPN tunnel that had been brought up after the browser had been started. > > Which is a bug IMO. If applications don't use the glibc supplied > functions for name-resolving, they should at least reinvent the wheel > properly and check for changes to resolv.conf. Nobody is rolling their own code; they all use gethostbyname. The problem is that glibc's resolver is too simplistic. I asked the glibc guys about this about 3 years ago and they said they wanted to keep glibc's resolver simple and that this should be handled either by lwresd or a caching nameserver. The core issue was that doing something like polling /etc/resolv.conf for updates would be unecessary on many platforms. So the answer seems to be that glibc will not change it's simple internal resolver (which has more limitations than just noticing resolv.conf changes), but the recommendation is that lwresd or a local caching nameserver be used for more complex DNS setups. Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list