5.3. Fully qualified and unqualified hostnames
DNS and NIS have different semantics when it
comes to dealing with qualified and
unqualified hostnames. A fully qualified hostname is one that
includes the DNS domain name as the suffix, whereas the unqualified
hostname does not have a domain suffix. So for example,
gonzo.sales.polygon.com is a fully qualified DNS name, but
gonzo is an unqualified name. With both DNS and
NIS, there is associated with the name service configuration a
default domain name. If an unqualified hostname is
passed to
gethostbyname( ) to be resolved, then both DNS
and NIS will associate the query with the default domain name. When
doing an address to name query, such
as
via
gethostbyaddr( ), DNS and NIS behave
differently. DNS will always return the fully qualified hostname,
whereas NIS may return the unqualified hostname. You can do one of
two things to address this issue:
-
Set up the hosts map to contain
only fully qualified names. The problem
is that attempts to look up an unqualified hostname would then fail
with NIS, whereas such attempts would succeed with DNS.
-
Include both the fully qualified and unqualified names in the
hosts map. A caveat is that it is not defined as
to which hostname, qualified or unqualified, is returned first in the
list of hostnames returned by gethostbyaddr( ).
In other words, NIS has no concept of a canonical form for hostnames,
unlike DNS. You can mitigate this by ensuring that for a given IP
address there is just one entry in the hosts
file used to build the hosts maps and ensuring
that the fully qualified hostname is listed first in the
hosts entry for a given IP address. If you take
this route, it is a good idea to use fully qualified hostnames in
netgroups.
The fully qualified versus unqualified hostname issue can produce
practical problems on the server side of services like NFS and
rlogin, which have lists of hostnames to control
access. If the server has both NIS and DNS enabled, then it is
possible that sometimes clients will have hostnames that appear as
unqualified, and sometimes as fully qualified. Unless the hostnames
that appear in files such as
/etc/dfs/dfstab or
/etc/hosts.equiv correspond with what the
directory service uses, access will be mistakenly denied. For
example, while we have not covered NFS operation yet, this is as good
as place as any to explain a common NFS access problem when DNS is
being used to resolve hostnames
to IP addresses. Suppose you have
the following entry in
/etc/dfs/dfstab:
share -o rw=gonzo /export
If DNS is being used, NFS client gonzo will be denied access. This is
because if DNS is being used to resolve hostnames to IP addresses, it
is also being used to resolve IP addresses to hostnames, and DNS
always generates fully qualified hostnames. Thus if
gonzo is in the
sales.polygon.com domain, then the following
gives
gonzo access:
share -o rw=gonzo.sales.polygon.com /export
The qualified versus unqualified hostname issue is one that has the
potential for causing you major grief, and at the end of the day, you
may decide that it is far simpler to use DNS across the board. If you
do opt to use both NIS and DNS, for consistent results, the following
is recommended:
-
Place in the hosts map only unqualified hostnames and only hosts that
belong to the same DNS domain that the NIS domain is based upon.
-
Place nis before dns in
the hosts entry of
nsswitch.conf. This way, if a host is in NIS,
then you will consistently use its unqualified form. If you had DNS
before NIS, then there would be no point in having NIS, except as a
fallback in case DNS became unavailable. In that case, you would find
that when DNS failed, access control lists set up to use the
qualified hostname form would not suddenly result in access failures.
-
Configure nsswitch.conf to return an error if
NIS is down:
hosts: files nis [UNAVAIL=return] dns
This seems nonintuitive, since it means that if NIS is down, you
won't be able to resolve hostnames and addresses. Let's
suppose that you had the following in
nsswitch.conf:
hosts: files nis dns
Now suppose gonzo is in NIS, and
gonzo.sales.polygon.com is in DNS.
Assume /etc/hosts.equiv contains an entry for
gonzo. If you use rlogin to log in from
gonzo to another machine, while NIS is up, then
you will be able to log in without a password prompt. This is because
when NIS is up, the IP address of gonzo is
resolved by gethostbyaddr( ) to gonzo. When NIS
is down, you will get a password prompt, because the IP address is
resolved in DNS to gonzo.sales.polygon.com. A workaround would be to
place both gonzo and
gonzo.sales.polygon.com in the
/etc/hosts.equiv file, but this is prone to error.
Of course, if you do configure nsswitch.conf to
return an error if NIS is down, then when NIS is down, you will not
be able to access hostnames that are in a different DNS domain. For
example:
% telnet quote.triangle.com
Not to belabor the point, but if NIS availability is a concern for
you, and you are running DNS, then you will want to give serious
consideration to not using the hosts map in
nsswitch.conf:
hosts: dns
 |  |  |
| 5.2. Implementation |  | 5.4. Centralized versus distributed management |
