The state of resolv.conf

[Simo Sorce]

On Tue, 2008-09-16 at 23:50 -0400, Dan Williams wrote:
> 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.

You are very wrong.
gethostbyname is useful only for querying A records, DNS is more.

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

And I think they are correct, it's not glibc duty to provide a solution
to good DNS caching.

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

A caching nameserver that can be instructed what to do when conditions
change is what we really need.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York