On Thu, Apr 27, 2006 at 11:14:19AM -0700, J.T. Conklin wrote:
> We've encountered an interesting problem with long lived server on our
> NetBSD 2.99-ish based appliance and changes to DNS configuration. 
> 
> It is my understanding that the best practice is for long running
> processes to call res_init() to reinitialize the resolver library
> when/if /etc/resolv.conf is changed, because on many systems (and it
> appears that NetBSD as among that set) it is not automatically done.
> 
> This works with single-threaded programs, but with multiple threads
> __res_get_state() gets the resolver context from a free list, only
> allocating and initializing a new one if the list is empty.  So the
> call to res_init() only reinitializes the global resolver context,
> which is not used.  With multiple threads, multiple resolve.conf
> updates, and a very slow nameserver, it's possible for each context
> on the free list to be different.  So depending on what thread gets
> what context, you can have completely different lookups.  This seems
> ... undesirable.
> 
> Other than running a local caching nameserver and never touching
> /etc/resolv.conf, what's the best practice for reseting the resolver
> context(s) for long lived processes?

There was a long thread about this on dec, 2003 and I may event have posted
a patch to have libc reread resolv.conf when needed (I don't remember).
I think the libc's resolver should take care of this; it's annoying to
have to restart firefox on a laptop because the network changed.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--