Chapter 5. Living with Multiple Directory Servers

5.1.1. DNS versus NIS

DNS provides a hierarchical hostname management system that spans the entire Internet. Each level in the hierarchy designates authoritative name servers that contain maps of hostnames and IP addresses, similar to the NIS hosts map but on a larger scale. The DNS server for a large name service domain would have host information merged from dozens of NIS domains. First among the advantages of DNS is its ability to decentralize responsibility for the maintenance of hostname-to-IP address mappings and the resulting domain name qualification that is used to differentiate identically named hosts.

Decentralized name management means that each organization running a name service domain -- whether it is a subdivision of a corporation or an entire company -- can maintain its own host information without having to notify some central authority of changes in its local configuration. Host information is published through the authoritative name server for that domain, and hosts in other name service domains retrieve information from the name server when needed. Every domain knows how to reach the next highest level in the name space hierarchy, and it can generally find most of its peer name servers within the same organization. If a name server does not know how to reach the name server for another domain, it can ask the next higher level domain name server for assistance.

For example, Princeton University is part of the educational, or .edu, domain. The domain name for the entire university is princeton.edu, and it is further divided by department:

cs.princeton.edu

politics.princeton.edu

history.princeton.edu

and so on. Each of the name servers for the departmental name service domains knows how to reach most of the others; therefore each department can run its own systems without having to notify a campus-wide network manager of any changes to host information. There is also a name server for the entire princeton.edu domain that points to lower-level name servers for incoming queries and locates other domains in .edu, .com, or .gov for outbound requests.

In a world in which every machine name must be unique, all of the good names are taken very quickly. DNS allows each domain to have a distinct name space, so that two domains may have hosts with the same name: the name service domain suffix distinguishes them on a higher level in the hierarchy. This is a job that cannot be performed by NIS, since the concatenation of /etc/hosts files from several different domains would result in hostname clashes. If the NIS domains are left independent, there is no global naming authority, because NIS lacks a mechanism for cross-domain hostname queries.

5.1.2. DNS integration with NIS

Hostnames are managed in a hierarchy. Each host manages its own name, so the hosts are the "leaf nodes" in this management tree. Hosts are grouped together into NIS or DNS domains, creating a two-level tree. DNS domains may be further grouped together by company, department, or physical location, adding more levels to the management hierarchy. NIS fits into the DNS management scheme at the lowest level in this hierarchy.

Within a single DNS domain, there may be many physical networks with several system administrators. NIS provides a system for the independent management of these small networks; NIS host map information can be combined to form the DNS host file. The approaches for doing this are described in Section 5.2, "Implementation" later in this chapter.

5.1.3. NIS and DNS domain names

If an Internet DNS is used in conjunction with NIS, it is helpful to tie the NIS domain names to the DNS domain name. Deriving NIS domain names from the DNS domain name links the two management schemes: the DNS-derived portion of the NIS domain name indicates where the NIS domain looks for its hostname information. Joining NIS and DNS domain names also makes sense if you have a single DNS domain that spans several physical locations. Each office will have its own networks, and its own NIS domains, so using the DNS domain name in the NIS domain name indicates how these locations fit into the "big picture."

For example, the Polygon Company uses the DNS domain name polygon.com. It has four NIS domains in its main office, which uses the polygon.com DNS domain name. The NIS domain names use the DNS domain name as a suffix:

bos-engin.polygon.com

philly-engin.polygon.com

finance.polygon.com

sales.polygon.com

If NIS is set up as the primary directory service, then Solaris versions of sendmail assume that an NIS domain name was derived from a DNS domain name, and they will strip the first component to derive the mail domain name. That is, if your NIS domain name is bos-engin.polygon.com, then sendmail uses polygon.com as your mail domain name by default. There may be many NIS domains in this DNS domain; sendmail strips off the leading component to form the DNS domain name.

However, if there are multiple NIS domains within the DNS domain -- several sales offices in different cities, for example -- then the NIS domain names should reflect the subdivision of the DNS domain, as shown in Table 5-1.

Table 5-1. Subdividing a DNS domain into NIS domains

NIS Domain	DNS Domain
boston.sales.polygon.com	.sales.polygon.com
philly.sales.polygon.com	.sales.polygon.com
rahway.sales.polygon.com	.sales.polygon.com
waltham.engin.polygon.com	.engin.polygon.com
alameda.engin.polygon.com	.engin.polygon.com

Because the NIS domain name contains four dot-separated components, sendmail drops the first component and uses the remainder as a DNS domain name. This allows all of the sales offices to be treated as a single administrative unit for mail and hostname management, even though they require distinct NIS domains.

It is important to note that each single administrative unit, whether it is implemented with one NIS domain or multiple NIS domains must share the same map entries. Thus, all the hosts listed in the hosts map of waltham.engin.polygon.com must be listed in the hosts map of alameda.engin.polygon.com. The converse must be true as well. Getting all hosts to agree on usernames, uid/gid values, and host addresses is a prerequisite for adding other distributed services such as the Network File System.

5.1.4. Domain aliases

Some systems impose a fairly small limit on the length of a domain name. If you've chosen a long NIS domain name, say nesales.East.Sun.COM, then implementations of NIS that restrict the length of a domain name will not be able to bind to a server.

You could build a second NIS domain with a shorter name and duplicate the maps from the first domain, but this leaves you with twice the administrative work. An easier solution to this problem is to create a domain name alias for the longer name by making a symbolic link in the NIS server directory /var/yp on each server host:

master# cd /var/yp 
master# ln -s nesales.East.Sun.COM nesales

NIS servers in the fully qualified domain respond to requests for service for the truncated domain name because they believe they have a set of maps for the specified domain. It is of no consequence that the "directory" is really a link to another domain's directory. This trick can also be used to force two distinct NIS domains to share exactly the same set of maps.

In a simple network, your domain names are likely to be short and easily managed. However, if you integrate DNS with NIS, and choose NIS domain names based on name service domains, you may end up with long, multicomponent names such as grad.history.princeton.edu. Using symbolic links to create aliases for long names may be necessary to make all of your NIS clients find NIS servers.