Subject: QTYPE=* [Re: DNS transport guidelines [Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt]]

From: Pekka Savola <[email-masked]>
Date: Wed, 5 May 2004 07:57:01 +0300 (EEST)

On Tue, 4 May 2004 [email-masked] wrote:
> > Does this need to be stated? As Rob explained, QTYPE=* is a beast
> > that's not really used except by folks playing with "dig" and
> > "nslookup"; the resolvers don't use them, so we might not need to care
> > about them?
> 
> 	dig is the -only- diagnostic tool available so if you
> 	drop or ignore QTYPE=* then you are going to hamper 
> 	DNS operators in their abilities to identify and correct
> 	DNS problems.

Isn't the use of QTYPE=* causing more problems than its worth, being 
unreliable and all that?  Or is it's usefulness precisely restricted 
to identifying what _is_ in the caches (and what is not)?

Note that I was only speaking in the context of this particular
document -- and I thought the effect of using QTYPE=* with or without
A or AAAA RRsets is not sufficiently interesting to be covered in this
document.  I also noticed that results from QTYPE=* become very
unreliable if you'd want to use it to get e.g., AAAA records for the
name where caches only have A records, hence it's not being so useful.

So, let me ask the WG -- 

 1) Should the problems (relavant to AAAA records) and QTYPE=* be
    covered in the document?

 2) Should the problems of QTYPE=* be covered in a separate new 
    document ("QTYPE=* Considered Unreliable" ? :) instead?  Or if 
    not, would an applicability statement be in order?

 3) Should we more or less try to deprecate QTYPE=*, as it does not
    produce reliable results?

Based on this, I personally think 1) probably, 2) fine by me if
someone would volunteer, 3) yes.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Rob Austein <[email-masked]>
Date: Wed, 05 May 2004 04:27:24 -0400

At Wed, 5 May 2004 07:57:01 +0300 (EEST), Pekka Savola wrote:
> ...

<hat co-chair=off just-another-bozo=on>

  2) An applicability statement sounds like a good idea.

  3) QTYPE=* itself should not be deprecated, but non-debugging use of
     QTYPE=* probably should.  See "applicability statement".

</hat>
.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 May 2004 10:49:25 -0400

>to identifying what _is_ in the caches (and what is not)?

This is an ancillary comment, based on the experience of being 
involved in DNSSEC and the longer-than-it-should-have-taken road it 
has travelled.

I'd address this issue like:

A) Don't bother discussing the usefulness of QTYPE=* here.  It isn't 
a v6.  (Debating the value of a feature good "only for 
troubleshooting" is a rat hole.  There's no objective answer.  Ever.)

B) Write the guidelines for IPv6 adoption mindful of all the quirks of DNS.

C) Don't smooth over the hard parts - doing so only creates the 
dreaded "corner cases."  Overly strict "rules" eventually cause 
conflict.  Instead, be loose enough to absorb the shocks of running 
over a rough road.

DNSSEC at first tried to solve for only the normal cases of DNS, as 
well as some cases that were interesting to the security community 
(like alternative chains of trust).  A lot of the delay of the 
security extensions to DNS came from not having enough of an 
understanding of the base protocol.

To address the questions 1,2,3...

1) Personally I don't see QTYPE=* as an oddity, it's just not very 
clear to the causal observer.  I'd not mention in the document 
anything positive, but a warning against assuming that QTYPE=* will 
retrieve both A and AAAA if they both exist.

2) I doubt there's much value is writing another document on QTYPE=*. 
It's defined in 1035 +/- 1, well enough I think.  (It's actually 
QTYPE=ANY, which makes it easier to understand - it's not QTYPE=ALL! 
The latter is the assumption many make.)

3) No - but perhaps we (and I) ought to be clearer and never refer to 
QTYPE=*.  There are times I rely on the ANY QTYPE for debugging.

This is off-thread, but a similar situation holds for the truncation 
discussion.   Ohta's better at it than I, the morale is not to dive 
into a treatise on the additional section for v6 without more 
research on the TC bit settings.  There's a lot already written in 
the topic.  I know - DNSSEC also messed with the rules there. ;)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

