Configuring DNS for Your
Standards-Based Mail Service:
How to Avoid the Most Common Misconfigurations
(Originally published in Messaging Magazine, January/February 1999)

By Paul Kincaid-Smith, Software.com, Inc.
with contributions from Richard Rocaberte
  

Introduction

Whether you’re setting up an e-mail system for an Internet Service Provider (ISP) or rapidly growing enterprise, prudence requires that you configure your e-mail servers and your Domain Name System (DNS) with the future in mind. Although your mail system may work adequately today, if it is not set up with flexibility in mind, you will experience problems when forced to add hardware to accommodate increased demand. This article shows you how to set up your DNS in order to reduce mail system disruptions, minimize the possibility of lost mail, and seamlessly add mail server capacity in the future. A good DNS configuration provides flexibility for mail system growth and disaster contingencies.

DNS Overview

Computers connected to the Internet (or an intranet) use a numeric addressing system to locate other computers on the network. This numeric addressing system requires that each computer connected to a network have its own, unique numeric address called an Internet Protocol (IP) address. IP addresses are represented by a string of numbers separated by periods, for example 123.45.67.89. Machines, of course, have no problem using these numerical addresses. People, on the other hand, find it easier to use and remember addresses if they are familiar, brief and meaningful (e.g., software.com).

Since computers on the Internet must use numeric addresses, an intermediary system is needed to translate a domain name (e.g., software.com) to its corresponding IP address. The DNS facilitates these translations.

The Internet’s DNS infrastructure consists of a distributed system of name servers. Each name server knows about some part of the overall name space, and can find its way to other parts of the name space. When a mail server needs to map a domain name to an IP address, it starts by asking its local name server, which may then ask one or more remote name servers for help in finding the answer.

The DNS stores a number of items of interest to mail servers. An address (A) record maps a server’s host name to its IP address. For example, using Bind’s notation:

mail.software.com     IN      A     123.45.67.89

A Mail Exchange (MX) record maps a domain name to a server’s host name. For example:

software.com              IN      MX   10   mail.software.com

When you send an e-mail to user@software.com, your local mail server receives the message and then searches for the IP address of software.com’s mail server. This is a two step process. First, it looks up the MX record for software.com, which identifies the name (A record) of the server that handles mail for the software.com domain. Next, it looks up mail.software.com’s (A record) to find its IP address. Your local mail server then establishes a connection with the host 123.45.67.89 and transfers the message to software.com’s mail server.

Avert Disaster by Preparing a Fallback MX Host

Having an alternate mail host can save the day if your primary inbound Simple Mail Transfer Protocol (SMTP) host gets knocked out, even for a short time. This fallback MX host receives mail for your site when your primary MX host is unavailable, queues your mail, then forwards it to your primary MX host when your site is back online.

If you haven’t set up a fallback MX host, and your MX host or network goes down, mail for your site will queue up on many servers throughout the Internet. This is likely to cause problems when your mail service is brought back online.

If you don’t know which mail servers have been queuing mail for your site, you won’t know whom to notify once your service is brought back online. Since manual intervention may be required to "flush" your queued mail, it may sit on these servers for a long time before it is sent to you. If it sits there long enough, it may even be bounced.

Once your primary MX server comes online, the queued messages it receives will not arrive in chronological order, since different sites will flush their queues at different times.

When it rains, it pours. The longer your mail service is unavailable, the more mail queues up. Since you can’t regulate the many machines that mail is queued on, a sudden flood of backlogged mail may overwhelm your system, degrading performance or even filling up spool disks.

By using a fallback MX host, you know where to find your (serialized) mail if your primary MX mail server crashes or becomes unreachable. Choose your fallback MX host wisely. It can be onsite, offsite, or both. An offsite fallback MX host is less likely to be affected by a catastrophe that disables your own system or network, but requires a cooperative, reliable partner. An unreliable fallback host may be worse than none at all, since it may lose your mail if it’s not managed properly. Your fallback host must have enough capacity to spool your mail, possibly for days. Beware of the ripple effect.

You’ll need to negotiate the configuration and operational procedures with the managers of your fallback site. Never use a fallback site without the consent of its management. Test the scenario periodically to ensure a SMTP-relay spam blocking policy doesn’t prevent the fallback host from receiving and queuing your mail.

