Intro to Name Resolution
You sit down at your computer and attempt to connect to your network resource Du Jour (website/ server/application) and it just doesn’t want to work this morning. I’m sure this has happen to you more than a few times. And if you are a support or help desk professional, multiply that by a 10. What’s interesting is from a network perspective there’s just a few things that break. And one of the key factors in making a connection is resolving a name. Today, we are going to talk about trouble shooting that type of problem. So let’s start with a simple analogy.
Can I ask you for your phone number?
When you meet anybody these days there are two pertinent pieces of information you need; their name and phone number. Of course, if you lose the number or the number changes, 411 or the phonebook might help you find, (think resolve), your friend’s phone number. For a computer something similar happens.
Phone Number = Address
Whenever your computer needs to make a connection to a network resource, at some point it has to locate the address of the machine it wants to talk to. So it performs something we call “Name Resolution” in the most general terms. There are different levels o f Name Resolution, as we’ll see later. But in general, the idea is the same; I’ve got a name and I need to know your phone number to contact you.
I promise, the layers make it easier.
You might have heard of the mighty OSI Network Model. We have different layers in networking because it lets us divide the big problem of communicating into smaller problems that are easier to manage. Name resolution is one of those problems, but it can occur on more than one layer. So we’ll discuss name resolution with regards to two different network layers.
It all starts with a name of the resource you are trying to attach. Of course, if computers ruled the world the plain numbers would be good enough. But they don’t, yet, so for now we’ll stick to our anthropomorphic habit of using friendly names so us humans can remember them easily. GSB-OFL5060-4 is what you’re company might use for instance, though I think I prefer PaulsOffice J
ARP – Address Resolution Protocol
In this case we are talking about machines that are physically connected together. When you send a broadcast packet out, all the other machines on your local network segment see it. If this is your house we are talking about, it’s probably all the machines you own. At work it may be those machines on your floor, building, or some other delineation as defined by your network configuration. But the idea is that there are usually a group of computers that are in shouting distance for a stream of electrons.
And while you could just broadcast everything, this is inefficient. A broadcast has to be handled by every computer that hears that traffic. So in the end we want to send our packets to just the machine we are intending to contact.
For ARP, we are talking about resolving IP addresses into machine addresses. Every Ethernet network card has an Ethernet machine address burned into it. They are all unique (unless we are talking about more archaic hardware like ARCNET, ugh). And in order for one of the higher layers to properly route network packets, we must use an IP address. So let’s look at a hardware address in NM3.1.
Here are the frame details of the Ethernet portion. The first two things in an Ethernet packet are the hardware destination address and source address. The destination is where this packet is going. The Source is who sent it. The source is normally your machine, unless you are doing promiscuous mode tracing. [Note: Promiscuous mode lets you see traffic from other machines. It tells your NIC to listen to more than just broadcasts and traffic directed to your NICs hardware address. This is disabled by default in NM3.1, but can be enabled by selecting the adapter, and pressing the P-Mode button.]
Now you can see that we’ve prettified the address for you in NM3.1. Remember I said all addresses are unique? Well there’s an organization (IEEE) that provides the first 3 bytes of the address to each network card manufacturing company. In many cases they may get multiple sets of numbers. The company part of these addresses is well known. So NM3 will display that friendly name instead (this can be changed in NPL if you wish). The last three bytes are shown following the manufacturer name, 0x03E5A4.
Shout it Out
So it’s quite simple really. You yell out the address you are looking for and presto, a response comes back with the hardware address (often call MAC address). So here’s an ARP Request.
You can see that the Destination says BROADCAST. This is a special address. Any NIC which is connected to your network will listen to for its own address and the BROADCAST address. When the machine responds, it will send back an ARP response.
With this ARP response we know the hardware address. Any future traffic to this machine can use this address to communicate directly to the machine in question without having to broadcast to the world.
Finding an IP address for Name
At the next level, you need to find the IP address for a name so you can ARP that to get physical address. Perhaps this sounds a little fishy. Why not just get the physical address and skip the middle man? Well IP can do something in its layer that ARP cannot. IP can span connected networks.
Yelling is all fine and good in your own house, but imagine if all houses were connected by intercom systems and a shout in one house would automatically be blasted out to all the others. Networks don’t like noise either. Too much traffic on the wire slows things down. One of the simple rules of the physical wired Ethernet medium is that it’s limited to just one machine talking at a time. If two machines speak at the same time, the message is garbled, and nobody understands what is said. In this situation one machine has to politely wait for the other to finish before its takes its turn. [This is called Collision Detection or CSMA/CD]
There happens to be more than one way to resolve an IP address. If it is a local machine, then we might use a resolution protocol known as NBTNS or NETBIOS Name Service. This uses the same strategy as ARP. We broadcast a request out and wait for a response.
In NM3.1 the summary looks like this:
Nbtns: Query Request for PAULYSSTUDIO <0x00> Workstation Service
It sends out the name and includes an identifier on the end of the type of name we are looking for. In NETBIOS you can also find the address information for domains, users and other things. The response carries a resource record which in this case contains the IP address.
Nbtns: Query Response, Success for PAULYSSTUDIO <0x00> Workstation Service, 192.168.1.7
But for traffic that is not local, we don’t want to broadcast a NBT Name Request to the world. Furthermore routers and such are programmed to block that kind of traffic. So the network gods have provided another protocol to solve this problem.
It’s also important to note that for NbtNS traffic we also have something called WINS which serves as a way to replicate NbtNS addresses across routers. This way if you have a local WINS server, it may respond on behalf of the machine you are looking for. This is similar to how DNS works, but it’s being phased out. These days, DNS has taken over this roll but there are legacy systems which still use WINS, like Windows 2000.
DNS - Domain Name Service
The third protocol we’ll talk about is DNS or Domain Name Service. This uses a distributed database, like 411 or a phone book for each city, to store addresses. Furthermore, if you’re local DNS doesn’t have the answer it can query or forward your request to other DNS servers. So DNS servers have a way of using its partners to resolve addresses.
When your machine receives an IP address, it will often also receive the IP address of your DNS server. This lets us contact the DNS Server. This potentially may also require an ARP, but sometimes this server is not local. We’ll talk about this a little further on in the blog.
The difference with DNS traffic is that it’s directed to the DNS server. There’s no need for broadcasts in this case. We send the server the name we want to look for, and it returns with the IP address of that machine. Here’s an example of a NM31 DNS query summary line.
Dns: QueryId = 0x2847, QUERY (Standard query), Query for MysteryMachine of type Host Addr on class Internet
You’ll note we send the name of the machine “MysteryMachine” and a query ID. Since this is UDP traffic the query ID is used to track which response is related to our request. You can also tell the server that you want it to do a recursive search for you. This means that if it doesn’t have the record local, it can query other DNS servers to resolve the name.
The DNS response contains one or more Answer Records with the IP address of the machine you are looking for. You may get multiple records if for instance there is a web farm for the address you are looking for and any one of multiple machines can accept your connection.
- Dns: QueryId = 0x2847, QUERY (Standard query), Response - Success <br> UINT16 QueryIdentifier: 10311 (0x2847)<br> + UINT16 Flags: Response, Opcode - QUERY (Standard query), AA, RD, RA, Rcode - Success<br> UINT16 QuestionCount: 1 (0x1)<br> UINT16 AnswerCount: 1 (0x1)<br> UINT16 NameServerCount: 0 (0x0)<br> UINT16 AdditionalCount: 0 (0x0)<br> + DNSQuestionRecord QRecord: MysteryMachine of type Host Addr on class Internet<br> - DNSResourceRecord ARecord: MysteryMachine of type Host Addr on class Internet<br> DnsString ResourceName: MysteryMachine<br> UINT16 ResourceType: A, IPv4 address, 1(0x1)<br> UINT16 ResourceClass: Internet, 1(0x1)<br> UINT32 TimeToLive: 1200 (0x4B0)<br> UINT16 ResourceDataLength: 4 (0x4)<br> IPv4Address IPAddress: 192.168.1.100
Conclusion
Name resolution problems are one of the more important pieces in networking and when it breaks, it can appear your network is down. The described protocols and processes give you a background of what is happening behind the scenes. In the next blog we’ll discuss how to trouble shoot those problems with Network Monitor 3.1.