Purpose of Name Services

Name services store information that users, workstations, and applications must have to communicate across the network. Without a name service, each workstation would have to maintain its own copy of this information.

For example, take a simple network of three workstations, pine, elm, and oak:

Before pine can send a message to either elm or oak, it must know their network addresses. For this reason, it keeps a file, /etc/hosts, that stores the network address of every workstation in the network, including itself.

Likewise, in order for elm and oak to communicate with pine or with each other, they must keep similar files.

Addresses are not the only network information that workstations need to store. They also need to store security information, mail information, information about their Ethernet interfaces, about network services, about groups of users allowed to use the network, about services offered on the

network, and so on. As networks offer more services, the list grows. As a result, each workstation may need to keep an entire set of files similar to /etc/hosts:

As this information changes, administrators must keep it current on every workstation in the network. In a small network this is simply tedious, but on a medium or large network, the job becomes not only time-consuming, but nearly unmanageable.

A network information service solves this problem. It stores network information on servers and provides it to any workstation that asks for it:

The workstations are known as clients of the server. Whenever information about the network changes, instead of updating each client's local file, an administrator updates only the information stored by the network information service. This reduces errors, inconsistencies between clients, and the sheer size of the task.

This arrangement, of a server providing centralized services to clients across a network, is known as client-server computing.

Although the chief purpose of a network information service is to centralize information, another is to simplify network names. A network information service enables workstations to be identified by common names instead of numerical addresses. (This is why these services are sometimes called "name services.") This makes communication simpler because users don't have to remember and try to enter cumbersome numerical addresses like "129.44.3.1." Instead, they can use descriptive names like Sales, Lab1, or Arnold.

For example, assume that a fictitious company called Wizard, Inc. has set up a network and connected it to the Internet. The Internet has assigned Wizard, Inc. the network number of 129.44.0.0. Wizard, Inc. has two divisions, Sales and Eng, so its network is divided into two subnets, one for each division. Each subnet has its own address:

Each division could be identified by its network address, as shown above, but descriptive names made possible by name services would be preferable:

So, instead of addressing mail or other network communications to 129.44.1.0, they could be addressed simply to Wiz. Instead of addressing them to 129.44.2.0 or 129.44.3.0, they could be addressed to Sales.Wiz or Eng.Wiz.

Names are also more flexible than physical addresses. While physical networks tend to remain stable, the organizations that use them tend to change. A network information service can act as a buffer between an organization and its physical network. This is because a network information service is mapped to the physical network, not hard-wired to it. For example,

assume that the Wiz network is supported by three servers, S1, S2, and S3, and that two of those servers, S1 and S3, support clients:

Clients C1, C2, and C3 would obtain their network information from server S1. Clients C4, C5, and C6 would obtain it from server S3. The resulting network is summarized in Table 2-1. (The table is a generalized representation of that network but does not resemble an actual network information map.)

Table 2-1

Network Address	Network Name	Server	Clients
129.44.1.0	Wiz	S1
129.44.2.0	Sales.Wiz	S2	C1, C2, C3
129.44.3.0	Eng.Wiz	S3	C4, C5, C6

Now assume that Wizard, Inc. created a third division, Testing, which borrowed some resources from the other two divisions, but did not create a third subnet. The physical network would then no longer parallel the corporate structure:

Traffic for the Test Division would not have its own subnet, but would instead be split between 129.44.2.0 and 129.44.3.0. However, with a network information service, the Test Division traffic could have its own dedicated network:

Thus, when an organization changes, its network information service can simply change its mapping:

Now clients C1 and C2 would obtain their information from server S2; C3 and C4 from server S4; and C5 and C6 from server S3.

Subsequent changes in the Wizard Inc., organization would continue to be accommodated by changes to the "soft" network information structure without reorganizing the "hard" network structure.

Overview of DNS

DNS, the Domain Naming Service, is the name service provided by the Internet for TCP/IP networks. It was developed so that workstations on the network could be identified with common names instead of Internet addresses.

