IT professionals learn early that when something goes wrong, a few culprits stand prominently apart from the crowd. In enterprise computing environments, a DNS failure is typically the first item to fall under suspicion. If users can’t access Web sites or exchange files or send e-mail, DNS usually leads the list of culprits.
And that’s as it should be.
DNS configuration is an incredibly complex element that is often taken for granted—at least until it fails. If you plan to take Microsoft’s Windows 2000 Network Infrastructure Administration test (exam number 70-216), you will need to have a strong grasp of DNS troubleshooting. In fact, all IT professionals should learn as much as they can about DNS, regardless of whether they plan to take the exam.
The network infrastructure exam tests general DNS expertise, as well as several specific DNS concepts. One of the most important concepts is the difference between recursive, iterative, and inverse queries. Memorize these query types and the manner in which they work, and troubleshooting failures will become easier.
How DNS powers the Internet
Network Magazine‘s Rik Farrow recently wrote an article describing how top-level DNS servers power address resolution. The process is complex, but Farrow explains it well.
When a client system sends a recursive query to a local name server, that local name server must return the IP address for the friendly name entered, indicate that it can’t find an address, or return an error saying that the requested address does not exist.
Name servers do not refer the client system requesting a recursive query to other DNS servers. When answering recursive queries, the originating client does not receive address information directly from any DNS server other than the local name server.
Typically, the local name server will first check DNS data from its own boot file, cache, database, or reverse lookup file. If the server is unsuccessful in obtaining the answer from those local sources, it may contact other DNS servers for assistance using iterative queries and then pass the information it receives back to the client that originated the name resolution request.
In iterative queries, name servers return the best information they have. Although a DNS server may not know the IP address for a given friendly name, it might know the IP address of another name server likely to have the IP address being sought, so it sends that information back. The response to an iterative query can be likened to a DNS server saying, “I don’t have the IP address you seek, but the name server at 10.1.2.3 can tell you.”
The process is straightforward. Here’s one example in which a local name server uses iterative queries to resolve an address for a client:
- The local name server receives a name resolution request from a client system for a friendly name (such as www.techrepublic.com).
- The local name server checks its records. If it finds the address, it returns it to the client. If no address is found, the local name server proceeds to the next step.
- The local name server sends an iterative request to the root (the “.” in .com) name server.
- The root name server provides the local name server with the address for the top-level domain (.com, .net, etc.) server.
- The local name server sends an iterative query to the top-level domain server.
- The top-level domain server replies with the IP address of the name server that manages the friendly name’s domain (such as techrepublic.com).
- The local name server sends an iterative request to the friendly name’s domain name server.
- The friendly name’s domain name server provides the IP address for the friendly name (www.techrepublic.com) being sought.
- The local name server passes that IP address to the client.
It seems complicated, but the process completes in a matter of moments. Or, if an address isn’t found, a 404 error message is returned to the client.
Inverse queries work differently. When a DNS server receives an inverse query, it returns the friendly name for an IP address, rather than an IP address for a friendly name. However, searching the entire Internet for a friendly name match would prove time consuming. Rather than waste resources, use of the in-addr.arpa domain notifies name servers of an inverse query.
Special pointer (PTR) records are added to the in-addr.arpa domain, and these PTR records match IP addresses (whose octets are actually reversed to delegate administration of A, B, and C class addresses) to friendly domain names.
For example, clients seeking to determine the friendly name for the IP address 192.168.1.2 would send the local name server a request for the PTR record for 126.96.36.199.in-addr.arpa.
DNS is complicated. It’s one of the most frequently searched topics on TechRepublic. Take time to understand how the DNS query types work, and you will help eliminate some of the confusion that inevitably arises as to how friendly names are resolved to IP addresses in DNS.