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

Chapter 3 Domain Name System (Overview)

This chapter describes the structure and provides an overview of the Domain Name System (DNS).

Note –

One of the most common and important uses of DNS is connecting your network to the global Internet. To connect to the Internet, your network IP address must be registered with whomever is administering your parent domain.

This chapter covers the following topics.

DNS Basics

The Domain Name System (DNS) is an application–layer protocol that is part of the standard TCP/IP protocol suite. This protocol implements the DNS naming service, which is the naming service used on the Internet.

This section introduces the basic DNS concepts. It assumes that you have some familiarity with network administration, particularly TCP/IP, and some exposure to other naming services, such as NIS+ and NIS.

Refer to Chapter 4, Administering DNS (Tasks) for information regarding initial setup and configuration of DNS.

Note –

DNS, NIS+, NIS, and FNS provide similar functionality and sometimes use the same terms to define different entities. Thus, this chapter takes care to define terms like domain and name server according to their DNS functionality, a very different functionality than NIS+ and NIS domains and servers.

Name-to-Address Resolution

Though it supports the complex, worldwide hierarchy of computers on the Internet, the basic function of DNS is actually very simple: providing name-to-address resolution for TCP/IP-based networks. Name-to-address resolution, also referred to as mapping, is the process of finding the IP address of a computer in a database by using its host name as an index.

Name-to-address mapping occurs when a program running on your local machine needs to contact a remote computer. The program most likely will know the host name of the remote computer but might not know how to locate it, particularly if the remote machine is in another company, miles from your site. To get the remote machine's address, the program requests assistance from the DNS software running on your local machine, which is considered a DNS client.

Your machine sends a request to a DNS name server, which maintains the distributed DNS database. The files in the DNS database bear little resemblance to the NIS+ host or ipnodes Table or even the local /etc/hosts or /etc/inet/ipnodes file, though they maintain similar information: the host names, the ipnode names, IPv4 and IPv6 addresses, and other information about a particular group of computers. The name server uses the host name your machine sent as part of its request to find or “resolve” the IP address of the remote machine. It then returns this IP address to your local machine if the host name is in its DNS database.

The following figure shows name-to-address mapping as it occurs between a DNS client and a name server, probably on the client's local network.

Figure 3–1 Name to Address Resolution

Diagram shows client sending host name data to name server over local network.

If the host name is not in that name server's DNS database, this indicates that the machine is outside of its authority, or, to use DNS terminology, outside the local administrative domain. Thus, each name server is spoken of as being “authoritative” for its local administrative domain.

Fortunately, the local name server maintains a list of host names and IP addresses of root domain name servers, to which it will forward the request from your machine. These root name servers are authoritative for huge organizational domains, as explained fully in DNS Hierarchy and the Internet. These hierarchies resemble UNIX file systems, in that they are organized into an upside down tree structure.

Each root name server maintains the host names and IP addresses of top level domain name servers for a company, a university, or other large organizations. The root name server sends your request to the top-level name servers that it knows about. If one of these servers has the IP address for the host you requested, it will return the information to your machine. If the top-level servers do not know about the host you requested, they pass the request to second-level name servers for which they maintain information. Your request is then passed on down through the vast organizational tree. Eventually, a name server that has information about your requested host in its database will return the IP address back to your machine.

The following figure shows name-to-address resolution outside the local domain.

Figure 3–2 Name to Address Resolution for a Remote Host

Diagram shows DNS client sending host data to list of servers on remote network until the target name server returns IP address.

DNS Administrative Domains

From a DNS perspective, an administrative domain is a group of machines which are administered as a unit. Information about this domain is maintained by at least two name servers, which are “authoritative” for the domain. The DNS domain is a logical grouping of machines. The domain groupings could correspond to a physical grouping of machines, such as all machines attached to the Ethernet in a small business. Similarly, a local DNS domain could include all machines on a vast university network that belong to the computer science department or to university administration.

For example, suppose the Ajax company has two sites, one in San Francisco and one in Seattle. The domain might be in Seattle and the domain might be in San Francisco. One part of the domain would be in one city, the other part in the second city.

Each administrative domain must have its own unique subdomain name. Moreover, if you want your network to participate in the Internet, the network must be part of a registered administrative domain. The section Joining the Internet has full details about domain names and domain registration.

