IP host name resolution should be straightforward, with just two basic types: a host file and the DNS system. However, the process for locating an address in the DNS system and the complexities of multiple layers of cache make the process slightly less transparent. In this article, we will discuss how a client resolves host names, specifically the names that are used in Web browsers and for utilities like PING. They are not, however, the names that you use to locate a Windows server, although most servers have the same NetBIOS and IP host names.
How host names work
Host names work by consulting a local file called hosts and determining if the host name matches an entry in the file. If it does not, then the host name is passed onto the Domain Naming System (DNS) for resolution. The format of the host’s file is very simple: It lists an IP address, followed by the host name. On Windows clients, the host’s file is located in:
For most Windows 2000 machines, this will be:
Adding a host is as easy as adding a new line, then typing an IP address, space, and host name.
One of the complexities of host name resolution is the fact that the name space for host names is a hierarchy. A host name is not just “www” or “penguin.” Its full name might be “penguin.datacenterdaily.com.” The host name is made up of both the actual host name and the host domain. When specified together, they form the fully qualified domain name (FQDN). When creating entries in the host’s file, the entries are assumed to be within the same host domain as the computer, unless the host name contains a dot (.). When a dot is present, it is assumed that the name present is an FQDN.
If the host’s file does not contain the host name being requested, the computer submits a request for the host’s IP address to a Domain Naming System (DNS) server. When the request is submitted, it contains both the host name and the domain name. If the domain name was not included (as evidenced by the lack of a dot), it is added. The domain name comes from the system’s IP configuration. In the case of Windows 2000 and greater, the system, as well as each network adapter or connection, can have a domain. The domain name associated with the adapter is the one that is used when DNS is queried.
A single client machine may have multiple DNS servers. They are essentially queried in a random order. Although there is a set of rules governing which server will be attempted next, in name resolution requests, the rules are sufficiently detailed as to make the process random from the user’s point of view. The important point is that the Windows client does not query every DNS server listed; only one of the DNS servers is queried.
Once a DNS server has the information, it checks its local cache of previous requests and the domains for which it considers itself to be authoritative. The local cache is created when answers are generated for clients for nonlocal domains. Each response is cached for a period of time so that, should the computer that made the request need the same answer again within a brief time period, it would not be necessary to repeat the entire resolution process.
The local domains that are maintained on the DNS server are called zones. These zones contain all of the hosts for an entire domain. Although deeper portions of the domain tree can be delegated to other naming servers, one level of the domain is always completely loaded by every DNS server that is authoritative for the domain. DNS servers that are authoritative for a domain will either resolve the address or indicate that the host does not exist.
Assuming that a DNS server is presented with a nonlocal and noncached response, it follows a procedure to resolve the name on behalf of the client. It is possible to establish a forwarder where the DNS server will send all requests that it does not understand. This prevents the normal resolution process described below; it inserts a first step in which it sends the request to a specific DNS server. Although setting up DNS forwarders is possible, it is rarely done today. Even if a forwarder is used, eventually a server will have to follow a process to resolve the name.
By decomposing the host name that is attempting to be resolved such that only the rightmost portions of the request are checked against the root DNS servers on the Internet, you can locate the DNS server with the result of a host name request. There are a small number of root DNS servers that know about all of the top-level domains. These servers resolve the rightmost two sections into a DNS server that is responsible for the rest of the address or that can find the responsible DNS server.
For instance, if you were searching for www.techproguild.com, your DNS server would contact one of the root DNS servers asking for techproguild.com. The root DNS server would respond with the location of the naming servers responsible for techproguild.com. Your DNS server would then contact one of the naming servers that it received back from the root DNS server and ask it for the www.techproguild.com address. The DNS server for techproguild.com would either respond with the “www” address, or it would indicate that the address was irresolvable.
To try a slightly more difficult example, let us suppose you were looking for preferred.us.techproguild.com and that there is another subdomain after techproguild.com. In this case, everything in the previous example would be the same, except that the DNS server for techproguild.com may or may not have the information for us.techproguild.com. The DNS server for techproguild.com may give one of three answers in this scenario. In addition to responding either with the IP address or a message that the address is irresolvable, it may also respond with the location of the us.techproguild.com naming servers that will be able to respond to the request. In that case, your DNS server makes another request, this time to the us.techproguild.com naming server received from the DNS server, and asks for the preferred.us.techproguild.com address. The response would either be an IP address or a message that the name is irresolvable.
This process is important because there are many opportunities for problems to arise. It is possible that the local domain name on the computer you are troubleshooting is incorrect or that the DNS server that you are pointing to is malfunctioning. It is also possible that the root DNS servers do not know the domain or that there is a configuration problem with the server hosting the domain name. The good news is that there are tools included on the Windows client, starting with Windows 2000, that can help you pinpoint exactly where the problem lies.
Troubleshooting when a host name will not resolve
The process of troubleshooting a host name problem begins with using the PING utility to try to ping the host name in question. This is done with ping <hostname>, where <hostname> is the name you are testing. Typically, the first test is just the host name that is being sought and not the FQDN of the host. If this initial test works, then name resolution is working and no further testing is necessary. However, in cases where the address is not resolved, the next test is to try the FQDN of the host.
If the FQDN works, then it is most likely the client does not contain the correct domain name setting. Changing the domain name will most likely resolve the problem. If not, then it is time to check the host’s file. Open the host’s file in:
In this file, look for a line that begins with an IP address and is followed by the host name or FQDN of the host you are testing. If the entry is in the file and the name is still not resolving, then there is an internal client software problem that is preventing it from working correctly. It may be necessary to remove and reinstall the network adapter and/or TCP/IP. This used to be a rather common issue with Windows 95/98, but it very rarely occurs with Windows 2000 or Windows XP. The bottom line is that it will sometimes occur when there is some sort of an internal disconnection in Windows with regard to name resolution, which is frequently resolved by removing and reinstalling TCP/IP.
The next step is to determine what DNS servers are being used and test connectivity with each one. This is most easily done by typing IPCONFIG /ALL at a command prompt and copying down all of the DNS servers that are returned (if you are on a UNIX host, this information is located in /etc/resolv.conf). Then, each DNS server should be pinged to verify basic connectivity.
Potential problems with pinging a DNS server
If you are unable to ping a DNS server, there are a few likely causes that you will need to investigate. The first potential cause is that you are unable to communicate beyond your local network. It is possible that your IP configuration does not allow you to communicate beyond your local network because of a default gateway or subnet mask configuration problem. The second potential cause is that the administrator has somehow blocked the ICMP packets needed for ping to work at a firewall or at the host itself. The third potential cause is that the server is down or is not responding.
Although it is possible for name resolution to work when only one DNS server is available, it is much better to ensure that all DNS servers listed in the client configuration can be reached. If you can establish basic connectivity with a DNS server, then it is time to test the actual DNS server’s resolution. This is done with the nslookup command. This command allows you to select a specific DNS server to be queried and gives a visual indication of the exact error returned. To start nslookup, just type nslookup at a command prompt. The prompt will change, indicating that nslookup is running. Before the prompt, you will be told which server is being used. You should manually change to the first server listed in the DNS configuration by typing server <IP Address> where <IP Address> is the IP address of the DNS server to use.
The next step is to type only the last two parts of the FQDN of the host, followed by another period. For www.techproguild.com, you would type techproguild.com. This prevents the nslookup tool from accidentally appending your current domain name to the request and searches to make sure that the top-level domain is present. If the answer is that the host is a “nonexistent domain,” then the DNS server cannot locate the domain of the host. This can happen for a few reasons. First, it is possible that the domain is not properly registered and the root naming servers do not know how to reach the domain. It is also possible that none of the naming servers for the domain are operational.
Before continuing, let us research the cause of this problem. While still in the nslookup tool, type set type=ns. This will cause the nslookup tool to try to locate naming servers instead of trying to completely resolve the name. At this point, you can type in the last two sections of the name and a trailing period as you did above. In our example, that was techproguild.com. This time you will either get a response that includes a few naming servers or the nonexistent domain answer. If you get a list of naming servers, then you know that the DNS server you are using is functioning properly and the domain is properly registered on the Internet, but none of the naming servers are operational.
If you need to determine whether the problem is with your DNS server or with the root registration, you can switch the server that you are testing by typing server <IP Address> where <IP Address> is an address of another naming server. Obviously, if another DNS server is able to resolve the address, then your DNS server has a configuration problem.
Intermittent host name problems
Perhaps the most difficult problems to resolve are those which are inconsistent: those problems that seem to work when you test them, but appear randomly from time-to-time just to annoy you. Perhaps the greatest cause of intermittent host name resolution problems is multiple DNS servers that are not properly synchronizing between themselves. DNS servers operate using a concept of a master DNS server for a zone, called a primary DNS server, and a slave DNS server, called a secondary DNS server. The secondary servers routinely perform a zone transfer to download the zone information from the primary server. The idea is that, in this way, the secondary servers are brought up-to-date with the primary server. This works fine in theory, but connectivity problems between the primary server and the secondary servers can lead to secondary servers that are not always available.
The tool of choice for diagnosing host name resolution problems is nslookup. Because it can be directed to use a specific naming server, you can check the same name query with each individual naming server to locate the one that does not return the answer that you would expect.
What to do when you have fixed the problem
The final step when you believe that you have resolved the problem is to tell the client to dump any caching that was done so you can verify that the name resolution process is working as it should. This is done by entering IPCONFIG /FlushDNS at a command prompt. This command will cause the internal resolver cache to be discarded, forcing all names to be re-resolved. It should be noted that some programs, such as Internet Explorer, sometimes cache name resolution internally as well. All programs should be completely stopped and restarted before being used to perform additional testing.
If you changed a setting that was not local to the client’s DNS server, then the cache for the DNS server that the client is using should be cleared as well. This can be done via the DNS MMC Snap-in by right-clicking on the server name and selecting Clear Cache.