DNS (Domain Name Service) Administration

The concept of DNS has been around since the 1980s. It was implemented to make the life of the network and system administrators easier by establishing a uniform architecture for identifying names for machines instead of TCP/IP addresses. In addition, DNS made it possible to centralize the places you look to find out the name for a particular machine into machines called DNS servers. In the following sections, we will discuss how the DNS service evolved, and how it is structured to be administered easily

A Brief History of DNS

As Internet use grew in the early 1980s, the number of networked machines required to house all of the information grew at an even higher pace. One of the biggest problems was in handling the names of all of these machines. In the beginning of the Internet, every computer had a file called hosts.txt that contained the hostname-to-IP address mapping for all the hosts on the ARPANET. UNIX modified the name to /etc/hosts. Since there were so few computers, the file was small and could be maintained easily The maintenance of the hosts.txt file was the responsibility of SRI-NIC, located at the Stanford Research Institute in Menlo Park, California. When administrators wanted to change this file, they e-mailed the request to SRI-NIC, which would incorporate requests once or twice a week. This meant that administrators also had to periodically compare their hosts.txt file against the SRI-NIC hosts.txt file, and if the files were different, the administrator had to ftp a new copy of the file.

As the Internet started to grow, the idea of centrally administering hostnames, as well as deploying the hosts.txt file, became a major issue. Every time a new host was added, a change had to be made to the central version, and every other host on ARPANET had to get the new version of this file. In addition to this problem, several other issues with a single file were encountered.

To maintain an updated hosts.txt file required administrators to constantly download new copies of the file, causing unnecessary traffic on the network and an unbearable load on the SRI machines. A single file could not handle duplicate names, which meant that machine names would eventually run out. Every computer on ARPANET needed to have the latest version of hosts.txt, but there was no automatic way of distributing updated versions. If two computers had different versions, the entire network would get confused.

In the early 1980s, the SRI-NIC called for the design of a distributed database to replace the hosts.txt file. The new system was known as the Domain Name System (DNS for short). ARPANET switched to DNS in September 1984, and it has been the standard method for publishing and retrieving host name information on the Internet ever since. DNS is a distributed database based on a hierarchical structure. Under DNS, every computer that connects to the Internet connects from an Internet domain. Each Internet domain has a name server that maintains a database of the hosts in its domain and handles requests for hostnames.

The Structure of DNS

DNS has a root domain, ‘.’, at the top of its tree, much as UNIX has the root directory, ‘/’. All domains and hosts are located underneath the root domain. The root-level domain currently has 13 name servers maintained by the NIC that can answer queries. Their names are a.root-servers.net., b.rootservers.net., c.rootservers.net., and so on.

In this section we will first look at the structure of DNS, starting with the concept of top-level domains and then continuing into subdomains. We will also look at three different types of name servers that are used to handle domain information.

Top-Level Domains

Under the root domain, several “top level” domains are classified into two types, generic and country codes. Generic top-level domains include

• .biz (Business)

• .com (Commercial)

• .edu (Educational)

• .gov (U.S. Government)

• .info (Information)

• .int (International, e.g., NATO)

• .mil (U.S. Military)

• .museum (Reserved for museums)

• .name (Reserved for individuals)

• .net (Network organizations and Internet service providers)

• .org (Nonprofit organizations)

• .travel (Reserved for the travel industry)

Country codes are used to identify top-level domains of machines located within a particular country For example, .uk is the country code for the United Kingdom, .au is the country code for Australia, .ca is the country code for Canada, and .mx is the country code for Mexico. (Note that the country code for the United States, .us, is not used very much.) A complete list of country codes, covering every part of the world, can be found at http://www. iana.org/cctld/.

Subdomains

In addition to the top-level domains, DNS also has subdomains such as att.com, nasa.gov, and berkeley.edu. Subdomains in DNS are equivalent to subdirectories in the file system. If a particular directory contains too many files, we usually create a subdirectory and move many of the related files into this new directory This helps to keep directories and files organized. The same principle applies to DNS: When a domain has too many hosts, a subdomain can be created for some of the hosts in the domain. Subdomains can be created at any time without consulting any higher authority within the tree.

