Subject: Re: re-reading /etc/resolv.conf on change
To: Manuel Bouyer <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 01/05/2004 16:52:49
[ On Monday, January 5, 2004 at 22:18:46 (+0100), Manuel Bouyer wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
> 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).
Are you certain of this? I.e. have you actually tested it (with BIND-8)?
According to the current documentation if the "forward" option is left
at its default setting of "first" (and the forwarders list is not empty)
then the forwarders will always be queried first. Alternately it can be
set to "only", in which case the server will only query the forwarders.
In either case it has been my understanding that no result will ever be
cached if it is retrieved from a forwarder, regardless of whether the
auth flag is set on the response or not.
I.e. the only time a forwarding nameserver should ever end up with
entries in its cache is if a forwarder doesn't answer the initial query
_and_ the "forward" option is set to "first" _and_ it manages to find an
answer from some other nameserver. (that's what I really meant by "gets
it from an authoritative nameserver")
> > >[[ ... regarding the "searchlist" setting in /etc/resolv.conf ... ]]
> And some apps don't have a way to re-read their ~/.?? files.
That's their problem. Besides you can always restart them, especially
if they're interactive applications. It's not like they can have any
open connections after their endpoint address has disappeared.
> No, but it's not too uncommnon to have a mail and wwwcache per domain :)
In purpose, but not in name. Common names for these services are quite
variable in my experience. In fact for the average person who moves a
laptop between something like a cable modem home connection and an
office connection, the likelyhood the names are the same is almost nil.
> > 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.
Yes, in practice it more or less does -- at least in the case where
"search" entry was written by /sbin/dhclient-script at the same time it
has rewritten the whole /etc/resolv.conf file. There's only one
"$new_domain_name" specified by the DHCP server.
(I have never understood why the ISC dhclient-script sets "search"
instead of "domain".... other than perhaps in an effort to confuse
> Also I'm not sure NIS can use something else than the kernel's domainname.
In my experience 99.99% of sites don't use NIS domain names, even those
using NIS for the username database.
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>