SETTING UP YOUR OWN DNS

Gary Kessler
March 1996

An edited version of this paper appeared with the title "Running Your Own DNS" in Network VAR, July 1996.

All hosts on the Internet, or any TCP/IP network for that matter, have an assigned 32-bit IP address. Most hosts have a name, as well, since host names are easier to remember than host addresses. The Domain Name System (DNS) is the distributed database that contains the names and addresses of all reachable hosts on a TCP/IP subnet, including the Internet.

Most, but not all, Internet service providers (ISPs) will set up and maintain the DNS information for their customers. There are several reasons, however, that a customer may want to operate their own DNS. This article will describe Internet domain names and the structure of the DNS, followed by a brief tutorial about creating and maintaining the DNS information.

INTERNET DOMAIN NAMES AND STRUCTURE

Internet host names use a hierarchical address structure comprising a top-level domain, subdomain, and host name. Top-level domain names and IP network addresses are assigned and maintained by the Internet Assigned Numbers Authority (IANA), which is responsible for the overall coordination and management of the DNS. Domain administrators are responsible for host name and address assignment within their domain.

"root"
.
|
-----------------------------------------------------------...
| | | | | | | | | |
com edu gov mil org net us fr ca jp
| | | | |
| -------- | ------- ac
| | | | | | |
| uvm smcvt | vt ca keio
| | | |
------- --------- state inst
| | | | | |
hill mfi ntia whitehouse dps myo
|
golem

FIGURE 1. Domain name tree.

The Internet naming hierarchy is best understood if a host name is read from right-to-left. All host names end with a top-level domain name (Figure 1). Generic top-level domains (although generally limited to the U.S.) include com (commercial organizations), edu (educational institutions, primarily 4-year colleges and universities), gov (U.S. government agencies), mil (U.S. military), org (non-profit organizations), net (network providers), and int (international treaty organizations).

The host name smcvax.smcvt.edu, for example, is assigned to a VAX computer (smcvax) within the St. Michael's College (Colchester, VT) subdomain (smcvt), which is within the educational top-level domain (edu). The name golem.hill.com refers to a host (golem) in the Hill Associates subdomain (hill) within the commercial top-level domain (com).

Other top-level domain names use international two-letter country codes, such as au (Australia), ca (Canada), de (Germany), es (Spain), fr (France), jp (Japan), mx (Mexico), and us (United States).

Each country determines for themselves how the country-based subdomains, and the associated DNS database, will be organized. The US domain, for example, is mostly organized on the basis of geography, usually using a name of the form organization.city.state.US; the format may be slightly different for special names, such as those for state government or K-12 and 2-year educational institutions. The address cnri.reston.va.us, for example, refers to the Corporation for National Research Initiatives located in Reston, Virginia. The ca subdomain within the us high-level domain does not cause a conflict with the ca high-level domain; the former refers to California and the latter to Canada. The host name myo.inst.keio.ac.jp refers to a system at the Science and Technology Department of Keio University in Yokohama, Japan; note that the ac subdomain within jp refers to academic institutions.

THE NAMING PROBLEM

As mentioned above, host names are easier to remember than IP addresses. Use of host names, then, is a convenience for the humans who use the network. The network has to provide some sort of name-address translation, however, for the network to operate.

The HOSTS.TXT file was used in the ARPANET prior to the definition of the DNS. This file contained the IP address, name, and alias(es) of every host on the ARPA network. This was a suitable scheme during the days when the network had only a few hundred systems and the network not very dynamic, but is wholly unsuited for the Internet with almost ten million hosts (as of January 1996) and 10% growth per month!

HOSTS.TXT files are still used, however. Their main function today is to contain the names of local systems so that one machine on a LAN (or other local network) can find other local systems without having to perform a DNS lookup. When TCP/IP software is configured on a host, the location of the HOSTS.TXT file must be provided if the file is used by a given system.

Domain: foo.com
IP address: 192.168.210.0

mail.foo.com dns.foo.com router.foo.com
192.168.210.4 192.168.210.2 192.168.210.1
--------------- -------------- ----------
| Mail server | | DNS server | | Router |===== Internet
--------------- -------------- ----------
| | |
=============================================== LAN
| | |
----------- ----------- -------------------
| User #1 | | System | | WWW/FTP server; |
----------- | Manager | | backup DNS/mail |
pc1.foo.com ----------- -------------------
192.168.210.5 pc2.foo.com mail2.foo.com
192.168.210.6 dns2.foo.com
Alias: 192.168.210.3
sysman.foo.com Aliases:
www.foo.com, ftp.foo.com,

