Fully qualified and unqualified hostnames (Managing NFS and NIS, 2nd Edition)

Book Home

Previous

Next

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
```