DNS is one of the most critical components of an Exchange (and Active Directory) deployment. While an in-depth...
discussion of DNS deployment and operational issues is beyond the scope of this tutorial, let's take a brief look at some common DNS issues that affect Exchange Server.
DNS servers used by Exchange Server: Exchange servers should use internal DNS servers for name resolution. In order for Exchange Server to start successfully, the DSAccess component of Exchange System Attendant needs to be able to locate domain controllers/global catalogs. Quite frequently one or more Exchange servers, or the DCs/GCs themselves, point to invalid or removed DNS servers or an ISP's DNS servers. In the last case, the ISP's DNS servers do not have the information about the DNS zone used by your Active Directory.
Presence of root domain (.) in internal DNS servers: The root domain, which is designated by a dot, is present in the internal DNS servers of many deployments. This prevents resolution of Internet domains using those DNS servers. If Exchange Server uses a DNS server with the root domain present, email delivery to Internet hosts may fail. If you're using a root domain on internal DNS servers, it is important to configure those servers with a forwarder for name resolution to Internet domains. However, in environments that need to be isolated from the Internet (where Exchange Server is used for internal email only), such configurations may be completely valid and used on purpose.
External DNS zones and MX records: For all domain names for which your Exchange server accepts inbound email, the external DNS zones should be configured on a DNS server that is accessible from the Internet on UDP and TCP port 53. An MX record is required in these zones so SMTP hosts on the Internet can send email to those domains.
MX records are resource records in DNS that generally point to A records of your mail server(s). A records, also known as host records, map a hostname to an IP address. For your external DNS zones, this should be the public/external IP address of the mail server responsible for receiving inbound Internet mail (whether it's Exchange Server or any other SMTP server).
Often the MX record actually points to a CNAME record, which is a Canonical Name or alias, for a hostname. An A record should already exist for this. However, pointing MX records to CNAMEs results in additional load on your DNS servers -- the sending host's DNS server will now need to query your DNS server twice. The first query is to resolve the MX record. It must query the DNS server a second time when a CNAME is returned from the query for the MX record, in order to resolve the CNAME to an A record.
Reverse lookup zones and pointer records: Another more often ignored issue, particularly in smaller organizations, is the configuration of reverse lookup zones. Reverse lookup zones contain PTR (pointer) records that resolve IP addresses to fully qualified hostnames, just as A records in forward lookup zones map hostnames to IP addresses.
As an antispam measure, many ISPs and organizations reject email from sending hosts where the sending IP address does not resolve to a hostname. In other words, email will be rejected if a reverse lookup zone does not exist or a PTR record for that IP address does not exist in the reverse lookup zone.
Most small organizations that have a single IP address or just a few IP addresses do not get their block of IP addresses delegated from the ISP. In such cases, it is important to contact the ISP to have the PTR records created for your Internet-facing hosts, particularly SMTP hosts like Exchange servers.
A common misconception is that the PTR record should resolve to the fully qualified hostname of the sending host. However, while it may be a good idea to do so, it's not always possible. This is particularly true in cases where multiple SMTP domains are being hosted in an Exchange organization, and the sending IP addresses sends email for those multiple domains. This is common in hosting setups. What is important for email delivery is for the IP address to have a PTR record that resolves to something.
SPF records: Sender ID is an antispam mechanism introduced by Microsoft, and implemented in Exchange Server 2003 Service Pack 2 as Sender ID Filter. Sender ID allows receiving SMTP hosts to verify that email is being sent from a server authorized to send email for the sender's domain. This relies on text records in DNS called SPF records. Even if you do not use Sender ID to filter inbound email, it is advisable to publish SPF records for your registered DNS domains.
The Microsoft Web site has more details about Sender ID Framework, and a Web-based wizard to help you publish SPF records.
BEST PRACTICES GUIDE: THE 10 MOST COMMON EXCHANGE SERVER ISSUES
Issue #1: Exchange Server storage sizing and location
Issue #2: SMTP virtual server and connector configuration
Issue #3: Exchange recipient policies and Recipient Update Service
Issue #4: Exchange Server messaging hygiene
Issue #5: Exchange Server and DNS
Issue #6: Front-end/back-end Exchange Server topology issues
Issue #7: Exchange Server information stores and mailbox sizes
Issue #8: Moving or removing Exchange servers
Issue #9: Exchange Server backups and disaster recovery
Issue #10: Exchange Server monitoring -- or lack thereof
|ABOUT THE AUTHOR:|
| Bharat Suneja, Microsoft Exchange MVP
Bharat Suneja is a Microsoft Certified Trainer (MCT), Exchange MVP, and Principal Exchange Architect for Zenprise, Inc., maker of real-time troubleshooting and diagnostics software for Exchange. Bharat Suneja has over 10 years of experience in IT, architecting and managing Exchange Server and Active Directory environments, ranging from small and mid-sized businesses and e-commerce companies to large ISPs and ASPs. An active writer and contributing editor for international IT publications such as PC Quest, Bharat was also a technical reviewer for Exchange Server 2003 24 Seven by Jim McBee. Visit Bharat Suneja's blog at www.exchangepedia.com/blog.