Any subdomain is free to create other subdomains. The relationship between a domain and its subdomain is similar to a parent and child relationship found in the UNIX directory tree. The parent domain must know which machine handles the subdomain database information so that it will be able to tell other name servers who holds the information for the subdomain. When a parent creates a subdomain, this is known as delegation. The parent domain delegates authority for the child subdomain to the subdomain’s name server.

Fully Qualified Domain Names

Each domain has a fully qualified domain name (FQDN), which is similar to a pathname in the file system, within the DNS. To identify the FQDN for a particular domain, we start by first getting the name of the current domain, adding the name of the parent domain, and then adding the name of the grandparent’s domain, and so on until we reach the root of the tree. This method is the reverse of the method used to construct directory names in the UNIX file system. An example of a fully qualified domain name is

csua.berkeley.edu

This particular domain name corresponds to the Computer Science Undergraduate’s Association at the University of California at Berkeley From this name we can tell that csua is a subdomain of the berkeley domain, which is itself a subdomain of the edu “top-level” domain. In this representation, the strings between the dot character, ‘.’, are called labels. The last ‘.’ is used to represent the root domain.

Resolvers

Special programs that store information about the domain name tree are called DNS resolvers or name servers. These programs usually have the complete information about some part of the domain name tree. The main types of name servers are master, slave, caching, and forwarding. You may see these servers referred to as full service resolvers, because they are capable of receiving queries from clients and other name servers. A full service resolver always maintains a cache of items that it has already looked up. It is also able to perform recursive queries to other name servers, if it does not have a cached answer for a query that it received.

Master DNS Servers

Each DNS domain has a master, or primary, server that contains the authoritative zone database file. This file contains all of the hostnames and their corresponding IP addresses for the domain, along with several other pieces of information about the zone. A master name server answers queries with authoritative answers for the zone in which it is located. To service client requests, a master name server normally queries other name servers to obtain the required information. It also maintains a memory cache to remember information returned by other name servers. The master name server’s database is also used to delegate responsibility for subdomains to other name servers.

To change the information for a domain, the zone database file on the master name server must be changed. The zone database contains a serial number that must be incremented each time the database is altered, as this ensures that secondary name servers will recognize the changes.

Slave DNS Servers

Each domain should have at least one slave, or secondary, server for redundancy purposes. The slave server will obtain a copy of the zone database, usually from the master name server. The slave will serve authoritative information for the zone just as the master server does. Slave name servers will normally query other name servers to obtain information from other name servers to answer client requests. Like master name servers, slave name servers have a memory cache that remembers information returned by other name servers.

Caching DNS Servers

Caching, or hint, name servers do not serve authoritative information for any zones. Clients query such a name server, and it forwards the query to other name servers until an answer for the query is found. Once an answer is found, the caching name server remembers the answer for a period of time. If the same client makes the same query again (or if other clients do), this name server gives the answer stored in cache, instead of forwarding the query to another name server. Caching name servers are generally used to reduce DNS traffic over slow or expensive network connections.

Forwarding DNS Servers

Forwarding, or proxy, client, or remote, servers have only one purpose, to forward all DNS requests to other DNS servers, caching the results. Although forwarding DNS servers may seem rather pointless, they can help reduce traffic and external access needs. In particular, they are used when access to an external network is slow or costly

DNS Resource Records

DNS resource records are entries stored in the DNS database. The DNS database is a set of ASCII text files that contain information about the machines in a domain. This information is stored in a specific format that we will examine in this section. Information is added to a domain by adding resource records to the database located on a primary name server. When a query is made to a name server, the server will return one or more resource records containing either the exact answer to the query or information pointing to another name server in the name space to look for the answer. The resource records on a primary name server are stored in a zone database. The zone database is usually made up of at least three files:

• db.network (for example, db.10.8.11)

• db.domain (for example, db.bosland)

• db.127.0.0

The first file contains the mapping of IP addresses to hostnames for a given network. The second file contains the reverse mapping of hostnames to IP addresses. The third file contains a mapping for the local host.

DNS bind allows you to name these files differently from the examples. The name of the zone databases for bind4 mapping is in /etc/named.boot, and that for bind9 mapping is in /etc/named.conf.

The Structure of DNS Database Files

Each database file has three main sections, the Start of Authority section (SOA), the name server section (NS), and the database section. Each of these sections has one or more DNS resource records. The syntax of a DNS resource record can be in one of the following forms:

[TTL] [class] type data
[class] [TTL] type data