FIGURE 2. Sample network for this article.

TABLE 1. Sample HOSTS.TXT file for the foo.com domain.

192.168.210.1 router.foo.com router
192.168.210.2 dns.foo.com dns
192.168.210.3 mail2.foo.com www ftp mail2 dns2
192.168.210.4 mail.foo.com mail
192.168.210.5 pc1.foo.com pc1
192.168.210.6 pc2.foo.com pc2 sysman


A sample HOSTS.TXT file is shown in Table 1 for the fictitous FOO.COM domain shown in Figure 2. Each line contains three fields: the IP address, host name, and (optionally) any aliases the system might use. As an example, a system on the local LAN that is trying to make an ftp connection to the local ftp server may attempt to open a connection to 192.168.210.3, ftp.foo.com, ftp, www, mail2, or dns2.

THE DOMAIN NAME SYSTEM

The DNS is a distributed database that contains the names and/or addresses of every host that is accessible via the Internet. The DNS was one of the key developments that allowed the Internet to grow as it has. Unlike the HOSTS.TXT files, which have to be individually maintained at every host on the network and be synchronized to ensure their correctness, DNS files are maintained by thousands of hosts on the network, each responsible for a portion of the name space (called a zone). The DNS provides a mechanism so that backup databases can be identified in case the first one becomes unavailable. DNS databases are updated automatically so that information on one name server does not remain out-of-date for long.

When TCP/IP software is installed on a host, the address (not the name!) of one or more (usually no more than three) name server(s) is one of the configured parameters. When the host attempts to establish a connection to another IP host, it will first check its local HOSTS.TXT file (if there is one) for the name of the remote host. If the remote host is not in the HOSTS.TXT file, the host will send a query to the primary DNS name server. The primary name server may well not contain the information about the particular destination host; in that case, the query must be forwarded to another name server that is higher up on the domain name hierarchy.

Consider the following example. Suppose a user on a system at Baz University (domain baz.edu) wishes to initiate a connection to the WWW server at Foo Corp. (www.foo.com). The following name resolution steps would occur:

1. The Baz host will check its HOSTS.TXT file. In this example, Foo's WWW server is not found.
2. The Baz host will then check its primary DNS name server. Since the Baz DNS server probably only covers the baz.edu zone, it will not contain Foo's WWW server's address; instead it will forward the query.
3. The query is passed to a name server higher up in the DNS hierarchy. A database exists for every top-level domain and it contains the name of every subdomain within that top-level domain, and its assigned name server(s). When the higher-level name server checks the com DNS file, it will find an entry for foo.com and the address of its DNS server(s). This information is returned to the Baz DNS server.
4. The query is forwarded to one of the name servers for foo.com, which returns the IP address of the WWW server (198.168.210.3).

The DNS can be examined with a number of common TCP/IP tools. The most common DNS lookup utilities are NSLOOKUP and Host. If you turn off the recursive option, you can see these steps in more detail.

The DNS database contains different types of information on resource records (RRs). The most common RRs are:

* SOA: Start of Authority records indicate the authoritative name server for a given domain and a few additional administrative items.
* A: Address records supply the IP address for a given host name.
* CNAME: Canonical Name records supply host alias names. It is allowable to define multiple A records for a given address, thus providing alias, or alternate, host names. It is usually easier (and less prone to human error) to supply one A record for a given address and use CNAME records to define alias host names for that address.
* PTR: Pointer records associate a host name with a given IP address. These records are used for reverse name lookups.
* MX: Mail Exchange records define the mail system(s) for a given domain.
* NS: Name Server records define the name server(s) for a given domain.

DNS SERVER SOFTWARE

DNS server software may be found by a variety of names depending on the operatng system; Windows NT simply refers to DNS while UNIX will have named or BIND (Berkeley Internet Name Daemon). When the DNS process is launched, the name of a boot file must be provided; this file contains the names of the database files containing the DNS information. A sample boot file, which might be called named.boot, is shown in Table 2.

TABLE 2. Sample named/BIND boot file.

; FILE: named.boot
directory /usr/local/named

