9.1 Overview

DNS stands for Domain Name 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 fully qualified hostnames (see Figure 9-1).

Figure 9-1. Domain names form a tree of information

The parts of a fully qualified name are separated from one another with dots. For example:

here.uofa.edu

This name describes the machine here that is part of the uofa subdomain of the edu top-level domain. In Figure 9-1 the dot at the top is the "root" of the tree. It is implied but never^[1] included in fully qualified domain names:

^[1] Well, hardly ever. It can be used under some circumstances to prevent the local domain from being accidently appended improperly.

here.uofa.edu.
              
             implied

The root corresponds to (is served by) actual machines.^[2] Each has knowledge of all the top-level domains (such as gov, com, biz, uk, au, 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 uofa, uofb, and uofc but might not know about anything below those subdomains, nor about the other domains next to itself such as com.^[3]

^[2] Actually, there are several machines named a.root-servers.net, b.root-servers.net, and so on.

^[3] There is also a type of server called "caching." This type doesn't originate information about domains but is able to look up and save information and to supply it on request.

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 Figure 9-1 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.

The way this distributed information is used is illustrated in Figure 9-2. 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 are explained immediately following the figure.

Figure 9-2. How DNS lookups are performed

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, ns.uofa.edu) for that address. The ns.uofa.edu name server might 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 has the authority to do so. For our example, .gov knows the address, and is authoritative, 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 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^[4] (least to most). An MX record does not need to point to the looked up host. MX records always take precedence over A records.

^[4] 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 address record gives the IP address directly. For IPv4 this is called an A record, and for IPv6 this is called an AAAA record.
A CNAME (Canonical NAME, or alias) record refers sendmail to the real name, which can have an A record, an AAAA record, or MX records. But note that an MX record cannot point to a CNAME.

9.1.1 Which BIND?

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 8.x at the minimum. BIND provides the software and libraries that are needed to perform DNS inquiries. Version 8.3.3 is the latest 8.x release. Version 9.x is an improvement over 8.x, but it is claimed by some to be slower than 8.x (9.2.1 is the latest release of 9.x as of this writing).

Unless you are already running the latest version, you should consider upgrading. The latest versions are available via anonymous FTP from ftp://ftp.isc.org/isc/bind.

In this book we won't describe how to install BIND. Instead, you should refer to the book DNS and BIND by Paul Albitz and Cricket Liu (O'Reilly & Associates, 4th Edition, 2001).

9.1.2 Make sendmail DNS-Aware

Not all releases of sendmail are ready to use DNS. To determine whether yours is ready, type the following command:

% /usr/sbin/sendmail -d0.1 -bt < /dev/null
Version 8.12.7
 Compiled with: LOG MIME8TO7 NAMED_BIND NETINET 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 your sendmail was compiled with NAMED_BIND support (NAMED_BIND). If it was, it can use DNS. If it wasn't, 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 (Section 2.2).

But even if your sendmail binary supports DNS, site configuration might not. If your host supports a service-switch file, for instance, make sure it lists dns as the method used to fetch information about hosts.

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.