Chapter 12. nslookup and dig

"Don't stand chattering to yourself like that," Humpty Dumpty said, looking at her for the first time, "but tell me your name and your business."
"My name is Alice, but -- "
"It's a stupid name enough!" Humpty Dumpty interrupted impatiently. "What does it mean?"
"Must a name mean something?" Alice asked doubtfully.

"Of course it must," Humpty Dumpty said with a short laugh...

To be proficient at troubleshooting name server problems, you'll need a troubleshooting tool to send DNS queries, one that gives you complete control. We'll cover nslookup in this chapter because it's distributed with BIND and with many vendors' operating systems. That doesn't mean it's the best DNS troubleshooting tool available, though. nslookup has its faults -- so many, in fact, that it's now deprecated (geekish for "officially out of favor") in the BIND 9 distribution. We'll cover it anyway, since it's pervasive. We'll also cover dig, which provides similar functionality and doesn't suffer from nslookup's deficiencies.

Note that this chapter isn't comprehensive; there are aspects of nslookup and dig (mostly obscure and seldom used) that we won't cover. You can always consult the manual pages for those.

12.1. Is nslookup a Good Tool?

Much of the time, you'll use nslookup to send queries in the same way the resolver sends them. Sometimes, though, you'll use nslookup to query other name servers as a name server would instead. The way you use it will depend on the problem you're trying to debug. You might wonder, "How accurately does nslookup emulate a resolver or a name server? Does nslookup actually use the BIND resolver library routines?" No, nslookup uses its own routines for querying name servers, but those routines are based on the resolver routines. Consequently, nslookup's behavior is very similar to the resolver's behavior, but it does differ slightly. We'll point out some of those differences. As for emulating name server behavior, nslookup allows us to query another server with the same query message that a name server would use, but the retransmission scheme is quite different. Like a name server, though, nslookup can transfer a copy of the zone data. So nslookup doesn't emulate either the resolver or the name server exactly, but it does emulate them well enough to make a decent troubleshooting tool. Let's delve into those differences we alluded to.

12.1.1. Multiple Servers

nslookup talks to only one name server at a time. This is the biggest difference between nslookup's behavior and the resolver's behavior. The resolver makes use of each nameserver directive in resolv.conf. If there are two nameserver directives in resolv.conf, the resolver tries the first name server, then the second, then the first, then the second, until it receives a response or gives up. The resolver does this for every query. On the other hand, nslookup tries the first name server in resolv.conf and keeps retrying until it finally gives up on the first name server and tries the second. Once it gets a response, it locks onto that server and doesn't try the next. However, you want your troubleshooting tool to talk to only one name server so you can reduce the number of variables when analyzing a problem. If nslookup used more than one name server, you wouldn't have as much control over your troubleshooting session. So talking to only one server is the right thing for a troubleshooting tool to do.

12.1.2. Timeouts

The nslookup timeouts match the resolver timeouts when the resolver is querying only one name server. A name server's timeouts, however, are based on how quickly the remote server answered the last query, a dynamic measure. nslookup's timeouts will never match a name server's timeouts, but that's not a problem either. When you're querying remote name servers with nslookup, you probably only care what the response was, not how long it took.

12.1.3. The Search List

nslookup implements the search list just as the resolver code does. Versions of nslookup shipped with pre-BIND 4.9 name servers tend to use a "full" search list: the local domain name and all ancestor domain names with at least two labels. Versions of nslookup shipped with BIND 4.9 and later name servers use an abridged search list that includes just the local domain name. We'll show you how to determine your type of nslookup later, in case you're not sure.

Name servers don't implement search lists, so, to act like a name server, the nslookup search function must be turned off -- more on that later.

12.1.4. Zone Transfers

nslookup does zone transfers just like a name server. Unlike a name server, however, nslookup does not check SOA serial numbers before pulling the zone data; if you want to do that, you'll have to do it manually.

12.1.5. Using NIS and /etc/hosts

This last point doesn't compare nslookup to the resolver or name server but to ways of looking up names in general. As distributed from the Internet Software Consortium, nslookup uses only DNS; it won't use NIS or /etc/hosts. Most applications can use DNS, NIS, or /etc/hosts, depending on how the system is configured. Don't count on nslookup to help you find your lookup problem unless your host is really configured to use name servers.[93]

[93]Or your vendor's nslookup has been enhanced to query NIS servers and check /etc/hosts, like the one in HP-UX.


11.4. The DNS Security Extensions		12.2. Interactive Versus Noninteractive