in.named and DNS Name Servers

As mentioned previously, name servers in an administrative domain maintain the DNS database. They also run the in.named daemon, which implements DNS services. in.named is a public domain TCP/IP program and is included with the Solaris operating environment.

Note –

The in.named daemon is also called the Berkeley Internet Name Domain service, or BIND, because it was developed at the University of California at Berkeley.

There are three types of DNS name servers.:

Each domain must have one master server and should have at least one slave server to provide backup. Implementing DNS explains primary and secondary servers in detail.

Server Configuration and Data File Names

To function correctly, the in.named daemon requires a configuration file and four data files.

Configuration File

The master server configuration file is /etc/named.conf. The configuration file contains a list of domain names and the file names containing host information. See The named.conf File for additional information on the named.conf file.

Names of DNS Data Files

If you are internally consistent, you can name the zone data files anything you want. This flexibility might lead to some confusion when working at different sites or referring to different DNS manuals and books.

For example, the file names used in Sun manuals and at most many Solaris sites vary from those used in the book DNS and BIND published by O'Reilly & Associates and both of those nomenclatures have some differences from that used in the public-domain Name Server Operations Guide for BIND.

In addition, this manual and other DNS documentation use generic names that identify a file's main purpose, and specific example names for that file in code samples. For example, this manual uses the generic name hosts when describing the function and role of that file, and the example names db.doc and db.sales in code samples.

The required data files are the following.


An include file is any file named in an $INCLUDE() statement in a DNS data file. $INCLUDE files can be used to separate different types of data into multiple files for your convenience. See $INCLUDE Files.

For reference purposes, the following table compares BIND file names from the above mentioned sources.

Table 3–1 File Name Examples

Solaris Names 

O'Reilly Names or Other Names 

U.C. Berkeley Names 

Content and Purpose of File 

/etc/named.conf, same file name for all three sources

BIND 8.1 adds a new named.conf file to replace the earlier named.boot file. This configuration file adds security, startup options, logging. It specifies the type of server it is running on and selectively applies options on a per-zone or per-server basis, rather than all zones or servers. It contains a list of domain names and the names of the data files.

/etc/resolv.conf, same file name for all three sources

This file resides on every DNS client (including DNS servers) and designates the servers that the client queries for DNS information.




This file establishes the names of root servers and lists their addresses. 

Generic: hosts Examples: db.doc, db.sales

Generic: db.domain Examples:, db.fx

Generic: hosts

Example: ucbhosts

This file contains all the data about the machines in the local zone that the server serves. 

Generic: hosts.rev Examples: doc.rev

Generic: db.ADDR Examples db.192.249.249 db.192.249.253


This file specifies a zone in the domain, a special domain that allows reverse (address-to-name) mapping.


Generic: db.cache Example: db.127.0.0


This file specifies the address for the local loopback interface, or local host. 

$INCLUDE files, same convention for all three sources

Any file identified by an $INCLUDE() statement in a data file.

Domain Names

A domain name is the name assigned to a group of systems on a local network that share DNS administrative files. A domain name is required for the network information service database to work properly.

Default Domain Name

DNS obtains your default domain name from your resolv.conf file.

Trailing Dots in Domain Names

When working with DNS-related files, follow these rules regarding the trailing dot in domain names:

DNS Clients and the Resolver

To be a DNS client, a machine must run the resolver. The resolver is neither a daemon nor a single program. It is a set of dynamic library routines used by applications that need to know machine names. The resolver's function is to resolve users' queries. To do that, it queries a name server, which then returns either the requested information or a referral to another server. Once the resolver is configured, a machine can request DNS service from a name server.

The DNS name server uses several files to load its database. At the resolver level, it needs the file /etc/resolv.conf listing the addresses of the servers where it can obtain its information. The resolver reads this resolv.conf file to find the name of the local domain and the location of name servers. It sets the local domain name and instructs the resolver routines to query the listed name servers for information. Normally, each DNS client system on your network has a resolv.conf file in its /etc directory. If a client does not have a resolv.conf file, it defaults to using a server at IP address

