Subject: Re: re-reading /etc/resolv.conf on change
To: Jason Thorpe <>
From: Greg A. Woods <>
List: tech-userlevel
Date: 01/06/2004 13:27:27
[ On Tuesday, January 6, 2004 at 09:19:20 (-0800), Jason Thorpe wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
> Uh, I don't really see how this is a better solution.  resolv.conf is 
> not a configuration file that gethostby*() should ever have to care 
> about.

Indeed gethostby*() should not directly care about /etc/resolv.conf

However the documented way to initialize and/or reload the configuration
for the low-level resolver(3) routines used by gethostby*() is to call

>  This is a violation of abstraction, pure and simple.

No, it's not any such thing, given one caveat.

The trick of course is to not use an explicit "/etc/resolv.conf" or
_PATH_RESCONF value (which is a private value for the resolver(3) code).

The quick hack would be to call res_init() at the beginning of every
higher level subroutine.

A better alternative would be to re-initialize it at most once every 60
seconds.  (Why 60 seconds?  Well it's a very reasonable value given
various aspects of the data being returned as well as given the human
factors involved.)

Another alternative would be to re-initialize it only if an error is
returned by a lower-level routine.

An ideal solution would be to add hooks to the lower level resolver(3)
code so that the current configuration file could be queried and also
optionally reset (thus solving two issues with one fix).  Then the
higher-level code could use stat() on the right file at appropriate

In practice of course simply assuming _PATH_RESCONF is the name of the
resolver(3) configuration file and using stat() on it is perfectly valid
given the absense of the aforementioned hooks.  After all the use of
_PATH_RESCONF has been hard-coded in all BIND releases for over a decade

>  The 
> underlying resolver code should be the one to re-initialize, if 
> necessary.

no, absolutely not -- at least not unless the decision for the change
comes directly from ISC (and as a very long-time bind-workers
participant I suspect they'll not agree, but you never know).

We probably shouldn't even modify gethostby*() either for this purpose
unless ISC agree, but it's far less of a hack to do it at the level of
gethostby*() than it is to muck with the low-level code that already has
an explicitly documented reinitialization entrypoint.

						Greg A. Woods

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