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 nameserver 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 because 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.
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 nameservers as a nameserver 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 nameserver? Does nslookup actually use the BIND resolver library routines?” No, nslookup uses its own routines for querying nameservers, 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 nameserver behavior, nslookup allows us to query another server with the same query message that a nameserver would use, but the retransmission scheme is quite different. Like a nameserver, though, nslookup can transfer a copy of the zone data. So nslookup doesn’t emulate either the resolver or the nameserver exactly, but it does emulate them well enough to make a decent troubleshooting tool. Let’s delve into those differences we alluded to.
Multiple Servers
nslookup talks to only one nameserver at a time. This is the biggest difference between nslookup’s behavior and the resolver’s behavior. The resolver uses each nameserver directive in resolv.conf. If there are two nameserver directives in resolv.conf, the resolver tries the first nameserver, 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 nameserver in resolv.conf and keeps retrying until it finally gives up on the first nameserver 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 nameserver so you can reduce the number of variables when analyzing a problem. If nslookup used more than one nameserver, 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.
Timeouts
The nslookup timeouts match the resolver timeouts when the resolver is querying only one nameserver. A nameserver’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 nameserver’s timeouts, but that’s not a problem either. When you’re querying remote nameservers with nslookup, you probably care only what the response was, not how long it took.
The Search List
nslookup implements a search list just as the resolver code does. nslookup, however, uses either the abridged BIND search list that includes just the local domain name or the one specified in the last search entry in /etc/resolv.conf. Nameservers don’t implement search lists, so, to act like a nameserver, the nslookup search function must be turned off—more on that later.
Zone Transfers
nslookup does zone transfers just like a nameserver. Unlike a nameserver, 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.
Using NIS and /etc/hosts
This last point doesn’t compare nslookup to the resolver or nameserver 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 nameservers.[*]
Interactive Versus Noninteractive
Let’s start our tutorial on nslookup by looking at how to start it and how to exit from it. You can run nslookup either interactively or noninteractively. If you only want to look up one record for one domain name, use the noninteractive form. If you plan on doing something more extensive, such as changing nameservers or options, use an interactive session.
To start an interactive session, just type nslookup:
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53 >^D
If you need help, type ? or help.[†] When you want to exit, type ^D (Ctrl-D) or exit. If you try to exit from nslookup by interrupting it with ^C (or whatever your interrupt character is), you won’t get very far. nslookup catches the interrupt, stops whatever it is doing (like a zone transfer), and gives you the > prompt.
For a noninteractive lookup, include the name you are looking up on the command line:
%nslookup carrie
Server: toystory.movie.edu
Address: 0.0.0.0#53
Name: carrie.movie.edu
Address: 192.253.253.4Option Settings
nslookup has its own set of dials and knobs, called options. All of the option settings can be changed. We’ll discuss here what each of the options means, and we’ll use the rest of the chapter to show you how to use them.
%nslookupDefault Server: bladerunner.fx.movie.edu Address: 0.0.0.0#53 >set allDefault Server: bladerunner.fx.movie.edu Address: 0.0.0.0 Set options: nodebug defname search recurse nod2 novc noignoretc port=53 querytype=A class=IN timeout=5 retry=4 root=a.root-servers.net. domain=fx.movie.edu srchlist=fx.movie.edu >^D
For BIND 9.3.2, a few of the options have been removed or changed:
novc nodebug nod2 search recurse timeout = 0 retry = 3 port = 53 querytype = A class = IN srchlist = fx.movie.edu
Before we get into the options, we need to cover the introductory lines. The default nameserver is bladerunner.fx.movie.edu . This means that nslookup will query bladerunner unless we specify another nameserver. The address 0.0.0.0 means “this host.” When nslookup is using address 0.0.0.0 or 127.0.0.1 as its nameserver, it is using the server running on the local system—in this case, bladerunner.
The options come in two flavors: Boolean and value. The options that do not have an equals sign after them are Boolean options. They have the interesting property of being either “on” or “off.” The value options can take on different, well, values. How can we tell which Boolean options are on and which are off? The option is off when a “no” precedes the option’s name. nodebug means that debugging is off. As you might guess, the search option is on.
How you change Boolean or value options depends on whether you are using nslookup interactively. In an interactive session, you change an option with the set command, as in set debug or set domain=classics.movie.edu. From the command line, you omit the word set and precede the option with a hyphen, as in nslookup -debug or nslookup -domain=classics.movie.edu. An option can be abbreviated to its shortest unique prefix, e.g., nodeb for nodebug. In addition to its abbreviation, the querytype option can also be called simply type.
Let’s go through each option:
- [no]debug
Debugging is turned off by default. If it is turned on, the nameserver shows timeouts and displays the response messages. See [no]d2 for a discussion of debug level 2.
- [no]defname
(This option is no longer supported as of 9.3.2.) Before search lists existed, the BIND resolver code added only the local domain name to names without any dots in them; this option selects that behavior. nslookup can implement the pre-search list behavior (with search off and defname on) or the search list behavior (with search on).
- [no]search
The search option supersedes the local domain name (defname) option. That is, defname applies only if search is turned off. By default, nslookup appends the domain names in the search list (srchlist) to names that don’t end in a dot.
- [no]recurse
nslookup sends recursive queries by default. This turns on the recursion-desired bit in query messages. The BIND resolver sends recursive queries in the same way. Nameservers, however, send out nonrecursive queries to other nameservers.
- [no]d2
Debugging at level 2 is turned off by default. If it is turned on, you see the query messages sent out in addition to the regular debugging output. Turning on d2 also turns on debug. Turning off d2 turns off d2 only; debug is left on. Turning off debug turns off both debug and d2.
- [no]vc
By default, nslookup sends queries using UDP datagrams instead of over a virtual circuit (TCP). Most BIND resolvers send queries over UDP, so the default nslookup behavior matches the resolver. As some resolvers can be instructed to use TCP, so can nslookup.
- [no]ignoretc
(This option is no longer supported as of 9.3.2.) By default, nslookup doesn’t ignore truncated messages. If a message is received that has the “truncated” bit set—indicating that the nameserver couldn’t fit all the important information in the UDP response datagram—nslookup doesn’t ignore it; it retries the query using a TCP connection instead of UDP. Again, this matches the BIND resolver’s behavior. The reason for retrying the query using a TCP connection is that TCP responses can be many times larger than UDP responses.
- port=53
Nameservers listen on port 53. You can start a nameserver on another port—for debugging purposes, for example—and nslookup can be directed to use that port.
- querytype=A
By default, nslookup looks up A (address) resource record types. In addition, if you type in an IP address (and the nslookup query type is A or PTR), nslookup inverts the address, appends in-addr.arpa, and looks up PTR records instead.
- class=IN
The only class that matters is Internet (IN). Well, there is the Hesiod (HS) class, too, if you are an MITer or run Ultrix.
- timeout=5
If the nameserver doesn’t respond within 5 seconds, nslookup resends the query and doubles the timeout (to 10, 20, and then 40 seconds). Most BIND resolvers use the same timeouts when querying a single nameserver.
- retry=4
Send the query four times before giving up. After each retry, the timeout value is doubled. Again, this matches most BIND resolvers’ behavior.
- root=a.root-servers.net
(This option is no longer supported as of 9.3.2.) There is a convenience command called root that switches your default nameserver to the server named here. Executing the root command from a modern nslookup’s prompt is equivalent to executing server a.root-servers.net. Older versions use nic.ddn.mil (old) or even sri-nic.arpa (ancient) as the default root nameserver. You can change the default root server with set root=server.
- domain=fx.movie.edu
(This option is no longer supported as of 9.3.2.) This is the default domain name to append if the defname option is on.
- srchlist=fx.movie.edu
If search is on, these are the domain names appended to names that do not end in a dot. The domain names are listed in the order in which they are tried, separated by a slash.
The .nslookuprc File
You can set up new default nslookup options in an .nslookuprc file. nslookup looks for an .nslookuprc file in your home directory when it starts up, in both interactive and noninteractive modes. The .nslookuprc file can contain any legal set commands, one per line. This is useful, for example, if your old nslookup still thinks sri-nic.arpa is a root nameserver. You can set the default root nameserver to a real, current root with a line like this in your .nslookuprc file:
set root=a.root-servers.net.
You might also use .nslookuprc to set your search list to something other than your host’s default search list or to change the timeouts nslookup uses.
Avoiding the Search List
nslookup implements the same search list as the resolver. When you’re debugging, though, the search list can get in your way. You may need to turn off the search list completely (set nosearch) or add a trailing dot to the fully qualified domain name you are looking up. We prefer the latter, as you’ll see in our examples.
Common Tasks
There are little chores you’ll come to use nslookup for almost every day: finding the IP address or MX records for a given domain name, or querying a particular nameserver for data. We’ll cover these first, before moving on to the more occasional stuff.
Looking Up Different Record Types
By default, nslookup looks up the address for a domain name, or the domain name for an address. You can look up any record type by changing the querytype, as we show in this example:
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53>miseryLook up address Server: toystory.movie.edu Address: 0.0.0.0#53 Name: misery.movie.edu Address: 192.253.253.2>192.253.253.2Look up domain name Server: toystory.movie.edu Address: 0.0.0.0#53 Name: misery.movie.edu Address: 192.253.253.2>set q=mxLook up MX records >wormholeServer: toystory.movie.edu Address: 0.0.0.0#53 wormhole.movie.edu preference = 10, mail exchanger = wormhole.movie.edu wormhole.movie.edu internet address = 192.249.249.1 wormhole.movie.edu internet address = 192.253.253.1>set q=anyLook up records of any type >monsters-incServer: toystory.movie.edu Address: 0.0.0.0#53 monsters-inc.movie.edu internet address = 192.249.249.4 monsters-inc.movie.edu preference = 10, mail exchanger = monsters-inc.movie.edu monsters-inc.movie.edu internet address = 192.249.249.4
These are only a few of the valid DNS record types, of course. For a more complete list, see Appendix A.
Authoritative Versus Nonauthoritative Answers
If you’ve used nslookup before, you might have noticed something peculiar: the first time you look up a remote domain name, the answer is authoritative, but the second time you look up the same name, it is nonauthoritative. Here’s an example:
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53 >slate.mines.colorado.edu. Server: toystory.movie.edu Address: 0.0.0.0#53 Name: slate.mines.colorado.edu Address: 138.67.1.3 >slate.mines.colorado.edu. Server: toystory.movie.edu Address: 0.0.0.0#53 Non-authoritative answer: Name: slate.mines.colorado.edu Address: 138.67.1.3
While this looks odd, it really isn’t. What’s happening here is that the first time the local nameserver looks up slate.mines.colorado.edu, it contacts the nameserver for mines.colorado.edu, and the mines.colorado.edu server then responds with an authoritative answer. The local nameserver, in effect, passes the authoritative response directly back to nslookup. It also caches the response. The second time you look up slate.mines.colorado.edu, the nameserver answers out of its cache, which results in the answer “non-authoritative.”[*]
Notice that we terminated the domain name with a trailing dot each time we looked it up. The response would have been the same if we’d left off the trailing dot. There are times when it’s critical that you use the trailing dot while debugging, and times when it’s not. Rather than stopping to decide if this name needs a trailing dot, we always add one if we know the name is fully qualified, except, of course, if we’ve turned off the search list.
Switching Nameservers
Sometimes you want to query another nameserver directly: you may think it is misbehaving, for example. You can switch servers with nslookup using the server or lserver command. The difference between server and lserver is that lserver queries your local nameserver—the one you started out with—to get the address of the server you want to switch to; server uses the default nameserver instead of the local server. This difference is important because the server you just switched to may not be responding, as we’ll show in this example:
%nslookup
Default Server: toystory.movie.edu
Address: 0.0.0.0#53When we start up, our first nameserver, toystory.movie.edu , becomes our lserver. This will matter later on in this session.
>server galt.cs.purdue.edu. Default Server: galt.cs.purdue.edu Address: 128.10.2.39#53 >cs.purdue.edu. Server: galt.cs.purdue.edu Address: 128.10.2.39#53 *** galt.cs.purdue.edu can't find cs.purdue.edu.: Query refused
At this point, we try to switch back to our original nameserver. But the nameserver running on galt.cs.purdue.edu refuses to look up toystory.movie.edu ’s address:
>server toystory.movie.edu.
*** Can't find address for server toystory.movie.edu.: Query refusedInstead of being stuck, though, we use the lserver command to have our local nameserver look up toystory.movie.edu ’s address:
>lserver toystory.movie.edu. Default Server: toystory.movie.edu Address: 192.249.249.3#53 >^D
Since the nameserver on galt.cs.purdue.edu refused to respond, it wasn’t possible to look up the address of toystory.movie.edu to switch back to using toystory’s nameserver. Here’s where lserver comes to the rescue: the local nameserver, toystory, was still responding, so we used it. Instead of using lserver, we also could have recovered using toystory’s IP address directly: server 192.249.249.3.
You can even change servers on a per-query basis. To specify that you’d like nslookup to query a particular nameserver for information about a given domain name, you can specify the server as the second argument on the line, after the domain name to look up, like so:
%nslookupDefault Server: toystory.movie.edu Address: 192.249.249.3#53 >saturn.sun.com. ns.sun.com. Name Server: ns.sun.com Address: 192.9.9.3#53 Name: saturn.sun.com Addresses: 192.9.25.2 >^D
And, of course, you can change servers from the command line. You can specify the server to query as the argument after the domain name to look up, like this:
%nslookup -type=mx fisherking.movie.edu. toystory.movie.edu.This instructs nslookup to query toystory.movie.edu for MX records for fisherking.movie.edu.
Finally, to specify an alternate default nameserver and enter interactive mode, you can use a hyphen in place of the domain name to look up:
%nslookup - toystory.movie.edu.Less Common Tasks
Let’s move on to some tricks you’ll probably use less often but are still handy to have in your repertoire. Most of these will be helpful when you are trying to troubleshoot a DNS or BIND problem; they’ll enable you to grub around in the messages the resolver sees and mimic a BIND nameserver querying another nameserver or transferring zone data.
Showing the Query and Response Messages
If you need to, you can direct nslookup to show you the queries it sends out and the responses it receives. Turning on debug shows the responses. Turning on d2 shows the queries as well. When you want to turn off debugging completely, you have to use set nodebug because set nod2 turns off only level 2 debugging. After the following trace, we’ll explain some parts of the output. If you want, pull out your copy of RFC 1035, turn to page 25, and read along with our explanation.
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53 >set debug>wormholeServer: toystory.movie.edu Address: 0.0.0.0#53 ------------ Got answer: HEADER: opcode = QUERY, id = 6813, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 2, authority records = 2, additional = 3 QUESTIONS: wormhole.movie.edu, type = A, class = IN ANSWERS: -> wormhole.movie.edu internet address = 192.253.253.1 ttl = 86400 (1D) -> wormhole.movie.edu internet address = 192.249.249.1 ttl = 86400 (1D) AUTHORITY RECORDS: -> movie.edu nameserver = toystory.movie.edu ttl = 86400 (1D) -> movie.edu nameserver = wormhole.movie.edu ttl = 86400 (1D) ADDITIONAL RECORDS: -> toystory.movie.edu internet address = 192.249.249.3 ttl = 86400 (1D) -> wormhole.movie.edu internet address = 192.253.253.1 ttl = 86400 (1D) -> wormhole.movie.edu internet address = 192.249.249.1 ttl = 86400 (1D) ------------ Name: wormhole.movie.edu Addresses: 192.253.253.1, 192.249.249.1 >set d2>wormholeServer: toystory.movie.edu Address: 0.0.0.0#53This time the query is also shown. ------------ SendRequest( ), len 36 HEADER: opcode = QUERY, id = 6814, rcode = NOERROR header flags: query, want recursion questions = 1, answers = 0, authority records = 0, additional = 0 QUESTIONS: wormhole.movie.edu, type = A, class = IN ------------ ------------ Got answer (164 bytes):The answer is the same as above.
The lines between the dashes are the query and response messages. As promised, we’ll go through the contents of the messages. DNS packets comprise five sections: header, question, answer, authority, and additional.
- Header section
The header section is present in every query and response message. The operation code nslookup reports is always QUERY. There are other opcodes for asynchronous notification of zone changes (NOTIFY) and for dynamic updates (UPDATE), but nslookup doesn’t see those because it just sends regular queries and receives responses.
The ID in the header associates a response with a query and detects duplicate queries or responses. You have to look in the header flags to see which messages are queries and which are responses. The string want recursion means that this is a recursive query. The string auth. answer means that this response is authoritative. In other words, the response is from the nameserver’s authoritative data, not from its cache. The response code, rcode, can be one of no error, server failure, name error (also known as nxdomain or nonexistent domain), not implemented, or refused. The server failure, name error, not implemented, and refused response codes cause the nslookup “Server failed,” “Nonexistent domain,” “Not implemented,” and “Query refused” errors, respectively. The last four entries in the header section are counters: they indicate how many resource records there are in each of the next four sections.
- Question section
There is always one question in a DNS message; it includes the domain name and the requested record type and class. There is never more than one question in a DNS message; the capability of handling more than one would require a redesign of the message format. For one thing, the single authority bit would have to be changed because the answer section could contain a mix of authoritative and nonauthoritative answers. In the present design, setting the authoritative answer bit means that the nameserver is authoritative for the zone that contains the domain name in the question section.
- Answer section
This section contains the resource records that answer the question. There can be more than one resource record in the response. For example, if the host is multihomed, there will be more than one address resource record.
- Authority section
The authority section is where nameserver records are returned. When a response refers the querier to some other nameservers, those nameservers are listed here.
- Additional section
The additional records section adds information that may complete the information included in other sections. For instance, if a nameserver is listed in the authority section, the nameserver’s address may be included in the additional records section. After all, to contact the nameserver, you need to have its address.
Querying Like a BIND Nameserver
You can make nslookup send out the same query message a nameserver would. Nameservers’ query messages aren’t that much different from resolvers’ query messages in the first place. The primary difference in the query messages is that resolvers request recursive resolution and nameservers seldom do. Requesting recursion is the default with nslookup, so you have to explicitly turn it off. Another difference in operation between a resolver and a nameserver is that the resolver applies the search list, and the nameserver doesn’t. By default, nslookup applies the search list, so that must be explicitly turned off as well. Of course, judicious use of the trailing dot will have the same effect.
In raw nslookup terms, this means that to query like a resolver, you use nslookup’s default settings. To query like a nameserver, use set norecurse and set nosearch. On the command line, that’s nslookup -norecurse -nosearch.
When a BIND nameserver receives a query, it looks for the answer in its authoritative data and in its cache. If it doesn’t have the answer, and it is authoritative for the zone, the nameserver responds that the name doesn’t exist or that there are no records of the type sought. If the nameserver doesn’t have the answer and it is not authoritative for the zone, it starts walking up the namespace looking for NS records. There are always NS records somewhere higher in the namespace. As a last resort, it uses the NS records for the root zone, the highest level.
If the nameserver has received a nonrecursive query, it responds to the querier by returning the NS records that it found. On the other hand, if the original query was a recursive query, the nameserver queries the remote nameservers in the NS records that it found. When the nameserver receives a response from one of the remote nameservers, it caches the response and, if necessary, repeats this process. The remote server’s response either has the answer to the question or contains a list of nameservers lower in the namespace and closer to the answer.
Let’s assume for our example that we are trying to satisfy a recursive query. When we ask the nameserver on toystory.movie.edu about www.usps.gov (the United States Postal Service), it doesn’t find any NS records until the gov zone. From there, we switch servers to a gov nameserver and ask the same question. It directs us to the usps.gov servers. We then switch to a usps.gov nameserver and ask the same question:
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53 >set norecQuery like a nameserver: turn off recursion >set nosearchTurn off the search list >set nodefnameTurn off appending the local domain (only for older nslookups) >www.usps.govWe don't need to dot-terminate since we've turned off search Server: toystory.movie.edu Address: 0.0.0.0#53 Name: www.usps.gov Served by: - G.GOV.ZONEEDIT.COM 66.135.32.100 gov - F.GOV.ZONEEDIT.COM 66.197.185.229 gov - E.GOV.ZONEEDIT.COM 82.165.40.134 gov - D.GOV.ZONEEDIT.COM 209.97.207.48 gov - C.GOV.ZONEEDIT.COM 69.72.142.35 gov - B.GOV.ZONEEDIT.COM 206.51.224.229 gov - A.GOV.ZONEEDIT.COM 216.55.155.29 gov
Switch to a gov nameserver (you may have to turn on recursion again temporarily if your nameserver doesn’t have the address of the gov nameserver already cached):
>server g.gov.zoneedit.com
Default Server: g.gov.zoneedit.com
Address: 66.135.32.100#53Ask the same question of the gov nameserver. It will refer us to nameservers closer to our desired answer:
>www.usps.gov
Server: g.gov.zoneedit.com
Address: 66.135.32.100#53
Name: www.usps.gov
Served by:
- DNS072.usps.gov
56.0.72.25
usps.gov
- DNS096.usps.gov
56.0.96.25
usps.gov
- DNS141.usps.gov
56.0.141.25
usps.govSwitch to a usps.gov nameserver—any of them will do:
>server dns096.usps.govDefault Server: dns096.usps.gov Address: 56.0.96.25#53 >www.usps.govServer:dns096.usps.govAddress: 56.0.96.25#53 Name: www.usps.gov Address: 56.0.134.23
Hopefully, this example gives you a feeling for how nameservers look up domain names. If you need to refresh your understanding of what this looks like graphically, flip back to Figures 2-12 and 2-13.
Before we move on, notice that we asked each of the servers the very same question: “What’s the address of www.usps.gov?” What do you think would happen if the gov nameserver had already cached www.usps.gov’s address itself? The gov nameserver would have answered the question out of its cache instead of referring you to the usps.gov nameservers. Why is this significant? Suppose you messed up a particular host’s address in your zone. Someone points it out to you, and you clean up the problem. Even though your nameserver now has the correct data, some remote sites find the old, messed-up data when they look up the domain name of the host. One of the nameservers that serves a zone higher up in the namespace, such as a nameserver for a top-level zone, has cached the incorrect data; when it receives a query for that host’s address, it returns the incorrect data instead of referring the querier to your nameservers. What makes this problem hard to track down is that only one of the higher-up nameservers has cached the incorrect data, so only some of the remote lookups get the wrong answer—the ones that use this server. Fun, huh? Eventually, though, the higher-up nameserver will time out the old record. Thankfully, most TLD nameservers have recursion turned off and consequently don’t cache data. A few, unfortunately, still do.
Zone Transfers
nslookup can be used to transfer a whole zone using the ls command. This feature is useful for troubleshooting, for figuring out how to spell a remote host’s domain name, or for just counting how many hosts are in some remote zone. Since the output can be substantial, nslookup allows you to redirect the output to a file. If you want to bail out in the middle of a transfer, you can interrupt it by typing your interrupt character.
Beware: some nameservers won’t let you pull a copy of their zones, either for security reasons or to limit the load placed on them. On today’s Internet, administrators must defend their turf.
Let’s look at the movie.edu zone. As you can see in the following output, all the zone data is listed; the SOA record is listed twice, which is an artifact of how the data is exchanged during the zone transfer. Since some nslookups show you only address and nameserver records by default, we specify the -d option to retrieve the whole zone:
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53 >ls -d movie.edu. [toystory.movie.edu] $ORIGIN movie.edu. @ 1D IN SOA toystory al ( 2000091400 ; serial 3H ; refresh 1H ; retry 4W2D ; expiry 1H ) ; minimum 1D IN NS toystory 1D IN NS wormhole wormhole 1D IN A 192.249.249.1 1D IN A 192.253.253.1 wh249 1D IN A 192.249.249.1 shrek 1D IN A 192.249.249.2 toys 1D IN CNAME toystory cujo 1D IN TXT "Location:" "machine" "room" "dog" "house" wh253 1D IN A 192.253.253.1 wh 1D IN CNAME wormhole shining 1D IN A 192.253.253.3 toystory 1D IN A 192.249.249.3 localhost 1D IN A 127.0.0.1 fx 1D IN NS bladerunner.fx bladerunner.fx 1D IN A 192.253.254.2 fx 1D IN NS outland.fx outland.fx 1D IN A 192.253.254.3 fx 1D IN NS huskymo.boulder.acmebw.com. 1D IN NS tornado.acmebw.com. me 1D IN CNAME monsters-inc carrie 1D IN A 192.253.253.4 monsters-inc 1D IN A 192.249.249.4 misery 1D IN A 192.253.253.2 @ 1D IN SOA toystory al ( 2000091400 ; serial 3H ; refresh 1H ; retry 4W2D ; expiry 1H ) ; minimum
Now let’s say you missed a record in the beginning of the zone data, one that flew off the top of your screen. nslookup lets you save the listing of a zone to a file:
>ls -d movie.edu > /tmp/movie.eduList all data into /tmp/movie.edu [toystory.movie.edu] Received 25 answers (25 records).
Some versions of nslookup even support a built-in view command that sorts and displays the contents of a zone listing from interactive mode. In the latest BIND 8 releases, though, view is broken, and it isn’t supported by BIND 9’s nslookup as of 9.3.2.
Troubleshooting nslookup Problems
The last thing you want is to have problems with your troubleshooting tool. Unfortunately, some types of failures render nslookup nearly useless. Other types of nslookup failures are (at best) confusing, because they don’t give you any clear information to work with. While there may be a few problems with nslookup itself, most of the problems you encounter will be caused by nameserver configuration and operation. We’ll cover these problems here.
Looking Up the Right Data
This isn’t really a problem per se, but it can be awfully confusing. If you use nslookup to look up a type of record for a domain name, and the domain name exists but records of the type you’re looking for don’t, you’ll get an error like this:
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53 >movie.edu. Server: toystory.movie.edu Address: 0.0.0.0#53 *** No address (A) records available for movie.edu.
So what types of records do exist? Just type set type=any to find out:
>set type=any>movie.edu. Server: toystory.movie.edu Address: 0.0.0.0#53 movie.edu origin = toystory.movie.edu mail addr = al.shrek.movie.edu serial = 42 refresh = 10800 (3H) retry = 3600 (1H) expire = 604800 (7D) minimum ttl = 86400 (1D) movie.edu nameserver = toystory.movie.edu movie.edu nameserver = wormhole.movie.edu movie.edu nameserver = zardoz.movie.edu movie.edu preference = 10, mail exchanger = postmanrings2x.movie.edu postmanrings2x.movie.edu internet address = 192.249.249.66
No Response from Server
What could have gone wrong if your nameserver can’t look up its own name?
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53 >toystoryServer: toystory.movie.edu Address: 0.0.0.0#53 *** toystory.movie.edu can't find toystory: No response from server
The “no response from server” error message means exactly that: the resolver didn’t get back a response. nslookup doesn’t necessarily look up anything when it starts up. If you see that the address of your nameserver is 0.0.0.0, then nslookup grabbed the system’s hostname (what the hostname command returns) for the Default Server field and gave you its prompt. It’s only when you try to look up something that you find there is no nameserver responding. In this case, it’s pretty obvious there’s no server running: a nameserver ought to be able to look up its own name. If you are looking up some remote information, though, the nameserver could fail to respond because it’s still trying to look up the data, and nslookup gave up waiting. How can you tell the difference between a nameserver that isn’t running and a nameserver that is running but didn’t respond? You can use the ls command to figure it out:
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53>ls foo. Try to list a nonexistent zone *** Can't list domain foo.: No response from server
In this case, no nameserver is running. If the host couldn’t be reached, the error would be timed out. If a nameserver is running, you’ll see this error message:
%nslookupDefault Server: toystory.movie.edu Address: 0.0.0.0#53 >ls foo. [toystory.movie.edu] *** Can't list domain foo.: No information
That is, unless there’s a top-level foo zone in your world.
No PTR Record for Nameserver’s Address
Here’s one of nslookup’s most annoying problems: something went wrong, and nslookup exited on startup:
%nslookup
*** Can't find server name for address 192.249.249.3: Non-existent host/domain
*** Default servers are not availableThe “nonexistent domain” message means that the name 3.249.249.192.in-addr.arpa doesn’t exist. In other words, nslookup couldn’t map 192.249.249.3, the address of its nameserver, to a domain name. But didn’t we just say that nslookup doesn’t look up anything when it starts up? In the configuration we showed you before, nslookup didn’t look up anything, but that’s not a rule. If you create a resolv.conf that includes one or more nameserver directives, nslookup tries to reverse-map the address to get the nameserver’s domain name. In the preceding example, there is a nameserver running on 192.249.249.3, but it said there are no PTR records for the address 192.249.249.3. Obviously, the reverse-mapping zone is messed up, at least for the domain name 3.49.249.192.in-addr.arpa.
The “default servers are not available” message in the example is misleading. After all, there is a nameserver available to say the address doesn’t exist. More often, you’ll see the error “no response from server” if the nameserver isn’t running on the host or the host can’t be reached. Only then does the “default servers are not available” message make sense.
Query Refused
Refused queries can cause problems at startup, and they can cause lookup failures during a session. Here’s what it looks like when nslookup exits on startup because of a refused query:
%nslookup
*** Can't find server name for address 192.249.249.3: Query refused
*** Default servers are not available
%Access lists can cause nslookup startup problems. When nslookup attempts to find the domain name of its nameserver using a PTR query, the query can be refused. If you think the problem is an access list, make sure you allow the host you’re running on to query the nameserver. Check any allow-query substatements for the IP address of the local host or the loopback address, if you’re running nslookup on the same host as the nameserver.
First resolv.conf Nameserver Not Responding
Here is another twist on the last problem:
%nslookup
*** Can't find server name for address 192.249.249.3: No response from server
Default Server: wormhole.movie.edu
Address: 192.249.249.1This time, the first nameserver listed in resolv.conf did not respond. We had a second nameserver directive in resolv.conf, though, and the second server did respond. From now on, nslookup will send queries only to wormhole.movie.edu ; it won’t try the nameserver at 192.249.249.3 again.
Finding Out What Is Being Looked Up
We’ve been waving our hands in the last examples, claiming that nslookup was looking up the nameserver’s address, but we didn’t prove it. Here is our proof. This time, when we started up nslookup, we turned on d2 debugging from the command line. This causes nslookup to print out the query messages it sent, as well as when the query timed out and was retransmitted:
%nslookup -d2
------------
SendRequest( ), len 44
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0,
additional = 0
QUESTIONS:
3.249.249.192.in-addr.arpa, type = PTR, class = IN
------------
timeout (5 secs)
timeout (10 secs)
timeout (20 secs)
timeout (40 secs)
SendRequest failed
*** Can't find server name for address 192.249.249.3: No response from server
*** Default servers are not availableAs you can see by the timeouts, it took 75 seconds for nslookup to give up. Without the debugging output, you wouldn’t have seen anything printed to the screen for 75 seconds; it’d look as if nslookup had hung.
Unspecified Error
You can run into a rather unsettling problem called an “unspecified error.” We have an example of this error here. We’ve included only the tail end of the output because we just want to talk about the error at this point (you’ll find the whole nslookup session that produced this segment in Chapter 14):
Authoritative answers can be found from: (root) nameserver = NS.NIC.DDN.MIL (root) nameserver = B.ROOT-SERVERS.NET (root) nameserver = E.ROOT-SERVERS.NET (root) nameserver = D.ROOT-SERVERS.NET (root) nameserver = F.ROOT-SERVERS.NET (root) nameserver = C.ROOT-SERVERS.NET (root) nameserver = *** Error: record size incorrect (1050690 != 65519) *** relay.hp.com can't find .: Unspecified error
What happened here is that there was too much data to fit into a UDP datagram. The nameserver stopped filling in the response when it ran out of room. The nameserver didn’t set the truncation bit in the response packet, or nslookup would have retried the query over a TCP connection; the nameserver must have decided that enough of the “important” information fit. You won’t see this kind of error very often. You’ll see it if you create too many NS records for a zone, so don’t create too many. (Advice like this makes you wonder why you bought this book, right?) How many is “too many” depends on how well the domain names in the packet can be “compressed,” which, in turn, depends on how many nameservers’ names end in the same domain name. The root nameservers were renamed to end in root-servers.net for this very reason: to allow more root nameservers (13) on the Internet. As a rule of thumb, don’t go over 10 NS records. As for what caused this error, you’ll have to read Chapter 14. Those of you who just read Chapter 9 may know already.
Best of the Net
System administrators have a thankless job. There are certain questions, usually quite simple ones, that users ask over and over again. And sometimes, when in a creative mood, sysadmins come up with clever ways to help their users. When the rest of us discover their ingenuity, we can only sit back, smile admiringly, and wish we had thought of it ourselves. Here is one such case, where a system administrator found a way to communicate the solution to the sometimes vexing puzzle of how to end an nslookup session:
%nslookupDefault Server: envy.ugcs.caltech.edu Address: 131.215.134.135 >quitServer: envy.ugcs.caltech.edu Addresses: 131.215.134.135, 131.215.128.135 Name: ugcs.caltech.edu Addresses: 131.215.128.135, 131.215.134.135 Aliases: quit.ugcs.caltech.edu use.exit.to.leave.nslookup.-.-.-.ugcs.caltech.edu >exit
Using dig
That’s one way to deal with what’s arguably a shortcoming in nslookup. Another is just to chuck nslookup and use dig, the Domain Information Groper (a reverse-engineered acronym if we’ve ever heard one).
We said earlier that dig isn’t as pervasive as nslookup, so we’d better begin by telling you where to get it. You can pick up source for dig from the src/bin/dig directory (BIND 8), or the bin/dig directory (BIND 9) of the BIND distribution. If you build the whole distribution, you’ll build a nice, new copy of dig, too.
With dig, you specify all aspects of the query you’d like to send on the command line; there’s no interactive mode. You specify the domain name you want to look up as an argument, and the type of query you want to send (e.g., a for address records, mx for MX records) as another argument; the default is to look up address records. You specify the nameserver you’d like to query after an “@.” You can use either a domain name or an IP address to designate a nameserver. The default is to query the nameservers in resolv.conf.
dig is smart about arguments, too. You can specify the arguments in any order you like, and dig will figure out that mx is probably the type of records, not the domain name, you want to look up.[*]
One major difference between nslookup and dig is that dig doesn’t apply the search list, so always use fully qualified domain names as arguments to dig. The following:
%dig plan9.fx.movie.edulooks up address records for plan9.fx.movie.edu using the first nameserver in resolv.conf, while:
%dig acmebw.com mxlooks up MX records for acmebw.com on the same nameserver, and:
%dig @wormhole.movie.edu. movie.edu. soaqueries wormhole.movie.edu for the SOA record of movie.edu.
dig’s Output Format
dig shows you the complete DNS response message in all its glory, with the various sections (header, question, answer, authority, and additional) clearly called out, and with resource records in those sections printed in master file format. This can come in handy if you need to use some of your troubleshooting tool’s output in a zone datafile or in your root hints file. For example, the output produced by:
%dig @a.root-servers.net ns.looks like this:
; <<>> DiG 8.3 <<>> @a.root-servers.net . ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4 H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53 C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12 G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4 F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241 B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17 E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10 D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90 ;; Total query time: 116 msec ;; FROM: toystory.movie.edu to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Fri Sep 15 09:47:26 2000 ;; MSG SIZE sent: 17 rcvd: 436
Let’s examine this output section by section.
The first line, beginning with the master file comment character
(;) and <<>> DiG 8.3 <<>>,
simply parrots the options we specified in the command line, namely,
that we were interested in the NS records that
a.root-servers.net had for the root zone.
The next line, (1 server
found), tells us that when dig looked
up the addresses associated with the domain name we specified after
the @, a.root-servers.net, it found one. (If
dig finds more than three, the maximum number of
nameservers most resolvers can query, it’ll report three.)
The line beginning with ->>
HEADER <<- is the first part of the header of the
reply message that dig received from the remote
nameserver. The opcode in the header is always QUERY, just as it is
with nslookup. The status is NOERROR; it can be
any of the statuses (stati?) mentioned in the earlier section "Showing the Query and Response
Messages.” The ID is the message ID, a 16-bit number used to
match responses to queries.
The flags tell us a bit more about the response. qr indicates that the message was a response, not a query. dig decodes responses, not queries, so qr will always be present. Not so with aa or rd, though. aa indicates that the response was authoritative, and rd indicates that the recursion-desired bit was set in the query (because the responding nameserver just copies the bit from the query to the response). Most of the time rd is set in the query, you’ll also see ra set in the response, indicating that recursion was available from the remote nameserver. However, a.root-servers.net is a root nameserver and has recursion disabled, like we showed you in Chapter 11, so it handles recursive queries the same as it does iterative queries. So it ignores the rd bit and correctly indicates that recursion wasn’t available by leaving ra unset.
The last fields in the header indicate that dig asked 1 question and received 13 records in the answer section, 0 records in the authority section, and 13 records in the additional data section.
The line after the line that contains QUERY SECTION: shows us the query
dig sent: for the NS records in the IN class for
the root zone. After ANSWER
SECTION:, we see the 13 NS records for the root nameservers,
and after ADDITIONAL SECTION:, we
have the 13 A records that correspond to those 13 root nameservers. If
the response had included an authority section, we’d have seen that,
too, after AUTHORITY
SECTION:.
At the very end, dig includes summary information about the query and response. The first line shows how long it took the remote nameserver to return the response after dig sent the query. The second line shows from which host you sent the query and to which nameserver you sent it. The third line is a timestamp showing when the response was received. And the fourth line shows the size of the query and the response, in bytes.
Zone Transfers with dig
As with nslookup, you can use dig to initiate zone transfers. Unlike nslookup, though, dig has no special command to request a zone transfer. Instead, you simply specify axfr (as the query type) and the domain name of the zone as arguments. Remember that you can transfer a zone only from a nameserver that’s authoritative for the zone.
So to transfer the movie.edu zone from wormhole.movie.edu , you can use:
%dig @wormhole.movie.edu movie.edu axfr
; <<>> DiG 8.3 <<>> @wormhole.movie.edu movie.edu axfr
; (1 server found)
$ORIGIN movie.edu.
@ 1D IN SOA toystory al (
2000091402 ; serial
3H ; refresh
1H ; retry
1W ; expiry
1H ) ; minimum
1D IN NS toystory
1D IN NS wormhole
1D IN NS outland.fx
outland.fx 1D IN A 192.253.254.3
wormhole 1D IN A 192.249.249.1
1D IN A 192.253.253.1
wh249 1D IN A 192.249.249.1
shrek 1D IN A 192.249.249.2
toys 1D IN CNAME toystory
cujo 1D IN TXT "Location:" "machine" "room" "dog" "house"
wh253 1D IN A 192.253.253.1
wh 1D IN CNAME wormhole
shining 1D IN A 192.253.253.3
toystory 1D IN A 192.249.249.3
localhost 1D IN A 127.0.0.1
fx 1D IN NS bladerunner.fx
bladerunner.fx 1D IN A 192.253.254.2
fx 1D IN NS outland.fx
outland.fx 1D IN A 192.253.254.3
me 1D IN CNAME monsters-inc
carrie 1D IN A 192.253.253.4
monsters-inc 1D IN A 192.249.249.4
misery 1D IN A 192.253.253.2
@ 1D IN SOA toystory al (
2000091402 ; serial
3H ; refresh
1H ; retry
1W ; expiry
1H ) ; minimum
;; Received 25 answers (25 records).
;; FROM: toystory.movie.edu to SERVER: wormhole.movie.edu
;; WHEN: Fri Sep 22 11:02:45 2000Note that as with nslookup, the SOA record appears twice, at the beginning and the end of the zone. And as with all dig output, the results of the zone transfer are printed in master file format, so you can use the output as a zone datafile if you need to.[*]
dig Options
There are too many command-line options to dig to show here, so look at dig’s manual page for an exhaustive list. Here’s a list of the most important ones, though, and what they do:
- -x address
nslookup is smart enough to recognize an IP address and look up the appropriate domain name in in-addr.arpa, so why not dig? If you use the -x option, dig assumes that the domain name argument you’ve specified is really an IP address, so it inverts the octets and tacks on in-addr.arpa. Using -x also changes the default record type looked up to ANY, so you can reverse-map an IP address with dig -x 10.0.0.1.
- -p port
Sends queries to the specified port instead of port 53, the default.
- +norec[urse]
Turns off recursion (recursion is on by default).
- +vc
Sends TCP-based queries (queries are UDP by default).
[*] Or your vendor’s nslookup has been enhanced to query NIS servers and check /etc/hosts, like the one in HP-UX.
[†] The help function isn’t implemented in BIND 9’s nslookup as of 9.3.2.
[*] BIND 9 nameservers, interestingly, show even the first responses as nonauthoritative.
[*] Actually, early BIND 9 versions of dig (before 9.1.0) are order-impaired and require that you specify the domain name argument before the type. You can specify the server to query anywhere, though.
[*] Though you’d need to delete the extra SOA record first.