'dig -t any ...' question

[Barry Margolin]

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.

> 
> >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.

I did notice a change related to that when we upgraded our caching 
servers from BIND 8 to 9.  Prior to that, if I asked for the A record of 
a nameserver, I would often get the address from the glue in the parent 
zone.  After the upgrade, it seemed to go to the authoritative server 
for this -- if all of the zone's servers were down, the query would hang 
and eventually return a SERVFAIL error.  The only way to get the cached 
glue record was to query without the RD flag set.

However, I think ANY queries would still return whatever happened to be 
in the cache, no matter how it was learned.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***