Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)
Previous Next

What Is a Naming Service?

Naming services store information in a central place, which enables users, machines, and applications to communicate across the network. This information can include the following.

  • Machine (host) names and addresses

  • User names

  • Passwords

  • Access permissions

  • Group membership, printers, and so on

Without a central naming service, each machine would have to maintain its own copy of this information. Naming service information can be stored in files, maps, or database tables. If you centralize all data, administration becomes easier.

Naming services are fundamental to any computing network. Among other features, naming service provide functionality that does the following.

  • Associates (binds) names with objects

  • Resolves names to objects

  • Removes bindings

  • Lists names

  • Renames

A network information service enables machines to be identified by common names instead of numerical addresses. This makes communication simpler because users do not have to remember and try to enter cumbersome numerical addresses like

For example, take a network of three machines that are named, pine, elm, and oak. Before pine can send a message to either elm or oak, pine must know their numerical network addresses. For this reason, pine keeps a file, /etc/hosts or /etc/inet/ipnodes, that stores the network address of every machine in the network, including itself.

Illustration shows pine, elm, and oak machines with respective IP addresses listed on pine.

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

Illustration shows machines keeping all IP addresses of machines on network in their respective /etc/hosts file.

In addition to storing addresses, machines store security information, mail data, network services information and so on. As networks offer more services, the list stored of information grows. As a result, each machine might need to keep an entire set of files which are similar to /etc/hosts or /etc/inet/ipnodes.

A network information service stores network information on a server, which can be queried by any machine.

The machines are known as clients of the server. The following figure illustrates the client-server arrangement. 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. Doing so reduces errors, inconsistencies between clients, and the sheer size of the task.

Illustration shows server and clients in client-server computing relationship.

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

Although the main purpose of a network information service is to centralize information, the network information service can also simplify network names. For example, assume your company has set up a network which is connected to the Internet. The Internet has assigned your network the network number and the domain name Your company has two divisions, Sales and Manufacturing (Manf), so its network is divided into a main net and one subnet for each division. Each net has its own address.

Diagram shows and two subnets with IP addresses.

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

Diagram shows and two subnets with descriptive names.

Instead of addressing mail or other network communications to, mail could be addressed to doc. Instead of addressing mail to or, mail could be addressed to sales.doc or manf.doc.

Names are also more flexible than physical addresses. Physical networks tend to remain stable, but company organization tends to change.

For example, assume that the network is supported by three servers, S1, S2, and S3. Assume that two of those servers, S1 and S3, support clients.

Illustration shows domain with three servers, two of which have three clients each.

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

Table 1-1 Representation of network

Network Address

Network Name







C1, C2, C3



C4, C5, C6

Now, assume that you create 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.

Diagram shows adding third division called Test without adding a third subnet.

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

Diagram shows Test Division with its own dedicated network.

Thus, when an organization changes, its network information service can change its mapping as shown here.

Illustration shows change in network mapping where some clients move from one server to another.

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

Subsequent changes in your organization would be accommodated by changes to the network information structure without reorganizing the network structure.

Previous Next

  Published under the terms fo the Public Documentation License Version 1.01. Design by Interspire