The Domain Name System (DNS) is a set of protocols and services on a TCP/IP network that allows users of the network to utilize hierarchical user-friendly names when looking for other hosts (that is, computers) instead of having to remember and use their IP addresses. This system is used extensively on the Internet and in many private enterprises today. If you've used a Web browser, Telnet application, FTP utility, or other similar TCP/IP utilities on the Internet, then you have probably used a DNS server.
The DNS protocol's best-known function is mapping user-friendly names to IP addresses. For example, suppose the FTP site at Microsoft had an IP address of 157.55.100.1. Most people would reach this computer by specifying FTP.microsoft.com and not the less "friendly" IP address. Besides being easier to remember, the name is more reliable. The numeric address could change for any number of reasons, but the name can always be used.
Before the implementation of DNS, the use of user-friendly computer names was done through the use of HOSTS files, which contained a list of names and associated IP addresses. On the Internet, this file was centrally administered and each location would periodically download a new copy. As the number of machines on the Internet grew, this became an unmanageable solution. The need for something better arose. This better solution became DNS.
According to Dr. Paul Mockapetris, principle designer of DNS, the original design goal for DNS was to replace the cumbersome singularly administered HOSTS file with a lightweight distributed database that would allow for a hierarchical name space, distribution of administration, extensible data types, virtually unlimited database size, and reasonable performance.
DNS maps to level 7 in the OSI model and can use either UDP or TCP as the underlying protocol. Resolvers send UDP queries to servers first for increased performance and only resort to TCP if truncation of the returned data occurs.
The most popular implementation of the DNS protocol "BIND" was originally developed at Berkeley for the 4.3 BSD UNIX operating system. The name "BIND" stands for Berkeley Internet Name Domain. The primary specifications for DNS are defined in Requests for Comments (RFCs) 974, 1034, and 1035.
A Domain Name System is composed of a distributed database of names. The names in the DNS database establish a logical tree structure called the domain name space. Each node or domain in the domain name space is named and can contain subdomains. Domains and subdomains are grouped into zones to allow for distributed administration of the name space. The domain name identifies the domain's position in the logical DNS hierarchy in relation to its parent domain by separating each branch of the tree with a period ".". The following figure shows a few of the top level domains, where the Microsoft domain fits, and a host called "rhino" within the "microsoft.com" domain. If someone wanted to contact that host, they would use the Fully Qualified Domain Name (FQDN) rhino.microsoft.com.
Figure 1. Domains and subdomains
The root of the DNS database on the Internet is managed by the Internet Network Information Center, located at www.internic.net/. The top-level domains were assigned organizationally and by country. These domain names follow the International Standard 3166. Two-letter and three-letter abbreviations are used for countries, and various abbreviations are reserved for use by organizations, as shown in the following examples.
| DNS Domain Name | Type of Organization |
| com | Commercial (for example, microsoft.com for Microsoft Corporation) |
| edu | Educational (for example, mit.edu for Massachusetts Institute of Technology) |
| gov | Government (for example, whitehouse.gov for the White House in Washington D.C.) |
| int | International organizations (for example, nato.int for NATO) |
| mil | Military operations (for example, army.mil for the Army) |
| net | Networking organizations (for example, nsf.net for NSFNET) |
| org | Noncommercial organizations (for example, fidonet.org for FidoNet) |
Each node in the tree of a DNS database, along with all the nodes below it, is called a domain. Domains can contain both hosts (computers) and other domains (subdomains). For example, the Microsoft domain microsoft.com could contain both computers such as FTP.microsoft.com and subdomains such as dev.microsoft.com, which could contain hosts such as ntserver.dev.microsoft.com.
Note In general, Domain names and Host names have restrictions in their naming that only allow the use of characters "a-z," "A-Z," "0-9," and "-" (dash or minus sign). The use of characters such as the "/," ".," and "_" (slash, period, and underscore) are not allowed.
A zone is some portion of the DNS namespace whose database records exist and are managed in a particular zone file. A single DNS server might be configured to manage one or multiple zone files. Each zone is anchored at a specific domain node-referred to as the zone's "root domain." Zone files do not necessarily contain the complete tree (that is, all subdomains) under the zone's root domain. For a comparison of domains and zones, look at the figure that follows. In this example, microsoft.com is a domain but the entire domain is not controlled by one zone file. Part of the domain is actually broken off into a separate zone file for dev.microsoft.com. Breaking up domains across multiple zone files might be needed for distributing management of the domain to different groups or possibly for efficiencies in data replication.
DNS servers store information about the domain name space and are referred to as name servers. Name servers generally have one or more zones for which they are responsible. The name server is then said to have authority for those zones.
When you configure a DNS name server (as we will soon see with the "NS" record), you tell it which DNS name servers are in the same domain.
A primary name server is a name server that gets the data for its zones from local files. Changes to a zone, such as adding domains or hosts, are done at the Primary Name Server. A secondary name server gets the data for its zones from another name server across the network which is authoritative for that zone. The processes of obtaining this zone information (that is the database file) across the network are referred to as zone transfer.
There are three reasons to have secondary servers within an enterprise:
You need at least two DNS name servers serving each zone, a primary name server and at least one secondary name server for redundancy. Like any fault-tolerant system, the machines should be as independent as possible (that is, different networks and so forth).
You should also have secondary servers (or other primary servers for subdomains) in remote locations that have a large number of clients. You would not want these clients to have to communicate across slow links for name resolution.
You also need secondary servers to reduce the load on the primary server.
Since information for each zone is stored in separate files, this primary or secondary designation is defined at a zone level. In other words, a particular name server may be a primary name server for certain zones and a secondary name server for other zones.
When defining a zone on a name server as a secondary, you must designate a name server from which to obtain the zone information. The source of zone information for a secondary name server in a DNS hierarchy is referred to as a master name server. A master name server can be either a primary or secondary name server for the requested zone. When a secondary name server starts up, it contacts its master name server and initiates a zone transfer with that server.
Note Use secondary servers as master servers when the primary is overloaded or when there is a more efficient network path between "secondary to secondary" versus "secondary to primary."
When a DNS name server receives a DNS request, it attempts to locate the requested information within its own zone files. If this fails because the server is not authoritative for the domain requested, it must communicate with other DNS name servers to resolve the request. Since, on a globally connected network, a DNS resolution request outside a local zone typically requires interaction with DNS name servers outside of the company on the public Internet, you may want to selectively enable specific DNS name servers in your company to do this wide-area communication.
To address this issue, DNS allows for the concept of forwarders. Specific DNS name servers are selected to be forwarders, and only forwarders are allowed to carry out the wide-area communications across the Internet. All other DNS name servers within the company are configured to use forwarders and are configured with the IP addresses of the DNS name servers designated as forwarders. This configuration is done on a per-server basis, not a per-zone basis!