Paul Vixie wrote:
Hmmm... If I may be permitted to state my own position, it is that recursive QTYPE=* queries should be treated in a similar fashion to other recursive queries, i.e. that the resolver, if it is willing to provide recursive service to the client, should make a good-faith effort to obtain the requested data, including talking to other resolvers/nameservers if it cannot give a sufficient answer wholly from its cache, and return the answer to said client. This seems rather obvious to me. In contrast, all of the current implementations I'm aware of seem to uniformly *disregard* the RD flag for QTYPE=* queries (which arguably violates RFC 1034 if it still has the nerve to set RA in its responses), treating them in effect as *inherently* non-recursive. The only reasons I've been able to discern for this anomalous behavior are a) a misreading of the query/response examples in RFC 1034 (apparently the text in the Section 6.2 intro about the example queries being RD=0 "Unless otherwise noted" was overlooked), and b) because of some ambiguity/trepidation about the interaction between QTYPE=* and caching, particularly negative caching (it didn't help that the Negative Caching RFC failed to recognize that *every* QTYPE=* response from an authoritative server is veritably a negative response, in *addition* to a positive response when ANCOUNT>0, inasmuch as this combination states that RRsets not included in the response do not in fact exist; this oversight led the RFC to define Negative Caching too narrowly as only being operative for NXDOMAIN or NODATA responses).[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.
Well, even if we disregard all of those old protocol-extension discussions, I think we can all agree, can't we?, that while RFC 1034/1035 may not *require* a robust handling of recursive QTYPE=* queries, certainly those RFCs nor any of the subsequent RFCs *forbid* it. One draconian measure which an implementation could take, without using any "signalling", a "flag day", or whatever, would be to simply ignore what may be in the cache for the name and always fetch a fresh answer to any QTYPE=* query from the authoritative servers (this would be a performance disaster for general use, of course, but might find some sort of niche application somewhere). A slightly less draconian measure would be to cache the results of QTYPE=* queries separately from any other cached RRsets for the same name, with the whole QTYPE=* cache entry expiring if any of the constituent RRsets expire. As far as I can tell, neither of these measures would violate any RFCs, since they are really just caching-policy nuances, which the RFCs typically leave up to implementations.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.)
As long as there is the "legal" possibility of an implementation which handles recursive QTYPE=* queries robustly, then the absolute statements in the draft about how QTYPE=* queries behave non-robustly seem rather precarious to me. If that doesn't bother anyone else, then by all means continue about your business and forget I said anything...
- Kevin
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
