Thus spake Greg A. Woods ("GAW> ") sometime Today...

GAW> > The thing is that domainname was intended as a NIS thing.
GAW>
GAW> That's totally irrelevant.  It's just a string that's been called a
GAW> "domain name".  Period.  Nothing more, nothing less.

On the contrary:  It's quite relevant.  DNS was around before NIS was.
Did it ever use something called 'domainname'?  [Hint:  No.]

To suggest that DNS should haul in domainname is ludicrous.

[on diverse NIS/DNS setups]

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

<dry>Gee, thank you so much for your implication.</dry>

I don't see that it's a bad thing to have done.

GAW> BTW, I've seen the configuration details of many hundreds of networks of
GAW> all sizes and I can probably count the number that were using NIS
GAW> domains on the fingers of one hand, and the only time I've ever seen
GAW> anyone use dischordant NIS and DNS domains was when an experiment with
GAW> NIS ended up being used for longer than it should have.

That is no more or less irrelevant than my statement.  Please paint them
with the same brush.

GAW>  These days
GAW> anyone still maintaining inside hosts data in NIS while also maintaining
GAW> DNS data for at least their outside networks, is really not doing
GAW> themselves much of a favour.

"Whatever."

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

I've had the opportunity to work at one large site and several smaller
ones in which domain(NIS) != domain(DNS).  This was NOT by accident.

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


GAW> > To link the two might cause some consternation; honestly, I'm rather
GAW> > surprised that you are the person to suggest this.
GAW>
GAW> I don't care about NIS -- I'll let those that do care about it and use
GAW> it worry about whether or not they want to link their "domain names" in
GAW> name or not.

Great for you, but unless you're going to push for separate NIS and DNS
and LDAP namespace in the kernel, just keep walking.

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

Well, bully for you, old boy.  Not everyone is going to hold themselves to
that standard.  I do try to migrate my thought process with my physical
location, and usually do not have a problem, either, but...

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

So you're saying the searchlist is useless?!?

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

Those are two completely opposite problems!  The first implies that you're
going to have an ambiguous result given an unqualified name, while the
second implies that you are not going to routinely be able to hit the
unqualified name in the first place.

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

You really know how to pontificate, don't you?

That said...

GAW> For the second case applications like Mozilla really need to know more
GAW> than just the "default" domain name (or rely on gethostbynme() to fill
GAW> it in for them).  They need to know more about whole the network they've
GAW> connected to, not just its netmask, gateway address, and DNS domain.

Mozilla needs to know about ip, netmask, gw and domain?  News to me.

Perhaps this is why mozilla supports separate profiles?  Who knows.

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

If that is the crux of the argument, I'm in agreement with you, above
statements notwithstanding.

I've a feeling that old-guard network constructs really no longer apply
in the world of mobile communications and computing.  I think it all
needs to be either expanded or rewritten at some point.  But that's just me.

				--*greywolf;
--
NetBSD: Tap The Power.