6.3. Mail and DNS

Mail servers rely heavily on DNS. An improperly configured nameserver is sure to result in general mail flow problems including lengthy delays, mail loops, and mail rejections. It's imperative that you understand DNS records as they pertain to mail before deploying your mail server. If others are responsible for administering the DNS servers for your organization, you'll at least need to let them know what you need.

First and foremost, your mail server must have an address (A) record. This makes it possible to resolve the fully qualified domain name of your name server into an IP address. Second, and frequently omitted by lazy or uninformed mail and DNS administrators, your server should have a pointer (PTR) record. This allows you to resolve the IP address back into the hostname. Third, there must be a mail exchanger (MX) record configured for every domain for which your mail servers accept mail.

Each MX record in DNS has two important variables: a priority and the fully qualified domain name of your mail server. A snippet from a BIND zone configuration file might look something like Example 6-3:

Example 6-3. MX records

$ORIGIN mexicanfood.net.                         MX    10    refried.mexicanfood.net.                         MX    20    garbanzo.mexicanfood.net.                         MX    30    bruchetta.italianfood.net.

The three MX records all reference servers that should be configured to accept mail for mexicanfood.net. Other mail servers will attempt to reach them in order of priority from lowest to highest. If any server is unreachable, the next server will be tried.

The server with the lowest priority is called the "preferred" MX, while the others are referred to as "backup" MXes. Backup MX servers are often configured to store-and-forward. When the preferred mail server becomes unreachable, the backup MX will accept the messages and hold them in a queue until the preferred server becomes available. In Example 6-3, both refried and garbanzo would have to be inaccessible for external systems to send mail to bruchetta.

One last thing to keep in mind is direct delivery. In a network of Unix systems, all running some mail daemon, you might end up sending mail from host to host, without needing MX records at all. If user paco on system taco.mexicanfood.net tries to send mail to user bruce on system guacamole.mexicanfood.net, how does it get there without an MX record for guacamole.mexicanfood.net? When there is no MX record for the latter half of the email address, mail servers will look for an A record. As long as guacamole resolves, taco will be able to connect directly to port 25 on guacamole and deliver the message.

6.3.1. Security Implications

The dependence SMTP has on name resolution should reemphasize the importance of deploying a secure DNS architecture. If name resolution for your domain is hijacked in one of the ways mentioned in the Chapter 5, rerouting your mail traffic (and web traffic, FTP traffic, etc.) becomes trivial. It is imperative that all systems involved in providing name services for your domain are tightly secured so they can be trusted.

This issue of trust exists with DNS servers and is also important with SMTP servers. Just as DNS slaves outside of your organization have to be systems you can trust, you also need to trust servers acting as backup mail exchangers. Admittedly, the risks are not quite as great:

• A compromised backup MX server may expose private or confidential queued mail, and an attacker might delete the messages altogether.

• A poorly configured backup MX may be more susceptible to a DoS attack. If timed correctly, it may be unavailable when you need it most.

• If the backup MX is not configured with the same spam-blocking mechanisms as your primary servers, the volume of spam that hits the backup when your primary servers go down may inadvertently create a DoS itself.

Ten years ago, backup MX servers were an imperative: systems were commonly intermittently connected. If you did not have one, momentary connectivity outages would likely result in the loss of mail. These days, most legitimate mail senders will patiently wait several days before giving up on your primary server altogether. Systems generally come back up quickly, and hard disks are a good deal larger.

Instead of seeking an extra-organizational backup MX, consider having a second on-site server or a server in an offsite co-location facility. The former provides decent protection against the loss of one system, the latter mitigates the risks associated with system failures and losses of connectivity at one location.

So far we've been looking at how mail servers are supposed to work using DNS and MX records. Bad guys don't always play by the rules, of course. Most spammers will download a list of MX records for the organization and either find the least protected one, or throw mail at all of them in some haphazard way. If you've configured one of your backup mail exchangers to simply pass mail to your internal mail server, you're going to be in trouble. They'll discover sooner or later that mail sent to your backup MX won't bounce spam and they'll start using it exclusively. Make sure all servers listed in your list of MXes are equally well protected.