The collection of networked workstations that use DNS are referred to as the DNS namespace. The DNS namespace can be divided into a hierarchy of domains. A DNS domain is simply a group of workstations. Each domain is supported by two or more name servers: a principal server and one or more secondary servers:

Both principal and secondary servers run the DNS software and store the names and addresses of the workstations in the domain. Principal servers store the original information and secondary servers store copies.

DNS clients request service only from the servers that support their domain. If the domain's server does not have the information the client needs, it forwards the request to its parent server, which is the server in the next-higher domain in the hierarchy. If the request reaches the top-level server, the top-level server determines whether the domain is valid. If it is not valid, the server returns a "Not Found" message to the client. If the domain is valid, the server routes the request down to the server that supports that domain.

DNS and the Internet

DNS is the network information service used by the Internet. The Internet is a vast network that connects many smaller networks across the world. Organizations with networks of any size can join the Internet by applying for membership in two domain hierarchies: an organizational one and a geographical one.

The Organizational hierarchy divides its namespace into the top-level domains listed in Table 2-2.

Table 2-2

Domain	Purpose
COM	Commercial organizations
EDU	Educational institutions
GOV	Government institutions
MIL	Military groups
NET	Major network support centers
ORG	Nonprofit organizations and others
INT	International organizations

The Geographic hierarchy assigns each country in the world a two- or three-digit identifier and provides official names for the geographic regions within each country.

A site using DNS can use any top-level names it prefers, but if it wants to connect to the Internet, it cannot use any of the organizational or geographic names reserved by the Internet's top-level domains.

Networks that join the Internet append their Internet domain name to their own names. For example, if the Wiz domain from the previous example joined the Internet, it would be placed in the "COM" domain.

Thus the full Internet names of the Wiz domains would be:

  Wiz.COM
  Sales.Wiz.COM
  Test.Wiz.COM
  Eng.Wiz.COM

The DNS service does not require domain names to be capitalized though they may be. Here are some examples of machines and domain names:

boss.Wiz.COM
neverhome.Sales.Wiz.COM
quota.Sales.Wiz.COM
lab.Test.Wiz.COM
worknights.Eng.Wiz.COM

The Internet regulates administration of its domains by granting each domain authority over the names of its workstations, and expecting each domain to delegate authority to the levels below it. Thus, the COM domain has authority over the names of the workstations in its domain. It also authorizes the formation of the Wiz.COM domain and delegates authority over the names in that domain. The Wiz.COM domain, in turn, assigns names to the workstations in its domain and approves the formation of the Sales.Wiz.COM, Test.Wiz.COM, and Eng.Wiz.COM domains.

DNS Name Resolution and Mail Delivery

DNS provides two principal services: it translates hostnames to internet protocol (IP) addresses (and also addresses to names) and it helps mail agents deliver mail along the Internet.

The process of translating names to addresses (and addresses to names) is called name resolution. To accomplish this, DNS stores the names and IP addresses of all the workstations in each domain in a set of maps, called zone files. One type of zone file stores IP addresses by name. When someone attempts a remote procedure such as ftp or telnet, it provides the name of the remote workstation. DNS looks up the name in the zone file and converts (or resolves) it into its IP address. The IP address is sent along with the remote procedure so the receiving workstation can know who sent the request. This enables the receiving workstation to reply without having to be a DNS client.

Another type of zone file stores workstation names by IP address. It uses them to convert IP addresses to workstation names, a process called reverse resolution. Reverse resolution is used primarily to verify the identity of the workstation that sent a message or to authorize remote operations on a local workstation (remote operations are usually authorized per IP addresses, which are more stable than workstation names).

To deliver mail across the Internet, DNS uses mail exchange records. Many organizations don't allow mail that comes across the Internet to be delivered directly to workstations within the organization. Instead, they use a central mailhost (or a set of mailhosts) to intercept incoming mail messages and route them to their recipients.

