'dig -t any ...' question
Kevin Darcy
kcd at daimlerchrysler.com
Tue Jun 15 00:45:31 UTC 2004
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.
>Note also that the OP has made a big deal about whether it should return
>records with cred=GLUE, but the DNS specification makes no mention of
>credibility levels for cached information. All it says, in section
>5.3.3 (the resolver algorithm, which is used by a server when processing
>a query that has RD set) is: "Step 1 searches the cache for the desired
>data. If the data is in the cache, it is assumed to be good enough for
>normal use."
>
RFC 2181 states "... data from the additional data section, and data
from the authority section of a non-authoritative answer, should not be
cached in such a way that they would ever be returned as answers to a
received query." This applies to QTYPE=* queries just as much as any
other query type.
- Kevin
More information about the bind-users
mailing list