Domain Name System

The Domain Name System (DNS) describes the distributed name service on the Internet that allows hosts to learn IP addresses from Internet names. The DNS is described in STD 13/RFC 1034/RFC 1035/RFC 1591, which defines the records maintained in the DNS database, as well as general concepts and specifications.

The importance of the DNS cannot be overstated. When the Internet was fairly small, every host was explicitly programmed to know the name and address of every other host. This information was kept in a file located on each system. As the Internet scaled, however, such a manual approach was not practical. DNS provides a distributed data base service by which an IP system can learn another system's IP address from its name (or vice versa).

Consider that when a user wishes to connect to a given site, such as www.hill.com, the application must send out a request to the local name server to find out that this host’s IP address is 64.30.48.12. In fact, the scenario is usually a bit more complicated than a simple query-response. When an application needs to learn the address of some host system, it sends an appropriate message to the local name server. If the requested name is not known by the local name server, it is the local name server’s responsibility to forward the request to other name servers until the request is satisfied. Only when the name has been translated to an address can the local host try to determine a route to the destination host.

The DNS maintains several types of records about every defined domain on the Internet. The most common types of DNS records are listed below.

Address (A) Record: Provides information to translate a host name to an IP address. Some hosts could have more than one address; conversely, multiple host names could translate to the same IP address. For example, both ftp.hill.com and www.hill.com could resolve to the IP address 64.30.48.12.

Pointer (PTR) Record: Provides information to translate an IP address to a host name. A single IP address will only resolve to a single host name.

Name Server (NS) Record: Lists the name server(s) associated with a given host and/or domain.

Mail Exchange (MX) Record: Identifies where electronic mail should be sent for a given domain.

There are a number of TCP/IP utilities that can be used to examine DNS records. The most common are NSLOOKUP and Host, commonly available on Windows and UNIX systems, as well as other commercial TCP/IP packages.

Contents

Root Servers in the DNS

There are currently 13 root servers handling the generic top-level domains (TDL). Each server is maintained by a separate organization in geographically diverse parts of the world (e.g., one is located at the University of Maryland, NASA’s Ames facility in California handles another, and one is run at the London Internet Exchange (LINX) by the European registry known as RIPE).

All U.S. root servers have exactly the same information in their databases. Of course, these databases are nothing more than simple text files that contain specific resource records about the top-level domains (e.g.,.com), pointing to the authoritative name servers of each registered domain.

The database for the roots is maintained under the control of ICANN, and files are updated daily.

The U.S. servers are only responsible for the U.S. name space. Every country also has its own country TDL root servers.

DNS Lookup: First Glance

DNS Lookup: First Glance

The DNS is a distributed database containing the name(s) and address(es) of every host accessible via the Internet. DNS files are maintained by thousands of hosts on the network, each responsible for a portion of the name space, which is called a zone.

When TCP/IP software is installed on a host, the address (not the name!) of one or more name servers must be supplied. When an application (e.g., a Web browser) needs to send an IP packet to another host, it first sends a query to its primary DNS name server to learn the address of that remote host (assuming that the application only has the destination hosts’ name). As far as the local host is concerned, the answer to the query magically appears.

Consider the following example. Suppose a user at the Save the Lake Champlain Monster Foundation (domain champ.org) wishes to connect to the WWW server at Foo Corp. (www.foo.com). As the visual shows, the user’s application (i.e., their Web browser) sends a query to the DNS asking for the address of www.foo.com and receives a response with the appropriate address.

DNS Lookup in Depth

DNS Lookup in Depth

The diagram on the visual steps through the process of resolving an IP address located in a foreign DNS domain. Each of the steps shown on the visual is discussed briefly below.

A browser in one DNS domain (requesting browser) requests connection to a Web site located in another DNS domain (target Web server). The domain name of the target is sent to the local DNS server for resolution.

The local DNS server fails to find the requested domain name in its database and proceeds to forward the request to a root server on the network.

The root server, which knows all domain names on the network, returns the IP address of the local DNS server responsible for the target resource to the local DNS server responsible for the original request.

The local DNS server, acting as an agent for the requesting browser, makes a direct query to the local DNS server responsible for the target resource.

The target’s local DNS server returns the IP address of the actual resource to the local DNS server that handles the requesting browser.

The local DNS server caches the address, typically for a period of about one hour. This operation saves time in cases where this particular target resource must be reached repeatedly.

The local DNS server passes the target’s IP address to the requesting browser.

The process described above is recursive and transparent to the requesting user. To the user, the response appears to come directly from the local DNS server.

DNS Fault Tolerance

DNS Fault Tolerance

Due to their critical role in supporting Internet connectivity, DNS servers can be configured in a fault-tolerant fashion. Every primary (i.e., active) DNS server can be associated with a secondary (i.e., backup) server. In case of the failure of the primary machine, the secondary can continue to mediate DNS requests. In order to provide up-to-date addressing information, communication between the primary and secondary DNS servers is required. The secondary is responsible for initiating a process called a “zone transfer” in which the contents of the primary server are copied to the secondary server. The zone transfer process is shown on the visual.

Zone transfers between paired DNS servers take place about every three hours. If no reply is received by the secondary server, it will retry at one hour intervals until an expiration timer is reached. These timers are governed by values set in the DNS Start of Authority record and are known as the refresh, retry, and expire intervals. If the secondary server receives no reply within approximately a week, the server will eventually give up.

Because of the length of the DNS database files and the need to transfer them reliably, TCP connections are used for zone transfers. For actual DNS lookups, UDP is used at the Transport Layer in an effort to boost the efficiency of the DNS lookup process.