'dig -t any ...' question

[Kevin Darcy]

Barry Margolin wrote:

>In article <calhbv$6ba$1 at sf1.isc.org>,
> Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>
>
>>Barry Margolin wrote:
>>
>>
>>>In article <calb87$2osn$1 at sf1.isc.org>,
>>>Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>>>
>>> 
>>>
>>>
>>>>That's fine and dandy. We all understand that DNS is "loosely coupled", 
>>>>and that caching requires all sorts of tradeoffs and compromises. But I 
>>>>think personally QTYPE=* has been compromised to the point of almost 
>>>>being unusable for its originally-intended purpose.
>>>>   
>>>>
>>>>
>>>Just what *is* that purpose?  I don't see any indication in RFC 1034; no 
>>>real justification is given for its existence.
>>>
>>>
>>RFCs are specification documents, they don't necessarily justify the 
>>existence of every aspect of what they specify. But it seems rather 
>>obvious to me that the purpose of QTYPE=* is to efficiently retrieve all 
>>relevant RRsets owned by a particular DNS name, as opposed to querying 
>>all of those RRsets individually. The way QTYPE=* has been implemented, 
>>however, has rendered it so untrustworthy that very few apps that could 
>>benefit from this efficiency even bother to issue QTYPE=* queries any 
>>more. This is a pity, all the more so because it would be a rather 
>>elegant way to retrieve both A and AAAA records for a given name, and 
>>thus ease the migration to IPv6.
>>
>
>But RFC 1034 included an example of QTYPE=* being sent to caching 
>servers, showing that different servers will return different records 
>based on what they happened to have cached at the time.  So the problem 
>is in the original design, not BIND's implementation.
>
Nope. Those example queries were *non-recursive* as per the following 
text in the Section 6.2 intro:

    Unless otherwise noted, the queries do not have recursion desired (RD)
    in the header. 

Nowhere is there a specific example in RFC 1034 of a response to a 
*recursive* QTYPE=* query, but one would assume, based on generic 
descriptions of recursive resolvers and how they are supposed to 
operate, that a recursive resolver would make its best efforts to get a 
complete answer, which clearly BIND and other implementations do not. 
Frankly, I think the implementors misread the RFC 1034 examples the same 
way you did, and refuse to admit their mistake.

                                                                         
                                    - Kevin