Print-friendly Version

Introduction to the Domain Name System

By Eric Rinker

The purpose of this article is to give system administrators new to the Domain Name System (DNS) enough basic knowledge and examples to set up and configure their own DNS servers. This article will focus on the specifics of installing ISC BIND 9.x. It is assumed that you have a basic understanding of the UNIX/Linux command-line interface, are already proficient in compiling software, and have root access to perform the required actions.

Overview, Part 1: The Internet

The Internet is primarily made up of machines using the TCP/IP protocol suite to communicate. This protocol suite identifies each machine on its network by using two unique pieces of information: a Media Access Control (MAC) address and an IP address. A MAC address is a unique number given to every piece of networking equipment on a network, typically by the manufacturers of said equipment. It is used at the hardware level of the TCP/IP interaction to determine which devices should open or read which packets. The IP address is an operator-defined unique number used at a higher level of the TCP/IP protocols to identify which machine or node on the network should open or read which packets. This separation between device and node identification allows for multiple devices to a node, or multiple nodes to a device, while utilizing the same system.

The IP address is used at a human interface level of the operating system to identify what machine is to be contacted for the task at hand. The OS then handles discovering the MAC address and using the two identifiers to transmit packets. To make the network easier to use for people, an IP address-to-name relationship was developed. This allowed a name to be used in place of an IP when defining the networking partner of a transaction. Initially, this information was contained in a separate hosts.txt file on every machine. As networks grew to more than a handful of machines, the host file method of tracking the IP-address-to-name relationship became too unwieldy to manage. A new system was developed to handle the distribution of this data, at the same time making it possible for multiple people to maintain the data by creating a decentralized management model.

Overview, Part 2: DNS Basics

And so, the Domain Name System was born. DNS is a network of servers designed to route a requesting party to the information they seek. Two types of queries exist in this system: a forward lookup (hostname -> IP Address) and a reverse lookup (IP Address -> hostname). Both lookups utilize the structure of DNS to find the authoritative server that handles the data being requested.

The structure of DNS can best be described using an inverted tree diagram (see Figure 1).

Figure 1: Structure of DNS

The top of the tree (root server) knows how to get each of the nodes below it (the .com, .edu, and .net servers), which in turn know the next step down the tree. Each node of the tree is polled in turn until the data requested is found or is known to not exist. This tree traversal is done every time a hostname -> IP Address or IP Address -> hostname translation is required.

For example, when trying to browse www.sun.com, the web browser asks the OS to send packets to the IP address of Sun's web server. The OS needs to translate the hostname to an IP address, and so it asks its defined DNS server for this information. If the DNS server is authoritative for the information or has a cached copy of said information, it returns it. Otherwise, it contacts the closest root server to track down the owner of the data. The root server, not being authoritative for .com, passes the searching DNS server onto the .com server. The .com server points to the .sun.com DNS server to find the answer. The .sun.com server then returns the IP address of www.sun.com to the requesting DNS server. The same process occurs for reverse lookups trying to get hostnames from IP addresses.

DNS structure was specifically designed for decentralized management. Each node on the tree can be controlled by separate parties, allowing almost unlimited possibilities for expansion. This aspect leads many companies to purchase a domain name and supply a public DNS server to control their section of the Internet.

Building Your Own Server -- Basic Configuration

The most common DNS package used today is Berkeley Internet Name Domain (BIND). It has been adopted as the standard DNS server in most UNIX distributions. Currently, it is developed and maintained by the Internet Systems Consortium (ISC). BIND has a long history (see A Brief History of BIND on the ISC site).

Three different BIND versions are in use today: v4, v8, and v9. v4 is a deprecated version, only updated with security patches, while v8 and v9 are currently under development. v8 is still in wide usage, but many users are migrating to v9 for its more advanced feature set. This article will cover a v9 installation, but many of the commands and configuration options still apply to v8 distributions.

It is assumed you already have BIND 9.x downloaded, compiled, and the binaries installed. If not, you will need to go to ISC's download page and get the latest version. You might also need to get a C compiler like GCC from GNU. Sun Studio 8 would also work if a C compiler is needed. Both GCC and BIND can be found prepackaged for installation at Sunfreeware.com.

NAMED.CONF

