Managing NFS and NIS, 2nd Edition - Mike Eisler [54]
The main argument for using DNS only is that it consolidates hostname management under one distributed service, instead of having it split across two services. The drawbacks to this approach are that each host is then dependent upon both an NIS and a DNS server for normal operation (if NIS is running), and a reliable DNS server or sufficient resolver information is required to make each small network self-supporting. Widespread use of DNS to replace NIS host maps suffers from the same server availability problems that NIS does — the entire network is dependent upon reliable and well-behaved servers.
Run NIS on client, enable DNS on NIS client
In this approach, the name services switch file, nsswitch.conf, is set up so that both nis and dns appear in the hosts entry of the nsswitch.conf file. The host maps should not have the "Inter-Domain" key enabled since all that will do is result in hostname resolutions via DNS occurring twice: once in the NIS client and once in the NIS server.
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