Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2013 (part 6)

External DNS Servers for the Internet

The external DNS server for Exchange (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 can route mail to outbound destinations two ways. One is by using smarthosts to off-load 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 2013 taking care of delivering messages to other domains. In this scenario, Exchange queries DNS servers for other domains’ MX records and A records for address resolution.

Troubleshooting DNS Problems

Troubleshooting is part of everyday life for administrators. DNS is no exception to this rule. Therefore, understanding how to use the following tools to troubleshoot DNS not only helps avoid mistakes when configuring DNS-related services, but also provides administrators with a useful toolbox to resolve issues.

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 2012, the DNS logs are conveniently located directly in the DNS MMC console. Parsing this set of logs can help the administrator troubleshooting 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:

1. Open the DNS Manager.

2. Right-click on the server name, and choose Properties.

3. Select the Debug Logging tab.

4. Check the Log Packets for Debugging check box.

5. Configure any additional settings as required, and click OK.

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.

Monitoring Exchange 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 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 3:

Figure 3. nslookup MX query.

1. Open a command prompt instance.

2. Type nslookup and press Enter.

3. Type set query=mx (or simply set q=mx), and press Enter.

4. Type cco.com and press Enter.

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:

1. Open a command prompt instance.

2. Type nslookup and press Enter.

3. Type server <server IP address> for the DNS server you want to query.

4. Type set query=mx (or simply set q=mx), and press Enter.

5. Type cco.com and press Enter.

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:

1. From the command line, type nslookup, and then press Enter.

2. Type server <server IP address> for the IP address of the DNS server queried.

3. Type set class=chaos and then press Enter.

4. Type set type=txt and then press Enter.

5. Type version.bind and then press Enter.

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.