The main configuration file of BIND is named.conf. Its default location is /etc. This file controls the behavior of named, the BIND daemon, and points named to the location of the zone files. A basic named.conf file should look like this:

options {
        directory "/var/named";
};

zone "." IN {
        type hint;
        file "named.ca";
};

zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
};

This configuration file names the zone file directory with the "directory" option. It then defines the root server information using the "." zone. Finally, it defines the two required master zones every DNS server must have, localhost (forward) and 0.0.127.in-addr.arpa (reverse) of the loopback address.

Other bits you might find in your named.conf file are the ndc control statements:

controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
include "/etc/rndc.key";

These are used to allow the ndc command to authenticate and have access to the BIND daemon. If you have these installed, great. If not, they can be configured later, but they will be ignored for the purpose of this article.

Since the named.conf file does not live in a vacuum, you need to know what the zone files look like. Here is an example of the forward zone localhost:

$TTL    86400
@                   1D IN SOA       @ root (
                           42          ; serial (d. adams)
                           3H          ; refresh
                           15M         ; retry
                           1W          ; expiry
                           1D )        ; minimum

                        1D IN NS        @
                        1D IN A         127.0.0.1

The first line of the zone file sets the Time To Live (TTL) of any lookups of this zone, so other DNS servers that look this information up know how long to cache their lookups before coming back to this server for authoritative data. TTL is configured in seconds. The second line begins the Start of Authority (SOA) resource record. Its components are as follows:

• Column 1 = Name of Domain -- The @ sign tells named to use the zone name as defined in named.conf that made reference to this file. This indirect naming allows for multiple domains to use the same file.
• Column 2 = Minimum Cache Period (optional) -- 1D tells other DNS servers that this record in this domain must be cached for 1 day. Caching, while expected, is not enforceable, so this is more of a suggestion. This column can be left empty, and often is since the $TTL is a global version of this record-specific option.
• Column 3 = Class of Data -- IN stands for Internet. There are other classes of data, but this is the only one in widespread use.
• Column 4 = Record Type (Must be SOA for an SOA)
• Column 5 = Primary Master Server
• Column 6 = Mail Address of Data Owner -- Uses a "." instead of an @ sign, so erinker@maliki.net would be erinker.maliki.net

The parentheses allow the record to span multiple lines, and the white spaces are ignored. The options to follow are, in order:

• Serial Number (used to determine if a slave server needs to download a new copy of the zone)
• Refresh Period (how long before a slave server should request a refresh of the zone)
• Retry Period (how long before a slave server retries a failed zone refresh)
• Expire Period (how long before a slave server should expire or stop using a zone's cached data)
• Minimum Cache Period (waiting period before the first attempt to refresh the zone data)

Next is the name server (NS) record. These records indicate to other DNS servers which machines should be contacted for this zone's authoritative DNS information. The first four columns are the same as the SOA record. Column 1, left blank, is the same as having an @ sign. The fifth column is the name of the name server for this domain. Again, the @ represents shorthand for "the name of this zone" as defined in named.conf.

Last comes the Address (A) record for this domain. We need one, and that is for the zone name itself, localhost. Leaving column 1 blank, we then put the IP address of this record in the fifth column.

The reverse zone follows the same pattern. Following are the contents of the 0.0.127.in-addr.arpa zone file:

@       IN      SOA     localhost. root.localhost.  (
                               1997022700     ; Serial
                               28800          ; Refresh
                               14400          ; Retry
                               3600000        ; Expire
                               86400 )        ; Minimum
              IN      NS      localhost.

1       IN      PTR     localhost.

The only differences are the Pointer (PTR) record instead of the A record and the empty second column. A PTR's first column is a number, and the fifth column is the hostname. Notice the "." at the end of localhost. This indicates that localhost is the full name, and that named should not append the zone name to the end of this field's data. This is handy shorthand for other files, but it would make this entry localhost.localhost, which is not what we want.

Since the idea is to make a useful DNS server, let us allow others to access our data by attaching to a real IP. To do this, we should be configured to know our own IP address. My test server will be listening on 192.168.1.100 for its traffic, so we will define that reverse:

zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "rev-192.168.1.0-24";
        allow-update { none; };
};

