Cover V03, I01
Article
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Listing 1
Listing 2
Listing 3
Sidebar 1

jan94.tar


Configuring DNS

Matthew Ganis

Implementations of the Domain Name System (DNS), such as the Berkeley Internet Name Domain (BIND), route and respond to TCP/IP address queries. Without DNS the Internet couldn't deliver the mail.

Why DNS?

It is easier for a human to remember a machine named tequila than one called 164.120.32.12. The /etc/hosts file can provide a simple sequential mapping of machine names to TCP/IP addresses, such as

164.120.32.2   nirvana
164.120.32.3   ns
164.120.32.12  tequila
164.120.32.21  draco

but separate /etc/hosts files reside in each machine, and every time a new processer is added to the network, those files must be refreshed. This situation gets worse as the local network gets bigger and becomes especially unmanageable when the system includes off-site nodes. An efficient solution is the nameserver, a daemon process that runs on a specified machine and answers queries about name-to-address translations for other machines in the network, both local and remote.

DNS divides the network into a hierarchy of smaller groups (called domains) and provides a hierarchy of nameservers to service them. Each nameserver is responsible only for the TCP/IP addresses within its own domain, and it may delegate some or all of that responsibility to other nameservers. The nameservers can then share the reponsibility for responding to address queries.

A Typical Application

Consider a fictitious corporation called sinag, which is part of a larger network. Its domain is sinag.com. This leads to a tree structure with sinag.com as the parent node of three subdomains (see Figure 1).

The root address, sinag.com, exists only in namespace. There is no machine at this level, so a machine beneath it in the hierarchy must serve as the authoritative nameserver for the entire domain (in this example, ns.chg.sinag.com is serving as the authoritative nameserver). But what if the domain is too big for a single nameserver? What if the subdomain .chq is in a different building (or a different town) from the .research subdomain? The authoritative nameserver can delegate responsibility for each subdomain to another nameserver that is better equipped to oversee the address list for that region. In this case, host.eng.sinag.com is the nameserver for the engineering division, draco.chq.sinag.com is the nameserver for the .chq division, and madman.research.sinag.com is the nameserver for the research division. As Figure 2 shows, though the machines are in fact siblings, in the DNS hierarchy they form a tree.

Sometimes even after all the delegating it is beneficial to designate more than one nameserver to field address queries for a given portion of the domain. Redundant nameservers can speed up the turnaround and provide a hedge against catastrophe in the event of a system crash. Secondary nameservers are designed to serve in this capacity. Secondary nameservers obtain their data directly from the main (called the "primary") nameserver, eliminating the need for independent TCP/IP address map files. Updates to the address file are input once and the secondaries get the data from the primary server for the region. A nameserver can be primary for one domain and secondary for another. In this example, ns.chq.sinag.com (authoritative nameserver for the sinag.com domain) will also "help out" host.eng.sinag.com by serving as a secondary nameserver for the .eng subdomain.

Interaction of /etc/hosts and /etc/resolv.conf

The routing system on each machine in a particular subdomain must know the address of the specific machine that is running the nameserver for that subdomain. In DNS, this address information is in the /etc/resolve.conf file:

domain  eng.sinag.com
nameserver 164.120.32.3

The resolver is that part of the kernel that attempts to translate an ASCII name to a TCP/IP address or an address to an ASCII name. When a command is issued (for example, ping draco), the resolver first checks the /etc/resolv.conf (if it exists) to determine the default domain and nameserver. If there are no dots in the original name (in this example, with draco, there are none), the resolver appends the domain specified in the /etc/resolv.conf file to the name, forms a query, and sends it to the nameserver specified. If the namesever can't find an entry for the target machine, the resolver can then look into the machine's local /etc/hosts file for a match.

Configuring DNS

The configuration of the domain nameserver starts in the boot file called named.boot (typically this file is in the /etc directory but the default location can be overridden with the -b option upon startup).

The named.boot file

  • lists the domains for which the nameserver has address information

  • designates whether the nameserver will serve as a primary or secondary nameserver for each of the domains

  • shows where to find the additional information that will define the role of the nameserver in each of the domains.

    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.


     



  •