[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: Add a new QTYPE

O'lafur Gu?mundsson wrote:

</co-chair>
At 22:36 2003-11-24, Kevin Darcy wrote:

The fact that all extant implementations (arguably) violate the standard in the same, interoperable way does not mean the behavior is correct -- that is, after all, the defining difference between _de_facto_ standards and _de_jure_ ones.


None of the implementations IMHO violate the standard.

The standard describes the basic resolver algorithm as a) answer from your cache if you can, or b) if recursion was requested and you're willing to provide it, go get the answer from an authoritative server or upstream resolver. Now, it's hard for me to read into that that a known *incomplete* answer from cache is acceptable to pass back to the client even though a complete answer is available via recursion. As was clarified later, dropping individual RRs from an answer RRset is illegal (except for properly-flagged truncation scenarios), why should it be any more legal to drop whole RRsets from a QTYPE=* response for any reason other than properly-flagged truncation or the fact that the only way to provide the missing RRset(s) would be to recurse, and recursion was either not requested or not available?

QTYPE=* is a debugging tool only.

That is arguably what it has become. I still don't agree that that is what was originally intended or specified.

More importantly, a faithful implementation of QTYPE=* recursivity might rescue that QTYPE from its current state of dubious usefulness (at best) and/or near-obsolescence (at worst), and put an end to all of these new-metatype proposals without the overreaching that EDNS1 represented or was perceived to represent. I can understand why you'd be bitter about how EDNS1 turned out, but that doesn't mean a more modest approach, one that stays within the existing RFC 1034/1035 framework without requiring extensions, can't or shouldn't work.


If you want all the types just ask an authoritative server directly.
There is no need to complicate caches. 

(If you are stuck behind a firewall that does not allow you to bypass the
cache, you are out of luck, but that is a well known problem.

It's not just a matter of connectivity, it's also a matter of resources and capacity. Bypassing one's upstream resolver may consume resources that one's network administrator never expected or provisioned for. Is conserving those resources worth the caching complexity that a robust implementation of QTYPE=* would require? Hard to generalize: in some cases, yes, some cases no. But this is something IMO that each administrator should decide for himself/herself (it's legal for them to simply REFUSE all QTYPE=* queries after all); it shouldn't be decided pre-emptively for them by software-implementation decisions based on questionable interpretations of the RFC.

Also, just because a problem is well known doesn't mean it cannot or should not be solved.

- Kevin




--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>