Table of Contents for

sendmail, 4th Edition

Before we discuss DNS in greater depth, we must first attend to an administrative detail. Every site on the Internet should, at a minimum, run BIND software version 9.x. BIND provides the software and libraries that are needed to perform DNS inquiries(9.3.4 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 from http://www.isc.org/.

In this book, we won’t describe how to install BIND. Instead, you should refer to the book DNS and BIND, Fifth Edition, by Paul Albitz and Cricket Liu (O’Reilly).

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.14.1
 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 on page 124). 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 (Download the Source on page 42).

But even if your sendmail binary supports DNS, site configuration might not. If your host supports a service-switch file, for instance, make sure that file 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.

All versions of sendmail use more or less the same logical process to obtain the canonical name of the local host. As illustrated in the following sample program, sendmail first calls gethostname(3) to obtain the local host’s name within its domain. That name can be either a short name or a fully qualified one depending on how your system is set up. If the call to gethostname(3) fails, the name of the local host is set to localhost:

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/param.h>
#include <netdb.h>
#include <stdio.h>

main(  )
{
        char hostbuf[MAXHOSTNAMELEN];
        struct hostent *hp;

        /* Get the local host name */
        if (gethostname(hostbuf, sizeof(hostbuf)) < 0)
        {
                strcpy(hostbuf, "localhost");
        }
        printf("hostname = "%s"\n", hostbuf);

        /* canonicalize it and get aliases */
        if((hp = gethostbyname(hostbuf)) =  = NULL)
        {
                perror("gethostbyname");
                exit(2);
        }
        printf("canonical = "%s"\n", hp->h_name);
        while (*hp->h_aliases != NULL)
        {
                printf("alias: "%s"\n", *hp->h_aliases);
                ++hp->h_aliases;
        }
}

The local hostname is then given to the gethostbyname routine to obtain the canonical name for the local host. That same routine also returns any aliases (other names for the local host). Note that, if you defined NETINET6 (NET... on page 126) when compiling (for IPv6 support), you must use getipnodebyname(3) in place of gethostbyname(3).

The short (host) name found by gethostbyname(3) or getipnodebyname(3) is assigned as the value of the $w sendmail macro. The short name, the canonical name, and any aliases are added to the class $=w.

If the DontProbeInterfaces option (DontProbeInterfaces on page 1023) is undefined, or set to false, the address and hostname associated with each interface are also added to the class $=w (Probe Network Interfaces on page 327).

Some old Sun and Ultrix machines are set up to use NIS where the canonical name is the short name, and a fully qualified name that should have been the canonical name appears as an alias. For such systems, you must link with the BIND library (libresolv.a) when compiling this program or compiling sendmail. That library gets its information from DNS rather than from NIS. But note that V8.7 and above versions of sendmail do the intelligent thing and use the canonical name that was found in the list of aliases, if it exists.

If a good BIND library is not available, or if it is not convenient to compile and install a new version of sendmail, you can circumvent the short name assigned to the $j sendmail macro by defining $j like this:

