[ On Sunday, January 4, 2004 at 17:52:20 (+0100), mouss wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> Greg A. Woods wrote:
> > 
> > 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.
> 
> ahem... Can you show me a change in the netbsd sources that solved 
> problems for real users in the world? Sure there are, but at the time 
> they were implemented in netbsd, they weren't available to other users. 
> And this is similar to the current issue. If a good solution is 
> implemented by netbsd, then it may be imported by others.

You're not looking at the big picture here.

What Manuel has proposed is a really bad hack to work around an
acknowledged bug in a very few applications.

That hack will only temporarily alleviate a minor problem for a very few
NetBSD users.   In the mean time it can only create confusion for
application developers.

> > 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.
> 
> No, at start, the resolver library was written so that applications 
> don't have to deal with the name system.

If you think that's true in the way you seem to mean it then I invite
you to propose the change to the folks at ISC _first_.

Meanwhile the standard BIND resolver has _always_ had a proper way to
deal with this issue:  simply call res_init() to reload the resolver's
configuration.

> I understand the concern that changes in the resolver will make it 
> harder to integrate the next version. However, the resolver has already 
> been modified.

This is not just an issue with NetBSD's own maintenance.  This is a
major problem with confusing application developers as well.

In case you didn't know there's no standard and documented way currently
for any appliation to see any difference at compile-time or run-time in
the resolver API provided by NetBSD vs. the BIND resolver it was derived
from.

> Mozilla was just an example. Proxies running on a firewall are another. 
> Do you want to force firewalls to run a name server?

I think you're inventing problems that don't really have to exist.

> > Yes of course.  They already do and all portable applications _must_ do
> > so!
> 
> Mozilla is portable and doesn't do so:)

If that's what you think then you have not investigated this issue
w.r.t. mozilla.

> No. What you're proposing (from my understanding) is that one 
> application (dhclient or whatever) send a signal to N applications (N 
> may be large), so as they call res_init() again.

For _daemons_, yes.

> This in turn requires apps to register with dhclient (or with something 
> else) saying "I wanna know when foo changes".

Absolutely not!  No registration is necessary.  Only three tiny hooks
are needed -- one, the res_init() call, in any applications that wish to
pay attention on reload to resolv.conf changes; and the second in
/etc/rc, and the third in dhclient-script (and similar scripts).

> A simpler approach is to 
> reboot.

<heavy sarcasm>Yeah, right.</>

(until recently NetBSD pretty much had to be rebooted just to restart
syslogd)

> Also, most daemons use sighup to reload their own config file. What you 
> are proposing is that they reload everything when resolv.conf changes 

Ah, NO!  Please try to pay attention.  I'm only proposing that "/etc/rc
reload" be used to signal _daemons_ of changes in their runtime
environment.  How they deal with that signal is their concern.

> (because signals don't carry data, so the app doesn't know why she's 
> signalled).

that's irrelevant.

> Add to this that those fork-on-accept daemons don't need to reload their 
> conf (older sessions use old config) except in the root process.

Please name them all.

> What if gethost* succeeds, with incorrect results?

That's irrelevant -- i.e. it's not in the scope of this issue.

-- 
						Greg A. Woods

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