Troubleshooting Exchange Networking: DNS (Part 1)Written by on January 5, 2012Often Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is slow and demanding resolution. These sorts of tickets (slow being at best a relative term, and never specific enough about what precisely is considered to be slow) can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue. While it is often a client issue, there are several places between Outlook and a users mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six part series of articles, well look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to useNetMonorWireshark, and PerfMon are out of scope. In Part 1 of this series, were going to discuss how Exchange is dependent upon and interacts with DNS on the network.DNSDNS is one of the most important, and fundamental services on any TCP/IP network and the critical role it plays in all aspects of Exchange cannot be understated. Every single interaction between servers depends on being able to resolve a name to an IP address, and being able to quickly (and correctly) perform name resolution can set the tone for the entire transaction.Most of you will be using AD integrated DNS, so your DNS servers will be domain controllers. Keep in mind that the default TTL for AD integrated zones is 3600, so your Exchange servers will cache responses for an hour before trying to resolve the same name again. Using AD integrated zones also means that changes to DNS records must replicate to all domain controllers, and then the TTL must expire before you can assume that a client or Exchange server is resolving the right IP address to name.To ensure that the right IP address is being provided in response to a query, open an administrative command prompt on the Exchange server you are troubleshooting, and use the NSLOOKUP command to query the primary DNS server, and the secondary. Confirm that both provide the same result and that it is correct, and then ping the destination server by name. Compare the IP address in the PING command to what NSLOOKUP returned to be sure that your Exchange server is trying to reach the right address. If it is not, issue the ipconfig /flushdns command to clear the local cache, and try again.>nslookup exch2.example.comServer: dc1.example.comAddress: 192.168.0.2Name: exch2.example.comAddress: 192.168.0.6>ping exch2.example.comPinging exch2.example.com [192.168.0.9] with 32 bytes of data:Reply from 192.168.0.104: Destination host unreachable.Ping statistics for 192.168.0.9: Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

>ipconfig /flushdnsWindows IP ConfigurationSuccessfully flushed the DNS Resolver Cache.

>ping exch2.example.comPinging exch2.example.com [192.168.0.6] with 32 bytes of data:Reply from 192.168.0.6: bytes=32 time=4ms TTL=128Ping statistics for 192.168.0.6: Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 2ms, Maximum = 2ms, Average = 2msYou want to place DNS servers as close to your Exchange servers as possible, configure your Exchange servers to use the closest DNS servers they can, and to keep the application response time (ART) for DNS queries as low as possible. If it takes more than 50 milliseconds to resolve a DNS performance will suffer. You can use a protocol analyzer like Microsofts NetMon or Wireshark to analyze that, or you can just use thedigcommand. A Windows port can be downloaded fromhere. Thedigcommand can tell you how long it takes to resolve a name.>dig @192.168.0.2 -t a exch2.example.com; DiG 9.3.2 @192.168.0.2 -t a exch2.example.com; (1 server found);; global options: printcmd;; Got answer:;; ->>HEADER