Nslookup Times Out on A Lookup To Well-Known Hosts

[Kevin Darcy]

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.

                                                                         
                     - Kevin

Will wrote:
> >From one of our internal machines, here is what I see when I dig on a domain
> 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 to
> 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 is
> 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
>
>