UnixWorld Online: ``PC-Unix Connection'' Column No. 004

The Domain Name System

By Tom Yager

On a network as vast as the Internet it would be impractical to identify
each system solely by its numeric IP address. Even on a corporate LAN that
connects more than a handful of machines, names are more than a convenience.
They help users and administrators locate far-flung network resources more
easily.

TCP/IP networking relies on a system's IP address to route its network
traffic. To give humans something better to work with, there is the Domain
Name System (DNS). Like much of the Internet's structure, DNS is a
fascinating notion: it's a distributed database holding the alphanumeric
names and IP addresses (and more) of every registered system on the
Internet. The databases are held by systems running name servers, usually
Unix machines running the Berkeley Internet Name Domain (BIND) software.

Each name server holds in its database the name-to-address mappings for a
group of hosts. The DNS database holds other data, too, which I'll describe
shortly. Smaller servers keep track of a single domain; ``maxx.net'',
``wcmh.com'' and ``npr.org'' are examples of domains. Beyond domain-specific
servers there are mid-level servers that maintain data for several domains.
The root name servers hold data for all the top-level domains (like ``com'',
``org'', and ``net'' and geographical domains like ``us'', ``uk'', and
``jp'' to name a few). These root name servers make it possible for every
host on the Internet to have access to the complete DNS database.

The process of translating given names to IP addresses is called name
resolution. Let's say you're sending a piece of mail to a friend on the
Internet. Your mail delivery program will parse the destination address and
pull out the host name. Making an SMTP (Simple Mail Transfer Protocol)
connection requires knowledge of the remote host's IP address. So the mail
delivery agent makes a function call to the name resolver. This code is part
of the standard C library on most operating systems derived from the
Berkeley Unix system.

The resolver will perform name-to-address translations according to the
contents of its configuration file, /etc/resolv.conf. This file lets you
configure three aspects of resolver operation: the default domain, the
search list, and up to three name servers that the resolver queries. (Some
vendors have extended this standard configuration).

Here's my resolver configuration file:

; Default domain:
domain maxx.net
; Name servers:
nameserver 204.251.17.241
nameserver 204.251.17.98

The purpose of the ``domain'' entry is to assign a default domain name. When
the resolver is queried with a name that's not a fully qualified domain name
(FQDN)--say just the host name--it will append this default domain before it
attempts resolution.

