Darren Kenny writes:
> I'm a little worried about always allowing the default-domain to be 
> configured...

I think we've still got some confusion lingering between DNS and
NIS/LDAP.

The "domain" that NIS and LDAP use has nothing whatsoever to do with
DNS's idea of domains.  They're unrelated concepts that (quite
unfortunately) share an English noun and (worse) are often conflated
together, as on the SWAN where NIS domains are constructed to look
like DNS names just to muddy the water.

Worse still, some people resolve host names through NIS/LDAP, even
though that's a pretty grotesque thing to do.  DNS is the right thing
for host names.  ;-}

> AFAIK the domainname is only *required* for NIS/LDAP, which I think we've 
> agreed on.

That's correct.

> With respect to non-NIS/LDAP,

With non-NIS/LDAP, there really isn't a "domain."

> in this scenario, I believe that sendmail gets the
> domain from the fully-qualified hostname, i.e. host.domain - if you don't
> configure such a domain it won't - but these days most configurations have at
> least a .local version of the hostname.

Sendmail *always* gets its host and domain information from DNS (or
fails trying).  The NIS/LDAP "domain" has nothing to do with it.

> Do we have a choice w.r.t. what NIS and LDAP will do if domainname is set in 
> the
> configuration - in many cases, this might be alright, but how do the servers
> react if they are different between the client and the server?

Each domain is distinct.  As part of the YP/NIS binding process, the
client will ask the server "do you serve this domain?"  If the answer
is no, then binding will fail, and you won't get NIS service.

> and then I travel to MPK - will the NIS servers accept this as my configured
> domain? I could be wrong but I feel that the servers might not like it....

The servers don't care.  But they won't provide service for domains
that they're not configured to serve.

> My worry is that if we allow the user to override the default domain when not 
> in
> manual mode, then it could cause more problems that it would help.

Overriding a NIS/LDAP domainname is equivalent to overriding the
server addresses.  You should be able to do one in exactly the same
cases you can do the other.

DNS domain names are different.  They're essentially optional advisory
information for the client.  Saying "domain east.sun.com" in
resolv.conf means "if you can't resolve the short name provided by the
user, then try appending .east.sun.com and try again."  You can have
*multiple* such entries using "search."  If no "domain" or "search" is
set in /etc/resolv.conf, then the client libraries look at the system
hostname(1), and check for dots in the name.  It assumes if there are
dots, then everything after the first dot is a "domain" to try for
short names.

It's a completely different thing.  Completely unrelated.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to