Trying to get full domain info in nslookup

[Kevin Darcy]

Barry Margolin wrote:

>In article <dhcjvd$2i0v$1 at sf1.isc.org>,
> Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>
>  
>
>>Mark Andrews wrote:
>>
>>    
>>
>>>>QTYPE=* (otherwise known as "any") queries are treated by BIND as 
>>>>non-recursive-when-something-is-cached-for-the-name-recursive-otherwise 
>>>>because of a misreading of RFC 1034 that has never been corrected.
>>>>   
>>>>
>>>>        
>>>>
>>>	In your opinion.  Please re-read Section 6.2.2.   It clearly
>>>	show the caching servers returning subsets of records.
>>>
>>>      
>>>
>>In response to a *non-recursive* query, sure. All of the example queries 
>>in Section 6.2.2 are RD=0 unless otherwise noted (see the intro 
>>paragraph at 6.2). Nowhere in 1034/1035 is it permitted to treat an RD=1 
>>query as RD=0 and yet return the response as RA=1, which is what BIND 
>>does. That's just fibbing. Of course, BIND or any DNS implementation for 
>>that matter, can decline to recurse a query but a) this decision should 
>>IMO be policy-driven, not hardcoded for QTYPE=* queries, and b) the 
>>responding server shouldn't *lie* about whether it is honoring recursion 
>>or not. Don't you think it kind of defeats the whole purpose of the RA 
>>bit if responders can set it any way they want, for any arbitrary reason?
>>    
>>
>
>I think this all hinges on the interpretation of step 1 in section 5.3.3:
>
>   1. See if the answer is in local information, and if so return
>      it to the client.
>
>If you have some records for a name in the local information, is that 
>"the answer" to a QTYPE=* query?  It's up to interpretation, so I don't 
>think you can definitively claim that the BIND developers' 
>interpretation is a "misreading".
>
Barry,
          Up until now, the only justification for BIND's behavior that 
I recall being given has been that the examples in Section 6.2.2 show 
partial answers being returned in response to QTYPE=* queries. I think 
I've successfully buried that canard. I agree, though, that this other 
text is subject to interpretation (although I still disagree with Mark's 
interpretation), so in the presence of at least a _plausible_ reading of 
the RFC I'll refrain from calling it a "misreading" from now on.

                                                                         
                                                                        
- Kevin