[EMAIL PROTECTED] (Pekka Savola) writes:
> QTYPE=* already returns all the RRsets _it knows_. The point is that
> currently there is no mechanism to ensure that caches _do_ know all
> the RRsets, so they cannot return all of them, and the user cannot
> count on it.
in my previous discussions with kevin on this topic, he has suggested
that a cache ought to treat QTYPE=255 (sometimes called * or ANY) as
a read-through operation. in other words, if the cache has data which
it received due to a QTYPE=255 query it should return it, but if it has
no data, or only data received by QTYPE<>255 queries, it should start
a new QTYPE=255 query and then return those results when they're heard.
kevin's suggestion was that the RD flag could control this functionality,
such that RD=1 would cause read-through, whereas RD=0 would yield the
present best-efforts result.
i have never disagreed with kevin that this would be useful, but since
there's no way to know that a remote server is behaving this way (unless
it was signalled through EDNS and new flag bits), it can't really be done.
kevin also once said that he believed BIND was incorrect in its treatment
of QTYPE=255 and that it's possible to read RFC1034/1035 as already
requiring his proposed behaviour. i disagree with that interpretation, but
even granting it for discussion purposes, there is still no way to identify
a server's behaviour ("right" vs. "wrong") due to the size of the installed
base, and to get this behaviour, a new EDNS-based signalling mechanism
would have to be developed.
the question then becomes, is this something that the dns protocol development
community thinks is worth pursuing? in other words, is this functionality
going to yield results worth more than its development/deployment costs?
i believe i know the answer to this, which is either "no" or "hell no"
depending on how one interprets namedroppers@ reactions, both in e-mail and
in meetings, to the RRD bit i once proposed as part of EDNS. (it comes with
FM and QDCOUNT>1, and turned out to be more complexity than anybody wanted.)
--
Paul Vixie
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