The purpose of a mail exchange record is to identify the mailhost that services each workstation. Therefore, a mail exchange record lists the DNS domain names of remote organizations and either the IP address or the name of its corresponding mailhost. For example:

DNS Domain	Mailhost
International.Com.	129.44.1.1
Sales.Wiz.Com.	SalesWizMailer
Eng.Wiz.Com.	EngWizMailer
Fab.Com.	FabMailer

When the mail agent receives a request to send mail to another domain, it parses the name of the recipient backwards and looks for a match in the table. For example, if it receives a request to send mail to neverhome.Sales.Wiz.Com, it first extracts the topmost label, Com. It examines the mail exchange record to see if there is an entry for Com. Since there is none, it continues parsing. It extracts the next label and looks for an entry for Wiz.Com; since there is none, it continues looking. The next entry it looks for is Sales.Wiz.Com. As you can see in the table above, the mailhost for that domain is SalesWizMailer. Because that is a workstation name, the mail agent asks DNS to resolve it. When DNS provides that mailhost's IP address, the mail agent sends the message.

If, instead of the mailhost name, the mail exchange record had specified an IP address, the mail agent would have sent the message directly to that address, since it would have needed no name resolution from DNS.

Overview of NIS

NIS was developed independently of DNS and had a slightly different focus. Whereas DNS focused on making communication simpler by using workstation names instead of addresses, NIS focused on making network administration more manageable by providing centralized control over a variety of network information. As a result, NIS stores information not only about workstation names and addresses, but also about users, the network itself, and network services. This collection of network information is referred to as the NIS namespace.

NIS uses a client-server arrangement similar to DNS. Replicated NIS servers provide services to NIS clients. The principal servers are called master servers, and for reliability, they have backup, or replica servers. Both master and replica servers use the NIS information retrieval software and both store NIS maps.

NIS, like DNS, uses domains to arrange the workstations, users, and networks in its namespace. However, it does not use a domain hierarchy; an NIS namespace is flat. Thus, this physical network:

would be arranged into one NIS domain:

An NIS domain can't be connected directly to the Internet. However, organizations that want to use NIS and be connected to the Internet can combine NIS with DNS. They use NIS to manage all local information and DNS for hostname resolution. NIS provides special client routines for this purpose ("DNS forwarding"). When a client needs access to any type of information except IP addresses, the request goes to the client's NIS server. When a client needs name resolution, the request goes to the DNS server. From the DNS server, the client has access to the Internet in the usual way.

NIS Maps

Like DNS, NIS stores information in a set of files called maps, instead of zones. However, NIS maps were designed to replace UNIX /etc files, as well as other configuration files, so they store much more than names and addresses. As a result, the NIS namespace has a large set of maps, as shown in Table 2-3 on page 23.

NIS maps are essentially bi-column tables. One column is the key and the other column is information about the key. NIS finds information for a client by searching through the keys. Thus, some information is stored in several maps because each map uses a different key. For example, the names and addresses of workstations are stored in two maps: hosts.byname and hosts.byaddr. When a server has a workstation's name and needs to find its address, it looks in the hosts.byname map. When it has the address and needs to find the name, it looks in the hosts.byaddr map.

Table 2-3

NIS Map	Description
bootparams	Lists the names of the diskless clients and the location of the files they need during booting
ethers.byaddr	Lists the Ethernet addresses of workstations and their corresponding names
ethers.byname	Lists the names of workstations and their corresponding Ethernet addresses
group.bygid	Provides membership information about groups, using the group id as the key
group.byname	Provides membership information about groups, using the group name as the key
hosts.byaddr	Lists the names and addresses of workstations, using the address as the key
hosts.byname	Lists the names and addresses of workstations, using the name as the key
mail.aliases	Lists the mail aliases in the namespace and all the workstations that belong to them
mail.byaddr	Lists the mail aliases in the namespace, using the address as the key

Table 2-3 (Continued)

