How to Troubleshoot DNS Issue?
The first problem scenario is rather simple: A user cannot
access the Internet. We have verified that the user can access
all of the internal resources of the network, including shares
on other workstations and applications hosted on local servers.
The network architecture is fairly straightforward, as all
clients and servers connect to a series of simple switches.
Internet access is handled through a single router serving as
the default gateway, and IP addressing information is
In order to determine the cause of the issue, we can have the user attempt to browse the Internet while our sniffer is listening on the wire. We use the information from “Sniffer Placement in Practice” on page 31 (see Figure 2-15) to determine the most appropriate method for placing our sniffer.
The switches on our network do not support port mirroring. We already have to interrupt the user in order to conduct our test, so we can assume that it is okay to take him offline once again. (That said, using a tap would be the most appropriate way to tap into the wire.) The resulting file is nowebaccess1.pcap.
The traffic capture begins with an ARP request and reply, as shown in Figure 8-17. In packet 1, the user’s computer, with MAC address 00:25:b3:bf:91:ee and IP address 172.16.0.8, sends an ARP broadcast packet to all computers on the network segment in an attempt to find the MAC address associated with the IP address of its default gateway, 172.16.0.10.
Figure 8-17: ARP request and reply for the computer’s default gateway
A response is received in packet 2, and the user’s computer learns that 172.16.0.10 is at 00:24:81:a1:f6:79. Once this reply is received, the computer now has a route to a gateway that should be able to direct it to the Internet.
Following the ARP reply, the computer must attempt to resolve the DNS name of the website to an IP address using DNS in packet 3. As shown in Figure 8-18, the computer does this by sending a DNS query packet to its primary DNS server, 184.108.40.206 .
Figure 8-18: A DNS query sent to 220.127.116.11
Under normal circumstances, a DNS server would respond to a
DNS query very quickly, but that’s not the case here. Rather
than a response, we see the same DNS query sent a second time to
a different destination address. As
Figure 8-19: A second DNS query sent to 18.104.22.168
Again, no reply is received from the DNS server, and the
query is sent again one second later to 22.214.171.124. This process
repeats itself, alternating the destination packets between the
primary and secondary configured DNS
Figure 8-20: DNS queries repeated until communication stops
Based on the packets we’ve seen, we can begin pinpointing the source of the problem. First, we see a successful ARP request to what we believe is the default gateway router for the network, so we know that device is online and communicating. We also know that the user’s computer is actually transmitting packets on the network, so we can assume there isn’t an issue with the protocol stack on the computer itself. The problem clearly begins to occur when the DNS request is made.
In the case of this network, DNS queries are resolved by an external server on the Internet (126.96.36.199 or 188.8.131.52). This means that in order for resolution to take place correctly, the router responsible for routing packets to the Internet must successfully forward the DNS queries to the server, and the server must respond. This all must happen before HTTP can be used to request the web page itself.
We know that no other users are having issues connecting to the Internet, which tells us that the network router and remote DNS server are probably not the source of the problem. The only thing remaining as the potential source of the problem is the user’s computer itself.
Upon deeper examination of the affected computer, we find
that rather than receiving a DHCP-assigned address, the computer
has manually assigned addressing information, and the default
gateway address is actually set incorrectly.
The problem in this scenario resulted from a misconfigured client. While the problem itself turned out to be quite simple, it significantly impacted the user. Troubleshooting a simple misconfiguration like this one could take quite some time for someone lacking knowledge of the network or the ability to perform a quick packet analysis as we’ve done here. As you can see, packet analysis is not limited to large and complex problems.
Notice that because we didn’t enter the scenario knowing the IP address of the network’s gateway router, Unicorn didn’t identify the problem exactly, but it did tell us where to look, saving valuable time. Rather than examining the gateway router, contacting our ISP, or trying to find the resources to troubleshoot the remote DNS server, we were able to focus our troubleshooting efforts on the computer itself, which was, in fact, the source of the problem.
Had we been more familiar with this particular network’s IP
addressing scheme, analysis could have been even faster. The
problem could have been identified immediately once we noticed
that the ARP request was sent to an IP address different from
that of the gateway router. These simple misconfigurations are
often the source of network
Unicorn Network Analyzer How tos