DNS monitoring: If it's slow, everything is slow

The DNS (domain name service) is involved in virtually every connection we establish on the Internet, as well as on our local area networks. As such, it is critical that this service perform without failure and as fast as possible. In this technical tip, we will explore some of the techniques for monitoring DNS performance and the impact on applications when it is not performing properly.

Below is an example of using our Web browser to go out to http://www.komotv.com. Frame 40 contains the DNS query requesting the IP address associated with the DNS name www.komotv.com.

The DNS server response in Frame 41 shows the IP address. Our time column shows that it took 0.065 seconds, or 65 milliseconds to get this response -- not too bad. Once we have the IP address of the Web server, we can then establish our TCP connection in Frames 42, 45 and 46. After this connection is established, we can finally send our HTTP GET in Frame 47.

The concern comes when the time between the DNS Query and the DNS Response begins to be longer than 200-300 milliseconds. When this occurs, Internet traffic starts to seem slow. Since typical users of a Web browser do not understand that each DNS name must be resolved to obtain the IP address, their overall impression is that "the network is slow."

An example of such a problem is an analysis job we were doing where all of the users were commenting on how slowly the Internet appeared to be responding. As part of the analysis, we connected a protocol analyser between one of their workstations and their network connection.

Above is an example of the DNS traffic between their computer and the DNS servers. In this case, traffic was being dropped between their local DNS server and the Internet DNS server. The local DNS server would wait five seconds before sending the same request to the secondary DNS server. As a result, they had to wait up to five seconds to resolve the DNS name to an IP address. Since a single Web page can reference multiple sites, each having a different DNS name, this could result in minutes of unnecessary delay.

Here are the steps for capturing and monitoring the DNS traffic on your network to determine how long it is taking to receive DNS responses.

Step 1: Download a packet-capturing analyser. A free analyser can be downloaded from http://www.wireshark.org. After downloading the analyser, install it on a computer that will be used for monitoring network traffic.

Step 2: Get the analyser in the path of the packets. Just plugging it into a switch port will not allow you to capture all of the traffic on the switch. By placing a hub between the Internet router and the rest of the network, then connecting the analyser to the hub, you will be able to capture all of the traffic to and from the Internet. Other methods of getting in the path of the packets are taps and the use of port "mirroring" or "spanning" to copy all of the traffic to and from the router to the analyser.

Step 3: Start capturing packets. For this example, you can capture all traffic seen by the analyser.

Step 4: Stop capturing the packets. All of the packets seen by the analyser will be displayed on the screen. You will now want to filter out only those packets that contain the DNS protocol.

Step 5: Build a DNS filter.

This is accomplished by typing dns in the filter field and clicking Apply.

Step 6: Change the time format. The default time format displays the number of seconds since the beginning of the trace in the Time column. To change this, click on View -- Time Display Format -- Seconds Since Previous Packet.

Step 7: Observe the time between the DNS Query and the DNS Query Response packets. In the example below, the host 10.0.0.111 sends a request to the DNS server 12.127.17.72 in Frame 444. After 0.066 seconds, it receives a response with the associated IP address.

A good practice is to set up such an analyser and leave it running all of the time. As the buffer fills up, the oldest packets will be replaced by the newest packets. When people begin commenting on slow response times, stop the analyser and start looking at the DNS response times.

About the author: Mike Pennacchi is owner of Network Protocol Specialists, a network analysis and training company based in Seattle. The company specialises in analysing network performance problems for companies throughout the United States. Pennacchi has taught at NetWorld+Interop since 1997 and has received the event's Instructor Award as highest-ranking instructor three of those years. He brings his experience as a network analyst into the classroom and assists students in understanding how to fix problems in their own networks. Mike was part of a team of analysts responsible for resolving network performance problems at the Pentagon immediately following September 11.