12.6. 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 name server querying another name
server or transferring zone data.

12.6.1. 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
ondebug 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, since 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.

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 is used to associate a response with a query and
detect duplicate queries or responses. You have to look in the header
flags to see which messages are queries and which are responses. The
stringwant recursion means that this is a recursive
query. The flag is parroted in the response. The string
auth. answer means that this response is
authoritative. In other words, the response is from the name
server'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 datatype 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 name
server 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 name
server records are returned. When a response refers the querier to
some other name servers, those name servers are listed here.

Additional section

The additional records section adds
information that may complete the information included in other
sections. For instance, if a name server is listed in the authority
section, the name server's address may be included in the
additional records section. After all, to contact the name server,
you need to have its address.

For you sticklers for detail, there is a time
when the number of questions in a DNS message isn't one: in
an
inverse query, when it's zero. In an inverse query, there is
one answer in the query message, and the question section is empty.
The name server fills in the question. But, as we said, inverse
queries are almost
nonexistent.

12.6.2. Querying Like a BIND Name Server

You can make
nslookup send out the same query message a name
server would. Name servers' 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 name servers seldom do. Requesting
recursion is the default with nslookup, so you
have to explicitly turn it off. The difference in operation between a
resolver and a name server is that the resolver applies the search
list, and the name server 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 name server, use set norecurse and
set nosearch. On the command line, that's
nslookup -norecurse -nosearch.

When a BIND name server 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 name server responds
that the name doesn't exist or that there are no records of the
type sought. If the name server 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 name server 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 name server
queries the remote name servers in the NS records that it found. When
the name server receives a response from one of the remote name
servers, 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 name servers lower in the
namespace and closer to the answer.

Let's assume for our example that we are trying to satisfy a
recursive query and that we didn't find any NS records until we
checked the gov zone. That
is, in fact, the case when we ask the name server on relay.hp.com about www.whitehouse.gov -- it
doesn't find any NS records until the gov zone. From there we switch servers
to a gov name server and ask
the same question. It directs us to the whitehouse.gov servers. We then switch
to a whitehouse.gov name
server and ask the same question:

Hopefully, this example gives you a feeling for how name servers look
up domain names. If you need to refresh your understanding of what
this looks like graphically, flip back to Figures Figure 2-12 and Figure 2-13.

Before we move on, notice that we asked each of the servers the very
same question: "What's the address of www.whitehouse.gov ?" What do you
think would happen if the gov name server had already cached
www.whitehouse.gov 's
address itself? The gov name
server would have answered the question out of its cache instead of
referring you to the whitehouse.gov name servers. 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 name server 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 name servers that serves a zone
higher up in the namespace, such as a root name server, 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 name servers. What makes this problem hard to track
down is that only one of the "higher up" name servers 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" name server will time
out the old record. If you're pressed for time, you can contact
the administrators of the remote name server and ask them to restart
named to flush the cache. Of course, if the
remote name server is an important, much-used name server, they may
tell you where to go with that suggestion.

12.6.3. 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 just for 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 name servers won't let you pull a copy of their
zones, either for security reasons or to limit the load placed on
them. The Internet is a friendly place, but 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 nslookup s
only show you address and name server records by default, we specify
the -d option to retrieve the whole zone:

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.1.0.