Recipe7.25.Verifying Your External DNS Configuration for Inbound SMTP

Recipe 7.25. Verifying Your External DNS Configuration for Inbound SMTP

Problem

You need to ensure that you have your external DNS properly configured to allow inbound SMTP traffic to your Exchange organization. In addition, you would like to avoid the kind of configuration errors that might cause your outgoing SMTP traffic to be rejected by other hosts.

Solution

Run the following commands from the command line for each server or cluster you intend to receive or send mail outside of your firewall. For outbound hosts, make sure to use the actual external IP address that will be used by your firewall, NAT device, or other SMTP proxy:

> nslookup  <server FQDN> <DNS server hostname or IP address> > nslookup red-exch01.redmond.3sharp.com ns1.msp.eschelon.com   Server:  ns1.msp.eschelon.com   Address:  209.150.200.10   Name:    red-exch01.redmond.3sharp.com   Address:  64.65.179.146 > nslookup  <server IP address> <DNS server hostname or IP address> > nslookup 64.65.179.146 ns1.msp.eschelon.com   Server:  ns1.msp.eschelon.com   Address:  209.150.200.10   Name:    red-exch01.redmond.3sharp.com   Address:  64.65.179.146 > nslookup -q=MX  <domain> <DNS server hostname or IP address> > nslookup -q=MX 3sharp.com ns1.msp.eschelon.com   Server:  ns1.msp.eschelon.com   Address:  209.150.200.10   3sharp.com      MX preference = 10, mail exchanger = exchange.robichaux.net   3sharp.com      MX preference = 20, mail exchanger = relay.salmark.net   3sharp.com      MX preference = 30, mail exchanger = relay.thorcom.net   3sharp.com      nameserver = ns1.msp.eschelon.com   3sharp.com      nameserver = ns.mazin.net   ns1.msp.eschelon.com    internet address = 209.150.200.10

Ensure that the reported FQDN and IP address for the server match. You must use the FQDN to avoid a NetBIOS lookup and you must supply a DNS server that has the same view of the DNS domain as the rest of the Internet.

Discussion

Even though Exchange 2000 and Exchange Server 2003 are thoroughly based around SMTP, Active Directory, and DNS, you do not have to worry about the same DNS configuration issues inside your organization as administrators of other native SMTP mail transports do. Active Directory (and therefore Exchange) is certainly critically reliant on a stable and well-configured DNS deployment, but almost all of the routing information Exchange needs comes from Active Directory, not DNS. It only uses DNS to locate domain controllers and global catalog servers via SRV records; it does not use MX records inside the organization.

Basic DNS health

When you exchange traffic with systems outside of your Exchange organization, however, you need to ensure that you have a solid, well-configured DNS configuration. SMTP mailers use DNS to figure out how to deliver messages to external domains. The basic SMTP and ESMTP transaction relies on the following DNS resource record (RR) types:

Address record (A): The A record provides the authoritative mapping between a fully qualified hostname and its corresponding IP address.
Mail exchanger record (MX): The MX record advertises a host that is responsible for accepting inbound SMTP connections. It contains a numerical preference field that determines precedence if there are multiple MX records and the FQDN of a corresponding A record. If no MX RRs are found for a given host, SMTP will attempt to locate and use an A record for that host instead. If it cannot find either, the mail will bounce as undeliverable.
Pointer record (PTR): The PTR record provides the authoritative mapping from an IP address to a fully qualified host name. If the PTR records are set up correctly, a host can determine the A record of an incoming SMTP connection by doing a PTR lookup, and then confirm that the results of the A lookup match. PTR lookups are not mandated by the SMTP RFCs, but many systems do so as part of their connection filtering.
Canonical name (CNAME): The CNAME record provides a noncanonical alias and points to the canonical A record. Although CNAMEs may be chained, this can slow down DNS resolution and can be complicated to maintain. It is a violation of the DNS standards to point an MX record to a FQDN that is a CNAME; this can result in hard-to-troubleshoot mail errors or worse. Likewise, hosts with a CNAME records cannot have an MX record; the remote system should resolve the CNAME to the corresponding A record and use those MX records.

An example zone file for the fictitious domain fqdn.tld, configured to allow proper SMTP, might look like this:

