21. DNS and sendmail

Contents:
Overview
How sendmail Uses DNS
Set Up MX Records
How to Use nslookup
Prepare for Disaster
Pitfalls

21.1 Overview

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).

Figure 21.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 21.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, 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 may not know about anything below those subdomains, nor about the other domains next to itself such as com. [3]

[2] 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.
[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 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.

Figure 21.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, 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 [4] (least to most). An MX record need not point to the original receiving 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 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.

21.1.1 Which DNS? 4.8.3 or 4.9?

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. [5]

[5] As of the final draft of this manuscript, release 4.9.3 was the most recent.

Unless you are already running the latest version, you should consider upgrading to V4.9. BIND 4.9 is available via anonymous FTP from

ftp://ftp.vix.com/pub/bind/release

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).

21.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/lib/sendmail -d0.1 -bt < /dev/null
Version 8.8.4
 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 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 [6] or you will have to download and compile the latest version of sendmail from scratch (see Section 18.3, "Obtain the Source").

[6] 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 may 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.

Another possible problem might be your configuration file. It may, for example, have been derived from the nodns FEATURE [7] (see Section 19.6.18, FEATURE(nodns)):

[7] Note that the nodns FEATURE 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 ResolverOptions (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.