NIS Map	Description
netgroup	Contains netgroup information, using group name as the key
netgroup.byhost	Contains information about the netgroups in the namespace, using workstation names as the key
netgroup.byuser	Contains netgroup information, using user as the key
netid.byname	Contains the secure RPC netname of workstations and users, along with their UIDs and GIDs
netmasks.byaddr	Contains network masks used with IP subnetting, using address as the key
networks.byaddr	Contains the names and addresses of the networks in the namespace, and their Internet addresses
networks.byname	Contains the names and addresses of the networks in the namespace, using the names as the key
passwd.byname	Contains password information, with username as the key
passwd.byuid	Contains password information, with userid as the key
protocols.byname	Lists the network protocols used
protocols.bynumber	Lists the network protocols used, but uses their number as the key
publickey.byname	Contains public and secret keys for secure RPC
rpc.bynumber	Lists the known program name and number of RPC's
services.byname	Lists the available Internet services
ypservers	Lists the NIS servers in the namespace, along with their IP addresses

Overview of NIS+

NIS+ was designed to replace NIS. NIS addresses the administration requirements of client-server computing networks prevalent in the 1980s. At that time client-server networks did not usually have more than a few hundred clients and a few multipurpose servers. They were spread across only a few remote sites, and since users were sophisticated and trusted, they did not require security.

However, client-server networks have grown tremendously since the mid- 1980's. They now range from 100-10,000 multi-vendor clients supported by 10- 100 specialized servers located in sites throughout the world, and they are connected to several "untrusted" public networks. In addition, the information they store changes much more rapidly than it did during the time of NIS. The size and complexity of these networks required new, autonomous administration practices. NIS+ was designed to address these requirements.

The NIS namespace, being flat, centralizes administration. Because networks in the 90's require scalability and decentralized administration, the NIS+ namespace was designed with hierarchical domains, like those of DNS:

This design enables NIS+ to be used in a range of networks, from small to very large. It also allows the NIS+ service to adapt to the growth of an organization. For example, if a corporation divided itself into two divisions, its NIS+ namespace could be divided into two domains that could be administered autonomously. Just as the Internet delegates administration of domains downward, NIS+ domains can be administered more or less independently of each other.

Although NIS+ uses a domain hierarchy similar to that of DNS, an NIS+ domain is much more than a DNS domain. A DNS domain only stores name and address information about its clients. An NIS+ domain, on the other hand, is a collection of information about the workstations, users, and network services in a portion of an organization.

Although this division into domains makes administration more autonomous and growth easier to manage, it does not make information harder to access. Clients have the same access to information in other domains as they would have had under one umbrella domain. A domain can even be administered from within another domain.

The NIS+ client-server arrangement is similar those of NIS and DNS in that each domain is supported by a set of servers. The principal server is called the master server, and the backup servers are called replicas. Both master and

replica servers run NIS+ server software and both maintain copies of NIS+ tables. Tables store information in NIS+ the way maps store information in NIS. The principal server stores the original tables, and the backup servers store copies.

However, NIS+ uses an updating model that is completely different from the one used by NIS. Since at the time NIS was developed, the type of information it would store changed infrequently, NIS was developed with an update model that focused on stability. Its updates are handled manually and, in large organizations, can take more than a day to propagate to all the replicas. Part of the reason for this is the need to remake and propagate an entire map every time any information in the map changes.

NIS+, however, accepts incremental updates to the replicas. Changes must still be made on the master server, but once made they are automatically propagated to the replica servers and immediately made available to the entire namespace. You don't have to "make" any maps or wait for propagation.

Details about NIS+ domain structure, servers, and clients, are provided in Chapter 3, "Understanding the NIS+ Namespace".

An NIS+ domain can be connected to the Internet via its NIS+ clients, using the name service switch, described below. The client, if it is also a DNS client, can set up its switch configuration file to search for information in either DNS zone files or NIS maps -- in addition to NIS+ tables.