;Type Domain Data file
primary foo.com foo.com.zone
primary 210.168.192.in-addr.arpa foo.com.rev
primary localhost localhost.zone
primary 0.0.127.in-addr.arpa localhost.rev
primary 0.in-addr.arpa all-zero.zone
primary 255.in-addr.arpa all-one.zone
cache . named.cache


The first record in the boot file contains directory information and points to the directory where the DNS program files reside. The remaining records each contain three fields which describe a DNS database file: the type of DNS information, the domain defined in the file, and the filename. There are six records that refer to DNS databases for which this DNS server has primary responsibility. The six domains defined here are:

* foo.com: The DNS entries for the foo.com zone, which are in the file foo.com.zone.
* 210.168.192.in-addr.arpa: The foo.com domain is associated with the IP Class C address 192.168.210.0 (a valid IP address for use in a private network per RFC 1918). Reverse lookups (i.e., obtaining the host name from an IP address) are accomplished with a reverse database file. The name of the domain is the reverse dotted decimal notation of the domain's IP address, followed by in-addr.arpa, an indication of the use of IP addresses within the ARPA address assignment domain. This latter nomenclature is an historic holdover from when more than one type of address could be found and when there was more than one addressing authority. The file containing this data is foo.com.rev.
* localhost: "Localhost" is a special IP name that always refers to the local host and, by convention, has the IP address 127.0.0.1. This information is in the file called localhost.zone.
* 0.0.127.in-addr.arpa: The Class A address 127.0.0.0 is reserved in IP for local loopback. This address, therefore, is not maintained by any global DNS registry. For completeness and security, we define the reverse lookup for this address in a file called localhost.rev.
* 0.in-addr.arpa and 255.in-addr.arpa: The all zeros (0) and all ones (255) addresses are reserved for special purposes in IP. These "domains" are defined in the all-zero.zone and all-one.zone file, respectively.

The final record defines where the DNS cache information for the root domain (".") can be found. This is not a "cache," as in short-term memory, but is a set of fixed pointers to the higher-level DNS databases. In this example, the cache information is maintained in the file named.cache.

DNS RECORD FORMATS AND DATABASE FILES

All of the DNS resource records have a similar format. Although there are many shortcut notations and abbreviations that may be found in DNS files, these examples use the simplest nomenclature to eliminate confusion and/or ambiguity.

The first field in any DNS record is always either an IP address or a host name. If it is missing, then the name/address from the previous record is implied. Note that all names and addresses end with a trailing "dot" (.). This signifies that the name or address is an absolute name/address rather than a relative name/address. Absolute addresses, also called fully qualified domain names, are relative to the root, while relative addresses are relative to a default domain (which may or may not be the root). This field may, optionally, be followed by a Time-to-Live (TTL) value, which indicates the length of time that the information in this field should be considered valid.

The second field indicates the address type. In today's DNS databases, the string "IN" is most likely to be found to indicate an Internet address. This field is present for historical purposes and compatibility with older systems.

The third field is a string that indicates the type of resource record. This field is followed by optional parameters that are specific to the RR.

TABLE 3. Sample foo.com.zone file.

; Start of Authority (SOA) record
foo.com. IN SOA dns.foo.com. dnsowner.foo.com. (
19960105 ; serial # (date format)
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400) ; TTL (1 day)

; Name Server (NS) records.
foo.com. IN NS dns.foo.com.
IN NS dns2.foo.com.

; Mail Exchange (MX) records.
foo.com. IN MX 20 mail.foo.com.
IN MX 40 mail2.foo.com.

; Address (A) records.
localhost.foo.com. IN A 127.0.0.1

router.foo.com. IN A 192.168.210.1
dns.foo.com. IN A 192.168.210.2
mail2.foo.com. IN A 192.168.210.3
dns2.foo.com. IN A 192.168.210.3
mail.foo.com. IN A 192.168.210.4
pc1.foo.com. IN A 192.168.210.5
pc2.foo.com. IN A 192.168.210.6

; Aliases in Canonical Name (CNAME) records...
ftp.foo.com. IN CNAME mail2.foo.com.
www.foo.com. IN CNAME mail2.foo.com.
sysman.foo.com. IN CNAME pc2.foo.com.


The foo.com.zone file (Table 3) contains information about the foo.com domain, including name lookup, mail exchange, and name server information. Specific resource records of note include:

