[ On Monday, January 5, 2004 at 10:23:16 (-0800), Greywolf wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> The thing is that domainname was intended as a NIS thing.

That's totally irrelevant.  It's just a string that's been called a
"domain name".  Period.  Nothing more, nothing less.

>  I have been in
> several shops which have had separate DNS and NIS domains (mine is now one
> of them).  Why?  I'm not sure; I'm currently doing it because my NIS does
> not need to defer to DNS for its host lookup.

Again that's _totally_ irrelevant.  Anyone stupid enough to create such
a configuration can either learn to live in their own mess, or they can
clean it up.  I don't expect the whole world to instantly adopt this
suggestion and I don't expect any site unable to adopt it would be
forced into a corner -- far from it.

BTW, I've seen the configuration details of many hundreds of networks of
all sizes and I can probably count the number that were using NIS
domains on the fingers of one hand, and the only time I've ever seen
anyone use dischordant NIS and DNS domains was when an experiment with
NIS ended up being used for longer than it should have.  These days
anyone still maintaining inside hosts data in NIS while also maintaining
DNS data for at least their outside networks, is really not doing
themselves much of a favour.

Note I'm not saying sites with NIS, or even sites with dischordant NIS &
DNS domains, don't exist -- I'm just saying they are very rare and
usually unintended and almost always wish they didn't.

Meanwhile the vast majority of sites that use network applications
regularly these days will only ever use DNS and it's pretty stupid for
them all to waste a couple of system calls and a bit of kernel storage
when they already have an appropriate use even given their existing
names.

> To link the two might cause some consternation; honestly, I'm rather
> surprised that you are the person to suggest this.

I don't care about NIS -- I'll let those that do care about it and use
it worry about whether or not they want to link their "domain names" in
name or not.

Meanwhile I've only been using domainname to hold the default DNS domain
for over a decade now on my own machines.  The only thing I've found
less than ideal about doing this is that so many DNS-using applications
fail to even try to use this ideal mechanism to find a default domain
name for their current host environment.  It's not often a big deal for
me though since I normally strive to use FQDNs all of the time.

> Regarding searchlist and domain in resolv.conf, they do exactly what they
> were put there to do.

Yeah, and perhaps if you try to think about it for just a little bit
longer you'll hopefully realize they have no true utility for mobile
computers that move between networks without reboots, and then once
you've come to that realization you'll look back on just exactly what
purpose they have in static machine configurations and you'll find it's
just about a silly there too.

>  I've found it extremely handy, while working at
> an employee-friendly company, to put my home domain into my resolv.conf
> at work on the searchlist -- if the host wasn't locally resolvable, look
> at my home domain server and connect to it.

What if your computer were mobile?  What do you do when both domains
have a machine called "mail" or "proxy" that you need to access
regularly and simultaneously?  What would you do if you regularly used
an application like Mozilla that needed to know the names of smtp and
proxy servers but each had a different unqualified name?

For the first case you really should learn to use FQDNs as a habit so
that you don't end up confusing yourself.

For the second case applications like Mozilla really need to know more
than just the "default" domain name (or rely on gethostbynme() to fill
it in for them).  They need to know more about whole the network they've
connected to, not just its netmask, gateway address, and DNS domain.
Some of the things they need to know can/could be told to them by DHCP
(e.g. the local DNS cache and NTP server, etc.), but expecting that to
always happen for everything would be wrong (I've not yet seen any
real-world network where DHCP tells clients what HTTP proxy to use, for
example).  Even if, for example, an "option http-proxy" setting were
available from the local DHCP server, getting all the applications to
use this value for all the users on the machine would require a great
deal of never-ending hacking and scripting since each new application
might have a different way of configuring the proxy server.  Something
more general and extensible needs to be designed (perhaps a sysctl MIB
for "locality specific settings").  Even having dhclient-script edit
/etc/resolv.conf is a nasty hack in this respect.

-- 
						Greg A. Woods

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