Whenever the resolver has to find the IP address of a host (or the host name corresponding to an address), the resolver builds a query package and sends it to the name servers listed in /etc/resolv.conf. The servers either answer the query locally or contact other servers known to them, ultimately returning the answer to the resolver.

When a machine's /etc/nsswitch.conf file specifies hosts: dns (or any other variant that includes dns in the hosts line), the resolver libraries are automatically used. If the nsswitch.conf file specifies some other naming service before dns, that naming service is consulted first for host information and only if that naming service does not find the host in question are the resolver libraries used.

For example, if the hosts line in the nsswitch.conf file specifies hosts: nisplus dns, the NIS+ naming service will first be searched for host information. If the information is not found in NIS+, then the DNS resolver is used. Since naming services such as NIS+ and NIS only contain information about hosts in their own network, the effect of a hosts:nisplus dns line in a switch file is to specify the use of NIS+ for local host information and DNS for information on remote hosts out on the Internet.

There are two kinds of DNS clients.

The resolv.conf File

For a detailed description of what the resolv.conf file does, see resolv.conf(4).

See Setting Up the resolv.conf File for a discussion on how to set up the resolv.conf file.

The named.conf File

BIND 8.1 added a new configuration file, /etc/named.conf, that replaces the /etc/named.boot file. The /etc/named.conf file establishes the server as a master, slave, or cache-only name server. It also specifies the zones over which the server has authority and which data files it should read to get its initial data.

The /etc/named.conf file contains statements that implement:

The configuration file is read by in.named when the daemon is started by the server's startup script, /etc/init.d/inetsvc. The configuration file directs in.named to other servers or to local data files for a specified domain.

The named.conf file contains statements and comments. Statements end with a semicolon. Some statements can contain a block of statements. Again, each statement in the block is terminated with a semicolon.

Table 3–2 named.conf Statements

Defines a named IP address match list used for access control. The address match list designates one or more IP addresses (dotted-decimal notation) or IP prefixes (dotted-decimal notation followed with a slash and the number of bits in the netmask). The named IP address match list must be defined by an acl statement before it can be used elsewhere. No forward references are allowed.


Inserts an include file at the point where the include statement is encountered. Use include to break up the configuration into more easily managed chunks.


Specifies a key ID used for authentication and authorization on a particular name server. See the server statement.


Specifies what information the server logs and the destination of log messages. 


Controls global server configuration options and sets default values for other statements. 


Sets designated configuration options associated with a remote name server. Selectively applies options on a per-server basis, rather than to all servers. 


Defines a zone. Selectively applies options on a per-zone basis, rather than to all zones. 

Example 3–1 Example Master Configuration File for a Master Server