If time travel were ever to be realized, public key crypto is toast.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 May 2004 09:00:15 +0300 (EEST)

OK -- let's try to summarize this.

1) let's avoid lengthy rat-holing discussions here,
2) a longer applicability statement might be good, but that's 
independent of this document, and
3) it might be useful to add a short warning of QTYPE=* in this 
document.

I propose adding the following as Section 1.4:

        <section title="Query Type 'ANY' and A/AAAA Records">
        <t>QTYPE=* is typically only used for debugging or management
purposes; it is worth keeping in mind that QTYPE=* ("ANY" queries)
literally return any available RRsets, not *all* available RRsets.
Therefore, to get both A and AAAA records reliably, two separate 
queries must be made.</t>
        </section>

Objections, rewording, ...?

.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 10 May 2004 08:21:55 -0400

>queries must be made.</t>

It's not "QTYPE=*" it's QTYPE=ANY.  And I'd clarify that "any 
available" and "all available" might differ in caches (not in 
authoritative servers).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Mon, 10 May 2004 10:32:55 -0400

At 9:26 -0500 5/10/04, Eric A. Hall wrote:
>Nobody should call it qtype=*, because its not, and because it perpetuates
>the confusion.

I have to issue a "my fault" here as far as the comment.  A qtype of 
"*" is referenced in RFC 1034, an as recently as rfc 2929 (IANA 
consid's).  You're right, Eric, "it's not", but it appears in the 
documents.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 May 2004 09:26:40 -0500

> available" and "all available" might differ in caches (not in 

The distinction can be clarified a bit by pointing out that:

    QCLASS=* is ALL but QTYPE=* is ANY

and that really much of this confusion can be categorized as the ugly
remnants of an ingrained UI-overload condition, where a single wildcard
mask ("*") is commonly used to represent two different actual queries.

.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 May 2004 09:50:30 +0300 (EEST)

> consid's).  You're right, Eric, "it's not", but it appears in the 

I revised the text a bit to bring out this contradiction:

        <section title="Query Type 'ANY' and A/AAAA Records">
        <t>QTYPE=* is typically only used for debugging or management
purposes; it is worth keeping in mind that QTYPE=* ("ANY" queries;  
note that QTYPE=* is the technically correct, though oxymoronic, term)
literally return any available RRsets, not *all* available RRsets, as
only some of these may be present in the caches. Therefore, to get
both A and AAAA records reliably, two separate queries must be
made.</t>

Does this look good?

.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 14 May 2004 20:18:03 -0400

>both A and AAAA records reliably, two separate queries must be
I think it's ill-advised to describe a particular resolver behavior in 
absolute terms when there is nothing in the specs (as far as I know) to 
prevent a future implementation from doing things differently, i.e. from 
always returning *all* of the RRsets in response to a QTYPE=* query. 
Perhaps it would be better to water down the description with "all known 
implementations as of this writing" or something like that...

- Kevin

P.S. In what way is QTYPE=* any more or less "oxymoronic" than QTYPE=ANY?

.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 15 May 2004 07:50:58 +0300 (EEST)

I think we've already closed this topic for this revision, but 
responding in any case, to revise the text if needed for the next 
version..

> implementations as of this writing" or something like that...

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.

If this is not sufficiently clear from the above, could you suggest 
something else e.g., more text on caches to change that? 

> P.S. In what way is QTYPE=* any more or less "oxymoronic" than QTYPE=ANY?

I think '*' is commonly treated as a wildcard, implying "ALL".  
RFC1034 even says "all".  "ANY" can mean less than all :).  It's a 
fine line..

.

---

From: Paul Vixie <[email-masked]>
Date: 15 May 2004 16:08:37 +0000

> the RRsets, so they cannot return all of them, and the user cannot 

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.

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.)
-- 
Paul Vixie
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 17 May 2004 19:00:59 -0400

>present best-efforts result.
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).

>FM and QDCOUNT>1, and turned out to be more complexity than anybody wanted.)
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.

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

.