[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: The state of resolv.conf

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]