Community Area

Troubleshooting DNS using NMCap

by
George Chetcuti
[Published on 4 April 2011 / Last Updated on 4 April 2011]

Network Monitor is a free tool available from Microsoft. You can capture data using either the graphical Network Monitor or the command-line NMCap tool. Analysis of the captured data must be done through the graphical interface. As network traffic is in abundance especially on busy servers, you would need to use filters to reduce the number of packets collected and remove the packets not related to the application you are examining. This blog post is about a typical troubleshooting scenario using NMCap where we use a DNS capture filter as to find out what is breaking our DNS test environment. We will capture DNS traffic from a client workstation in a domain while pinging valid and inexistent external web servers, and also when our DNS services are down! The Network Monitor tool is installed on a domain controller which happens to be the DNS server as well. For these tests we will use the following syntax: NMCap /network * /capture &quot;DNS&quot; /StopWhen /TimeAfter 2 min /file DNS.cap Where we are saving our captured data in a file called DNS.cap located in c:\Prorgam Files\Microsoft Network Monitor\ and only DNS related traffic will be collected for a period of 2 minutes. Now, from the client workstation we ping a valid URL such as, windowsecurity.com for several times or using the ping &ndash;t option. You can also use the command nslookup www.windowsecurity.com. After the 2 minute period, go to Network Monitor and open dns.cap. You should be able to verify the complete path of the DNS requests from the client to the DNS server to the gateway and vice-versa as shown below:

The request completed successfully and this means that the client can resolve domain names without any problems. There is no need to go into much detail, it is sufficient to select each frame and verify its DNS query flag! As shown above, the first frame represents the DNS request from the client (192.168.100.2) to the DNS server (192.168.100.2) ending with a success query flag. The s

Network Monitor is a free tool available from Microsoft. You can capture data using either the graphical Network Monitor or the command-line NMCap tool. Analysis of the captured data must be done through the graphical interface. As network traffic is in abundance especially on busy servers, you would need to use filters to reduce the number of packets collected and remove the packets not related to the application you are examining. This blog post is about a typical troubleshooting scenario using NMCap where we use a DNS capture filter as to find out what is breaking our DNS test environment.

We will capture DNS traffic from a client workstation in a domain while pinging valid and inexistent external web servers, and also when our DNS services are down! The Network Monitor tool is installed on a domain controller which happens to be the DNS server as well. For these tests we will use the following syntax:

Where we are saving our captured data in a file called DNS.cap located in c:\Prorgam Files\Microsoft Network Monitor\ and only DNS related traffic will be collected for a period of 2 minutes.

Now, from the client workstation we ping a valid URL such as, windowsecurity.com for several times or using the ping –t option. You can also use the command nslookup www.windowsecurity.com. After the 2 minute period, go to Network Monitor and open dns.cap. You should be able to verify the complete path of the DNS requests from the client to the DNS server to the gateway and vice-versa as shown below:

The request completed successfully and this means that the client can resolve domain names without any problems. There is no need to go into much detail, it is sufficient to select each frame and verify its DNS query flag! As shown above, the first frame represents the DNS request from the client (192.168.100.2) to the DNS server (192.168.100.2) ending with a success query flag. The second frame represents the forwarded DNS request by the DNS server (192.168.100.2) to the gateway (192.168.1.1) which happens to act as a DNS forwarder apart from routing functions. The third frame starts the reply process from the gateway to the DNS server back to the client. By following these simple steps you can conclude that your DNS services are functioning correctly.

Next, let's try to ping an inexistent URL from the client machine while we start monitoring for another 2 minute period.

From the data captured as shown above, we can tell that the URL used by the client was not found and returned a name error. The first two frames had no errors while in the third which is the reply from the gateway back to the DNS server we get the first name error. Therefore, we can conclude that our internal DNS services are functioning correctly and the fault is originating from an external entity or as in this case, the destination domain does not exist! Now, let's switch off our internal DNS server as to simulate an internal DNS server fault.

As you can see from above, the client repetitive requests are successfully ending at the server hosting our DNS services but there's no reply back! From this we can conclude that our DNS services are at fault and should focus our attention on them!

This exercise is a quick and basic one, however, it can help you determine the source of basic problems. You can spend more time examining the frames details and extend the filter to capture ARP requests which may be needed to identify the MAC address of a DNS server that resides on another subnet.

Featured Links

How to Prevent Security Breaches

Join Brien Posey, Microsoft MVP, for a discussion of the increasing trend of data breaches and real-life lessons learned, including recent examples such as the Anthem breach. Brien will also discuss future trends based on recent data breach investigations and address a range of topics including:

How and why do data breaches happen and which firms are more exposed?

What is the cost that data breaches hold for organizations?

What can companies do to stay protected?

The webinar includes a live Q&A session with our expert presenters to answer your top questions.

Online Survey: The Definitive State of Load Balancing and High Availability

MSExchange.org, KEMP Technologies and numerous MSFT and VMware experts worldwide would like to invite you to participate in our confidential 6 question survey on Load Balancing and High Availability. This survey takes about 6 minutes and all participants who wish can leave their email address and register to win a $50 Amazon gift certificate.

The results of this survey will be used to create a white paper on the State of Load Balancing. Everyone who registers will also get a copy of the white paper.

PowerShell Essentials (Part 7)

In this article, I'll explain how you can pass values to a PowerShell function... Read More

Tips and Tricks Using the Windows Hosts File

Here I will discuss how to access, open, and modify the Windows hosts file. I’ll give some tips and advice on making redirects, whether you want to block or filter sites or create shortcuts to certain websites... Read More