![[Go to Content]](/uworld/graphics/ti-go-to-content-button.gif)
![[Search Editorial]](/uworld/graphics/ti-search-button.gif)
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.
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.
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.