Figure 3 shows the named.boot file for the nameserver of the sinag.com domain, which will run on the host ns.chq.sinag.com. The file defines five "zones" of domain addresses for which the nameserver will provide information. When the daemon starts, data for the sinag.com.120, 164.in-addr.arpa., chq.sinag.com., and 0.0.127.in-addr.arpa. zones will be loaded from their respective source files. Because the nameserver is serving as a secondary for the eng.sinag.com domain, data for this domain is obtained via the network from the machine at TCP/IP address 164.120.32.1 and stored in the backup file /etc/named.eng.bak.

The source files referenced in named.boot are in standard reference record format (see sidebar). The Start-of-Authority (SOA) record for the sinag.com domain is shown in Figure 4.

Every zone must have an SOA record. It defines a domain, in this case sinag.com, and declares that the authoritative machine for this domain is ns.chq.sinag.com. Any questions regarding this nameserver should be directed to sysadmin@draco.sinag.com (note that the "@" symbol is replaced with a "." to form an e-mail address). In the next line are five parameters which regulate the activities of secondary nameservers.

The first parameter is the serial number associated with this version of the data. If the data changes on the primary nameserver, the serial number should be increased by one to reflect that a change occurred. When a secondary is checking for changed data, it compares the serial number it has for the zone with the serial number of the primary's zone. If the primary has a higher serial number, a zone transfer occurs and the secondary obtains a "refresh" of data for the zone.

Next is the refresh interval. Once a secondary nameserver has done a zone transfer, how long should it wait until it checks with the primary again to see if it the data has changed? The value is a time period expressed in seconds (in this case it's one day, or 86,400 seconds).

The retry interval tells the secondary nameserver how long it should wait (in this example, 600 seconds) before it tries again in the event that it can't reach the primary through the network.

The expire value defines how long data should be held without getting an update from the primary nameserver. In this example I've set the expire value to 259,200 seconds, so if a refresh fails three times (i.e., if fails for 3 days), the secondary assumes the data is invalid and expires it.

To help save on network overhead, nameservers also cache information locally. Each record has a time-to-live (TTL) value. Any given piece of information can exist in a nameserver cache only for the length of the time-to-live. If the TTL is not coded on a record, the minimum TTL (coded in the SOA record) is used.

The file then designates ns.chq.sinag.com as a nameserver and gives its address. The $include control word allows the sysadmin to insert another file. I use this technique to keep the data for my domain separate from the SOA record. This allows for easier editing. Figure 5 shows the included file, which designates nameservers for the various subdomains within sinag.com.

The SOA records for the subdomains (e.g., chq) shown in Figure 6, look similar to the one in Figure 4.

The data file for the chq.sinag.com domain is shown in Figure 7.

Nameservers must not only translate names into addresses, but must also transform addresses to names. Services like lpd require address-to-name translation as a rudimentary security measure. The /etc/named.rev file contains the map of TCP/IP addresses to names (see Figure 8). in-addr.arpa is an "anchor" or indicator that the end of the line has been reached (similar to a dot).

Each resource record (RR) is a pointer (for lack of a better term) to a fully qualified domain name. So when a request is sent to resolve 164.120.32.199 into a name, for instance, enterprise.chq.sinag.com is returned.

The 0.0.127.in-addr.arpa domain in Figure 3 defines the loopback address of the local machine. The loopback address tells the machine how to send queries to itself. Figure 9 shows the SOA record for this domain. The "@" in the owner field of the SOA record tells the nameserver to use the previous owner (in this case, the named.boot file which defined zone 0.0.127.in-addr.arpa).

Signals

Once the domain nameserver is up and running, DNS provides certain signals than can be sent (via the kill command) to the process.

HUP -- causes the daemon to re-read the /etc/named.boot file and reload the database. This is useful when you add a new entry to your nameserver.

INT -- dumps the contents of the DNS database to the file /usr/tmp/named_dump.db.

USR1 -- increases the debugging level by 1 each time it is sent. Debugging is done by levels of verboseness (1 = quiet and 15 = very active). I like a medium level of debugging, somewhere around 5 or 6.

USR2 -- turns off all debugging.

As the named process comes up, it writes its process ID into the file /etc/named.pid for later reference.

Listing 1 is a simple shell script to make nameserver debugging a bit easier. It turns debugging on or off and dumps or reloads the database.

Listing 2 is a shell script I use every time I make a change to my database. Its purpose is to create a new serial number and rebuild the SOA record for my domain. For this article, I've parameterized most of the interesting fields and combined them into a config file called ns.config (Listing 3).

About the Author

Matt Ganis is currently an Advisory programmer for the Advantis corporation, located in White Plains, NY where he works on multi-protocol networking. In his spare time he teaches Astronomy at Pace University in Pleasantville, NY. He can be reached at 14 Udell Ct, Cortlandt Manor, NY 10566 or ganis@vnet.ibm.com.