Cached resolver state issues

Paul A Vixie vixie at mibh.net
Mon Aug 21 06:50:29 UTC 2000


> I've recently had cause to swing /etc/resolv.conf on various RedHat 5 and 6
> machines to move my local internal DNS server to another box.
> 
> As a consequence of this I find some unpleasant side effects of "resolver
> state caching" on each host.
> 
> A very very brief delve into glibc source and sendmail source suggested
> that any given process only calls res_init() ( as a sub call within
> getXXbyYY() ) once to retrieve and parse ( amongst other things ) the
> contents of /etc/resolv.conf /etc/host.conf /etc/nsswitch.conf and perhaps
> /etc/hosts...

yes.

> Once called, further calls to the resolver library seem to use that cached
> information for performing upper level functions like gethostbyname() et
> al.

right.

> Hence any changes made to /etc/resolv.conf once a given daemon process has
> started are ignored.

right again.

> Hence modifying and reflecting the changes in /etc/resolv.conf on a 24x7
> server become ever more difficult to achieve as the side-effect of the
> caching is to virtually require a reboot of the machine to flush remnants
> of resolver state from running daemons.
> 
> The sendmail source has an explicit call to res_init() which hinted at this
> caching behaviour, but tests with various Perl scripts and other daemons
> running on a fairly recently built RedHat 6.2 / Kernel 2.2.16 box suggest
> that this problem is pretty global to all "clients" of gethostbyname().
> 
> I've been able to restart the sendmail processes globally to alleviate the
> worst side effects of this caching, but the question remains....
> 
> Does the BIND Resolver Library exhibit the same problem? - my understanding
> was that glibc's resolver library is heavily influenced if not identical to
> BIND's resolver library.
> 
> Additionally, does anyone know whether Solaris resolver libraries have the
> same problem?

glibc and solaris both derive their resolver libraries from older bind code.
but both old and new bind code, and all derivatives i know of, require an
explicit call to res_init() to reload resolv.conf.  the alternative is to
have gethostbyname() possibly cause stat() to be called to see if resolv.conf
has changed -- nobody does that.



More information about the bind-workers mailing list