The first two fields, TTL and class, are optional fields that correspond to the “Time-To-Live” and the class of the record. The “Time-To-Live” is a decimal number that indicates to the name server how often this particular record needs to be updated. Usual values range from a few minutes to a few days. If this field is blank, it is, by default, assumed to be three hours.

The class field indicates which class of data the record belongs to. The only class that is used is the IN class, corresponding to Internet data. The type field is a required field and describes the type of data in the record:

• SOA Record The Start of Authority resource record is located at the top of each file in the zone database. The SOA includes many pieces of information that are primarily used by the secondary name server.

• NS Record The name server section is the second section in each of the files in the zone database. It contains a name server resource record, NS, for each of the primary and secondary name servers for the zone that the database serves.

• A Record An A record is an address record used for providing translations for hostnames to IP addresses.

• PTR Record The pointer, or PTR, records are typically seen in the db.network or the db.127.0.0 files. They are used for reverse address resolution, which is used by the name server to turn an IP address into a hostname.

• CNAME Record The Canonical Name (CNAME for short) record makes it possible to alias hostnames. This is useful for giving common names to large servers. For example, it is useful to have the server that handles both web traffic and FTP traffic for a domain respond to the names www and ftp.

• MX Record The list of host names that will accept mail for this domain, and their priority The priority indicates the urgency of mail delivery for a given host. A smaller number indicates quicker response.

The Database portion of the zone file contains all of the resource records that contain the data for the hosts in the zone. Three main types of records are encountered in this section. In the db.network file we will encounter PTR records. In the db.domain file we will encounter A and CNAME records.

Using NSLOOKUP to Find a Machine on the Network

You may want to connect to another machine on the TCP/IP network to send or receive information but not be sure what the machine’s address is, or even that the machine name (hostname) that you want to reach exists. The nslookup utility enables you to find out this information. You provide the hostname of the desired machine as part of the command line. For example,

# nslookup dodger.com
Name Server: damian.master.com
Address:   198.5.22.7
Name: dodger.com
Address: 199.14.36.112

provides the name server (damian.master.com) that dodger.com exists on as well as the IP address for both the name server and dodger.com. If the hostname for the machine does not exist, you will get a message back indicating so. For example, if you were to type in the name dogder.com by mistake, you would get a message like this:

# nslookup dogder.com
Name Server: damian.master.com
Address:   198.5.22.7
*** damian.master.com can't find dogder.com: Non-existent domain

One important point to note is that nslookup uses an authoritative approach to do its translations. It uses either your local name server or whatever is specified in /etc/resolυ.conf to do queries. As long as the machine is in your domain, you can guarantee that the machine exists without going outside the domain (called an authoritative answer). If you need to go outside your domain to get the information from another domain server, the answer is nonauthoritative (you are taking the other domain server’s word that the domain name exists). In the successful example shown previously, damian.master.com needs to be authoritative to dodger.com; otherwise, you will be informed that it is a nonauthoritative lookup.

Using host and dig

Besides nslookup, two other commands, host and dig, are often used to obtain DNS information about a particular hostname or IP address. These two commands are supported by Solaris, AIX, HP-UX, Linux, FreeBSD, NetBSD, and OpenBSD, as well as other UNIX variants. Some UNIX variants support one, but not both, of them.

The host Command

The host command can be used to find the IP address corresponding to a particular hostname, or vice versa. For example,

# host dodger.com

dodger.com is 198.5.22.7

gives us the IP address corresponding to the host dodger.com. We can find the hostname corresponding to the IP address 198.5.22.7 as follows:

# host 198.5.22.7

dodger is 198.5.22.7

The dig Command

The dig (short for domain information groper) is a powerful command that can be used to extract information from DNS servers. You can use this command for DNS lookups on particular DNS servers. Network administrators used the dig command to troubleshoot DNS problem because of its flexibility and ease of use, as well as the clear way output is presented. The following is an example of a dig query that will query each of the DNS servers listed in /etc/resolυ.conf:

# dig dodger.com

To query a particular DNS server, you use a command like

# dig @ns.dodger.com dodger.com any

This command directly queries the DNS server ns.dodger.com for any information about the hostname dodger.com. See the man page for the dig command to learn about the output provided by this command, as well as options that can be used to troubleshoot DNS problems.