* The SOA record includes the name of the DNS server system and the e-mail address of the person responsible for the name server. Note that the e-mail address is not in the expected form; rather than user@domain, the format user.domain is used. This record also contains five other parameters:
1. The serial number identifies the version of the DNS database. Whenever the file's information is changed, the serial number must be incremented so that secondary servers that examine this database know that the information has been altered. In this example, we use a serial number format containing the year (all four digits!), month, and day of the last update, a numbering scheme that is usually sufficient if you don't change your DNS database more than once a day. Some systems just start counting at 1 and increment it every time there's a change.
2. The refresh value tells the secondary name server(s) how often to check for updated information (10,800 seconds is three hours).
3. If the secondary name server is unable to contact the primary name server, it will re-attempt a connection every retry seconds (3600 seconds is one hour).
4. If a secondary name server cannot contact the primary name server for expire seconds, the secondary will stop answering any queries about this domain. The theory here is that at some point, the data is so old as to be possibly harmful, and no answer is better than a bad answer (604,800 seconds is one week).
5. The TTL (time-to-live) value is returned with all responses to database queries, and tells the requester (or other servers) how long the information can safely be cached (86,400 seconds is one day). This TTL value is the default value for all records in the file; it may be over-ridden by a TTL value provided with a given RR.
* The NS records contain the address of the name server(s) for this domain. In this example, there are two name servers with the foo.com DNS information.
* The MX records contain the address of the mail exchange system(s) for this domain. The number before the address is the preference. When a remote user sends mail to user@foo.com, the remote mail system looks up the MX record for the foo.com domain. The remote mailer will then attempt to establish a Simple Mail Transfer Protocol (SMTP) connection with the foo.com mail system with the lowest preference value (in this case, mail.foo.com). If that system is not available, the remote mailer tries the next level mailer, in this case mail2.foo.com.
* The A records contain an IP address to be associated with the host name in the first field of the record.
* The CNAME records contain an alias host name to associate with the host named in the first field of the record. Although a single A records and many CNAME records can be assigned to a single system, care must be taken; some mailers, for example, do unpredictable things when asked to resolve an MX host name that uses a CNAME record rather than an explicit A record. In the examples below, the address of both the backup DNS and mail servers are specified with separate A records, even though they point to the same machine.


TABLE 4. Sample foo.com.rev file.

; Start of Authority (SOA) record
210.168.192.in-addr.arpa. IN SOA dns.foo.com. dnsowner.foo.com.
(19960105 ; serial # (date format)
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400) ; minimum TTL (1 day)

; Name Server (NS) records.
210.168.192.in-addr.arpa. IN NS dns.foo.com.
IN NS dns2.foo.com.

; Addresses point to canonical names (PTR) for reverse lookups
1.210.168.192.in-addr.arpa. IN PTR router.foo.com.
2.210.168.192.in-addr.arpa. IN PTR dns.foo.com.
3.210.168.192.in-addr.arpa. IN PTR mail2.foo.com.
4.210.168.192.in-addr.arpa. IN PTR mail.foo.com.
5.210.168.192.in-addr.arpa. IN PTR pc1.foo.com.
6.210.168.192.in-addr.arpa. IN PTR pc2.foo.com.


Reverse lookups are handled by the database file for the IP address domain. The records and their formats are essentially the same as above, except that PTR records are used instead of A records. PTR records contain a host name to associate with the IP address that is in the first field of the record. The foo.com.rev file that corresponds to the FOO.COM network is listed in Table 4.

TABLE 5. Sample localhost.zone file.

localhost. IN SOA dns.foo.com. dnsowner.foo.com. (
19950910 ; serial # (date format)
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400) ; minimum TTL (1 day)

localhost. IN NS dns.foo.com.
IN NS dns2.foo.com.

localhost. IN A 127.0.0.1



TABLE 6. Sample localhost.rev file.

; Start of Authority (SOA) record
0.0.127.in-addr.arpa. IN SOA dns.foo.com. dnsowner.foo.com. (
19951106 ; serial # (date format)
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400) ; minimum TTL (1 day)

; Name Server (NS) records.
0.0.127.in-addr.arpa. IN NS dns.foo.com.
IN NS dns2.foo.com.

; Only one PTR record
1.0.0.127.in-addr.arpa. IN PTR localhost.


Tables 5 and 6 show sample localhost.zone and localhost.rev files, respectively, providing forward and reverse address lookups for the loopback address. Tables 7 and 8 show sample files for the all zeros and all ones addresses. As mentioned above, these files are provided only for completeness and security.

