Subject: Re: re-reading /etc/resolv.conf on change
To: mouss <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 01/04/2004 16:23:06
[ 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
> > 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
> 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
> 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
> 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
<heavy sarcasm>Yeah, right.</>
(until recently NetBSD pretty much had to be rebooted just to restart
> 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
> 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 <email@example.com>
Planix, Inc. <firstname.lastname@example.org> Secrets of the Weird <email@example.com>