Installing and Administering Internet Services

Chapter 3 147
Configuring and Administering the BIND Name Service
Troubleshooting the BIND Name Server
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 sinceit is from port 53. Since
our server sent a query to 15.19.11.2, we assume this is the response.
send_msg -> 15.19.10.14 (UDP 7 4258) id=1
The response was sent back to host 15.19.10.14 on port 4258.
Example 2: Retransmissions
The next example shows a successful lookup which involved
retransmissions. Retransmissions take place from the resolver and the
name server. The resolver retransmits to the local name server, and the
local name server retransmits to remote name servers during the process
of looking up a name. When the local server receives the resolver
retransmissions, it discards them as duplicates if it is still processing the
first request.
datagram from 15.19.10.14 port 4253, fd 6, len 41
req: nlookup(cucard.med.columbia.edu) id 1 type=1
req: found ’cucard.med.columbia.edu’ as ’edu’ (cname=0)
forw: forw -> 128.9.0.107 6 (53) nsid=17 id=1 1478ms retry 4
sec
datagram from 128.9.0.107 port 53, fd 6, len 212
resp: nlookup(cucard.med.columbia.edu) type=1
resp: found ’cucard.med.columbia.edu’ as ’columbia.edu’
(cname=0)
resp: forw -> 128.59.16.1 6 (53) nsid=18 id=1 0ms
datagram from 15.19.10.14 port 4253, fd 6, len 41
req: nlookup(cucard.med.columbia.edu) id 1 type=1
req: found ’cucard.med.columbia.edu’ as ’columbia.edu’