[ On Sunday, January 4, 2004 at 02:20:34 (+0100), Manuel Bouyer wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> > results in potentially less ideal answers from such a "tuned"
> 
> less ideal == not working in my case. In some cases it returns RFC 1918
> addresses for some servers, which otherwise have public addresses.
>[[...]]
> No, because the nameserver has cached the previous ansewrs.

Just to recycle back to this alternative for a moment....

If I understand correctly this is not normally a problem when using a
forwarding nameserver.  Such a nameserver should only cache replies it
receives directly from other authoritative servers but otherwise will
always refer to the forwarders -- i.e. this can only be a problem if the
forwarders are unavailable or otherwise fail some request.

That said it's been a long time since I've actually tested using a
forwarding configuration and I may be mistaken.  If I'm wrong then the
solution is to explicitly restart named from dhclient-script instead of
relying on a reload.

>[[ ... regarding the "searchlist" setting in /etc/resolv.conf ... ]]
> 
> Yes, but if it's changed, running applications won't use the new values,
> and the local nameserver can't do anything about that.

"searchlist" and/or "domain" from /etc/resolv.conf are the only things a
locally running named might not be able to help with.  But named shouldn't
have to help applications with this information either.

I.e. the fact that applications do not see the new "searchlist" should
not _ever_ be an issue, but of course people are lazy (even me) and
applications aren't all re-configured correctly by dhclient-script (and
fixing some apps would require modifying ~/.* files for all users) and
thus things can get very messy.

I.e. making use of "searchlist" in /etc/resolv.conf to mask yet more
application bugs is a bad hack.  Just because you might have a "mail"
and "proxy" server or similar in each domain your laptop currently
DHCP's to, doesn't mean everyone will have similar "convenience" names
for similar purposes.

I think the right solution for interactive applications would be for
them to use the kernel's "domainname" setting as the default domain and
for them to qualify un-qualified hostnames themselves (and yes I know
some people seem to think this is a NIS thing, but it's not -- it's just
a string setting maintained in the kernel and it even has a very
convenient and meaningful name for this very purpose!).  Maybe mozilla
already does this -- I don't know (but I do know that every DNS-using
application I have the occasion to hack any significant amount on does
learn to do this! ;-)

(Daemons should always use FQDNs and their configs should be edited by
dhclient-script and reloaded by "/etc/rc reload".)

I.e. I personally would rip "searchlist" and "domain" and even
"sortlist" right out of the resolver -- they have no valid place there
in a properly designed "mobile" system since the "convenience" they
cause is far more trouble than it's worth once mobility enters the
equation.

> If we go to the route of a local nameserver, it would not be bind, but a
> process using /etc/resolv.conf as configuration file,
> and some local communication between libc and this process. A real nameserver
> as bind is is clearly not the way to go.

I would agree, but other than the BIND-9 lwresd I see no other alternative.

-- 
						Greg A. Woods

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