Subject: Re: Issue: Add a new QTYPE

From: Kevin Darcy <[email-masked]>
Date: Tue, 25 Nov 2003 22:54:12 -0500

Paul Vixie wrote:

>>>there is no way to "clarify" QTYPE=* short of a protocol extension.  the
>>>current behaviour is perfectly well understood and there are no incorrect
>>>implementations of it.  there's no document quality issue around QTYPE=*,
>>>and all extant implementations are fully interoperable regarding QTYPE=*.
>>>      
>>>
>>         The current behavior is fine as long as one puts on blinders with
>>respect to correctness and completeness of answer content. In my opinion,
>>giving out a known-incomplete answer to *any* query, when a complete answer
>>is available via recursion and where recursion was both requested and its
>>availability advertised, is a violation of the spirit if not the precise
>>wording of the standards (and let's face it, RFC 1034&1035 leave a lot to
>>the imagination wrt how QTYPE=* queries are actually supposed to work).
>>    
>>
>
>thanks for your sharing your opinion.  here's mine.  QTYPE=* is a wonderful
>debugging aid designed to let me find out what's in a middlebox cache, much
>better than successive RD=0 queries.
>
Why "successive" RD=0 queries? Even if QTYPE=* recursed properly, you'd 
still have the option of using a *single* RD=0 QTYPE=* query if all you 
want to do is debug a middlebox'es cache. What I've been discussing all 
along is fulfilling the stated need for a way to reliably fetch 
*complete* multiple-RRset answers for a given name in a single 
query/response transaction, preferably without actually extending the 
protocol. An RD=1 QTYPE=* query *can* fulfill and IMO 
*should*always*have* fulfilled that need, regardless of whatever 
debugging capabilities its non-recursive counterpart might possess.

>>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.
>>    
>>
>
>the standard is completely clear on this topic.  you might not agree with
>it but there is no possible reading of 1034/1035 that makes it acceptable
>to do anything other than return whatever partial results are in cache:
>
>| RFC 1034             Domain Concepts and Facilities        November 1987
>| 
>| If a similar query was directed to two name servers which are not
>| authoritative for SRI-NIC.ARPA, the responses might be:
>| 
>|                +---------------------------------------------------+
>|     Header     | OPCODE=SQUERY, RESPONSE                           |
>|                +---------------------------------------------------+
>|     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
>|                +---------------------------------------------------+
>|     Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
>|                |                            A       10.0.0.51      |
>|                +---------------------------------------------------+
>|     Authority  | <empty>                                           |
>|                +---------------------------------------------------+
>|     Additional | <empty>                                           |
>|                +---------------------------------------------------+
>| 
>| and
>| 
>|                +---------------------------------------------------+
>|     Header     | OPCODE=SQUERY, RESPONSE                           |
>|                +---------------------------------------------------+
>|     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
>|                +---------------------------------------------------+
>|     Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
>|                +---------------------------------------------------+
>|     Authority  | <empty>                                           |
>|                +---------------------------------------------------+
>|     Additional | <empty>                                           |
>|                +---------------------------------------------------+
>| 
>| Neither of these answers have AA set, so neither response comes from
>| authoritative data.  The different contents and different TTLs suggest
>| that the two servers cached data at different times, and that the first
>| server cached the response to a QTYPE=A query and the second cached the
>| response to a HINFO query.
>| 
>| Mockapetris                                                    [Page 42]
>
>i dearly wish that every part of The Spec were as clear as this!
>
As I pointed out to DJB, those examples are responses to *non-recursive* 
queries, and thus not particularly relevant to what I'm talking about. 
Use RD=0 QTYPE=* queries to debug caches, and RD=1 QTYPE=* queries if 
you're really serious about getting all of the RRsets owned by the name. 
Unfortunately, there were no RD=1 QTYPE=* examples in RFC 1034, and I 
think that's what led to the implementation confusion.

>>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.
>>    
>>
>
>it's not bitterness.  it's that without a protocol change, there is no way
>for a requestor to signal that it desires "the new behaviour", nor any way
>for a responder to signal that it performed "the new behaviour."  
>
I don't see how any client could be relying on the old behavior, since 
the old behavior is so non-deterministic. Conversely, no client can 
*prevent* a caching resolver from giving it a full answer in response to 
a QTYPE=* query, i.e. the new behavior, so it must already be prepared 
for that contingency. If nothing relies on the old behavior, and the new 
behavior is known to cause no problems, what would be the issue with 
simply switching over to the new behavior, _sans_ signalling or 
versioning or whatnot?

>therefore
>even if the standard weren't clear on this point (but it is!) there would
>be no effective way to fix "the problem" (but there isn't one.)
>
For me, this isn't really about "fix[ing] 'the problem'", it's more 
about realizing the potential of QTYPE=* and using it to head off other, 
arguably ill-advised metatypes, such as the "dual stack" metatype 
proposed by the initiator of this thread...

										- Kevin

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

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 26 Nov 2003 01:18:54 -0600

> proposed by the initiator of this thread...

I agree with you that RD=1 should work as you suggest.

But that wouldn't be better than a 'metatype' as you call it, given that
the answer sets for qtype=* would often be much larger than an answer set
for (say) MX+A, and thus much less efficient.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/