Recipe 7.25. Verifying Your External DNS Configuration for Inbound SMTPProblemYou 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. SolutionRun 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. DiscussionEven 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 healthWhen 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:
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.
Reverse DNSHaving 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. See AlsoDNS on Windows Server 2003 (O'Reilly), Chapter 4, "Configuring DNS," of the Exchange Server 2003 Deployment Guide on the Microsoft TechNet web site, and MS KB 153001 (XFOR: DNS MX Records and CNAMEs) |