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 "DNS" /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 –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.
