[ On Wednesday, January 7, 2004 at 23:34:47 (-0500), James K. Lowden wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> I was going to offer that suggestion, but realized that errors aren't the
> only reason to re-read resolv.conf.  
> 
> Move a machine from one network to another, and if it can reach the
> Internet from both places, it will of course be able to use any (or, at
> any rate many) DNS on the Internet.  But it won't pick up names that
> aren't exposed to the Internet, making it blind to its internal network.  

That's not really true.  If a process never makes any queries for
private names that would only be visible if it looked to new
caching/forwarding nameserver(s) then it really doesn't care what the
new /etc/resolv.conf says -- the results for public domain names it
queries about will be available and everything will be fine.  On the
other hand if it does make queries for new private names then it will
encounter an error and the reload would be triggered.

(this is assuming the application always uses FQDNs, of course  :-)

> One could say, OK, so tie it to a dhcp update, but that's no good, either,
> because there's no rule that says both (or either) of the networks are
> dhcp-managed.  

Assuming DHCP for the moment, as I and others have alluded to already
there are a great deal of other common settings (i.e. unrelated to
/etc/resolv.conf) that might change if a DHCP client system moves from
one network to another and which are not yet dealt with by the likes of
dhclient.script.

Some of those settings can be adjusted/edited in existing well known
system-wide configuration files (just as nameserver settings can be
changed in /etc/resolv.conf or /etc/named.conf), and then either the
daemons that use those files can be told to reload them, or the
applications can monitor their own config files for changes and reload
as necessary, or as a last resort the applications can be restarted by
the user.

However there are some other commonly used DHCP settings that are not
(only) directly related to any existing well known system-wide
configuration files which are already used by the various applications
that might need to know these things.  Those that come immediately to
mind include:

	- the default DNS domain
	- the POP servers
	- the SMTP servers
	- the NNTP servers
	- the IRC servers

They're all recorded in the dhclient.leases file of course, but I don't
know of any application that uses that file to learn these things.

However many applications will expect to learn these settings from their
very own "private" per-user configuration files (~/.* files).

Fixing all of this will require a rather more grand approach that can be
widely adopted by all platforms and the applications that run on them.

Such a plan could be driven by the ISC DHCP folks (since they provide a
DHCP client implementation that's widely used on systems that face these
problems).  It might be as simple as providing a basic API for
third-party applications to use to access the options recorded in the
dhclient.leases file.  Provided that API also includes an interface to
detect a new lease (a trivial task), then it's simply a matter of having
applications make use of that call on what would be an appropriate
interval for them and to re-set their internal settings should that call
indicate they may have changed (perhaps with/after some user confirmation).

I.e.  there's no need for any fancy new "event notification system" and
all the baggage it would drag in, nor even any need to use a new signal
(though a signal would still be the best and most unix-like approach).
Daemons will of course still use SIGHUP, including for this purpose and
interactive applications will be doing interactive things where there'll
be a logical time and place to check for new settings.

As for why systems and applications should adopt this DHCP-based
mechanism for adjusting client settings, well if something comes along
and tries to replace DHCP then I'll bet it'll have to follow DHCP's lead
on this and other fronts if it ever hopes to gain any ground, even if
that thing is infinitely better than DHCP.  :-)

-- 
						Greg A. Woods

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