resolver search order question

[Kevin Darcy]

Well, I guess at this point one option would be to go back to nslookup 
and run it with -debug. The way that it uses the "search" directive 
should be a fairly close approximation to what your system resolver is 
doing. See if it's appending the suffixes you expect, and what responses 
it is getting to those queries.

Alternatively, look at the query logs on the server to see what is being 
queried, and then "dig" those queries to see what the responses are.

                                                                         
                           - Kevin

Norman P. B. Joseph wrote:
> Well, here's the output from "dig":
>
> ------
> % dig +search aj-mail1
>
> ; <<>> DiG 9.2.4 <<>> +search aj-mail1
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13973
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;aj-mail1.ctc.com.              IN      A
>
> ;; AUTHORITY SECTION:
> ctc.com.                900     IN      SOA     server3a.ctc.com. postmaster.ctc.com. 2006052503 10800 1800 2419200 900
>
> ;; Query time: 396 msec
> ;; SERVER: 10.160.17.10#53(10.160.17.10)
> ;; WHEN: Fri May 26 08:14:58 2006
> ;; MSG SIZE  rcvd: 90
> ------
>
> Status says NOERROR.  Is there some other tool or switch or
> debugging/logging option I can use to see more clearly what is occurring
> here?
>
> Thanks,
>
> -norm
>
>
> On Thu, 2006-05-25 at 22:09 -0400, Kevin Darcy wrote:
>   
>> Yes, you are correct, I misinterpreted your question.
>>
>> I just performed a little test here, and it seems that a NODATA response 
>> causes a failover to the next element in the searchlist, just as an 
>> NXDOMAIN would. I don't know why it wouldn't do that in your setup. Have 
>> you confirmed that the response is actually NODATA? I could maybe 
>> understand if it were SERVFAIL, NOTIMP, FORMERR or something like that, 
>> the resolution algorithm might stop dead in its tracks...
>>     
>
>