Newer versions of BIND (newer than that in the UnixWare I'm using) permit
the use of the ``search'' keyword. Under normal circumstances, host names
that are not fully qualified are automatically resolved by tacking on the
local domain, then the parent of that domain, and so on until a match is
found. For instance, In the domain ``dallas.maxx.net'', the request ping
wilma would generate resolver queries for ``wilma.dallas.maxx.net'', then
``wilma.maxx.net''. The resolver stops at the last qualifier, knowing that a
search of the top-level domain (here, ``net'') would be useless.

You may specify up to six domains to be searched in order whenever an
unqualified name is presented to the resolver. This sample resolv.conf file
line:

search dallas.maxx.net austin.maxx.net tx.maxx.net maxx.net

creates a search list that modifies the natural search order.

If the system you're configuring will be running its own name server you
must include an entry containing your system's own IP address. You could try
the localhost address, 127.0.0.1, but some systems apparently have a bug
that prevents this from working. Either way, you need to point to your local
host. Otherwise, the resolver will never look in your system's own database
to identify systems on your own LAN. Imagine having every request for a
local machine's address shipped to a root name server thousands of miles
away!

If you're just putting one system on the Internet you should be content
without running your own name server. All you need to do is create a
/etc/resolv.conf file with the address of your service provider's name
server. You might also want to include a ``domain'' entry for your
provider's domain.

If your provider has more than one name server, you can name up to three in
the file. The resolver will automatically fail over to a second, then a
third server if the second server fails to respond.

Your Own Server

If you have more than a couple of machines connected to the Internet you may
want to run your own name server. It's not essential; chances are your
service provider will create entries in its database for your machines. It
may take some time for your provider's staff to satisfy your name server
database change requests. Also, if you're going to register your own domain
it's wise to maintain a name server. It will make it easier to change
providers later if that becomes necessary.

Domain registration is a necessary step. You can run a name server on your
host, but until it's registered no one outside your LAN will know your name
server exists. You'll probably need your service provider's help submitting
a domain registration; it's a service most providers offer for a fee. It's a
bit of a chicken-and-egg scenario: your name server is useless until your
domain is registered, but the Internet Network Information Center (InterNIC)
requires that your name server be running when your registration is
submitted.

No matter who registers your domain, it'll set you back a few bucks. Each
new domain costs $100. That buys you two years on the InterNIC's books.
After that you'll need to pay $50 a year to keep your domain active. The
InterNIC will send you a reminder 60 days before your yearly payments are
due. Check with your provider to see if they're covering these fees for you.

You'll need to provide InterNIC an address for a secondary name server. This
can be a separate system on your LAN, or perhaps your service provider can
help. If your name server goes down, other systems' name server daemons will
fail over to the secondary server you specify. There isn't room here to
launch into a discussion of setting up secondary servers; consult the book
mentioned at the end of this article if you need details. You can also
obtain information from the InterNIC Registration Services Web site
(http://rs.internic.net/rs-internic.html).

If you choose to run your own name server you'll be using a program called
named, the BIND server program. Check your system's manual pages for the
location; under UnixWare it's in /usr/sbin/in.named. Configuration
information for named is contained in a database that consists of a group of
ASCII text files. The first such file, /etc/named.boot, tells named where to
find the rest of the database. Here's what my ``boot'' file contains:

directory       /usr/local/bind
primary         maxx.net                        maxx.net.hosts
primary         0.0.127.in-addr.arpa            named.local
primary         17.251.204.in-addr.arpa         maxx.net.revhosts
cache           .                               named.ca

The first entry specifies the directory in which the database files are
held. The last column of the remaining entries holds the file names. For a
system running a full name service, you need to include four databases: your
domain, your loopback network, your reverse domain, and the root name-server
hints file.

We'll discuss your domain database next time; that's where most of the
action is. The name server not only binds names to addresses, but can also
do the reverse: given an IP address, it can serve up the name of the system.
(This way log files can contain readable names instead of lists of IP
numbers). The loopback (``localhost'') entry is a special case. Applications
on your system reverse-resolving your loopback address would hit a brick
wall because the loopback address (127.0.0.1) looks to be part of a
different network. The named.local file is a special entry to register the
network 127.0.0 and its single host, numbered 1.

Reverse-resolution entries look a little strange because the IP addresses
you specify for this treatment must be entered backward. Take each of the
dot-separated elements of the network portion of your IP address and reverse
them, last to first. So the loopback network, 127.0.0, becomes 0.0.127. The
reserved domain ``in-addr.arpa'' is added to identify its purpose.

Just as named.local sets up reverse-resolution for the loopback network, so
maxx.net.revhosts does for the hosts in the maxx.net domain. You can, by the
way, name your database files anything you like. Just create an entry in
/etc/named.boot that points to each file.

The last entry--which is crucial to all systems--specifies a file that holds
the addresses of the root name servers. This file is called the cache file
because earlier BIND versions would cache all the data it found in this
file. However, that's no longer the case, but the term cache file stuck.
Thus, root name-server hints file is more accurate.

There are two classes of responses to resolver queries: indirect and
authoritative. An indirect response is one that your resolver can't resolve
locally. It must pass the request to another name server, which may in turn
pass it along, and so on until the query is resolved. An authoritative
response is one which is contained in a server's own database.

Is it important to get authoritative responses? They're quicker and, as the
name implies, more current and accurate. However, propagation of DNS
database changes amongst the root servers is quite efficient. Changes you
make to your name server's database can be picked up by the root servers in
a few minutes or a few hours.

Next month we'll talk about the nslookup program, and a popular
public-domain alternative named dig. These are marvelously useful commands
which can, among other things, tell you whether your name server (or
another) is healthy.

More to Come

In the next installment I'll cover the database files and more. If you're
itching to read ahead, be my guest. By far the best book on the subject is
DNS and BIND by Paul Albitz and Cricket Liu, published by O'Reilly and
Associates. The ISBN is 1-56592-010-4. O'Reilly and Associates provide a
descriptive Web page (http://www.ora.com/gnn/bus/ora/item/dns.html).

Thanks for reading. See you next month.

----------------------------------------------------------------------------
Copyright © 1995 The McGraw-Hill Companies, Inc. All Rights Reserved.
Edited by Becca Thomas / Online Editor / UnixWorld Online /
editor@unixworld.com

 [Go to Content]   [Search Editorial]

Last Modified: Wednesday, 03-Jan-96 14:50:13 PST