Nslookup Times Out on A Lookup To Well-Known Hosts

Mark Andrews Mark_Andrews at isc.org
Wed Oct 4 00:30:57 UTC 2006 

> Will,
>            You still seem to be focused on SOA records. Why? SOA records 
> are not used in the normal process of iterative resolution. Typically 
> iterative resolution only sends queries for the actual thing it was 
> asked to look up, which is almost always *not* QTYPE=SOA (it's far more 
> likely to be A, MX or PTR), and only looks in the Authority Section of a 
> response if it gets a referral. True, if the lookup ends up with an 
> RCODE=NXDOMAIN result, or a so-called "NODATA" result (i.e. 
> RCODE=NOERROR, but no records in the Answer Section), the SOA in the 
> Authority Section will be used for setting the Negative Caching TTL, but 
> that's only *after* the lookup has already finished. My statement above 
> about the SOA records not being used *in* the resolution process still 
> holds true.
> 
> In the case of cox.net, assuming nothing relevant is already cached, the 
> sequence that a resolver would follow under iterative resolution would be:
> 1. Ask a root nameserver, get a referral to .net
> 2. Ask a .net nameserver, get a referral to ns.cox.net, ns.east.cox.net 
> and ns.west.cox.net (at least that's what I get now, such information is 
> subject to change at any time).
> 3. Ask one or more of those nameservers and get a definitive answer, 
> i.e. either a non-zero number of records in the Answer Section, an 
> NXDOMAIN RCODE, or a NODATA response.
> 
> Note that nowhere in that sequence are any SOA queries generated.
> 
> The +trace option to dig will pretty much execute this sequence 
> automatically for you, although the output is arguably hard to parse, 
> and sometimes certain error conditions cause it to generate unexpected 
> results.

	"dig +trace +all" will show the complete answer to each query.

	Now if you can't get to the nameserver to get their addresses
	(not just the glue) one may need to look at the addresses returned
	by the parent and perform dig queries using those addresses.

	Also the OP mentioned packet traces.  Why wern't they posted?
	When things are going wrong seeing what is happening on the wire
	is useful for debugging.  Descriptions of what is happing on the
	wire often miss critical details.

	Mark

; <<>> DiG 9.3.2-P1 <<>> +trace +all cox.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23226
;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 11

;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			461863	IN	NS	J.ROOT-SERVERS.NET.
.			461863	IN	NS	L.ROOT-SERVERS.NET.
.			461863	IN	NS	B.ROOT-SERVERS.NET.
.			461863	IN	NS	I.ROOT-SERVERS.NET.
.			461863	IN	NS	M.ROOT-SERVERS.NET.
.			461863	IN	NS	E.ROOT-SERVERS.NET.
.			461863	IN	NS	C.ROOT-SERVERS.NET.
.			461863	IN	NS	A.ROOT-SERVERS.NET.
.			461863	IN	NS	G.ROOT-SERVERS.NET.
.			461863	IN	NS	K.ROOT-SERVERS.NET.
.			461863	IN	NS	D.ROOT-SERVERS.NET.
.			461863	IN	NS	H.ROOT-SERVERS.NET.
.			461863	IN	NS	F.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
M.ROOT-SERVERS.NET.	3600	IN	A	202.12.27.33
H.ROOT-SERVERS.NET.	3600	IN	A	128.63.2.53
C.ROOT-SERVERS.NET.	172785	IN	A	192.33.4.12
F.ROOT-SERVERS.NET.	3600	IN	A	192.5.5.241
B.ROOT-SERVERS.NET.	3600	IN	A	192.228.79.201
K.ROOT-SERVERS.NET.	3600	IN	A	193.0.14.129
M.ROOT-SERVERS.NET.	3600	IN	AAAA	2001:dc3::35
H.ROOT-SERVERS.NET.	3600	IN	AAAA	2001:500:1::803f:235
F.ROOT-SERVERS.NET.	3600	IN	AAAA	2001:500::1035
B.ROOT-SERVERS.NET.	3600	IN	AAAA	2001:478:65::53
K.ROOT-SERVERS.NET.	3600	IN	AAAA	2001:7fd::1

;; Query time: 9 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Oct  4 10:25:06 2006
;; MSG SIZE  rcvd: 464

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24319
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15

;; QUESTION SECTION:
;cox.net.			IN	A

;; AUTHORITY SECTION:
net.			172800	IN	NS	A.GTLD-SERVERS.net.
net.			172800	IN	NS	G.GTLD-SERVERS.net.
net.			172800	IN	NS	H.GTLD-SERVERS.net.
net.			172800	IN	NS	C.GTLD-SERVERS.net.
net.			172800	IN	NS	I.GTLD-SERVERS.net.
net.			172800	IN	NS	B.GTLD-SERVERS.net.
net.			172800	IN	NS	D.GTLD-SERVERS.net.
net.			172800	IN	NS	L.GTLD-SERVERS.net.
net.			172800	IN	NS	F.GTLD-SERVERS.net.
net.			172800	IN	NS	J.GTLD-SERVERS.net.
net.			172800	IN	NS	K.GTLD-SERVERS.net.
net.			172800	IN	NS	E.GTLD-SERVERS.net.
net.			172800	IN	NS	M.GTLD-SERVERS.net.

