Exchange Server 2010 : Troubleshooting DNS Problems

Configuring DNS to Support Exchange Servers

Because DNS is already required and integrated with Active Directory before Exchange Server is installed, most companies already have a robust DNS environment in place. Exchange Server by itself accesses DNS servers to find resources on the local network, such as global catalog servers and domain controllers. It also uses DNS to search for MX records of other domains.

External DNS Servers for the Internet

The external DNS server for Exchange Server (or any other mail system) is responsible for giving out the correct MX and A records for the domain for which it is authoritative. Administrators should take security precautions regarding who can change these records—and how. Intentionally or accidentally changing these records can result in undelivered mail.

Most companies let their ISP host the external DNS entries for their domain. ISPs provide internal administrators with methods of managing DNS entries for their domain. In some cases, it has to be done over the phone, but normally a secure web interface is provided for management. Although this setup is convenient and ISPs usually take care of load balancing and redundancy, some companies opt to host their own zone records for the Internet. In this case, companies have to host their own DNS server in-house with the ISP responsible only for forwarding all requests to their DNS server. When hosting an external DNS server, in-house administrators have to think about security issues and DNS configuration issues.

Internal DNS Servers for Outbound Mail Routing

Exchange SMTP gateways are responsible for delivering mail to external hosts. As with any name process involving resolving names to IP addresses, DNS plays a major part in successful mail delivery.

Exchange Server can route mail to outbound destinations two ways. One is by using smarthosts to offload all processing of messages destined to other domains. As seen in the previous section, an NLB cluster can be used to route Internet mail to its final destination.

The second way is the default, with Exchange Server 2010 taking care of delivering messages to other domains. In this scenario, Exchange Server queries DNS servers for other domains’ MX records and A records for address resolution.

Using Event Viewer to Troubleshoot

The first place to look for help when something is not working, or appears to not be working, is the system logs. With Windows Server 2008, the DNS logs are conveniently located directly in the DNS MMC console. Parsing this set of logs can help the administrator troubleshoot DNS replication issues, query problems, and other issues.

For more advanced event log diagnosis, administrators can turn on Debug Logging on a per-server basis. Debugging should be turned on only for troubleshooting because log files can fill up fast. To enable Debug Logging, follow these steps:

Turn off these settings after the troubleshooting is complete.

Troubleshooting Using the ipconfig Utility

The ipconfig utility is used not only for basic TCP/IP troubleshooting, but can also be used to directly resolve DNS issues. These functions can be invoked from the command prompt with the correct flag, detailed as follows:

• ipconfig /displaydns— This command displays all locally cached DNS entries. This is also known as the DNS resolver cache.

• ipconfig /flushdns— This switch can be used to save administrators from a lot of headaches when troubleshooting DNS problems. This command flushes the local DNS cache. The default cache time for positive replies is 1 day; for negative replies, it is 15 minutes.

• ipconfig /registerdns— This flag informs the client to automatically reregister itself in DNS, if the particular zone supports dynamic zone updates.

\\HKLM\System\CurrentControlSet\Services\Dnscache\Parameters
MaxCacheEntryTtlLimit = 1 (default = 86400)
NegativeCacheTime = 0 (default = 300)

Monitoring Exchange Server Using Performance Monitor

Performance Monitor is a built-in, often-overlooked utility that enables a great deal of insight into issues in a network. Many critical DNS counters can be monitored relating to queries, zone transfers, memory use, and other important factors.

Using nslookup for DNS Exchange Server Lookup

In both Windows and UNIX environments, nslookup is a command-line administrative tool for testing and troubleshooting DNS servers. Simple query structure can provide powerful results for troubleshooting. A simple query contacts the default DNS server for the system and looks up the inputted name.

To test a lookup for www.companyabc.com, type

nslookup www.companyabc.com

at the command prompt. nslookup can also be used to look up other DNS resource types—for example, an MX or SOA record for a company. To look up an MX record for a company type, use the following steps, as illustrated in Figure 1:

Figure 1. nslookup MX query.

An MX record output not only shows all the MX records that are used for that domain, their preference number, and the IP address they are associated with, but it also shows the name server for the domain.

By default, nslookup queries the local DNS server the system is set up to query. Another powerful feature of nslookup is that it can switch between servers to query. This feature enables administrators to verify that all servers answer with the same record as expected. For example, if an organization is moving from one ISP to another, it might use this technique because the IP addresses for its servers might change during the move. The DNS change takes an administrator only a few minutes to do, but replication of the changes through the Internet might take 24 to 72 hours. During this time, some servers might still use the old IP address for the mail server. To verify that the DNS records are replicated to other DNS servers, an administrator can query several DNS servers for the answer through the following technique:

Repeat from step 3 for other DNS servers.

nslookup can also help find out the version of BIND used on a remote UNIX DNS server. An administrator might find it useful to determine which version of BIND each server is running for troubleshooting purposes. To determine this, the following steps must be performed:

If the administrator of the BIND DNS server has configured the server to accept this query, the BIND version that the server is running is returned. As previously mentioned, the BIND version must be 8.1.2 or later to support SRV records.

Troubleshooting with DNSLINT

DNSLINT is a Microsoft Windows utility that helps administrators diagnose common DNS name resolution issues. The utility is not installed by default on Windows servers and has to be downloaded from Microsoft. Microsoft Knowledge Base Article #321046 found at http://support.microsoft.com/kb/321046 contains the link to download this utility.

When this command-line utility runs, it generates a Hypertext Markup Language (HTML) file in the directory it runs from. It can help administrators with Active Directory troubleshooting and also with mail-related name resolution and verification. Running DNSLINT /d <domain_name> /c tests DNS information as known on authoritative DNS servers for the domain being tested; it also checks SMTP, Post Office Protocol version 3 (POP3), and Internet Message Access Protocol (IMAP) connectivity on the server. For the complete options for this utility, run DNSLINT /?.

Using dnscmd for Advanced DNS Troubleshooting

The dnscmd utility is essentially a command-line version of the MMC DNS console. Installed as part of the Windows Server 2003 support tools or installed natively with Windows Server 2008, this utility enables administrators to create zones, modify zone records, and perform other vital administrative functions. To install the support tools, run the support tools setup from the Windows Server 2003 CD (located in the \support\tools directory). You can view the full functionality of this utility by typing DNSCMD /? at the command line.