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

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.

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.

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!

> 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,
for now and for good, and it will have many other benefits for both you
and others as well.  It really is the right tool for the job.

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

> So you're proposing to have each application implement its own hack for this,

Yes of course.  They already do and all portable applications _must_ do
so!

And it's not a hack -- it's simply proper use of an existing well known
API designed for this very purpose (though sadly it has not been as
clearly documented as being usable for this purpose as it should have
been, even though it has been usable for this purpose for well over a
decade now).

> with different behavior between applications ?

Well the difference in behaviour is necessary to match the particular
needs of each application, though ultimately the differences will be
minor and for the most part invisible to the end user.

For the most part the obvious way for any application to safely deal
with this issue without having to know any system specific details (such
as the pathname of the resolver configuration file) is to simply retry
failed gethost*() lookups after calling res_init() (or res_ninit() for
thread safety, or their equivalent in non-BIND resolver APIs) and only
return an error if the second try also fails.

-- 
						Greg A. Woods

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