'dig -t any ...' question

[Kevin Darcy]

Guido Roeskens wrote:

>Hello,
>
>I thought I've seen a discussion about this on namedroppers before
>http://marc.theaimsgroup.com/?l=namedroppers&m=106920851901151&w=2
>(start of the thread)
>
>
>Kevin Darcy wrote:
>
>  
>
>>Barry Margolin wrote:
>>
>>
>>    
>>
>>>In article <caobi7$1lkv$1 at sf1.isc.org>,
>>>Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>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.
>>>>  
>>>>
>>>>        
>>>>
>>>The server algorithm says that when a query has RD set, the server 
>>>should consult its resolver.  If you read the section on the resolver 
>>>algorithm, it says that if the records are already in the cache it 
>>>doesn't need to query the authoritative server.
>>>
>>>      
>>>
>>Actually, what RFC 1034 says in the resolver algorithm description is 
>>"See if the *answer* is in local information" (emphasis mine). Not just 
>>any old records that happen to be owned by the QNAME, but the *answer* 
>>to the query. I suppose reasonable people could disagree over exactly 
>>what "answer" means in that context, but it seems a rather strange 
>>interpretation to me to say that a recursive resolver can choose to give 
>>the client *less* of an answer than it wanted (note that the description 
>>of the "General Lookup Function" in Section 5.2.1 refers to the client 
>>wanting "*all* of the matching RRs" (emphasis added)), even when a 
>>complete answer is available via recursion, recursion was requested by 
>>the client and the availability of recursion is being advertised by the 
>>recursive resolver via the RA bit. If the client wanted a least-efforts 
>>answer, it wouldn't have set RD=1 in the first place, surely. The 
>>description of the RA flag in the RFCs is not "Recursion Available, 
>>except for QTYPE=* queries, to which I'll give partial answers from 
>>cache if I don't feel like recursing for something better"...
>>
>>    
>>
>In the thread mentioned above someone (I think it's Paul Vixie says
>that QTYPE=* is some sort of debugging aid.
>The problem is how a resolver should know if it has to query the
>authoritative server(s) or not. It would need to keep a record of
>when it last queried the authoritave server for QTYPE=* and set it's
>TTL to the lowest anwer given.
>Or the resolver would need to query the authoritative servers each time
>for the answer, since the QTYPE=* cannot be cached.
>This could overload the server easily or open doors for DOS attacks.
>
I'm not suggesting that QTYPE=* answers be treated as completely 
non-cacheable, nor am I suggesting that QTYPE=* responses be treated as 
"atomic" cache entries that expire with the lowest-valued TTL of all 
included RRsets. The resolver should be able to answer QTYPE=* queries 
entirely from cache, or perhaps by fetching only 1 RRset if only 1 is 
missing, as long as it can provide a "complete" answer to the client, 
which it can construct from RRsets from the original query, from 
subsequent queries, or some combination of the two. I guess one could 
quibble about the exact definition of "complete"...

As for DoS attacks, how is it any more vulnerable than allowing clients 
to make multiple type-specific queries? You could argue, I suppose, that 
QTYPE=* responses are "heavier" than queries for individual record 
types, and thus might fly under the radar of rate-limiters, IDS'es and 
such, which only look at the number of queries. But the counter-argument 
is that the non-robustness of QTYPE=* has, in reality, forced a 
relaxation of those rate-limiter/IDS thresholds, and thus the position 
that robust QTYPE=* treatment leads to "stealth" DoS'es is actually a 
self-defeating one. Make QTYPE=* more robust, and when apps with 
legitimate requirements to fetch records of multiple types are rewritten 
to do so *efficiently* via QTYPE=* instead of separate queries, then you 
can dial down the rate-limiter thresholds to thwart *real* DoS'es, and 
everyone is happy (or at least happier).

- Kevin