DNS Defined - DNS and Mail
One advantage of DNS is its ability to route mail.
At the very least, DNS can specify which hosts e-mail should go to in case the host specified in the message is unavailable. Using Mail Exchanger (MX) resource records in a server database, you can specify a backup host or hosts in a mail delivery and even specify the order in which you want them used.
This chapter uses the Simple Mail Transport Protocol (SMTP) as an example of a mail protocol.
How Does SMTP Use DNS?
To translate a domain name into an internet address, SMTP queries the name servers for the domain’s MX records. If SMTP finds MX records, it sorts them by preference and gets the mail exchanger internet addresses. It uses these addresses to deliver the mail.
If there are no MX records, SMTP gets the host's address by querying the name servers, or from the local hosts file (etc/hosts or HOSTS.). If you don't use DNS, any host to which you want to send mail must appear in the hosts file. You use the full official host name for all hosts in this file (SMTP won’t look at the aliases).
For example, an entry in the HOSTS, file for host BETA in the SOMECO.COM domain could be:
223.42.95.2 BETA.SOMECO.COM BETA
In this example, 223.42.95.2 is the internet address, BETA.SOMECO.COM is the host name, and BETA is the alias name.
As you can see, if you don't have DNS, you need several of these entries to ensure mail goes where it should go. If a host is not in the list, it won’t get any mail. This is also the case with certain implementations of sendmail, although newer versions do make the attempt to deliver the mail to the destination host no matter what.
Routing Mail
Using DNS for mail routing is like planning a travel itinerary. Let's say you want to fly from Boston to San Francisco. You can set your preferences as follows, as in Figure 8:
- Boston -> San Francisco
- Boston -> Chicago -> San Francisco
- Boston -> Toronto -> San Francisco
- Boston -> Toronto -> Chicago -> San Francisco
You can create an MX record "itinerary" in the order of your stated preferences, as in Example 16 (the domain names are fictitious).
Example 16 Sample MX Records
boston.travel.edu MX 0 san-francisco.target.edu
MX 10 chicago.target.edu
MX 20 toronto.target.edu
DNS interprets these records as:
- If at all possible, you’ll fly non-stop from Boston to San Francisco.
- If you can’t fly you non-stop, you’ll fly to Chicago and try to get on a flight to San Francisco.
- If you can’t fly non-stop and Chicago service is unavailable, you’ll go to Toronto. From there, you’ll try to find a non-stop flight to San Francisco. If that isn't available, you’ll wait for the next available service in Chicago.
Just as when choosing airports, you base your decision about how to route mail first on directness, and then on the relative size, uptime, and connectivity (proximity) of any alternative mail exchanger.
If mail goes to the host successfully, DNS doesn't need to try any of the other hosts on the list. If your own host happens to be on the list, the mailer discards all MX records at an equal or lower preference (that is, a higher preference value). This prevents loops.
Routing in a Cluster: an SMTP-OpenVMS Example
Consider a network with hosts A, B, C, and D. Hosts A, B, and C form an OpenVMScluster while host D is a UNIX system. All are in domain CS.XYZ.EDU. Hosts A and B run TCPware’s SMTP-OpenVMS. Host C runs some other SMTP software.
Because users in an OpenVMScluster can access their mail from any of the hosts in the OpenVMScluster, it doesn't matter which host accepts mail for a user. However, it would be desirable to have mail addressed to host A go to host B if host A goes down, and vice versa. You can do this using MX records.
You can also have a domain name refer to the entire OpenVMScluster so that the sender doesn't need to be concerned about the recipient's exact host name.
For example, you can set up the domain name CLUSTER.CS.XYZ.EDU to refer to any host on the OpenVMScluster. Example 17 shows the MX records for this scenario.
Example 17 MX Records for a Cluster$origin CS.XYZ.EDU. ;system prefval gateway A IN MX 10 A.CS.XYZ.EDU. A IN MX 20 B.CS.XYZ.EDU. B IN MX 10 B.CS.XYZ.EDU. B IN MX 20 A.CS.XYZ.EDU. C IN MX 10 A.CS.XYZ.EDU. C IN MX 10 B.CS.XYZ.EDU. CLUSTER IN MX 10 A.CS.XYZ.EDU. CLUSTER IN MX 10 B.CS.XYZ.EDU.
In Example 17, A is a gateway set up to accept mail for itself as well as for B, C, and CLUSTER. The system manager on A, running SMTP-Open VMS, can set a configuration parameter so that B, C, and CLUSTER are the “local hosts” for which A can accept mail. Likewise, the system manager on B can configure B so that A, C, and CLUSTER are the systems for which B can accept mail.
Any remote host on the network that uses DNS and processes MX records can send mail to someone on the cluster using any of the following domain names:
- A.CS.XYZ.EDU
- B.CS.XYZ.EDU
- C.CS.XYZ.EDU
- CLUSTER.CS.XYZ.EDU
In defining a domain for the entire cluster, the system managers on A and B might also want to specify during the SMTP-Open VMS configuration that CLUSTER be the domain name identified in the From: field in outgoing SMTP mail messages. This way, remote users can reply to messages and not worry about the exact originator host except that it's somewhere on the CS.XYZ.EDU cluster.
Configuring Firewall Mail Exchangers
Many networks use an extra security measure to protect their network, known as a firewall. A firewall is a host on a network that prevents other hosts on that network from “getting” out as well as external hosts from “getting in.” You can usually limit access using access control lists, incoming or outgoing access restrictions, or other means on the firewall host.
Figure 9 shows an arrangement in which iris is the firewall host. The other hosts, daisy, tulip, and lilac on the “inside” of the firewall, can exchange TCP/IP packets among themselves, shown by the dotted lines, but can’t access anything beyond the firewall. It is iris, which has a direct connection, that prevents them from doing so.
But how can external correspondents address mail to, say, daisy? Example 18 shows how the MX records in the named.hosts file should look for it to happen.
Example 18 MX Records for Firewall Mall Exchanges$origin process.com. ;host pref mail exchanger daisy IN MX 10 daisy.process.com. daisy IN MX 20 iris.process.com.
The first preference is for all correspondence to go directly to daisy. This satisfies any mail exchange among the internal hosts. The condition fails for external hosts on the Internet. But these hosts can use the second, lower preference MX record to send mail to daisy through iris.
You can set up similar MX records for tulip and lilac.