On Sun, Jan 04, 2004 at 07:22:42PM -0500, Greg A. Woods wrote:
> [ 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.

It happens if the forwarder is also authoritative for a zone
(which is not uncommon: the local recursive server is also
authoritative for the local domain).

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

And some apps don't have a way to re-read their ~/.?? files.

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

No, but it's not too uncommnon to have a mail and wwwcache per domain :)

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

It still doesn't do the exact same thing as a search list.
The search list if you have several domains on a site.
Also I'm not sure NIS can use something else than the kernel's domainname.


-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--