On Sat, Jan 03, 2004 at 06:21:34PM -0500, Greg A. Woods wrote:
> [ 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.

It was just one example that behaves in a different way.
I'm sure there are other examples.

> 
> > 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

It helps the users of this OS. And if it's a good change it will be
picked up by others.

> 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.

Stop refering to Mozilla. It's only one amongs many networks applications.

> 
> > 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

Err, no. I'm a NetBSD developer, and I'm talking about the NetBSD resolver.

> 
> > > 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.

I did.

> 
> > 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?

nameserver, sorry.

> 
> If you're talking about some far-away nameserver then I don't think

Not far away, the one available on the network I'm connected to.

> 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

No I didn't, but this doesn't change the problem.

> results in potentially less ideal answers from such a "tuned"

less ideal == not working in my case. In some cases it returns RFC 1918
addresses for some servers, which otherwise have public addresses.

> nameserver, it will end up producing exactly the same results as if you
> edit your resolv.conf and restart your application).

No, because the nameserver has cached the previous ansewrs.

> 
> > 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.

Yes, but if it's changed, running applications won't use the new values,
and the local nameserver can't do anything about that.
> 
> 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.

Yes, and if I change resolv.conf, running applications will be back to
the first point.

If we go to the route of a local nameserver, it would not be bind, but a
process using /etc/resolv.conf as configuration file,
and some local communication between libc and this process. A real nameserver
as bind is is clearly not the way to go.

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

It is in my case (to the one provided by the local dhcp server), and
it's convenient.

> 
> > 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.

Not in the proxy settings for example. But I don't use this only for mozilla.

> > > 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?

Which can run linux binaries, which are more and more often made available
without sources when it comes to proprietary solutions.
Some ISP may provide binary-only kits for connection (or maybe some
already do).

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