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
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
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 Retail.Sales.Ajax.com. domain might be in Seattle and the Wholesale.Sales.Ajax.com. domain might be in San Francisco. One part of the Sales.Ajax.com. 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.
/var/named/named.ca See "The named.ca File" for additional information on the named.ca file. As long as you are internally consistent, you can name this file anything you want.
/var/named/hosts See "The hosts File" for additional information on hosts files.
The name hosts is a generic name indicating the file's purpose and content. But to avoid confusion with /etc/hosts, you should name this file something other than hosts. The most common naming convention is db.domainname. Thus, the hosts file for the doc.com domain would be called db.doc.
If you have more than one zone, each zone must have its own hosts file and each of these zone hosts files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts file db.doc and the other db.sales.
/var/named/hosts.rev See "The hosts.rev File" for additional information on the hosts.rev file.
The name hosts.rev is a generic name indicating the file's purpose and content. If you have more than one zone, each zone must have its own hosts.rev file and each of these zone hosts.rev files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts.rev file doc.rev and the other sales.rev.
/var/named/named.local See "The named.local File" and for additional information on the named.local file. As long as you are internally consistent, you can name this file anything you want.
$INCLUDE Files
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. | ||
named.ca | db.cache db.root | root.cache | This file establishes the names of root servers and lists their addresses. |
Generic: hosts Examples: db.doc, db.sales | Generic: db.domain Examples: db.movie, 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 | hosts.rev | This file specifies a zone in the in-addr.arpa. domain, a special domain that allows reverse (address-to-name) mapping. |
named.local | Generic: db.cache Example: db.127.0.0 | named.local | 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. | ||