Installing and Administering Internet Services

110 Chapter 3
Configuring and Administering the BIND Name Service
Troubleshooting the BIND Name Server
• In the third group of four lines, the inc.com server responded with
NS records for dept.inc.com.
• In the fourth group of four lines, the dept.inc.com server responded
with the address of john. The local server responds with the answer
to 15.19.10.14.
Following are detailed explanations of certain lines from the above
example.
Debug turned ON, Level 1
The name server was already running. The first level of debugging was
turned on with sig_named debug 1.
datagram from 15.19.10.14 port 4258, fd 6, len 35
This line shows the IP address of the host that generated the query, the
port that the request comes from, the file descriptor that the name server
received the query on, and the length of the query.
req: nlookup(john.dept.inc.com) ID 1 type=1
This message was logged from the routine that handles requests. Shown
are the name looked up, the packet ID (used to determine duplicate
requests), and the type (as defined in
/usr/include/arpa/nameser.h). Type 1 is an address query.
req: found 'john.dept.inc.com' as 'inc.com' (cname=0)
Since the server is authoritative for div.inc.com, it has an entry for
inc.com in its database. The only data at inc.com is the subdomain
entry for div. This line does not indicate what was found at inc.com.
Since the server sent the next query to a root name server, we conclude
that there were no NS records for inc.com. For more information,
including the domain for which the queried server is authoritative, check
Debug level 3. Debug levels are explained in See “Name Server
Debugging” on page 101
forw: forw -> 192.67.67.53 6 (53) nsid=29 id=1 0ms retry
4 sec
The query was forwarded to 192.67.67.53. The name server tags each
query it sends out so that it can detect duplicate responses. Here the
assigned ID is 29. The original ID was 1. The query will be retried in four
seconds.
resp: found 'john.dept.inc.com' as 'inc.com' (cname=0)