Subject: Re: re-reading /etc/resolv.conf on change
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-userlevel
Date: 01/01/2004 00:21:42
[ On Wednesday, December 31, 2003 at 13:43:23 (-0500), John Hawkinson wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
> Jason Thorpe <> wrote on Wed, 31 Dec 2003
> at 09:33:55 -0800 in <>:
> > 
> > On Dec 31, 2003, at 7:10 AM, Manuel Bouyer wrote:
> > > 
> > > OK, would a message to syslog be acceptable ?
> > 
> > I don't think any message is necessary.
> I think a message should appear when RES_OPTIONS=debug is set.

I would agree.  Also there are a bunch of #ifdef DEBUG wrappers around
really useful debug messages in the resolver code that should probably
be changed to #ifndef NDEBUG, or perhaps changed to some new unique macro
that's defined by default (which is what I do:  CPPFLAGS+=-DRESOLVDEBUG).
Any new message(s) could/should be similarly wrapped.

> I'm a bit puzzled at all the clamoring for this change.

Me too!  ;-)

> Why don't
> people simply run local caching resolvers? It's far better on the
> network (though increases the memory footprint some).


It wouldn't even be difficult to have dhclient or whatever modify the
forwarders settings in /etc/named.conf.  :-)

> If we're actually going to propose a filesystem access on every
> nameservice check (i.e. fstat() or lstat()), I think that is not an
> appropriate change if it is mandatory, and it should be controlled by
> an option.


Personally though I'd rather have a hook that an application could use
to force a re-read.  Long-running network daemons could then simply call
that hook at the same time they re-read their own configs on SIGHUP,
something most any daemon of interest will already support, and if not
then it should.

> I'd also like to have a better understanding of its
> performance effects, especially on slow machines.

That's for sure!

						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <>
Planix, Inc. <>          Secrets of the Weird <>