;; ADDITIONAL SECTION:
A.GTLD-SERVERS.net.	172800	IN	AAAA	2001:503:a83e::2:30
A.GTLD-SERVERS.net.	172800	IN	A	192.5.6.30
G.GTLD-SERVERS.net.	172800	IN	A	192.42.93.30
H.GTLD-SERVERS.net.	172800	IN	A	192.54.112.30
C.GTLD-SERVERS.net.	172800	IN	A	192.26.92.30
I.GTLD-SERVERS.net.	172800	IN	A	192.43.172.30
B.GTLD-SERVERS.net.	172800	IN	AAAA	2001:503:231d::2:30
B.GTLD-SERVERS.net.	172800	IN	A	192.33.14.30
D.GTLD-SERVERS.net.	172800	IN	A	192.31.80.30
L.GTLD-SERVERS.net.	172800	IN	A	192.41.162.30
F.GTLD-SERVERS.net.	172800	IN	A	192.35.51.30
J.GTLD-SERVERS.net.	172800	IN	A	192.48.79.30
K.GTLD-SERVERS.net.	172800	IN	A	192.52.178.30
E.GTLD-SERVERS.net.	172800	IN	A	192.12.94.30
M.GTLD-SERVERS.net.	172800	IN	A	192.55.83.30

;; Query time: 298 msec
;; SERVER: 192.58.128.30#53(J.ROOT-SERVERS.NET)
;; WHEN: Wed Oct  4 10:25:07 2006
;; MSG SIZE  rcvd: 510

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36024
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;cox.net.			IN	A

;; AUTHORITY SECTION:
cox.net.		172800	IN	NS	ns.cox.net.
cox.net.		172800	IN	NS	ns.east.cox.net.
cox.net.		172800	IN	NS	ns.west.cox.net.

;; ADDITIONAL SECTION:
ns.cox.net.		172800	IN	A	68.1.16.100
ns.east.cox.net.	172800	IN	A	68.1.16.101
ns.west.cox.net.	172800	IN	A	68.111.106.76

;; Query time: 403 msec
;; SERVER: 2001:503:a83e::2:30#53(A.GTLD-SERVERS.net)
;; WHEN: Wed Oct  4 10:25:07 2006
;; MSG SIZE  rcvd: 134

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21496
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;cox.net.			IN	A

;; ANSWER SECTION:
cox.net.		86400	IN	A	68.1.17.9

;; AUTHORITY SECTION:
cox.net.		86400	IN	NS	ns.west.cox.net.
cox.net.		86400	IN	NS	ns.cox.net.
cox.net.		86400	IN	NS	ns.east.cox.net.

;; ADDITIONAL SECTION:
ns.cox.net.		86400	IN	A	68.1.16.100
ns.east.cox.net.	86400	IN	A	68.1.16.101
ns.west.cox.net.	86400	IN	A	68.111.106.76

;; Query time: 265 msec
;; SERVER: 68.1.16.100#53(ns.cox.net)
;; WHEN: Wed Oct  4 10:25:07 2006
;; MSG SIZE  rcvd: 150

 
>                      - Kevin
> 
> Will wrote:
> > >From one of our internal machines, here is what I see when I dig on a doma
> in
> > we can resolve:
> >
> > [c:\etc]dig @192.168.11.11 -t soa earthlink.net
> >
> > ; <<>> DiG 9.3.2-P1 <<>> @192.168.11.11  -t soa earthlink.net
> > ; (1 server found)
> > ;; global options:  printcmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1071
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> >
> > ;; QUESTION SECTION:
> > ;earthlink.net.                 IN      SOA
> >
> > ;; ANSWER SECTION:
> > earthlink.net.          1800    IN      SOA     itchy.earthlink.net.
> > hostmaster.earthlink.net. 2006092203 3600 300 2592000 1800
> >
> > ;; AUTHORITY SECTION:
> > earthlink.net.          1800    IN      NS      itchy.earthlink.net.
> > earthlink.net.          1800    IN      NS      scratchy.earthlink.net.
> >
> > ;; ADDITIONAL SECTION:
> > itchy.earthlink.net.    154455  IN      A       207.69.188.196
> > scratchy.earthlink.net. 154455  IN      A       207.69.188.197
> >
> > I'm not sure why, but the request for just SOA records above also returns t
> o
> > the name server records, followed by the name server's IP addresses.
> >
> > I issue the same dig command on cox.net, I get a pur timeout with:
> >
> > [c:\etc]dig @192.168.11.11 -t soa cox.net
> >
> > ; <<>> DiG 9.3.2-P1 <<>> @192.168.11.11 -t soa cox.net
> > ; (1 server found)
> > ;; global options:  printcmd
> > ;; connection timed out; no servers could be reached
> >
> > Using a sniffer on the server I am digging to, what I see are cox.net SOA
> > records, and I also see NS records.   I don't put together how those get
> > there, but they do.
> >
> > It's a mystery to me why dig sees nothing for cox.net, when the resolver on
> > 192.168.11.11 is getting at least partial information on the domain.
> >
> > How much of what is being returned above is given to the resolver by the
> > root server (or its equivalent)?   If I could understand how the sequence i
> s
> > supposed to work, and who is responsible for handing out what information
> > prior to contacting the domain's primary name servers, I could check if
> > there is some server
> >
> >   
> 
> 
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email training at isc.org.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org

More information about the bind-users mailing list