TABLE 7. Sample all-zero.zone file.

0.in-addr.arpa. IN SOA dns.foo.com. dnsowner.foo.com. (
19950910 ; serial # (date format)
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400) ; minimum TTL (1 day)

0.in-addr.arpa. IN NS dns.foo.com.
IN NS dns2.foo.com.



TABLE 8. Sample all-one.zone file.

255.in-addr.arpa. IN SOA dns.foo.com. dnsowner.foo.com. (
19950910 ; serial # (date format)
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400) ; minimum TTL (1 day)

255.in-addr.arpa. IN NS dns.foo.com.
IN NS dns2.foo.com.


Finally, if a name cannot be resolved by the local name server, the query will be forwarded to a name server higher up on the domain name tree. The named.cache file contains the addresses of the top-level DNS servers. This actual file should be downloaded periodically from the Internet Network Information Center (InterNIC) at ftp://rs.internic.net/domain/named.cache; note that this file is also called named.root and named.ca. Table 9 shows an abbreviated version of the current named.cache file (most comments have been removed in the interest of space). The single "." indicates the root domain, while the "3600000" is the TTL value, indicating that these entries should expire after about 6 weeks (3.6 million seconds).

TABLE 9. The November, 1995 named.cache file.

; last update: Nov 8, 1995
; related version of root zone: 1995110800
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
; End of File

WHY MAINTAIN YOUR OWN DNS

Since most ISPs will maintain a DNS for you, why should a network manager consider operating their own? The most obvious and pressing reason is that not all ISPs will do this for you so, in some cases, you will have to do this yourself.

However, a site may want to run their own DNS anyway, primarily for better control and to ensure the database's accuracy. If your site is constantly moving systems around, changing host names, and/or changing IP addresses, your ISP may not be able to keep the DNS as up-to-date as you would like -- or need. Another issue is reverse name mapping; some ISPs keep reverse name information only for servers but not the individual host systems. In this case, users may not be able to connect to FTP or other information servers that attempt to reconcile the user's host name with the IP address. Furthermore, as your site grows in size and complexity, your ISP may be unable or unwilling to continue to meet your needs.

AND THAT'S NOT ALL...

Running a DNS is not terribly hard but one must be very careful when creating the databases. The DNS files must be updated whenever a system name or address change is made. The serial number must be appropriately updated whenever a change is made. The most up-to-date named.cache file must be periodically downloaded from the InterNIC. Zone transfers, the procedure for moving DNS data between primary and secondary name servers, must be managed.

These procedures, and more, are not difficult but must be planned. The example shown in this article is a very simple case for a small LAN attached to the Internet; much more complex arrangements are possible. One of the best references for establishing, maintaining, and troubleshooting a DNS server is DNS and BIND by P. Albitz and C. Liu (O'Reilly & Associates, 1992). Several Request for Comments (RFCs) documents describe the basic background concepts of the DNS, including RFCs 1591 (Domain Name System Structure and Delegation), 1035 (Domain Names - Implementation and Specification), 1034 (Domain Names - Concepts and Facilities), and 974 (Mail Routing and the Domain System). Several other RFCs describe potential DNS pitfalls and tools, including RFCs 1912 (Common DNS Operational and Configuration Errors), 1713 (Tools for DNS Debugging), and 1536 (Common DNS Implementation Errors and Suggested Fixes).

There is also an Internet discussion list for DNS protocol-related issues; this list is not for DNS questions. To subscribe to the list, send mail to namedroppers-request@nic.ddn.mil and put the word subscribe in the body of the message.

As a final note, IP version 6 (IPv6) will use a 128-bit address and an address architecture that is different from today's IP version 4. IPv6 and the new address structure are described in RFCs 1883 and 1884, respectively. RFC 1886 describes extensions to the DNS that will be necessary to accommodate IPv6, in particular the AAAA resource record and IP6.INT address domain.

ABOUT THE AUTHOR: At the time this article was published, Gary Kessler was a Senior Member of Technical Staff at Hill Associates, a telecommunications training and education firm headquartered in Colchester, VT. Gary is the author of over 50 papers for industry publications and the co-author of ISDN, 3rd. edition (McGraw-Hill, 1997). He may be reached on the Internet at kumquat@sover.net.