DNS and Linux

The Domain Name System was developed in 1984 for use on the Internet’s TCP/IP backbone. DNS was developed to allow scalable address resolution, meaning the mapping of a domain name to an IP address. Prior to DNS, a single file was used to hold all the information about the machines connected to the Internet, and each machine that acted as a forwarding server had to have this file updated as new machines were added to the network. DNS solved the update problem by providing a distributed database approach. (DNS is responsible for the .com, .net, and other domain name extensions we now take for granted.) If your network is connected to the Internet, you must use DNS either directly or through an ISP. Understanding how DNS works, and how you should configure your Linux systems to work with DNS, is the focus of this article.

Every machine on the Internet has a domain name, composed of the network name, perhaps a subnetwork name, and an identifier for each machine. For example, the machine brutus.develop.tpci.com means the “tpci.com” domain, the subnetwork “develop”, and the machine “brutus”. There can be only one machine on the entire Internet with this name. For each machine there is also an IP address, which is unique over the entire Internet as well. The IP address is used by most network services such as e-mail. You don’t usually bother entering the IP address into your e-mail “To:” fields, though, just a user and a domain name. The mapping between the domain name and the IP address is one task of DNS.

To understand the way DNS resolves domain names, we need to look at how DNS compares to the UNIX filesystem. DNS has a hierarchical structure just like a filesystem. The top level of DNS is called “.”, with a few subdirectories underneath it with the most popular domain extensions (.com, .net, .mil, .org, .edu, .gov and the foreign domains like .uk, .jp, and .dn). The machine name “brutus.develop.tpci.com.” (the trailing period is important here) is called a “fully qualified domain name” of FQDN. For DNS to resolve the FQDN it starts at the root “.” domain and moves down into the .com domain, then looks for a directory under that called “tpci”. From there, another subdirectory exists called “develop” (which may be hidden from DNS depending on how the tpci.com network is structured. Underneath that is a list of all the machines connected to that domain. DNS doesn’t actually keep track of all the individual machine, usually relying on the gateway machine for tpci.com to keep track of everything within the domain.

Along the Internet backbone (or on a network backbone), DNS servers maintain information about the machines and domains that are attached. These machines are called name servers. Name servers each have an area of the Internet or an internal network that they are responsible for. Each area is called a zone. The name server is said to have authority over that zone. Some name servers can have authority over multiple zones. In general there is a correlation between zones and domains, but this is not always true. For example, there are several zones for the .com domains, as there are so many of them. Also, there is far more information about all the .com domains that one of the name servers responsible for a small fraction of the domains needs, so it only keeps track of the domains in its zone. When a name server needs information about a domain outside its zone, it communicates with the name server responsible for that zone.

To complicate the picture, there are two types of name servers: primary masters and secondary masters (sometimes called a slave). A primary master name server has a complete list of all the domains or machines in its zone. A secondary master name server doesn’t have a complete list, relying on a partial list and queries with another machine to fill in what is missing as needed. The information about the zones are stored in “zone data files” also called db files (short for database files). The last part of this picture are resolvers. Resolvers are machines that connect to a name server to query the files for an IP address or a name resolution.

All of the information about a domain is maintained in resource records, or RRs. There are several classes of RRs, as well as several types of RRs within each class. Different RRs are used depending on the type of information to be stored.

One of the most important types of RR for name resolution purposes is called IN-ADDR-ARPA. This maps an IP address to a domain name. The IP address is actually read backwards (from machine to topmost domain) so the IP address 205.150.89.210 is actually stored as 210.89.105.205 in the RR. By reading the IP address from primary domain (205) to subdomain (105) to sub-subdomain (89) to machine (210), read right to left like a UNIX filename, the DNS system can resolve to a machine name.

Configuring a DNS Server

Why would you want a DNS server on your network? The most common reason is to handle the subdomains and machine identification of all incoming requests. You could let the Internet DNS system handle this for you, but that is seldom a good option for larger networks. Setting up your own DNS server for your network is not difficult, but it does require following a few steps to complete the task. Linux machines (as with most UNIX versions) are ideal for DNS server use, and the DNS server can reside on any workstation, including those in use by users or as application servers.

There are five files that need to be created or updated for most DNS purposes. These files are named.hosts (which defines the current domain as well as name to IP address mappings), named.rev (which use IN-ADDR-ARPA for IP address to name mappings), named.local (used for the loopback driver), named.ca (lists root domain servers), and names.boot or named.conf (provides file and database locations). The format for each of the five files follows RR formats, but instead of going through all the details, we’ll present sample files and let you modify them as you need. (If you need more details on resource records, a DNS or TCP/IP book should be able to provide all you need.)

The named.hosts file contains an RR called the Start of Authority (SOA), which indicates the domain name as well as a number of parameters for refreshing and retrying resolution attempts. Following the SOA RR is a Name Server (NS) RR which identified the name server for the network and subnetworks. Following the NS RR are several Address (A) RRs which define machine names and their IP addresses. These are used for name to IP address mapping. This is the named.hosts file from my Linux DNS server (I’ve changed the actual IP addresses for security reasons):

bullet ; named.hosts files

bullet ; Start Of Authority RR

bullet tpci.com. IN SOA merlin.tpci.com

bullet root.merlin.tpci.com (

bullet 2 ; Serial number

bullet 7200 ; Refresh (2 hrs)

bullet 3600 ; Retry (1 hr)

bullet 151200 ; Expire (1 week)

bullet 86400 ); min TTL

bullet ;

bullet ; Name Service RRs

bullet tpci.com IN NS merlin.tpci.com

bullet develop.tpci.com IN NS goofy.develop.tpci.com

bullet ;

bullet ; Address RRs

bullet artemis IN A 143.23.25.7

bullet merlin IN A 143.23.25.9

bullet windsor IN A 143.23.25.12

bullet reverie IN A 143.23.25.23

bullet bigcat IN A 143.23.25.43

bullet pepper IN A 143.23.25.72
…

You can use the same format for your named.hosts file, substituting the relevant machine names and IP addresses.

The named.rev file uses IN-ADDR-ARPA to resolve IP address to name mappings. The named.rev file uses a similar layout to the named.hosts file (it contains SOA and NS enries) but the Address RRs are replaced by Pointer (PTR) RRs. Here’s the named.rev file for my network:

bullet ; named.rev files

bullet ; Start Of Authority RR

bullet 23.143.in-addr.arpa IN SOA merlin.tpci.com

bullet root.merlin.tpci.com (

bullet 2 ; Serial number

bullet 7200 ; Refresh (2 hrs)

bullet 3600 ; Retry (1 hr)

bullet 151200 ; Expire (1 week)

bullet 86400 ); min TTL

bullet ;

bullet ; Name Service RRs

bullet 23.143.in-addr.arpa IN NS merlin.tpci.com

bullet 100.23.143.in-addr.arpa IN NS goofy.develop.tpci.com

bullet ;

bullet ; Address RRs

bullet 9.25.23.143.in-addr.arpa IN PTR merlin

bullet 12.25.23.143.in-addr.arpa IN PTR windsor

bullet 23.25.23.143.in-addr.arpa IN PTR reverie

bullet 43.25.23.143.in-addr.arpa IN PTR bigcat

bullet 72.25.23.143.in-addr.arpa IN PTR pepper
…

The PTR records at the end of the named.rev file use the reverse IP addresses to allow mapping to the machine names.

The named.local file is used for the loopback driver (which always has the IP address 127.0.0.l) and should be installed on each Linux machine that uses TCP/IP. The named.local file indicates the IN-ADDR-ARPA address of the loopback, and looks like this:

bullet ; named.local files

bullet ; Start Of Authority RR

bullet 0.0.127.in-addr.arpa IN SOA merlin.tpci.com

bullet root.merlin.tpci.com (

bullet 2 ; Serial number

bullet 7200 ; Refresh (2 hrs)

bullet 3600 ; Retry (1 hr)

bullet 151200 ; Expire (1 week)

bullet 86400 ); min TTL

bullet ;

bullet ; Name Service RR

bullet 0.0.127.in-addr.arpa IN NS merlin.tpci.com

bullet ;

bullet ; Address RR

bullet 1.0.0.127.in-addr.arpa IN PTR localhost

The named.ca file specifies the name servers the local name server should turn to when they can’t resolve an address or name mapping request. These tend to be machines that are on the Internet and don’t change IP addresses frequently. The machines are usually part of the Internet backbone and updates can be obtained from the NIC. Here’s a named.ca file:

bullet ; named.ca

bullet ; servers for the root domain

bullet ;

bullet . 99999999 IN NS ns.nic.ddn.mil.

bullet 99999999 IN NS ns.nasa.gov.

bullet 99999999 IN NS ns.internic.net

bullet ; servers by address

bullet ;

bullet ns.nic.ddn.mil 99999999 IN A 192.112.36.4

bullet ns.nasa.gov 99999999 IN A 192.52.195.10

bullet ns.internic.net 99999999 IN A 198.41.0.4

We’ve cut the number of nameservers listed to three to show the format, but normally there will be a dozen or more.

The final file on your DNS server is the named.boot file. It is used when the DNS daemon is loaded and specifies the primary and secondary name servers on the network. A named boot file looks like this:

bullet ; named.boot

bullet directory /usr/lib/named

bullet primary tpci.com named.hosts

bullet primary 25.143.in-addr.arpa named.rev

bullet primary 0.0.127.in-addr.arpa named.local

bullet cache named.ca

This file tells the DNS daemon (named) that the file named.hosts is to be used for the primary DNS server of the network, that the IN-ADDR-ARPA information is in named.rec, and the loopback is in named.local. The server and name cache information is in named.ca. The filenames we’ve used in these examples are the conventional naming system, but you could rename the files to anything you want.

Setting up DNS on your Linux servers takes a bit of time while you type all the information into these files. As you can image, if you have a couple of hundred machines on your network, you need to enter the information in both the named.hosts and named.rev files, which can take a while. Once done, through, you can maintain the files quite easily. There are some utilities available that will do a lot of the DNS setup work for you.

Running DNS on your local network will make the network function better, as it does not have to resort to name servers outside the network, and allows more flexibility for name to IP address mapping than an /etc/hosts file on each machine.