Following is a recommended configuration of your DNS MX records:

software.com,     86400   IN    MX  10  mail.software.com
                             86400   IN    MX  20  fallback.software.com
                             86400   IN    MX  90  mail.othercorp.com

During normal operation, mail is received by your primary MX host, mail.software.com. Should it become unreachable (and SMTP connections fail), mail will be routed to your lower priority (20) onsite fallback host, fallback.software.com. If it too is unavailable, your mail gets queued on your offsite fallback host, mail.othercorp.com.

Ensure that you have a secondary DNS server hosted offsite. If you don’t and a disaster strikes, taking down both your DNS and your primary mail servers, mail will not be able to find its way to your fallback MX server after its DNS Time-to-Live (TTL) expires.

DNS configurations for disaster scenarios are covered in detail in O’Reilly’s book DNS and BIND by Paul Albitz and Cricket Liu.

Common DNS Misconfigurations

Let’s assume that you want to set up a mail domain, software.com. You could start with three machines, one for DNS, one for web services, and one for mail.

The DNS address records that define the addresses of those machines are:

jupiter.software.com     IN   A 123.45.67.80
venus.software.com      IN   A 123.45.67.81
mercury.software.com  IN   A 123.45.67.82

Because ISP and corporate mail systems usually start small, it is common to find their initial mail system architecture and service address schemes unnecessarily restrictive. Configurations that worked adequately at a small scale often become a "ball and chain" that make it difficult to accommodate user population and load increases without inconveniencing users.

The following common DNS configuration hides some complexity for e-mail users, but is not recommended because you cannot transparently separate POP and SMTP services onto different machines.

Setting up your system this way may make it marginally simpler for you and your users today, but it gives you no flexibility if future growth requires you to deploy a multiple-host solution.

Mail servers use DNS MX records to route mail for a domain to the appropriate mail server. MX records associate a mail domain with an actual machine name. MX records should not refer to a DNS Canonical Name (CNAME) like software.com, but rather an A record like mail.software.com:

software.com  IN  MX  10    mail.software.com

These DNS address records define address aliases for the following inflexible architecture:

dns.software.com       IN  A 123.45.67.80
www.software.com     IN   A 123.45.67.81
mail.software.com      IN   A 123.45.67.82

Most current Internet mail clients would be configured as follows:

E-mail address:                 user@software.com
Mail server login name:     POPloginid
Outgoing mail server:        mail.software.com
Incoming mail server:        mail.software.com

Older Eudora 3.x users would have the following configuration:

Return address:                 user@software.com
POP account:                     POPloginid@mail.software.com
SMTP:                                mail.software.com

A Simple but Flexible Mail Server Configuration

Although all your mail traffic may be handled comfortably by a single machine today, the day may come when you need to separate your mail services onto several machines. You can prepare for this eventuality by configuring your DNS as follows:

dns.software.com        IN A 123.45.67.80
www.software.com      IN A 123.45.67.81
mail.software.com       IN A 123.45.67.82
pop.software.com        IN A 123.45.67.82
smtp.software.com      IN A 123.45.67.82

The MX record for the mail domain software.com will reference the host mail.software.com. e.g.,:

software.com                 IN MX 10  mail.software.com

Most current Internet mail clients would be configured as follows:

E-mail address:                 user@software.com
Mail server login name:    POPloginid
Outgoing mail server:       smtp.software.com
Incoming mail server:        pop.software.com

Older Eudora 3.x users would have the following configuration:

Return address:                 user@software.com
POP account:                     POPloginid@pop.software.com
SMTP:                                 smtp.software.com

At this point, you may be wondering why three host names map to the same IP address. The reason: future flexibility. Your users should configure their mail clients to use pop.software.com for retrieving in-bound mail via POP, and smtp.software.com for sending outgoing mail. Both of these host names resolve to the same IP address. If later you decide to have POP or outgoing SMTP traffic handled via another machine, you just change the IP address of pop.software.com or smtp.software.com in your DNS server. Your users do not change their mail client’s configuration. It is essential to use separate SMTP and POP service host names before you have many users, otherwise it can be very disruptive to change your service’s architecture, since they may need to reconfigure their mail clients. This can place a significant burden on your help desk.

