The state of resolv.conf

Dan Williams dcbw at redhat.com
Wed Sep 17 03:50:05 UTC 2008


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






More information about the fedora-devel-list mailing list