On Sat, Jan 03, 2004 at 03:24:52PM -0500, Greg A. Woods wrote:
> [ On Saturday, January 3, 2004 at 15:21:54 (+0100), Manuel Bouyer wrote: ]
> > Subject: Re: re-reading /etc/resolv.conf on change
> >
> > On Fri, Jan 02, 2004 at 09:33:15PM -0500, Greg A. Woods wrote:
> > > Regardless hacking the resolver code in some vain attempt to solve this
> > > problem for the application is still the wrong solution.
> > 
> > remplace mozilla with any other web browser, MUA or news reader.
> 
> and the answer remains the same.
> 
> > It's silly to go fix each applications when we could do it in one
> > centralised place, and get consistent behavior of all applications.
> 
> No, it's not "silly" at all.
> 
> Hacking on the NetBSD resolver "fixes" the problem for a tiny percentage
> of real users in the world.  In the mean time the problem remains for
> all DNS-using applications on all other platforms.  Now that's silly.

Not all: windows does the right this for this, for example.
Other platforms could fix their resolver as well.

> 
> The only _right_ place to "fix" this problem is in the applications.
> All portable applications _must_ deal with this issue directly on their
> own anyway, if they care to.

Which doesn't prevent the OS from being smart in his libraries too.
> 
> If you really want to try to fix the resolver then please propose your
> change _first_ to ISC and see if maybe they think it might be a good
> idea.  Then if they do they can choose to implement it and then IFF they
> choose to do so "we" can incorporate _their_ final design solution into
> the NetBSD resolver IFF "we" think it'll take too long to get their
> actual implementation incorporated into NetBSD.

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

> 
> Meanwhile all DNS-using applications will continue to have to deal with
> this issue until the vast majority of installed resolver implementations
> universally deal with it for them.
> 
> > As already pointed out, a local caching nameserver isn't always an option,
> 
> 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 ! For resolvers who don't give the same anserw depending on the
source IP of the query for example
And there are some smarts in resolv.conf (the search list, specifically)
which isn't dealt with by a local nameserver.

> 
> > and in my case I don't want it.
> 
> Running a local caching nameserver is the best possible solution for
> you.  It'll solve all of your problems with DNS resolvers in one pass,

And create other ones: giving the wrong anserw from its cache,
and won't solve the problem of the search list being changed in resolv.conf
anyway.

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

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