'dig -t any ...' question
Kevin Darcy
kcd at daimlerchrysler.com
Wed Jun 23 00:49:20 UTC 2004
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
More information about the bind-users
mailing list