On Tue, Jun 02, 2009 at 07:41:16AM -0400, James Carlson wrote:
> 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.
No arguments here. :-)
> 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.
I'm not sure that's correct for the Solaris-specific version of sendmail;
according to the domainname(1M) man page:
The sendmail(1M) daemon, as shipped with Solaris, and the
sendmail implementation provided by sendmail.org (formerly
referred to as "Berkeley 8.x sendmail") both attempt to
determine a local host's fully qualified host name at
startup and both pursue follow-up actions if the initial
search fails. It is in these follow-up actions that the two
implementations differ.
Both implementations use a standard Solaris or Unix system
call to determine its fully qualified host name at startup,
following the name service priorities specified in
nsswitch.conf(4). To this point, the Solaris and
sendmail.org versions behave identically.
If the request for a fully qualified host name fails, the
sendmail.org sendmail sleeps for 60 seconds, tries again,
and, upon continuing failure, resorts to a short name. The
Solaris version of sendmail makes the same initial request,
but then, following initial failure, calls domainname. If
successful, the sleep is avoided.
So, in a worst-case scenario, the solaris sendmail implementation
will resort to using the value returned from /usr/bin/domainname.
That said, the bottom line question we wanted to answer was whether
or not it made sense to allow the default-domain property (nwam's
equivalent of the /etc/defaultdomain file) to be set if NIS or LDAP
was not in use; and I'm now convinced that that does not make sense.
The default-domain property may be set if and only if NIS or LDAP
is in use and being configured manually; it is required in those
cases and not allowed in any others.
I think this is the right answer; but in any case, I also think it
will be easier to loosen things up in the future if needed than to
make them more restrictive, so starting out this way seems like the
right approach.
-renee
