Managing NFS and NIS, 2nd Edition - Mike Eisler [22]
DNS has stood the test of time. In 1993, a memorandum (RFC 1401) was written by the chair of the Internet Architecture Board that noted that the transition from hosts.txt to DNS was largely complete. This is fortuitous, as the World Wide Web was about to explode from tens of thousands of hosts to millions. DNS proved capable of handling that explosion.
Network Information Service (NIS)
NIS was developed by Sun Microsystems in the mid-1980s to solve a problem that until then had no solution in the Unix world. Let's return to the telephone directory service concept. One nice thing about calling your telephone company's directory service is that the operator (the server) is more apt to have up-to-date information than you would. Your telephone book is replaced once a year, whereas the server's information is updated more frequently, perhaps instantly with each new telephone number assignment and de-assignment. When networking was added to Unix systems, system administrators very quickly ran into difficulties keeping files like /etc/hosts (holds hostname to host address mappings) and /etc/passwd (holds username, user identifier, password). If a system administrator had 100 systems, then adding a host to a network or a user to the organization meant the tedium of updating the /etc/hosts or /etc/passwd files on all 100 systems. NIS, originally called the Yellow Pages or YP, was invented to simplify management of these files by changing the underlying programming interfaces, such as gethostbyname( ) and getpwnam( ), to use NIS client libraries.
While DNS was being developed around the time NIS was, DNS was mostly concerned with the directory of hostnames and addresses, whereas NIS went beyond that. In addition, DNS was designed so that a host in one domain could access information from other domains, whereas NIS shared the limitations of the early Internet's hosts.txt file: flat and not very dynamic.
We will go into much more detail on how NIS operates in Chapter 3.
NIS+
In 1992, Sun Microsystems released NIS+ with Solaris 2.0. Despite its name, NIS+ was more different than it was similar to NIS. NIS+ was developed to address several deficiencies in NIS:
Hierarchical operation
While NIS was designed to be split into unique domains, there was no simple way for a client in one domain to get directory information from another domain. NIS+ addressed this by supporting a multilevel hierarchy in a manner similar to DNS.
Security
There are really two issues here. First is that some kinds of directory information need to be kept more secure than others, such as a directory containing credit card numbers. The directory server needs to know who is accessing the data, and properly authenticate the client. Second, the client needs to be certain that the server is the true authority for the service. An attacker in the middle between the client and real server could masquerade as the server and return bogus information. NIS+ deals with both these issues by supporting mutual authentication: the client and server authenticate each other, via a secure form of RPC known as RPC/dh, which is described in Chapter 12.
Updates
Updating a NIS database and propagating the changes is a cumbersome process. Only the system administrator can make updates (with few exceptions), and the changes must be pushed to each replica server by pushing the entire database, even if only one record changes. NIS+ supports the ability to allow users to update directory entries they have access rights to. For example, a user changes the name that appears in the password database, which might be necessary upon a status change like a new job title, or a new surname as a result of a marriage or divorce. NIS+ servers have the capability to accept incremental updates, which allows the updates to be more efficiently