Trouble Shooting Name Resolution with NM3

 

Using the previous blog on “Intro to Name Resolution” we should have a basic idea of what is supposed to happen when a name needs to be resolved. Now let’s discuss how you’d use Network Monitor to determine where the problem is when connecting to your network resource. But let’s first list out some general breaking scenarios and the suggested course of action.

1. DNS address not found – This could be due to the fact the machine you are trying to reach hasn’t registered itself properly or the machine name you are using is incorrect. Resolution: verify the resource name; you should check to make sure it’s properly registered in DNS. It may also be possible that the name hasn’t properly propagated to your DNS server.

2. Machine not responding to NBTSS – Either the machine is not responding at all, or the NBTSS service is not started. Resolution: check with owner of the machine to make sure NBTSS is running properly. This may be indication of a larger problem.

3. Machine not responding to ARP – In this case perhaps the machine is hung or not accepting network requests. Resolution: find the owner of that machine. It may require a reboot and this could be an indication of a larger problem as to why it’s getting in this state to begin with.

4. Machine not responding to connect request – The machines name can be resolved, but the particular service you are trying to reach is not running properly. The machine may also be in a hung or unavailable state or you may not have rights to connect in this fashion. This could also indicate the IP Address you are receiving is old and inaccurate. Resolution: Check with the owner of that machine to make sure the IP address is correct. If it is correct, then check DNS to make sure that address is properly registered. This might also indicate the machine is blocking traffic, perhaps due to a firewall.

So the first step in t-shooting any network problem is getting a trace. So start an NM3.1 capture, attempt to connect to the resource in question, and then stop the trace.

The next thing we’ll want to do is filter out everything but name resolution type traffic for the resource we are connecting to.

nbtns.NbtNsQuestionSectionData.QuestionName.Name.contains("ResourceName")

OR

dns.QRecord.QuestionName.contains("ResourceName")

Checking DNS

Once you apply this filter you’ll see any name resolution traffic, either DNS or NBTNS that involves the machine you are trying to reach. Depending on how your machine is setup, you may see both DNS and NBTNS or just one of the two. If you see DNS traffic show up, then you can just look at the corresponding response to see if it was successful. If it was not, then you have situation #1 described above. Here’s an example of the successful summary info provided for DNS.

DNS: QueryId = 0xDF19, QUERY (Standard query), Query for ResourceName of type Host Addr on class Internet

DNS: QueryId = 0xDF19, QUERY (Standard query), Response - Success

And here’s an example of a failed DNS request.

QueryId = 0xA92E, QUERY (Standard query), Query for asdfg.northamerica.corp.microsoft.com of type Host Addr on class Internet

QueryId = 0xA92E, QUERY (Standard query), Response - Name Error

Checking NBTNS

If instead you see NBTNS traffic, then you’ll see the same kind of things, but only NBTNS will be the protocol. So for instance you might see this for NBTNS.

NbtNs: Query Request for RESOURCENAME <0x00> Workstation Service

NbtNs: Query Response, Success for RESOURCENAME <0x00> Workstation Service, 192.168.1.100

If in your case the response does not come back at all OR it comes back negative for NBTNS and there is no successful DNS traffic to resolve your name, then the resource you are looking for is not registered properly. If the machine that responded to the NbtNS request is not the owner of the Name then you may also have a WINS problem. In that case you may have to check the WINS server to make sure it’s data is replicating properly. This is situation #2 above.

Checking ARP

Once you’ve resolved the name to an IP address, you may have to further find the hardware address. This only occurs if the traffic is local to your subnet. We haven’t talked about IP Subnets, but the basic idea is you can determine if the address is local or not by using your subnet mask. You could actually apply the following tricky filter to determine this. This is similar to what your computer does when determining if traffic is local or not.

(ipconfig.LocalIpv4Address & 255.255.252.0) == (192.168.1.100 & 255.255.252.0)

In this example the subnet mask is 255.255.252.0. You can determine this from the NetworkInfoEx frame if you started the capture in NM3. This is also available from the command line when you run IPCONFIG. The 192.168.1.100 is the destination address that is returned from DNS or NBTNS.

If applying the filter returns no frames, then the machine in question IS NOT on the same subnet. If it returns all frames, then it IS on the same subnet. The filter simply returns 0 or 1, which when applied as a filter shows all frames or none.

If the IP address is remote, then your machine sends the packet to your preferred gateway and lets your router determine where to route the packet. In this case you’ll never know the hardware address, so you can continue to the next section.

If it is a local address, then you should see an ARP request for the packet, assuming it’s hasn’t been resolved already. To avoid extra calls, ARP requests are cached. In fact you can see this cache by typing “ARP –a” from a command prompt. You can also clear the cache of the entry, “ARP –d 192.168.1.100”.

So assuming that is has not been resolved already, you should see ARP traffic. At this point I would recommend a filter to just show the ARP traffic for that IP address. So if the machine you were looking for is 192.168.1.100, your filter would be as follows.

Arp.TargetIp4Address == 192.168.1.100

OR

Arp.SendersIp4Address == 192.168.1.100

We choose the same address for the target and sender so we can see both the request and response. You should see at least one of each, again assuming it hasn’t been cached. If you see only ARP requests, then the machine may not be responding. This is situation #3 above.

ARP Successful Response:

ARP: Request, 65.53.5.59 asks for 65.53.4.240

ARP: Response, 65.53.4.240 at 00-11-43-03-E5-A4

A failure is indicated by the lack of a Response. While the lack of a response doesn’t always indicate a problem, it could mean the machine is not responsive.

Name Resolves but No Response

At this point the name resolution portion seems to be working. But the resource in question may be there and not responding. The next step is to take a look at the traffic going to that machine. You can do this with the following filter.

IPv4.Address == 192.168.1.100

This will show only traffic where this machine is involved. Since you took the trace with traffic only leaving your machine, this should show you traffic to and frame your machine to the destination resource, 192.168.1.100.

At this point you’ll usually see one of two things occurring. You might see an attempt to connect to the machine from TCP. When you look at the summary for TCP it looks like this.

TCP: Flags=.S......, SrcPort=2932, DstPort=HTTPS(443), Len=0, Seq=2697306090, Ack=0, Win=65535 (scale factor not found)

The S (synchronize) in the Flags indicates that TCP is attempting to connect to the port, in this case 443. If you don’t see a response from this machine going back to your IP, then the service or machine you are connecting to is in some kind of hung state. It’s also possible in this case that the port is being blocked by a firewall somewhere in your network. The next thing I’d recommend is trying to PING the machine by the IP Address you obtained above. If this succeeds, the problem is specific to the server or a firewall. If it doesn’t respond then again it might be the machine, though it’s possible a firewall may again be blocking PINGS as well.

If you narrow it down to just one port and PINGs work fine, this indicates that the program or service you are talking to may be hung or not working properly. Or it still may be a firewall that is just blocking that one port.

Wrapping Things Up

Unfortunately there are other things that could go wrong. And while IPv6 has a different scheme for resolving names, it’s still an important step in the process of making a connection. The aim of this blog was just to help you understand one major component of getting connected, Name Resolution. Perhaps next time you run into a situation where you can’t reach a resource, you’ll fire up Network Monitor and see if Name Resolution is at the root of the problem.