NIS+ stores information in tables instead of maps or zone files. NIS+ provides 16 types of predefined, or system, tables:

Each table stores a different type of information. For instance, the Hosts table stores information about workstation addresses, while the Password table stores information about users of the network.

NIS+ tables provide two major improvements over the maps used by NIS. First, an NIS+ table can be searched by any column, not just the first column (sometimes referred to as the "key"). This eliminates the need for duplicate maps, such as the hosts.byname and hosts.byaddr maps used by NIS. Second, the information in NIS+ tables can be accessed and manipulated at three levels of granularity: the table level, the entry level, and the column level. NIS+ tables -- and the information stored in them -- are described in Chapter 4, "Understanding NIS+ Tables and Information".

NIS+ Security

NIS+ protects the structure of the namespace, and the information it stores, by the complementary processes of authorization and authentication. First, every component in the namespace specifies the type of operation it will accept and from whom. This is authorization. Second, NIS+ attempts to authenticate every request for access to the namespace. Once it identifies the originator of the request, it can find out whether the component has authorized that particular operation for that particular individual. Based on its authentication and the component's authorization, NIS+ carries out or denies the request for access. A full description of this process is provided in Name Services Administration Guide.

NIS+ and the Name Service Switch

NIS+ works in conjunction with a separate program called the name service switch. The name service switch, sometimes referred to as "the switch," enables Solaris 2.x-based workstations to obtain their information from more than one name service; specifically, from local or /etc files, from NIS maps, from DNS zone files, or from NIS+ tables. The switch not only offers a choice of sources, but allows a workstation to specify different sources for different types of information. A complete description of the switch software and its associated files is provided in Chapter 5, "Understanding the Name Service Switch".

NIS+ and Solaris 1.x

Although NIS+ is provided with the Solaris 2.4 package, it can be used by workstations running the Solaris 1.x software in two different ways:

• NIS-compatibility mode
• Solaris 1.x Distribution

NIS-Compatibility Mode

NIS+ provides an NIS-compatibility mode. The NIS-compatibility mode enables an NIS+ server running Solaris 2.4 to answer requests from NIS clients while continuing to answer requests from NIS+ clients. NIS+ does this by providing two service interfaces. One responds to NIS+ client requests, while the other responds to NIS client requests.

This mode does not require any additional setup or changes to NIS clients. In fact, NIS clients are not even aware that the server that is responding isn't an NIS server -- except for some differences including: the NIS+ server running in NIS-compatibility mode does not support the ypupdate and ypxfr protocols and thus it cannot be used as a replica or master NIS server. For more information on NIS-compatibility mode see NIS+ Transition Guide.

---

Note - In Solaris 2.3 and later releases, the NIS-compatibility mode supports DNS forwarding. In Solaris 2.2, support for DNS forwarding is available as a patch. The DNS forwarding patch is not available in Solaris 2.0 and 2.1 releases.

---

Two more differences need to be pointed out. One is that instructions for setting up a server in NIS-compatibility mode are slightly different than those used to set up a standard NIS+ server. For details, see Chapter 7, "Setting Up NIS+". The other is that NIS-compatibility mode has security implications for tables in the NIS+ namespace. Since the NIS client software does not have the capability to provide the credentials that NIS+ servers expect from NIS+ clients, all their requests end up classified as unauthenticated. Therefore, to allow NIS clients to access information in NIS+ tables, those tables must provide access rights to unauthenticated requests. This is handled automatically by the utilities used to set up a server in NIS-compatibility mode, as described in Part II. However, to understand more about the authentication process and NIS-compatibility mode, read NIS+ Transition Guide and the chapter on security in Name Services Administration Guide.

Solaris 1.x Distribution

NIS+ provides a separate package called the Solaris 1.x Distribution, which enables workstations running Solaris 1.x to operate as NIS+ servers without having to upgrade to Solaris 2.x. This use of NIS+ is not recommended, however. It is better to upgrade to Solaris 2.x before making the transition to NIS+. See NIS+ Transition Guide for more information on how to make the transition from NIS to NIS+.