define(`confDOMAIN_NAME', `canonical name here')

The canonical name is your site’s hostname with a dot and your domain name appended.

The result of all these lookups can be viewed by running sendmail with a -d0.4 debugging switch (-d0.4 on page 542). The actual DNS lookups can be watched with the -d8.8 debugging switch (-d8.8 on page 549).

After the canonical name, and any other names for the local machine, have been placed in $=w, sendmail then searches (probes) all the network interfaces to find any additional names and addresses that might also need to be added to $=w. But note that if the DontProbeInterfaces option (DontProbeInterfaces on page 1023) is defined as true, this additional step is skipped. Note also that if the DontProbeInterfaces option is defined as the literal value localhost, only the loopback interface is skipped, and all the other network interfaces are included.

The list of network interfaces is obtained from your kernel using a system call appropriate for your operating system. The kernel generally returns a list composed of interface and IP address pairs. If you defined NETINET6 (NET... on page 126) when compiling, the list might contain IPv6 addresses. If you defined NETINET (NET... on page 126) when compiling, the list might contain IPv4 addresses.

For each address that is found, sendmail performs a reverse lookup using gethostbyaddr(3) or getipnodebyaddr(3). Each lookup (if successful) will return the hostname associated with the address.

Each address and hostname is appended to the class $=w. The names and addresses added can be viewed with the -d0.4 debugging command-line switch (-d0.4 on page 542), which also allows errors in this process to be printed.

When sendmail begins to run as a daemon, it creates a socket, binds to that socket, and listens for incoming SMTP connections. When a remote host connects to the local host, sendmail uses the accept(2) library routine to accept the connection. The accept(2) routine provides the IP address of the remote machine to sendmail. After that, it calls gethostbyaddr(3) or getipnodebyaddr(3) to convert that IP address to a canonical hostname. The sendmail program then calls gethostbyname(3) or getipnodebyname(3) to find all the addresses for that found hostname. If the original address is not in that list, sendmail considers the address and hostname to be forgeries and records that fact in its syslog messages, its added Received: header, and its reply to the initial greeting:

(may be forged)

The sendmail program needs a valid canonical hostname for five reasons:

If you define the dnsbl feature (FEATURE(dnsbl) on page 261) or the enhdnsbl feature (FEATURE(enhdnsbl) on page 263) in your mc configuration file, you will cause sendmail to look up the IP address of each connecting site at the blackhole server you specify. If a lookup is successful and returns a match, the connection is rejected, or as of V8.14, discarded or quarantined. If a lookup is successful and returns no match, the connection is accepted. If the lookup fails, the connection is either deferred or accepted, depending on the nature of the failure.

Lookups are performed using the host database type (dns on page 905). Each lookup attempts to find A (address) records that correspond to the address looked up. Note that this is different from the usual way in which addresses are looked up. Normally, addresses are reverse-looked-up to find hostnames. But for blackhole purposes, addresses are forward-looked-up, as though they are hostnames.

When sendmail prepares to connect to a remote host for transfer of mail, it first performs a series of checks that vary from version to version. All versions accept an IP address surrounded with square brackets as a literal address and use it as is.

Beginning with V8.1, sendmail first checks to see whether the host part of the address is surrounded with square brackets. If so, it skips looking up MX records. (We’ll elaborate on MX records soon.)

Beginning with V8.8, sendmail first checks to see whether the F=0 flag (F=0 (zero) on page 761) is set for the selected delivery agent. If it is set, sendmail skips looking up MX records.

If sendmail is allowed to look up MX records, it calls the res_search(3) BIND library routine to find all the MX records for the host. If it finds any MX records, it sorts them in order of cost, and lists them, placing the least expensive first. If V8 sendmail finds two costs that are the same, it randomizes the selection between the two when sorting.^[152]

After all MX records are found and listed, or if no MX records are found, sendmail adds the host specified by the FallbackMXhost option (FallbackMXhost on page 1030) to the end of the list. For V8.11 and earlier, the hostname, if there was one, was added to the end of the list as is. Beginning with V8.12, if a hostname is listed, MX records are looked up for it as well, and those MX records are added (in the proper sorted order) to the end of the list. By surrounding the hostname specified under V8.12 in square brackets, the behavior of earlier versions is emulated in that the hostname is added as is (surrounded in square brackets).

If there are no MX records, the original hostname becomes the only entry in the list. If, in this instance, the FallbackMXhost option adds MX records, they are added following that hostname.

The sendmail program then tries to deliver the message to each host in the list of MX hosts, one at a time, until one of them succeeds or until they all fail. The value of an MX record contains a cost value (also called preference) and the hostname to which to connect. All MX hosts at a given cost (preference) are tried before any at a higher cost (lower preference) are tried (that is, all the 5’s are tried, for example, before any 6’s). Beginning with V8.8 sendmail, if a host in the list returns a 5xy SMTP code (permanent failure), the effect is to cause subsequent MX hosts to be ignored. (Connect failures are the exception, in that they continue to the next MX host as usual.) Most temporary errors cause sendmail to try the next MX record. If sendmail exhausts the MX list with neither success nor a permanent error, the temporary error will cause the message to be queued for a later attempt.

If no MX records are found, sendmail tries to deliver the message to the address of the single original host. If all else fails, sendmail attempts to deliver to the host listed with the FallbackMXhost option. And, beginning with V8.13, if the FallbackMXhost host fails or was not defined, and if the FallBackSmartHost option (FallBackSmartHost on page 1031) is defined, the host defined by the FallBackSmartHost option is the last host attempted.

Whether sendmail tries to connect to the original host or to a list of MX hosts or to a fallback host, it calls gethostbyname(3) or getipnodebyname(3) to get the network address for each. It then opens a network connection to each address in turn and attempts to send SMTP mail. If there are IPv6 addresses,^[153] they are tried first, then IPv4 addresses, if any. If a connection fails, it proceeds to the next address in the list until the list is exhausted. When there are no more addresses to try, the message is deferred and held in the queue for a later attempt.

The $[ and $] operators (Canonicalize Hostname: $[ and $] on page 668) are used to canonicalize a hostname. Here is a simplified description of the process.

Each lookup is actually composed of many lookups that occur in the form of a loop within a loop. In the outermost loop, the following logic is used:

Each lookup just described is performed by using the following three steps:

Each query searches the data returned as follows:

All this apparent complexity is necessary to deal with wildcard MX records (Wildcard MX Records on page 335) in a reasonable and usually successful way.

The sendmail program will look up AAAA records only if it is built with the NETINET6 (NET... on page 126) compile-time macro defined. As described earlier, sendmail looks up the AAAA records first, then A records.

All name servers should return NODATA if a host is found and no AAAA records are available. But some name servers are broken and, when asked for an AAAA record, will wrongly return a temporary failure (SERVFAIL). This causes sendmail to queue the mail for later delivery.

If you have defined NETINET6 when building sendmail, and if you notice this kind of error, we have two recommendations:

Email spammers tend to send to the highest cost MX server, rather than the lowest cost one as you might expect. To illustrate, consider a backup MX server that is intended for emergency use only:

hostA   IN      MX 0  hostA
        IN      MX 100 BackupHost

Here, hostA has the lowest cost (0 versus 100 for BackupHost), so the first delivery attempt should be to hostA. But most spam-sending software ignores low-cost records (the record for hostA in the preceding code) and will instead deliver to the highest cost server (BackupHost) on purpose.

The theory is that a site will run connection-based spam filters on the main (lowest cost) server (hostA) but will be much more lax on a failover MX server that is intended only for emergency use (BackupHost). The main server (hostA) will never reject connections from its own failover MX server (BackupHost). Spam senders use that knowledge to circumvent connection-based rejections by always sending to the failover MX server.

If you list multiple MX records, be certain that the same level of connection-based spam controls are installed on all of them. Content-based spam control may still reside only on the main mail server because it will still screen messages from all MX failover machines.

The A and AAAA records for a host are lines that give the host’s IP address or addresses:

hostC  IN     A      123.45.67.8                 ← IPv4
hostC  IN     AAAA   3ffe:8050:201:1860:42::1    ← IPv6

Here, hostC is the host’s name. The IN says this is an Internet-type record. The A marks this as an IPv4 A record, with the IP address 123.45.67.8. The AAAA marks this as an IPv6 AAAA record, with the IP address 3ffe:8050:201:1860:42::1.

An MX record must point to a hostname that has an A or AAAA record. To illustrate, consider the following:

hostA  IN     MX  10 hostB           ← illegal
       IN     MX  20 hostC
hostB  IN     MX  10 hostC
hostC  IN     A   123.45.67.8

Note that hostB lacks an A record but hostC has one. It is illegal to point an MX record at a host that lacks an A or AAAA record. Therefore, the first line in the preceding example is illegal, whereas the second line is legal.

Although such a mistake is difficult to make when maintaining your own domain tables, it can easily happen if you rely on a name server in someone else’s domain, as shown here:

hostA    IN     MX  10 mail.other.domain.

The other administrator might, for example, retire the machine mail and replace its A record with an MX record that points to a different machine. Unless you are notified of the change, your MX record will suddenly become illegal.

Note that although an MX record must point to a hostname that has an A or AAAA record, it is illegal for an MX record to point directly to an A or AAAA record:

hostA  IN     MX  10 123.45.67.89           ← illegal

Finally, note that it is unwise to point an MX record at a domain name, because a domain is not a host and therefore is not required to have an A or an AAAA record.

The sendmail program is frequently more forgiving than other MTAs because it accepts an MX record that points to a CNAME record. The presumption is that, eventually, the CNAME will correctly point to an A or AAAA record. But beware: this kind of indirection can cost additional DNS lookups. Consider this example of an exceptionally bad setup:

hostA    IN     MX  10 mailhub
mailhub  IN     CNAME  nfsmast
nfsmast  IN     CNAME  hostB
hostB    IN     A 123.45.67.89

First, sendmail looks up hostA and gets an MX record pointing to mailhub. Because there is only a single MX record, sendmail considers mailhub to be official. Next, mailhub is looked up to find an A or AAAA record (IP address), but instead a CNAME (nfsmast) is returned. Now, sendmail must look up the CNAME nfsmast to find its A or AAAA record. But again a CNAME is returned instead. So, sendmail must again look for an A or AAAA record (this time with hostB). Finally, sendmail succeeds by finding the A record for hostB, but only after far too many lookups.^[155]

The correct way to form the preceding DNS file entries is as follows:

hostA    IN     MX  10 hostB
mailhub  IN     CNAME  hostB
nfsmast  IN     CNAME  hostB
hostB    IN     A 123.45.67.89

In general, try to construct DNS records in such a way that the fewest lookups are required to resolve any records.

Consider the following MX setup, which causes all mail for hostA to be sent to hostB and all mail for hostB to be sent to hostB, or to hostC if hostB is down:^[156]

hostA   IN     MX  10 hostB
hostB   IN     MX  10 hostB
        IN     MX  20 hostC

One might expect sendmail to be smart and deliver mail for hostA to hostC if hostB is down. But sendmail won’t do that. The RFC standards do not allow it to recursively look up additional MX records. If sendmail did, it could get hopelessly entangled in MX loops. Consider the following:

hostA   IN     MX  10 hostB
hostB   IN     MX  10 hostB
        IN     MX  20 hostC
hostC   IN     MX  10 hostA     ← potential loop

If your intention is to have hostA MX to two other hosts, you must state that explicitly:

hostA   IN     MX  10 hostB
        IN     MX  20 hostC
hostB   IN     MX  10 hostB
        IN     MX  20 hostC

Another reason sendmail refuses to follow MX records beyond the target host is that costs in such a situation are undefined. Consider the previous example with the potential loop. What is the cost of hostA when MX’d by hostB to hostC? Should it be the minimum of 10, the maximum of 20, the mean of 15, or the sum of 30?

Wildcard MX records should not be used unless you understand all the possible risks. They can provide a shorthand way of MX’ing many hosts with a single MX record, but it is a shorthand that can be easily abused. For example:

*.dc.gov.       IN  MX  10 hostB

This says that any host in the domain .dc.gov (where that host doesn’t have any record of its own) should have its mail forwarded to hostB.

; domain is .dc.gov
*.dc.gov.       IN  MX  10 hostB
hostA           IN  MX  10 hostC
hostB           IN  A   123.45.67.8

Here, mail to hostD (no record at all) will be forwarded to hostB. But the wildcard MX record will be ignored for hostA and hostB because each has its own record.

Extreme care must be exercised in setting up wildcard MX records. It is easy to create ambiguous situations that DNS might not be able to handle correctly. Consider the following, for example:

; domain is sub.dc.gov
*.dc.gov.       IN  MX  10 hostB.dc.gov.
*.sub.dc.gov.   IN  MX  10 hostC.dc.gov.

Here, an unqualified name such as the plain hostD matches both wildcard records. This is ambiguous, so DNS automatically picks the most complete one (*.sub.dc.gov.) and supplies that MX record to sendmail.

One compelling weakness of wildcard MX records is that they match any hostname at all, even for machines that don’t exist:

; domain is sub.dc.gov
*.dc.gov.       IN  MX  10 hostB.dc.gov.

Here, mail to foo.dc.gov will be forwarded to hostB.dc.gov, even if there is no host foo in that domain.

Wildcard MX records almost never have any appropriate use on the Internet. They are often misunderstood and are often used just to save the effort of typing hundreds of MX records. They do, however, have legitimate uses behind firewall machines and on networks not connected to the Internet.

Many older MTAs on the network ignore MX records. Some pre-Solaris Sun sites, for example, wrongly run the non-MX version of sendmail when they should use /usr/lib/sendmail.mx. Some Solaris sites wrongly do all host lookups with NIS when they should list dns on the hosts line of their /etc/nsswitch.conf file. Because of these and other mistakes, you will occasionally find some sites that insist on sending mail to a host even though that host has been explicitly MX’d to another.

To illustrate why this is bad, consider a UUCP host that has only an MX record. It has no A record because it is not on the network:

uuhost   IN    MX  10 uucpserver

Here, mail to uuhost will be sent to uucpserver, which will forward the message to uuhost with UUCP software. An attempt to ignore this MX record will fail because uuhost has no other records. Similar problems can arise for printers with direct network connections, terminal servers, and even workstations that don’t run an SMTP daemon such as sendmail.

If you believe in DNS and disdain sites that don’t, you can simply ignore the offending sites. In this case, the mail will fail if your MX’d host doesn’t run a sendmail daemon (or another MTA). This is not as nasty as it sounds. There is actually considerable support for this approach; failure to obey MX records is a clear violation of published network protocols. RFC1123, Host Requirements, Add STARTTLS Support to Your mc File, notes that obeying MX records is mandatory. RFC1123 has existed for more than 12 years.

On the one hand, to ensure that all mail is received, even on a workstation whose mail is MX’d elsewhere, you can run the sendmail daemon on every machine. On the other hand, to ensure that all mail is received, even for hosts that are not machines (like uuhost earlier) you can assign each such host an IP address that is the IP address of your mail server.

Although you are not required to have MX records for all hosts, there is a good reason to consider doing so. To illustrate, consider the following host that has only an A record:

hostB           IN  A   123.45.67.8

When V8.12 and above sendmail first look up this host, they ask the name server for that host’s MX records. Because there are none, that request comes back empty. The sendmail program must then make a second lookup for the IP address.

When pre-V8.12 sendmail first looks up this host, it asks the local name server for all records. Because there is only an A record, that is all it gets. But note that asking for any record causes the local name server to cache the information.

The next time sendmail looks up this same host, the local name server will return the A record from its cache. This is faster and reduces Internet traffic. The cached information is “nonauthoritative” (because it is a copy) and includes no MX records (because there are none).

When pre-V8.12 sendmail gets a nonauthoritative reply that lacks MX records, it is forced to do another DNS lookup. This time, it specifically asks for MX records. In this case there are none, so it gets none.

Because hostB lacks an MX record, sendmail performs a DNS lookup each and every time mail is sent to that host. If hostB were a major mail-receiving site, its lack of an MX record would cause many sendmail programs, all over the world, to waste network bandwidth with useless DNS lookups.

We strongly recommend that every host on the Internet have at least one MX record. As a minimum, it can simply point to itself with a low cost:

hostB           IN  A   123.45.67.8
                IN  MX  1 hostB

This will not change how mail is routed to hostB but will reduce the number of DNS lookups required.

RFC974 leaves the treatment of ambiguous MX records to the implementor’s discretion. This has generated much debate in sendmail circles. Consider the following:

foo    IN MX 10 hostA
foo    IN MX 20 hostB        ← mail from hostB to foo
foo    IN MX 30 hostC

When mail is sent from a host (hostB) that is an MX record for the receiving host (foo) all MX records that have a cost equal to or greater than that of hostB must be discarded. The mail is then delivered to the remaining MX host with the lowest cost (hostA). This is a sensible rule because it prevents hostB from wrongly trying to deliver to itself.

It is possible to configure hostB so that it views the name foo as a synonym for its own name. Such a configuration results in hostB never looking up any MX records because it recognizes mail to foo as local.

But what should happen if hostB does not recognize foo as local and if there is no hostA?

                              ← no hostA
 foo    IN MX 20 hostB        ← mail from hostB to foo
 foo    IN MX 30 hostC

Again, RFC974 says that when mail is being sent from a host (hostB) that is an MX record for the receiving host (foo) all MX records that have a cost equal to or greater than that of hostB must be discarded. In this example, that leaves zero MX records. Three courses of action are now open to sendmail, but RFC974 doesn’t say which it should use:

This situation is not an idle exercise. Consider the MX record for uuhost presented in the previous section:

uuhost   IN    MX  10 uucpserver

Here, uuhost has no A or AAAA record because it is connected to uucpserver via a dial-up line. If uucpserver is not configured to recognize uuhost as one of its UUCP clients, and if mail is sent from uucpserver to uuhost, it will query DNS and get itself as the MX record for uuhost. As we have shown, that MX record is discarded, and an ambiguous situation has developed.

The dig(1) program can be used to look up the IP address of a host by specifying the hostname:

% dig example.com

The first time you run dig(1) you may be surprised by the volume of its output,^[158] which is composed of comment lines (that begin with a semicolon) and information lines. The first section of output that dig(1) prints might look like this:

% dig example.com
; <<>> DiG 9.2.3 <<>> example.com
;; global options:  printcmd
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

This first section is a summary of dig(1)’s command line and information about how it performed the lookup. The global options line shows the resolver options that were in effect when you ran the command. Here, printcmd means that introductory comment lines and other information will print in addition to the answer. If you wish to restrict dig(1)’s output to just the answer, you can execute it with a +short command-line argument. We demonstrate that argument shortly.

The next section of commentary begins with the “Got answer” line:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19898

Here, the opcode is QUERY, which means a simple lookup was performed. The status is NOERROR, which means the lookup was successful, and the id shows the ID of the dig(1) query itself.

The last section of introductory commentary produced by dig(1) is a summary of what it found:

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

The flags are the actual flags returned by the name server. The qr is present if this answer is a response to a request. (Note that because dig(1) only performs lookups, this flag will always be set.) The rd is present if the lookup request asked for recursion to be used to get a result. The ra is present if the replying server actually used said recursion. These, and other possible flags that might appear, are documented in RFC1035.

A list of what was returned by the lookup follows the flags on the same line. There are four possible items, each of which may have a value of zero or more. In the above, one question was answered (QUERY: 1), one record was provided as the answer (ANSWER: 1), two authority replies were included (AUTHORITY: 2), and two additional records were provided (ADDITIONAL: 2).

Following the introductory commentary is the QUESTION SECTION:

;; QUESTION SECTION:
;example.com.              IN      A

The QUESTION SECTION echoes your original query in the form of a comment. Here, you originally provided dig(1) with a hostname as its command-line argument, implying that you wished to obtain the host’s IP address. An IP address is also an Internet (the IN) address (the A).

Following the QUESTION SECTION is the ANSWER SECTION which, sensibly, provides the answer to the question, in this case the IP address for the domain example.com:

;; ANSWER SECTION:
example.com.            2D IN A         192.0.34.166

If more information is available, that too, will be returned. Here, the address was returned (the 192.0.34.166) along with information that this record will time out in two days (the 2D), that the record is an Internet record (the IN), and that it is an A (address) record (an IP address).

If this domain had more than one address, more lines would be listed. For example, the following shows three answers:

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2
;; ANSWER SECTION:
example.com.            2D IN A         192.0.34.166
example.com.            2D IN A         192.168.0.1
example.com.            2D IN A         192.168.1.1

The next section that appears (if such information was returned) is the AUTHORITY SECTION. The AUTHORITY SECTION lists name server (NS) records for the domain, although it can also contain a Start Of Authority (SOA) record.

;; AUTHORITY SECTION:
example.com.            6H IN NS        b.iana-servers.net.
example.com.            6H IN NS        a.iana-servers.net.

Here, two name server machines are listed. Either one can provide authoritative information about this domain, hence the term and title AUTHORITY SECTION. In order to look up additional information about this domain, we need to know more than just the hostnames of the name servers. We also need their addresses.

The last section to appear is the ADDITIONAL (information) SECTION. It provides any information that was missing from the other sections, if that additional information is necessary for future lookups:

;; ADDITIONAL SECTION:
a.iana-servers.net.     13h31m29s IN A  192.0.34.43
b.iana-servers.net.     13h31m29s IN A  192.168.5.6

Here, the IP addresses (A records) are given for the two name servers for this domain. These records will time out in 13 hours, 31 minutes, 29 seconds each (the 13h31m29s). These IP addresses are the ones that will be connected to when the next lookup for this domain is performed.

After the introductory commentary, and the informational sections, the dig(1) program summarizes what it did:

;; Total query time: 1866 msec
;; FROM: your.host.domain to SERVER: default -- 127.0.0.1
;; WHEN: Fri Oct 13 14:46:06 2006
;; MSG SIZE  sent: 29  rcvd: 109

Normally, dig(1) is used to look up hosts by name, that is, find the IP address that corresponds to the hostname. This is called a forward lookup. A reverse lookup, instead, starts with the IP address and seeks to find the hostname that belongs to it.

To reverse-look-up IP addresses you use dig(1) with the -x command-line switch:

dig -x address

In the following example, we will also use the +noall, +question, and +answer command-line arguments to limit dig(1)’s reply to just the items we are interested in. The +noall tells dig(1) to print nothing. The +question and +answer tell dig(1) to print only the question and answer sections:

% dig +noall +question +answer -x 192.0.34.166
;166.34.0.192.in-addr.arpa.     IN      PTR
166.34.0.192.in-addr.arpa. 20341 IN     PTR     www.example.com.

Note that because -x specifies an IP address, the IP address must immediately follow it. Here, dig(1) produced just two lines of output. The first line (a comment line) is the original question that was asked. That line is followed by the answer line.

You might reasonably ask, however, where did the in-addr.arpa come from? In the halcyon days of yore, there was no dig(1) program; hence, there was no easy way to look up a host by its address. In order to look up the address, you first had to reverse it (hence, a reverse lookup) and then to append an in-addr.arpa to the result:

192.0.34.166   reverses to    166.34.0.192.in-addr.arpa

Internally, dig(1) performs this task for you, thus causing your question to look different from your command line. In summary, then, the following two dig(1) commands perform the same lookup,^[159] but the second is easier to use:

% dig ptr 166.34.0.192.in-addr.arpa
% dig -x 192.0.34.166

Finally, note that forward lookups and reverse lookups don’t always agree. This is especially true when a host is connected to a satellite or DSL line. Consider, for example, the following three commands:

% dig +noall +answer mypc.example.com
mypc.example.com.        3600    IN     A       192.168.45.55
% dig +noall +answer -x 192.168.45.55
55.45.168.192.in-addr.arpa 3600  IN     PTR     dhcphost12.isp.domain
% dig +noall +answer dhcphost12.isp.domain
dhcphost12.isp.domain    3600    IN     A       192.168.45.55

Here, the host mypc.example.com is looked up, yielding its IP address. Next, that IP address is reverse-looked-up, but instead of yielding mypc.example.com as expected, it yields dhcphost12.isp.domain. This is a simplified example of a PC in someone’s home connected to a telephone company’s DSL service. Note that when this new hostname is looked up, that lookup reveals the original IP address.

Although such false or misleading lookups may seem dishonest, there is actually no restriction in the RFCs against them.

Recall that an MX record is a Mail eXchanger record. MX records list the hosts that should receive email for a host or a domain. A handy way to look up MX records with dig(1) is to use its +short command-line argument and pipe the result through sort(1):

% dig +short mx example.gov | sort -n
5 amx.example.gov.
5 bmx.example.gov.
5 cmx.example.gov.
100 backup1.example.gov.
100 backup2.example.gov.

Here, a +short argument limits output to just brief answers, the cost and hostnames found as MX records. The sort(1) uses -n to sort numerically, lowest through highest costs.

This example reveals a handy property of MX records. When multiple hosts share the same cost, the rule is to select randomly from among them. That is, in this example, all three of the cost 5 hosts are tried first before any of the cost 100 hosts, but the order in which the cost 5 hosts are tried is random.

Note that we discuss MX records, generally, in Set Up MX Records on page 332, covering their management and associated pitfalls. Here, we have limited our discussion to using dig(1) to look up MX records.

Normally, dig(1) talks to the name server that is defined in your /etc/resolv.conf file. There will be times, however, when you will need to use a different name server. To illustrate, consider the need to move from one ISP to another. Let’s say your MX records are correct on the old ISP name servers, and you wish to make sure that they are correct on the new name servers before switching over to them. You could change your /etc/resolv.conf file to use the new name servers, but that isn’t advisable until you are certain the new name servers are working correctly. Instead, simply cause dig(1) itself to use the new name servers:

% dig @nameserver host

Here, the @ is immediately followed by the hostname or IP address of the name server to use instead of the default. The dig(1) program will perform its lookups directly using the name servers specified. Consider:

% dig +short mx your.domain
0 mail.your.domain
10 mail2.your.domain
% dig +short @123.45.67.89 your.domain
1 mailserver.new.isp
10 mail.your.domain

Here, we first look up the local domain using the current name servers (there is no @ argument) and find that the output from dig(1) is correct. We then look up the local domain at the new name server using its IP address (the @123.45.67.89) and discover that they are set up incorrectly. This discovery gives you time to fix your MX records on the new name servers before you actually switch services to them.