Peter Koch wrote:
On Wed, Aug 20, 2008 at 03:27:15PM +0000, Paul Vixie wrote:
i answered this on namedroppers, where the thread actually belongs.
at the risk of splitting hairs, the three different proposals did not all
strive to change the protocol. Also, this started out from the observation
that ANY queries might be routinely used where they probably shouldn't.
Short of deprectaing QTYPE=* altogether, giving guidance to application
programmers when and (most likely mostly) when not to use ANY might still
be a good thing.
QCLASS=* or ANY is already recommended against in RFC 1123, section 6.1.2.2
and penalized by RFC 1034, section 3.7.1 (must not set AA).
QTYPE=* and QCLASS=* aren't really comparable, in terms of use cases and
practical value.
Non-IN classes have pretty much become extinct since 1034/1035 were
published, yet the range of RR types has grown significantly, thus
making QTYPE=* potentially *more* useful than before (case in point,
obtaining A and AAAA records in a single query).
There are still nagging problems concerning the cache
consistency/coherency of QTYPE=* queries, though (e.g. if one of the
RRsets expires before the others, is the whole QTYPE=* cached RRset
"group" now to be considered invalid?), and those would need to be
clarified or worked around before QTYPE=* could see regular use.
- Kevin
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
