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 Figure 21.1).
This name describes the machine
here that is part of the
subdomain of the
edu 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:
 Well, hardly ever. It can be used under some circumstances to prevent the local domain from being accidently appended improperly.
The root corresponds to (is served by) actual machines.
Each has knowledge of all the top-level domains
com, 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
edu "knows" about the subdomains
uofc but may not know
about anything below those subdomains, nor about the other
domains next to itself such as
 This used to be a single machine named ns.internic.net but is now several machines named a.root-servers.net, b.root-servers.net, and so on.
A knowledgeable machine, one that can look up or distribute information about its domain and subdomains, is called a name server. Each little black square in the figure represents a name server for a portion of a domain. 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 Figure 21.2 for the steps that are taken when sendmail on here.uofa.edu (the local host) attempts to connect to fbi.dc.gov (the remote host) to send an email message to a user there.
The local sendmail needs the IP number of the remote host to initiate a network connection. The local sendmail asks its local name server (say, mail.uofa.edu) for that address. The mail.uofa.edu 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 sendmail, 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 fbi.dc.gov 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 .gov domain and provides our local name server with the address of that .gov domain server machine.
The local name server then contacts the .gov name server. This process continues until a name server provides the needed information. As it happens, any name server can return the final answer if it happens to have it in its cache. For our example, .gov knows the address for fbi.dc.gov. It returns that address to the local name server, which in turn returns the address to the local sendmail.
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.
The sendmail 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.
 Technically, this field is called the preference. We use cost to clarify that lower values are preferable, whereas preference wrongly connotes that higher values are preferable.
An A (Address) record gives the IP address directly.
A CNAME (Canonical NAME, or alias) record refers sendmail 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 minimum. BIND provides the software and libraries that are needed to perform DNS inquiries. Version 4.8.3 was the last stable version before Paul Vixie (while at dec.com) started rewriting the code. The current release is 4.9. 
 As of the final draft of this manuscript, release 4.9.3 was the most recent.
We won't describe in this book how to install BIND. Instead, you should refer to the book DNS and BIND by Paul Albitz and Cricket Liu (O'Reilly & Associates, 2nd edition, 1997).
/usr/lib/sendmail -d0.1 -bt < /dev/nullVersion 8.8.4 Compiled with: LOG MIME8TO7
NAMED_BINDNETINET NETUNIX NEWDB SCANF USERDB XDEBUG ============ 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 sendmail was compiled with NAMED_BIND support (see 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 sendmail from scratch (see Section 18.3, "Obtain the Source").
 Sun typically supplies two versions. The one named sendmail.mx is able to use DNS.
But even if your sendmail binary supports DNS, site configuration
If your host supports a service-switch file, for instance,
make sure it lists
dns 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
(see Section 19.6.18, FEATURE(nodns)):
 Note that the
nodnsFEATURE did nothing in V8.7 sendmail.
grep dns /etc/sendmail.cf##### @(#)nodns.m4 8.1 (Berkeley) 8/6/93 #####
If it was, as indicated by the phrase
nodns.m4, you can
get sendmail back into the DNS business by setting the
I) option (see Section 34.8.55, ResolverOptions (I)).
If your sendmail still seems unable to use DNS, despite your efforts, look for other reasons for failure. Make sure, for example, that your /etc/resolv.conf 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.