options {
         directory "/var/named";
         datasize 2098;
         forward only;
         forwarders {
         recursion no;
         transfers-in 10;
         transfers-per-ns 2;
         allow-transfer {
logging {
         category queries { default_syslog; };
include "/var/named/abcZones.conf"
// here are the names of the master files
zone "cities.zn" {
         type master;
         file "db.cities.zn";
zone "" {
         type master;
         file "db.127.cities.zn";
zone "" {
         type master;
         file "db.cities.zn.rev";
zone "" {
         type slave;
         file "slave/db.sales.doc";
         masters {
zone "" {
	         type slave;
         file "slave/db.sales.doc.rev";
         masters {

DNS Hierarchy in a Local Domain

If your company is large enough, it might support a number of domains, organized into a local namespace. The following figure shows a domain hierarchy that might be in place in a single company. The top-level, or “root” domain for the organization is, which has three subdomains,,, and

Figure 3–3 Hierarchy of DNS Domains in a Single Organization

Illustration shows hierarchy of DNS domains in the domain, with Sales, Test and Manf being subdomains.

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” type message to the client. If the domain is valid, the server routes the request down to the server that supports that domain.

DNS Hierarchy and the Internet

The domain hierarchy shown in the following figure is a “leaf” of the huge DNS namespace supported on the global Internet.

It consists of the root directory, represented as a dot (.), and two top level domain hierarchies, one organizational and one geographical. Note that the com domain introduced in this figure is one of a number of top-level organizational domains in existence on the Internet.

Figure 3–4 Hierarchy of Internet Domains

Diagram shows organizational and geographical top level domain structures for the Internet.

At the present time, the organizational hierarchy divides its namespace into the top-level domains listed shown in the following table. It is probable that additional top-level organizational domains will be added in the future.

Table 3–3 Internet Organizational Domains




Commercial organizations  


Educational institutions 


Government institutions 


Military groups 


Major network support centers 


Nonprofit organizations and others 


International organizations 

The geographic hierarchy assigns each country in the world a two or three-letter identifier and provides official names for the geographic regions within each country. For example, domains in Britain are subdomains of the uk top-level domain, Japanese domains are subdomains of jp, and so on.

Joining the Internet

The Internet root domain, top-level domains (organizational and geographical) are maintained by the various Internet governing bodies. People with networks of any size can “join” the Internet by registering their domain name in either the organizational or the geographical hierarchy.

Every DNS domain must have a domain name. If your site wants to use DNS for naming service without connecting to the Internet, you can use any name your organization wants for its your domains and subdomains, if applicable. However, if your site plans wants to join the Internet, it must register its domain name with the Internet governing bodies.

To join the Internet, do the following.

There are two ways to accomplish this.

Domain Names

Domain names indicate a domain's position in the overall DNS namespace, much as path names indicate a file's position in the UNIX file system. After your local domain is registered, its name is added to the name of the Internet hierarchy to which it belongs. For example, the ajax domain shown in Figure 3–5 has been registered as part of the Internet com hierarchy. Therefore, its Internet domain name becomes

The following figure shows the position of the domain in the DNS namespace on the Internet.

Figure 3–5 Ajax Domain's Position in the DNS Namespace

Diagram shows Ajax as a subdomain of .com in the worldwide DNS namespace.

The subdomains now have the following names.

DNS does not require domain names to be capitalized, though they can be. Here are some examples of machines and domain names.

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

Fully Qualified Domain Names (FQDNs)

A domain name is said to be fully-qualified when it includes the names of every DNS domain from the local domain on up to “.”, the DNS root domain. Conceptually, the fully qualified domain name indicates the path to the root, as does the absolute path name of a UNIX file. However, fully qualified domain names are read from lowest, on the left, to highest, on the right. Therefore, a fully-qualified domain name has the following syntax.

Diagram shows root domain positioned last in an FQDN when read left to right.

The fully qualified domain names for the ajax domain and its subdomains are:

Note the dot at the furthest right position of each name.


DNS service for a domain is managed on the set of name servers. Name servers can manage a single domains or multiple domains, or domains and some or all of their corresponding subdomains. The part of the namespace that a given name server controls is called a zone. Therefore, the name server is said to be authoritative for the zone. If you are responsible for a particular name server, you might be given the title “Zone Administrator”.

The data in a name server's database are called zone files. One type of zone file stores IP addresses and host names. When someone attempts to connect to a remote host using a host name by a utility like ftp or telnet, DNS performs name-to-address mapping, by looking up the host name in the zone file and converting it into its IP address.

Figure 3–6 Domains and Zones

Diagram shows Ajax domain, with four subdomains and five sub-subdomains, divided into four zones.

For example, the Ajax domain shown in the above contains a top domain (Ajax), four subdomains, and five sub-subdomains. It is divided into four zones. Thus, the Ajax name server administers a zone composed of the Ajax, Sales, Retail, and Wholesale domains. The Manf and QA domains are zones unto themselves served by their own name servers, and the Corp name server manages a zone composed of the Corp, Actg, Finance, and Mktg domains.

Reverse Mapping

The DNS database also includes zone files that use the IP address as a key to find the host name of the machine, enabling IP address to host name resolution. This process is called reverse resolution or more commonly, reverse mapping. Reverse mapping is used primarily to verify the identity of the machine that sent a message or to authorize remote operations on a local host.

The Domain

The domain is a conceptual part of the DNS namespace that uses IP addresses for its leaves, rather than domain names. It is the part of your zone that enables address-to-name mapping.

Just as DNS domain names are read with the lowest level subdomain occupying the furthest left position and the root at the far right, domain IP addresses are read from lowest level to the root. Thus, the IP addresses are read backward. For example, suppose a host has the IP address In the zone files, its address is listed as with the dot at the end indicating the root of the domain.