DNS stands for Domain Naming System.
A domain is any logical or physical collection of related hosts or sites.
A naming system is best visualized as an inverted tree of information
that corresponds to full qualified hostnames (see
The parts of a fully qualified name are separated
from one another with dots. For example,
This name describes the machine
that is part of the
subdomain of the
top-level domain. In
the dot at the top is the "root" of the tree.
It is implied but never
included in fully-qualified domain names:
The root corresponds to (is served by) actual machines.
Each has knowledge of all the top-level domains
, etc.) and the server machines
for those domains.
Each of the top-level domain's servers knows of one or more machines with
knowledge of the next level below.
For example, the server for
"knows" about the subdomains
but may not know
about anything below those subdomains, nor about the other
domains next to itself such as
A knowledgeable machine, one that can look up or distribute information about
its domain and subdomains, is called a
Each little black square in the figure represents a name server for a portion of
Each is required to have knowledge only of what is immediately
below it. This minimizes the amount of knowledge
any given name server must store and administer.
To illustrate the way this distributed information is used, see
for the steps that are taken when
(the local host) attempts to
(the remote host) to send
an email message to a user there.
needs the IP number of the
remote host to initiate a network connection. The local
asks its local name server (say,
) for that address.
name server may already
know the address (having cached that
information during a previous inquiry). If so, it gives the requested
address to the local
, and no further DNS requests
need to be made. If the local name server
doesn't have that information, it contacts other name servers for
the needed information.
In the case of
the local name server
next contacts one of the root servers (the dot in the big box in our example).
A root server will likely not have the information requested
but will indicate the best place to inquire.
For our example, the root server
recommends the name server for the
domain and provides
our local name server with the address of that
The local name server then contacts the
This process continues until a name server provides the
As it happens, any name server can return the final
answer if it happens to have it in its cache.
For our example,
knows the address for
It returns that address to the local name server, which in turn
returns the address to the local
Note that this is a simplified description. The actual practice can be more or
less complex depending on who is "authoritative" about which machines
and domains and what is cached where.
program needs the IP address
of the machine to which it must connect. That address can be
returned by name servers in three possible forms:
An MX (Mail eXchanger) record lists one or more machines
that have agreed to receive mail for a particular site or machine.
Multiple MX records are
tried in order of cost
(least to most). An MX record need not point
to the original receiving host.
MX records always take precedence over A records.
An A (Address) record gives the IP address directly.
A CNAME (Canonical NAME, or alias) record refers
to the real
name, which may have an A record or MX records.
Before we discuss DNS in greater detail,
we must first attend to an administrative detail.
Every site on the Internet should run BIND software version 4.8.3 at the
BIND provides the software and libraries that are needed to perform
Version 4.8.3 was the last stable version before
Paul Vixie (while at
) started rewriting the code. The current
release is 4.9.
Unless you are already running the latest version, you should consider
upgrading to V4.9.
BIND 4.9 is available via anonymous FTP from
We won't describe in this book how to install BIND. Instead, you
should refer to the book
DNS and BIND
Paul Albitz and Cricket Liu (O'Reilly & Associates, 2nd edition, 1997).
Not all releases of
are ready to use DNS. To determine whether
yours is ready, type the following command:
/usr/lib/sendmail -d0.1 -bt < /dev/null
Compiled with: LOG MIME8TO7
NETINET NETUNIX NEWDB SCANF
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = here
(canonical domain name) $j = here.uofa.edu
(subdomain name) $m = uofa.edu
(node name) $k = here
Look for a statement that indicates whether or not your
was compiled with NAMED_BIND support
Section 18.8.23, NAMED-BIND
). If so, it can use DNS.
If not, either you will have to get a corrected version
from your vendor
or you will have to download and compile the latest version of
from scratch (see
Section 18.3, "Obtain the Source"
But even if your
binary supports DNS, site configuration
If your host supports a service-switch file, for instance,
make sure it lists
as the method used to fetch
information about hosts.
Another possible problem might be your configuration
file. It may, for example, have been derived from the
Section 19.6.18, FEATURE(nodns)
grep dns /etc/sendmail.cf
##### @(#)nodns.m4 8.1 (Berkeley) 8/6/93 #####
If it was, as indicated by the phrase
, you can
back into the DNS business by setting the
) option (see
Section 34.8.55, ResolverOptions (I)
still seems unable to use
DNS, despite your efforts, look for other reasons for failure.
Make sure, for example,
file is present and that it contains
the address (not the name) of a valid name server machine for your domain.
If you are running NIS or NIS+, make sure it is configured
to look up hosts with DNS.