HP-UX IP Address and Client Management Administrator's Guide HP-UX 11i v2, HP-UX 11i v3

Example 1: No Retransmissions
Debug turned ON, Level 1
datagram from 15.19.10.14 port 4258, fd 6, len 35
req: nlookup(john.dept.inc.com) id 1 type=1 req: found ‘john.dept.inc.com’ as ‘inc.com’ (cname=0)
forw: forw -> 192.67.67.53 6 (53) nsid=29 id=1 0ms retry 4 sec
datagram from 192.67.67.53 port 53, fd 6, len 166
resp: nlookup(john.dept.inc.com) type=1 resp: found ‘john.dept.inc.com’ as ‘inc.com’ (cname=0)
resp: forw -> 15.19.11.2 6 (53) nsid=32 id=1 0ms
datagram from 15.19.11.2 port 53, fd 6, len 119
resp: nlookup(john.dept.inc.com) type=1 resp: forw -> 15.19.15.15 6 (53) nsid=33 id=1 0ms
datagram from 15.19.15.15 port 53, fd 6, len 51
send_msg -> 15.19.10.14 (UDP 7 4258) id=1
Debug turned OFF, Level 1
• In the first group of four lines, a query is received for john.dept.inc.com. The query is
forwarded to a root server, ns.inc.ddn.mil, at address 192.67.67.53
• In the second group of four lines, ns.nic.ddn.mil responds with NS records for inc.com.
• In the third group of four lines, the inc.com server responds with NS records for
dept.inc.com.
• In the fourth group of four lines, the dept.inc.com server responds 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 previous 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)
Because 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. Because the server sent the next query to a root name server, you can 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
“Name Server Debugging” (page 90).
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)
After the response from the root server, the database is searched again. inc.com is found once
again. The next query goes to an inc.com server, so this time there were NS records.
datagram from 15.19.11.2 port 53, fd 6, len
119
This datagram is from another name server because it is from port 53. Because the example server
sent a query to 15.19.11.2, you can assume this is the response.
send_msg -> 15.19.10.14 (UDP 7 4258) id=1
96 Configuring and Administering the BIND Name Service