Subject: Re: Issue: Add a new QTYPE

From: Paul Vixie <[email-masked]>
Date: Sat, 22 Nov 2003 02:30:54 +0000

> >Special rules about A/AAAA just seem short-sighted to me.
>
> I tend to agree. We already have QTYPE=*, but it has been rendered
> unreliable because BIND and AFAIK most other implementations never bother
> recursing for QTYPE=* queries (even as they advertise the RA bit to the
> client, natch).

that's just not true.  if a nameserver (bind or any other recursive server)
gets a QTYPE=* query and it has no rrsets cached for that QNAME then it will
recurse.  however, if it has learned an rrset it will return that rrset even
though an authority server might return additional rrsets that the recursive
server has not had occasion to see or store.

> Instead of a new QTYPE, perhaps we just need to tighten up the specs
> to require recursive resolvers to recurse for QTYPE=* queries, when
> necessary (i.e. whenever they are unable to synthesize an answer from
> the cached results of a previous QTYPE=* query).
> 
> Whatever resource/capacity reasons, if any, went into the original
> decisions to emasculate QTYPE=* are probably mooted by EDNS0.

it wasn't resource/capacity, but rather complexity, which took this
functionality off the table.  see http://sa.vix.com/~vixie/edns1.txt,
and the working group minutes from DNSIND.

--
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: Paul Vixie <[email-masked]>
Date: Sat, 22 Nov 2003 16:30:32 +0000

> ... IMO this raises the unreliability of the QTYPE to a whole new
> level, and I think it's why QTYPE=* has been abandoned for the most
> part (e.g. by sendmail), even in situations where it could be a useful
> optimization.

sendmail was incorrect in its usage of QTYPE=* and when they "abandoned"
it, it was to fix the bug in their code where they had used it at all.

> > ... it wasn't resource/capacity, but rather complexity, which took
> > this functionality off the table.  see http://sa.vix.com/~vixie/edns1.txt
> I did dig back through the archives, and saw a message from you
> <http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01448.html>
> admitting that QTYPE=* wasn't really germane ("it was a debugging wish
> rather than an operational expectation") to the RRD-flag part of the EDNS1
> proposal, and a statement of intention that you were going to remove that
> reference from the draft. There was, however, no subsequent published
> revision of the draft, so the verbiage still remains.

the draft is expired.  the DNSIND working group decided to scrap everything
therein.  my offer to pull out RRD was insufficient; the wg wanted the whole
thing killed.

> As far as I can tell, there has been no attempt to clarify QTYPE=*
> recursivity independently of the EDNS1 proposal.

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=*.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 25 Nov 2003 04:52:35 +0000

>          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.

> 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!

> 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."  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.)

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Nov 2003 05:13:56 +0000

> 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...

there is no protocol element that can be used to tell a cache to send
a packet toward an authority server, other than perhaps QTYPE=SOA.  if
RD=1 QTYPE=* meant what you wish it meant, then this would be used all
the time, by applications whose authors "wanted to be certain".

if you propose a new protocol element which bypasses caching in this
way, then implementations will be free to support it or not, and operators
will be free to enable it or not (or rate limit it).