Implementations of the Domain Name System (DNS), such
as the Berkeley
Internet Name Domain (BIND), route and respond to TCP/IP
Without DNS the Internet couldn't deliver the mail.
It is easier for a human to remember a machine named
than one called 22.214.171.124. The /etc/hosts file can
provide a simple
sequential mapping of machine names to TCP/IP addresses,
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,
process that runs on a specified machine and answers
name-to-address translations for other machines in the
local and remote.
DNS divides the network into a hierarchy of smaller
domains) and provides a hierarchy of nameservers to
Each nameserver is responsible only for the TCP/IP addresses
its own domain, and it may delegate some or all of that
to other nameservers. The nameservers can then share
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
this example, ns.chg.sinag.com
is serving as the authoritative
nameserver). But what if the domain is too big for a
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
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,
is the nameserver for the research division. As Figure
2 shows, though
the machines are in fact siblings, in the DNS hierarchy
Sometimes even after all the delegating it is beneficial
more than one nameserver to field address queries for
a given portion
of the domain. Redundant nameservers can speed up the
provide a hedge against catastrophe in the event of
a system crash.
Secondary nameservers are designed to serve in this
nameservers obtain their data directly from the main
(called the "primary")
nameserver, eliminating the need for independent TCP/IP
files. Updates to the address file are input once and
get the data from the primary server for the region.
can be primary for one domain and secondary for another.
In this example,
ns.chq.sinag.com (authoritative nameserver for the sinag.com
will also "help out" host.eng.sinag.com
as a secondary nameserver for the .eng
Interaction of /etc/hosts and /etc/resolv.conf
The routing system on each machine in a particular subdomain
know the address of the specific machine that is running
for that subdomain. In DNS, this address information
is in the /etc/resolve.conf
The resolver is that part of the kernel
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
resolver first checks the /etc/resolv.conf (if it exists)
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
can't find an entry for the target machine, the resolver
look into the machine's local /etc/hosts file for a
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
designates whether the nameserver will
serve as a primary
or secondary nameserver for each of the domains
shows where to find the additional information
will define the role of the nameserver in each of the
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
for the sinag.com.120,
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 126.96.36.199
and stored in the backup file /etc/named.eng.bak.
The source files referenced in named.boot are in standard
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 firstname.lastname@example.org
(note that the "@" symbol is replaced
with a "." to
form an e-mail address). In the next line are five parameters
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,
number should be increased by one to reflect that a
When a secondary is checking for changed data, it compares
number it has for the zone with the serial number of
zone. If the primary has a higher serial number, a zone
and the secondary obtains a "refresh"
of data for the zone.
Next is the refresh interval. Once a secondary nameserver
a zone transfer, how long should it wait until it checks
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,
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
an update from the primary nameserver. In this example
I've set the
expire value to 259,200 seconds, so if a refresh fails
(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
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,
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
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,
also transform addresses to names. Services like lpd
address-to-name translation as a rudimentary security
/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
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
188.8.131.52 into a name, for instance, enterprise.chq.sinag.com
domain in Figure 3 defines the loopback
address of the local machine. The loopback address tells
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,
file which defined zone 0.0.127.in-addr.arpa).
Once the domain nameserver is up and running, DNS provides
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
USR2 -- turns off all debugging.
As the named process comes up, it writes its process
ID into the file
/etc/named.pid for later
Listing 1 is a simple shell script to make nameserver
bit easier. It turns debugging on or off and dumps or
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
the SOA record for my domain. For this article, I've
most of the interesting fields and combined them into
file called ns.config
About the Author
Matt Ganis is currently an Advisory programmer
for the Advantis
corporation, located in White Plains, NY where he works
networking. In his spare time he teaches Astronomy at
in Pleasantville, NY. He can be reached at 14 Udell
Manor, NY 10566 or email@example.com.