;  Database file fqdn.tld.dns for fqdn.tld zone. ; @                       IN  SOA ns.fqdn.tld. hostmaster.fqdn.tld. (                          32           ; serial number                          900          ; refresh                          600          ; retry                          86400        ; expire                          3600       ) ; default TTL ; ; Zone NS records ; @                       NS     ns.fqdn.tld. ; ;  Zone records ; @                       MX     10 bridge01.fqdn.tld. @                       MX     20 bridge02.fqdn.tld. ; bridge01                A      192.168.0.20 bridge01                MX     10 bridge01.fqdn.tld. bridge01                MX     20 bridge02.fqdn.tld. ; bridge02                A      192.168.0.30 bridge02                MX     10 bridge01.fqdn.tld. bridge02                MX     20 bridge02.fqdn.tld. ; exchfe01                A      192.168.0.40 exchfe01                MX     10 bridge01.fqdn.tld. exchfe01                MX     20 bridge02.fqdn.tld. ; exchfe02                A      192.168.0.50 exchfe02                MX     10 bridge01.fqdn.tld. exchfe02                MX     20 bridge02.fqdn.tld. ; mail                    CNAME  exchfe01.fqdn.tld. mail                    CNAME  exchfe02.fqdn.tld.

Though we cannot fully explain the intricacies of DNS here (grab the excellent book DNS on Windows Server 2003 by Matt Larson, Cricket Liu, and Robbie Allen [O'Reilly]) for a thorough grounding), we can highlight some points of interest.

Lines 3-8 are really one record, the statement of authority (SOA). It refers to the root of the zone, which is the fqdn.tld domain. Lines 12, 16, and 17 also establish RRs that apply to the root of the zone.

Lines 16 and 17 set up the MX records for the fqdn.tld domain. They establish two machines that accept incoming mail: bridge01 and bridge02. Because bridge01 has a lower preference (10 versus 20) than bridge02, remote systems should attempt SMTP deliveries to bridge01 first and fall back to bridge02 otherwise.

Lines 19-21 establish the A record and MX records for the bridge01 host. Since bridge01 is an inbound MX host, it needs to have an A record so that remote systems can contact it. If we left the MX records off, any systems that attempted to deliver to address@bridge01.fqdn.tld would fail to find an MX record, find the A record, and always attempt direct delivery. Some people argue that this behavior is desired for inbound mail hosts and that the actual hosts therefore do not need MX records. After many years of running high-traffic mail servers at ISPs with hundreds of zones, we prefer to keep a level of redundancy in our DNS arrangements.

Lines 23-33 do the same thing for bridge02, exchfe01, and exchfe02. Again, whether you want to do this is a matter of taste and preference. Many administrators feel that this level of DNS is clutter; we have in the past found it very useful in protecting our domains from unintended consequences of hasty DNS changes.

Lines 35 and 36 create an alias mail that points to exchfe01 and exchfe02. Because this host is actually a CNAME, it does not get to have separate MX records. Any systems trying to send to mail will follow the CNAME to the canonical names of exchfe01 and exchfe02, performing the MX lookup on that host instead.

Many administrators have the idea that they must use a special hostname for their Internet-facing SMTP hosts such as smtp or mail. This is not true. Setting up host aliases like this can make things easier for end users who need to remember their SMTP server settings, but they also make it more complicated to properly configure reverse DNS, which can cause mail to be delayed or worse.

Reverse DNS

Having MX records pointing to the A records of your inbound SMTP servers (whether they are your Exchange servers, a mail firewall application, or some other system) is enough to allow inbound mail to flow. However, you may find you have problems sending mail to a growing number of systems if your forward DNS (A records) do not match up with your reverse DNS (PTR records).

Reverse DNS is delegated out to ISPs from the in-addr.arpa domain. To find the reverse DNS record for bridge01.fqdn.tld, the DNS resolver would query for the PTR record for the 20.0.168.192.in-addr.arpa. domain:

$ORIGIN 0.168.192.in-addr.arpa. 20                      PTR    bridge01.fqdn.tld.

The returned answer, bridge01.fqdn.tld., should match up with the hostname that was initially used to perform the forward query. If not, you either have an administrator who has not configured their DNS correctly or someone pretending to be a host they are not. There is no requirement that a hostname of a mail server be in some way connected to or a member of the domains it accepts mail for, which makes it easy for ISPs or other mail servers that handle multiple domains to do the right thing regarding reverse DNS.

Many systems take this check one step farther. They will note the IP address of the incoming SMTP connection, note the hostname used in the HELO or EHLO SMTP command, and perform a forward and reverse DNS lookup on it all. If it does not all match, they may reject the connection, flag the message as possible spam, or take other actions as their local policies dictate. If you want to avoid trouble and ensure the widest reception for messages from your organization, make sure that your forward and reverse DNS are correct and complete and that your outbound SMTP virtual servers are configured to present themselves with the hostname that matches the public view of their IP address.

There is an unfortunate but widely held perception in many quarters that Exchange is not ready for the rough and tumble world of Internet SMTP. In part, this is because far too many Exchange administrators either do not learn how or do not take the time to perform the simple task of ensuring that their DNS settings are correct and complete. One of the best things that you can do to ensure propagation of your message traffic and be a good neighbor to others on the Internet is to not be one of those administrators.