In the server configurations that follow, mail clients don’t need to be reconfigured in response to a server reconfiguration since their SMTP and POP server settings have different host names.

Dual Hosts Segregate Internal Traffic From External

You are better able to withstand "denial of service" and spam attacks by segregating your mail services so that your users send and retrieve mail from a machine that’s not accessible from the Internet. If the SMTP host comes under attack, your users will still be able to send mail among themselves and out to the Internet using the private machine that hosts the POP and SMTP services. Relay blocking and other anti-spam rules need only be maintained on the externally accessible SMTP host.

In this configuration, you could place the "inbound" mail service on your firewall machine (or outside your private network) and route incoming mail for your domain to the private mail host. For increased protection, the SMTP and POP services are not accessible to users outside the firewall (or the outside your unroutable 10.x.x.x private network).

The DNS address records that define addresses for the mail services should be:

mail.software.com     IN  A 123.45.67.82
smtp.software.com    IN  A 123.45.67.83
pop.software.com      IN  A 123.45.67.83

If you’re using Post.Office as your mail server, the SMTP Mail Routing Table on the inbound SMTP mail host, mail.software.com, would be:

software.com:123.45.67.83

(The mail client and MX record configurations are the same as those in Figure 2.)

Mail Load Distribution with Three Servers

Three servers can partition the load of incoming SMTP, outgoing SMTP, and POP traffic. Each machine can be "scaled" with appropriate hardware to handle the anticipated volume of each of the three types of mail traffic.

The DNS address records that define addresses for the mail services should be:

mail.software.com     IN  A 123.45.67.82
smtp.software.com   IN  A 123.45.67.83
pop.software.com     IN  A 123.45.67.84

If you’re using Post.Office as your mail server, the SMTP Mail Routing Table on the inbound SMTP mail host, mail.software.com, would be:

software.com: 123.45.67.83

This configuration allows you to move an IP from one machine to another. It is also preferred because an IP number stays associated with a particular service. Because DNS servers (and even some e-mail clients) throughout the Internet cache IP information, it is best not to change IP numbers for an MX record or a host name that is used for e-mail services. This will reduce the number of support calls to your help desk should you ever need to migrate or reconstruct your service on another server.

Multi-Homing

The most flexible way to set up a mail service is to assign different IP address numbers for each of your mail service’s components (POP, SMTP, Internet Message Access Protocol (IMAP), WebMail, etc.). Many times, however, you are able to squeeze multiple services onto a single machine. A multi-homed host is configured to answer for all its service’s (i.e., multiple) IP addresses. (Configuring a server to multi-home is operating system-dependent and is beyond the scope of this article.)

Load Distribution with Round-Robin DNS

A highly scalable product can be configured to use multiple SMTP, POP, and IMAP servers. When a single service (like SMTP) is distributed over multiple machines, DNS can be used to "round-robin" connection requests among servers, thereby distributing (but not necessarily balancing) the load.

If a round-robined server crashes or is taken out of service, you’ll need to quickly remove its IP address from your DNS server’s round-robin list. Even so, other DNS servers may have cached the crashed server’s IP address, perhaps directing new connections to the "dead" server. How do we deal with this?

First, keep the TTL short (perhaps between five and 15 minutes) so other DNS servers update their cached information frequently. If a mail host is out of service and you do not have a high availability (HA) configuration, assign another machine its IP address. New connection requests will then be directed at this other machine.

You might also consider using a product like Cisco’s LocalDirector. It can redirect connection requests for the "dead" host to another that’s alive and well. Although you may be tempted to use LocalDirector for the round-robining itself, you may make your system dependent upon it if you do. One option is to use DNS for round-robining in conjunction with a product like LocalDirector for immediately redirecting traffic when a server crashes.

Conclusion

Once you’ve set up your DNS flexibly, you will be able to accommodate e-mail server growth comfortably because you can rearchitect your mail system without reconfiguring your users’ mail clients. The potential help desk savings alone could be enough to justify the effort required to set up your DNS and mail systems flexibly. And don’t forget to develop a mail system contingency plan. A fallback MX host could save you a lot of grief if your primary MX server crashes. As the Boy Scouts say, be prepared.