Notice the difference between this zone and the 0.0.127.in-addr.arpa address. First, the 1.168.192.in-addr.arpa zone name tells named that 192.168.1.x IPs are defined in this zone. The complicated mechanics behind it are discussed later, but for simplicity, just reverse the order of the numbers and put an in-addr.arpa on the zone name for a reverse zone. Second, the file name is different. This file name is purely arbitrary and can be any unique name you want it to be. For ease of use and simplicity, I use the naming convention of "zone-<zonename>" for forward zones, and "rev-<ip>-<network length>" for reverse zones. For example, the file for "sun.com" would be zone-sun.com and the file for 192.168.1.x (a /24 network) would be rev-192.168.1.0-24.

Next, we will create the reverse zone file rev-192.168.1.0-24 in /var/named:

$TTL    86400
@       IN      SOA     testingfool.net. root.localhost.  (
                                      2003120100 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
              IN      NS      localhost.

100       IN      PTR     testdns1.testingfool.net.

At this point, we should have no problems with starting DNS and answering queries. But we have not completely set up our new domain, so let's create a forward. Define it in named.conf:

zone "testingfool.net" IN {
        type master;
        file "zone-testingfool.net";
        allow-update { none; };
};

And create the zone file zone-testingfool.net in /var/named:

$TTL    86400
@       1D IN SOA       @ root (
                            2003120100      ; serial (d. adams)
                            3H              ; refresh
                            15M             ; retry
                            1W              ; expiry
                            1D )            ; minimum

                            1D IN NS        @
testdns1                    1D IN A         192.168.1.100

And we're done. We now have a fully functional basic DNS server serving one domain and one reverse domain. This should fulfill the need of replacing the host file data on every box. Should you need more from your DNS server (which most companies these days do), continue reading the Advanced Setup section for bigger and better DNS options.

Building Your Own Server -- Advanced Setup

Aliases

Rather than defining multiple A records to represent the same IP with different names, the Conocial Name (CNAME) record was devised. This allows you to point one name in the zone at another name's A record. Change the one A record, and any CNAME referencing that A record will also return the new IP. The first column is the alias name, while the fourth column is "CNAME" and the fifth column is the A record's name.

mydns          1D IN CNAME         testdns1

Mail

To point a domain's mail to a specific server requires a Mail Transfer (MX) record. The first column is the domain to be answered for. The fifth column is the priority of this MX record over other MX records. Lower is better. The sixth column is the hostname of the machine answering for this MX record. For example:

                        1D IN MX 10     testmail1
                        1D IN MX 20     testmail2
                        1D IN MX 20     testmail3
                        1D IN MX 30     testmail4

These entries have mail destined for this zone sent to testmail1. If that fails, the sending server attempts to contact testmail2 and testmail3 (delivering to whichever it contacts first). If that also fails, it finally tries testmail4 before considering it impossible to send its message.

Since a zone can have defined multiple subdomains, you can also have multiple layers of MX records for different subdomains. For example:

                        1D IN MX 10     testmail1
                        1D IN MX 20     testmail2
eastcoast         	1D IN MX 10     testmail3
westcoast        	1D IN MX 10     testmail4

Assuming this is defined in the "testingfool.net" zone, this would have testmail1 and testmail2 used for @testingfool.net mail, while anything for @eastcoast.testingfool.net would go to testmail3, and @westcoast.testingfool.net mail would be sent to testmail4.

Master and Slave Servers

If you want a server to authoritatively serve zone data, but don't want it to be the location from which you make zone modifications, then it is a perfect candidate to be a slave server. A slave server can have all or some of its zones be copied data from another machine that acts as the master server for that zone. First the master server (192.168.1.100) will need to be configured to allow the slave server (192.168.1.101) to access its data. The following on the master server:

zone "testingfool.net" IN {
        type master;
        file "zone-testingfool.net";
        allow-update { none; };
};

zone "testingfool.net" IN {
        type master;
        file "zone-testingfool.net";
        allow-transfer { 192.168.1.101; };
        allow-update { none; };
};

The "allow-transfer" option to this zone overrides any global settings and allows the listed servers, separated by a ";" to transfer zone information from this server. Next, the slave server will need to be configured with the zone information:

zone "testingfool.net" IN {
        type slave;
        masters { 192.168.1.100; };
        file "zone-testingfool.net";
        allow-update { none; };
};

Notice the change in the "type" field as well as the addition of the "masters" field. "masters" is a list of servers from which this machine will accept zone updates for this zone.

DNS Concepts to Understand

Dynamic DNS

The purpose of Dynamic DNS is to tie Dynamic Host Configuration Protocol (DHCP) and DNS into one system. This allows a new machine on the network handed a DHCP license to be instantly recognized by other machines for the purpose of validation, as is used in many security measures. It is beyond the scope of this document to illustrate how to do this, since many Dynamic DHCP systems could be configured to work with ISC's BIND 9.x, and there is not yet a standard Dynamic DNS/DHCP system.

Proxy or Caching DNS Server

A proxy/cache DNS server is one that contains no master zone data, and is instead used entirely for query lookups. Typically used in an environment where multiple machines make the same DNS lookup calls on a repeated basis, this server allows for the elimination of redundant network traffic. This type of server is also commonly set to hold onto non-authoritative data for a longer period than recommended by the authoritative server.

Recursion

When a DNS server is sent a recursive query, the DNS server will find the answer for the query if it does not already have it. It does this by recursively walking the DNS tree until the answer is found, and then returning that information to the requester. Typically, it caches all of the information it gathered walking the tree for later use.

Forwarding DNS Servers

When a DNS sends a query to another DNS server, it's a non-recursive query designed to ascertain if the target machine has the required information. When other DNS servers are configured to use the machine as a forwarding server, they send a recursive query to that server. The forwarding server then attempts to do all the work for its comrades and so becomes a storehouse of all the cache data that each individual DNS server in the network would have had. As time goes by, this forwarding server should be able to answer many of the DNS requests from cache. This fulfills the common purpose of such a configuration, which is to eliminate off-site network traffic.

Non-Recursive DNS Servers

Non-recursive DNS servers have been configured to not do recursive searches to eliminate the extra workload from a busy server such as the primary server for a heavily trafficked domain or the important machines like the root servers. A side-effect of this setting is that the non-recursive server does not build up a cache of non-authoritative data, since it never looks it up. This type of server should never be configured in a host's resolv.conf file, nor should it be used by a forwarding DNS server.

Tools Used with DNS

DIG

The Domain Information Groper is a DNS server interrogation tool. It is specifically designed to troubleshoot DNS problems. It has the ability to do batched operations and is very versatile.

NSLOOKUP

nslookup allows a direct lookup of DNS information. Its ability to direct DNS queries to a specific server make it the perfect tool to externally test a new DNS installation, and it is found on almost every UNIX distribution. Although nslookup has been made obsolete by the dig command, this tool is still more common because of its simplicity and availability.

WHOIS

The whois tool searches an Internet database maintained by registrars that contains information about top-level domain name registrations. It is very useful for verifying ownership of a domain, and it is also the first step in troubleshooting external resolution problems because it shows what is currently configured as the primary DNS server for a domain.

A Few Common Issues

1. Always have a ";" at the end of each block in named.conf. This common typo is the bane of many a DNS System Administrator. Better safe than sorry: End all blocks with a ";".
2. In your zone files, end fully qualified hostnames with a ".". Otherwise, BIND thinks you are using shortcuts and appends the zone file's domain to your entry. For example, www.sun.com in the sun.com zone file will become www.sun.com.sun.com.
3. After modifying a zone file, make sure to increment the zone's serial number. This number is used by slave servers to identify when they need to update their cache of the zone information.
4. Older versions of BIND required the ability to look themselves up on whatever IP they were listening on. This almost always meant they had to be authoritative for the domain and reverse of that IP. If you are running a v4 or v8 DNS server, this may be the reason your new install is not answering.
5. Check the message log. Almost every show-stopping error can be found there with enough information to fix the problem, even on standard non-debugging setting.

Resources

We hope we have given you enough information to get your DNS server up and running, and keep it that way for a long time. The following useful links and books can help you if you need a deeper understand of DNS and the Internet in general.

Sites:

• American Registry for Internet Numbers (ARIN)
• Internet Corporation for Assigned Names and Numbers (ICANN)
• www.DNSstuff.com (useful DNS tools)

Books:

• DNS & BIND, 4th Edition
• DNS & BIND Cookbook

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.