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 that is used on the Internet.
This section introduces the basic DNS concepts. You should 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.
DNS, NIS+, NIS, and FNS provide similar functionality and sometimes use the same terms to define different entities. In this chapter, terms like domain and name server are defined by their DNS functionality.
Though DNS supports the complex, worldwide hierarchy of computers on the Internet, the basic function of DNS is actually very simple. DNS provides 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 might know the host name of the remote computer. However, the program might not know how to locate the machine, particularly if the machine is in another company domain, for example. 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. DNS files bear little resemblance to files that contain similar information. For example, the NIS+ host, the ipnodes Table, the local /etc/hosts and the /etc/inet/ipnodes files contain the host names, the ipnode names, IPv4 and IPv6 addresses, and other information about a particular group of computers. The name server uses your machine's host name as part of your request to find or “resolve” the IP address of the remote machine. The name server 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 between a DNS client and a name server, probably on the client's local network.
If the host name is not in that name server's DNS database, 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 the server forwards requests. 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 the servers 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 given organization. The root name server sends your request to the known top-level name servers. If one server has the IP address for the host you requested, the server returns the information to your machine. If the top-level servers do not recognize the requested host, the request is passed to second-level name servers. 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 returns the IP address back to your machine.
The following figure shows name-to-address resolution outside the local domain.
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, in San Francisco and in Seattle. The Retail.Sales.Ajax.com. domain is in Seattle. The Wholesale.Sales.Ajax.com. domain is 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.
As mentioned previously, name servers in an administrative domain maintain the DNS database. Name servers 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.
in.named is also called the Berkeley Internet Name Domain service, or BIND, because the daemon was developed at the University of California at Berkeley.
Each domain must have one master server and at least one slave server to provide backup. Implementing DNS: A Practical Example explains primary and secondary servers in detail.