[ On Saturday, January 3, 2004 at 21:50:56 (+0100), Manuel Bouyer wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> Not all: windows does the right this for this, for example.

M$-Windoze doesn't use the BIND resolver code (at least not
unmodified).  However many other platforms do.

> Other platforms could fix their resolver as well.

Thus my suggestion that you ask the authoritative maintainers of the
resolver code whether or not they think such a change is worthwhile.

> Which doesn't prevent the OS from being smart in his libraries too.

Fixing one OS, and especially one that's not very commonly used as a
desktop system, doesn't help _anyone_, really.  All you're proposing to
do is confuse the issue.  It's bad enough that Mozilla developers seem
to think first to read Glibc code when they want to try to hack around
how something works internally in libc or libresolv.

> We're talking about the NetBSD resolver here, not ISC's one (even if
> the NetBSD resolver is derived from the ISC one).

No, we're really talking about the BIND resolver in general -- since
what we're really talking about are the semantics of the interface it
provides to do DNS lookups, since in the end the application you're
talking about uses the BIND resolver API as do all the others anyone
else has mentioned.

You're talking about hacking on the NetBSD version of the BIND resolver
so as to make it behave differently than any other version of the BIND
resolver.  That's not a good thing to do.

> > As already pointed out the problems with using a local caching resolver
> > do not apply to anyone running the likes of Mozilla!
> 
> Yes it does !

Well I was talking about the problems actually mentioned so far in this
thread, specifically the resource overhead problems.  I don't think the
other ones you outline below have been mentioned until now.

> For resolvers who don't give the same anserw depending on the
> source IP of the query for example

Which "resolver", exactly, are you talking about in this particular case?

If you're talking about some far-away nameserver then I don't think
you've really thought through all of this clearly, and you've also
forgotten that the local caching named will ideally be configured as a
forwarder, not as a stand-alone caching resolver (since even though this
results in potentially less ideal answers from such a "tuned"
nameserver, it will end up producing exactly the same results as if you
edit your resolv.conf and restart your application).

> And there are some smarts in resolv.conf (the search list, specifically)
> which isn't dealt with by a local nameserver.

Note that if you have a search list and/or default domain specified in
your /etc/resolv.conf it'll still have exactly the same effect no matter
which caching nameserver it queries, local or the DHCP specified one
directly.  The exact same queries are sent from the stub resolver to the
nameserver.

Remember too that the ideal situation with a local caching resolver on
something like a laptop is going to be that the named.conf file is
edited by your dhclient (or whatever) script to change the forwarders to
the new DHCP (or whatever) specified nameservers and then run
"/etc/rc.d/named reload".  The result is that your local named still
normally queries the very same "local" DHCP-specified caching servers
that the stub resolver would query if you didn't run a local named.

I.e. the "search" setting wouldn't necessarilly be changed by your
modified dhclient-script.

All you're doing by running a forwarding local named is to hide the bugs
in the applications that don't already know how to use res_[n]init().
This is possible because named knows how to reload its config file and
deal with "dynamic" changes in the forwarders settings.

> And create other ones: giving the wrong anserw from its cache,

I'm not so sure that can ever be a problem if you're using a forwarding
named configuration as I suggested.

In any case you can always restart your local named if some screwed up
DNS does get stuck in its cache -- and that's something you might not be
able to do if the junk is stuck in the cache of some DHCP-specified
nameserver.

> and won't solve the problem of the search list being changed in resolv.conf
> anyway.

If I'm not mistaken that's not a problem for Mozilla in the first place
-- it deals with unqualified names all by itself.

Calling res_[n]init() does guarantee to solve that problem though, and
ultimately its still the best and most portable solution.

> > > In addition, some internet tools only
> > > know how to change resolv.conf, not the nameserver config.
> > 
> > Then fix those tools -- they are broken.  The fixes are pretty trivial
> > too since the job that needs doing is almost exactly the same as the one
> > they already do.
> 
> Exept that some of them are binary-only.

Which ones are those?!?!?!?  Are we still talking about a NetBSD client
host here, or have you jumped off base?

(all the tools I know of that modify /etc/resolv.conf after a dynamic
address change are simple shell scripts!)

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>