The NIS+ Solaris 1.x Distribution consists of the NIS+ daemon, all the NIS+ commands, the NIS+ client libraries, and a README file. It is delivered in a tar file, NISPLUS.TAR, included in the Solaris 2.4 CD-ROM. To transfer the distribution from the CD-ROM to a Solaris 1.x-based workstation, first mount the CD-ROM, then transfer the NISPLUS.TAR file using the tar command. If you have network access to the Solaris 1.x Distribution, you can ftp or rcp it. Instructions for installing it are provided in the README file.

NIS+ Administration Commands

NIS+ provides a full set of commands for administering a namespace. They are described in Name Services Administration Guide. Table 2-4, below, summarizes them.

Table 2-4

Command	Description
nisaddcred	Creates credentials for NIS+ principals and stores them in the Cred table.
nisaddent	Adds information from /etc files or NIS maps into NIS+ tables.
nis_cachemgr	Starts the NIS+ Cache Manager on an NIS+ client.
niscat	Displays the contents of NIS+ tables.
nischgrp	Changes the group owner of an NIS+ object.
nischmod	Changes an object's access rights.
nischown	Changes the owner of an NIS+ object.
nischttl	Changes an NIS+ object's time-to-live value.

Table 2-4 (Continued)

Command	Description
nisdefaults	Lists an NIS+ object's default values: domain name, group name, workstation name, NIS+ principal name, access rights, directory search path, and time-to-live.
nisgrep	Searches for entries in an NIS+ table.
nisgrpadm	Creates or destroys an NIS+ group, or displays a list of its members. Also adds members to a group, removes them, or tests them for membership in the group.
nisinit	Initializes an NIS+ client or server.
nisln	Creates a symbolic link between two NIS+ objects.
nisls	Lists the contents of an NIS+ directory.
nismatch	Searches for entries in an NIS+ table.
nismkdir	Creates an NIS+ directory and specifies its master and replica servers.
nispasswd	Changes password information stored in the NIS+ Passwd table.
nisrm	Removes NIS+ objects (except directories) from the namespace.
nisrmdir	Removes NIS+ directories and replicas from the namespace.
nissetup	Creates org_dir and groups_dir directories and a complete set of (unpopulated) NIS+ tables for an NIS+ domain.
nisshowcache	Lists the contents of the NIS+ shared cache maintained by the NIS+ Cache Manager.
nistbladm	Creates or deletes NIS+ tables, and adds, modifies or deletes entries in an NIS+ table.
nisupdkeys	Updates the public keys stored in an NIS+ object.

NIS+ API

The NIS+ application programmer's interface (API) is a group of functions that can be called by an application to access and modify NIS+ objects. The NIS+ API has 54 functions that fall into nine categories:

• Object manipulation functions (nis_names)
• Table access functions (nis_tables)
• Local name functions (nis_local_names)
• Group manipulation functions (nis_groups)
• Application subroutine functions (nis_subr)
• Miscellaneous functions (nis_misc)
• Database access functions (nis_db)
• Error message display functions (nis_error)
• Transaction log functions (nis_admin)

The functions in each category are summarized in the Network Interfaces Programmer's Guide. The category names match the names by which they are grouped in the NIS+ man pages.

What Next?

The remainder of this book shifts focus from name services in general toward NIS+ and DNS in particular. NIS is no longer mentioned except when discussing how to use it with NIS+. Before attempting to set up NIS+, be sure you understand the information presented in the remaining chapters of Part I:

• Chapter 3, "Understanding the NIS+ Namespace," describes NIS+ directories, domains, servers, clients, and the NIS-compatibility mode.
• Chapter 4, "Understanding NIS+ Tables and Information," describes NIS+ tables and the information in each of the 16 system tables.
• Chapter 5, "Understanding the Name Service Switch," describes the switch.