Subject: Issue: Add a new QTYPE

From: "CTO WEI Renxiang" <[email-masked]>
Date: Wed, 19 Nov 2003 10:09:52 +0800

> issue: Propose to add a QTYPE to support dual-stack host.
> 
> name: Renxiang Yan
> email: [email-masked]
> date:   2003-11-18
> Type: T
> Priority: F
> 
>      Currently, the DNS resolver libraries on  a dual-stack host have to initiates two DNS query 
> for a specific host, one with QTYPE AAAA(or A6), the other with QTYPE A. The disadvantages are: 
>      1. increasing the delay in communication.
>      2. waste network bandwidth.
> 
>     Also, while DNS resolver libraries get two record, it have to decision to filter or order DNS results,
> and this process  have not been specified. 
> 
>     I suppose in this mail to:
>     1. add a new QTYPE ( which could be named "DS", means Dual Stack") to indicate both AAAA (A6) 
> and A record. DNS resolver libraries can initiate just one DNS query to get both IPv4 and IPv6 DNS
> record from DNS server.
>    2.  To promote the IPv6 deployment, DNS results for a dual-stack host returned by DNS resolver
> is suggested to be ordered in IPv6-IPv4.
> 
> R.G.
> Renxiang Yan
>

---

From: bill <[email-masked]>
Date: Wed, 19 Nov 2003 01:13:26 -0800 (PST)

two comments:

	there is not enough functional distinction laid out in the arguments
	to justify a new QTYPE, they are both QUERY's but for different address
	classes.

	there already exists an RR with type "DS" and overloading memnonics
	has never been a good idea.

> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C3AE42.37AD8229
> Content-Type: text/plain;
> 	charset="gb2312"
> Content-Transfer-Encoding: quoted-printable
> 
> 
> >=20
> >=20
> >      Currently, the DNS resolver libraries on  a dual-stack host have =
> to initiates two DNS query=20
> > for a specific host, one with QTYPE AAAA(or A6), the other with QTYPE =
> A. The disadvantages are:=20
> >=20
> >     Also, while DNS resolver libraries get two record, it have to =
> decision to filter or order DNS results,
> > and this process  have not been specified.=20
> >=20
> >     1. add a new QTYPE ( which could be named "DS", means Dual Stack") =
> to indicate both AAAA (A6)=20
> > and A record. DNS resolver libraries can initiate just one DNS query =
> to get both IPv4 and IPv6 DNS
> > record from DNS server.
> >    2.  To promote the IPv6 deployment, DNS results for a dual-stack =
> host returned by DNS resolver
> >=20
> >=20
> ------_=_NextPart_001_01C3AE42.37AD8229
> Content-Type: text/html;
> 	charset="gb2312"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dgb2312">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 6.0.6249.1">
> <TITLE>Issue: Add a new QTYPE</TITLE>
> </HEAD>
> <BODY>
> <!-- Converted from text/rtf format -->
> <BR>
> 
> <P><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">issue: Propose to =
> add a QTYPE to support dual-stack host.</FONT></SPAN>
> </P>
> 
> <P><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">name: Renxiang =
> Yan</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">email: =
> [email-masked]</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">date:&nbsp;&nbsp; =
> 2003-11-18</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">Type: =
> T</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">Priority: =
> F</FONT></SPAN>
> </P>
> 
> <P><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 =
> FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; Currently, the DNS resolver =
> libraries on&nbsp; a dual-stack host have to initiates two DNS query =
> </FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">for a specific =
> host, one with QTYPE AAAA(or A6), the other with QTYPE A. The =
> disadvantages are: </FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 =
> FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; 1. increasing the delay in =
> communication.</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 =
> FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; 2. waste network =
> bandwidth.</FONT></SPAN>
> </P>
> 
> <P><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
> Also, while DNS resolver libraries get two record, it have to decision =
> to filter or order DNS results,</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">and this =
> process&nbsp; have not been specified. </FONT></SPAN>
> </P>
> 
> <P><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; =
> I suppose in this mail to:</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 =
> FACE=3D"Arial">&nbsp;&nbsp;&nbsp; 1. add a new QTYPE ( which could be =
> named &quot;DS&quot;, means Dual Stack&quot;) to indicate both AAAA (A6) =
> </FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">and A record. DNS =
> resolver libraries can initiate just one DNS query to get both IPv4 and =
> IPv6 DNS</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">record from DNS =
> server.</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
> 2.&nbsp; To promote the IPv6 deployment, DNS results for a dual-stack =
> host returned by DNS resolver</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">is suggested to =
> be ordered in IPv6-IPv4.</FONT></SPAN>
> </P>
> 
> <P><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">R.G.</FONT></SPAN>
> 
> <BR><SPAN LANG=3D"zh-cn"><FONT SIZE=3D2 FACE=3D"Arial">Renxiang =
> Yan</FONT></SPAN>
> </P>
> 
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C3AE42.37AD8229--
> 
> --
> 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/>
> 

--
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: Robert Elz <[email-masked]>
Date: Wed, 19 Nov 2003 17:21:38 +0700

Date:        Wed, 19 Nov 2003 01:13:26 -0800 (PST)
    From:        bill  <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	there is not enough functional distinction laid out in the arguments
  | 	to justify a new QTYPE, they are both QUERY's but for different address
  | 	classes.

No, it is clear what is being requested, that's the invention of a meta
query for IP type addresses.   This has been discussed before, meta
queries just don't work if you actually care about the answers (but
are fine if you don't really care - the ANY query is an example, the
proposed query is just a subset ANY really).

The namedroppers archives contain plenty os material on just why meta
queries don't work, so I don't think we need to repeat it all here.

A more feasible (but still not easy) solution to the problem raised,
as much as it actually is a problem, is to do one query with multiple
questions.   That doesn't really work with standard DNS that's deployed,
but can be made to work with suitable levels of EDNS added in (I forget
which EDNSn is required for it nor if it is even agreed yet).

  | 	there already exists an RR with type "DS" and overloading memnonics
  | 	has never been a good idea.

Indeed, but if that were the only issue, fixing it would not be hard...

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 19 Nov 2003 07:28:30 -0600

Jim Reid put out a draft that was useful and promising as I recollect.

> proposed query is just a subset ANY really).

Ah, yeah we have, but QTYPE=ADDR wasn't a subset of QTYPE=ANY.

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

---

From: bill <[email-masked]>
Date: Wed, 19 Nov 2003 09:08:57 -0800 (PST)

> query for IP type addresses.  
> 
...
> which EDNSn is required for it nor if it is even agreed yet).

	or.... one query with multiple, valid replies.  see also (DISCOVER)

> kre

--bill

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 17:18:14 +0000

> queries don't work, so I don't think we need to repeat it all here.

there's meta and then there's meta.  had we specified that AAAA responses
had additional data processing of the form "add any matching A RRsets"
then a single AAAA query, either to an authority or a cache, would give
us all of the data we'd want in one query.  (note that these would be 
added even if the AAAA response set was empty.)

it's not too late for that by the way.

> which EDNSn is required for it nor if it is even agreed yet).

it was part of edns1 as proposed, but that was shot down as "too complex"
because of the other things that had to be optioned (like first match vs.
all matches, and recursive vs. really recursive).

my strong recommendation is still that we include A RR's in the additional
data section of any response to AAAA.  then if clients who want "whichever
exists" or even "both if possible" simply ask for AAAA first, and if they
happen to be talking to an aaaa-additional-a capable server, they can get
what they want in one RTT.  when talking to older servers they still have
to pay two RTTs but that's no worse than today.

---

From: Robert Elz <[email-masked]>
Date: Thu, 20 Nov 2003 01:31:57 +0700

Date:        Wed, 19 Nov 2003 17:18:14 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | my strong recommendation is still that we include A RR's in the additional
  | data section of any response to AAAA.

That might work, if we can get enough servers to actually implement it.
But it is a short term hack, which we'd need to eradicate eventually,
and that's one reason I don't think it is a good idea.

That is it would work now, as in practice, just about everything has an
A record, so you'd either expect to get one, or assume the server is old
and do a second query.

But if/when we reach the state where many names have only AAAA, then
not getting the A just means there isn't one - unless of course, it is
an old server for which we need an extra A query.   The effect of this
is that as the number of A records decreases, the number of A queries
increases.   That's not a good property.

Doing it just this way (and not also saying "add AAAA as additional in
any A query") is also assuming that AAAA is a 2nd class type of address,
and that everyone is really going to need the A that goes along with it.
That's not the message to send either.

So, I wouldn't support this (I actually don't really believe that simply
doing both an A and an AAAA query is all that bad - hosts can prefer one,
and only do the other if the preferred one is NODATA - or they can simply
send 2 queries in parallel, and get back both answers).

Briefly in reply to a couple of other messages ...

Eric - as I recall the ADDR query wasn't quite a subset of ANY, but
to get that more or less abandoned reasonable caching - which is the
real problem with all meta queries, they simply don't play well with
caches, and caches are more important.   In any case, those discussions
are in the archives too...   The point of my original reply was that
the suggested idea is not new, and has never gotten anywhere before.

Bill - I can't even begin to imagine what discover has to do with any
of this.

kre

---

From: Peter Koch <[email-masked]>
Date: Wed, 19 Nov 2003 20:12:42 +0100

> send 2 queries in parallel, and get back both answers).

what one can see at an "edge nameserver" is an amount of queries for AAAA and
A6 which each is around 50% of the number of A queries. That's far higher than
justified by the currently deployed IPv6 base. One "culprit" is a popular
nameserver implementation. Another share is due to the usually lower TTLs
for negative answers. So A stays in the cache, the NODATA for AAAA doesn't.
While I think the multiple-queries-approach deserves some further investigation
I'm not too sure it would help in significantly reducing the number of queries
and thus RTT. There's simply no way to influence the lifetime of a
particular negative response and there's no other way to say "I have no
AAAA for foo.example.com and won't for the next day".

Paul's suggestion to piggy-back the A RRs onto the AAAA responses won't really
help unless the queries are sent non-recursively (to the local resolver/cache).

-Peter

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 19:12:18 +0000

> and that's one reason I don't think it is a good idea.

for it to be a short term hack in need of eventual eradication, there
would have to be a large difference in expected lifetime between "names
for which A RR's exist" and "clients who need A RR's".  i think that
those two lifetimes are in the same rough order of magnitude, and that
by the time you'd be thinking of eradicating it because the additional
data wasn't generally useful, the data itself would go into end-of-life.

> Bill - I can't even begin to imagine what discover has to do with any

agreed.  DISCOVER is about finding servers, not finding answers.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 19:38:11 +0000

> Paul's suggestion to piggy-back the A RRs onto the AAAA responses
> won't really help unless the queries are sent non-recursively (to the
> local resolver/cache).

when a recursive server has no AAAA and so forwards the AAAA query to
an authority, if that authority includes A as additional data then it
will land in the same recursive cache as the AAAA.

---

From: Peter Koch <[email-masked]>
Date: Wed, 19 Nov 2003 20:53:14 +0100

> will land in the same recursive cache as the AAAA.

sure, but if there's no AAAA you learn that from the cache, provided the
NODATA is there. If it is, the A-RRs may be put into the answer packet (out of
the cache) or the application has to query again. Local traffic, no problem.

Now, if there's neither an AAAA (maybe it really doesn't exist) nor a NODATA
(which has expired), you can only learn the NODATA from an authoritative server.
NODATA will expire frequently, so you'll have to ask an authoritative server
again and again, although the A RR will still sit in your cache.

If you first check your cache and use whatever is in there and only ask for
AAAA if the cache is empty (i.e. has neither A nor AAAA), there's lesser RTT
and lesser queries. Obviously for this to work positive TTLs for A and AAAA
need to be the same.

Maybe we should stick AAAA RRs in the additional section for A responses
instead.

-Peter

---

From: Rob Austein <[email-masked]>
Date: Wed, 19 Nov 2003 15:13:28 -0500

> for negative answers. So A stays in the cache, the NODATA for AAAA doesn't.

Another known culprit is a certain (otherwise rather nice) open source
web browser, which apparently includes its own resolver implementation
and which issues not just AAAA but also A6 queries for every new name
it sees in a URL.  (One finds the oddest things running dnstop....)

Point here is not to slam the browser authors, it's to underscore that
even with negative caching there's a limit how much we can hold down
the traffic generated by a busy little dual-stack application.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 19 Nov 2003 14:10:21 -0600

> the suggested idea is not new, and has never gotten anywhere before.

It's true that all of the proposals have gone nowhere, but that's because
they all share the same problem, which is that empty RRsets of alternate
addresses can't be represented in the answer -- you can't give AAAA RRs
and an NXDATA for (non-existent) A RRs in the same answer, so resolvers
are forced to assume that any incomplete answer is truly incomplete,
essentially requiring multiple queries to find out for sure. This problem
exists for qtype=ADDR and just-include alike. If it is explicitly
addressed in either proposal (such as including some kind of flag, or
including an SOA, or whatever), it can also be addressed in the other.

We need to figure out the preferred mechanism for representing incomplete
answers in the zone versus incomplete answers in the cache, and then we
can back-design whatever mechanism we want to use for the query part.

---

From: [email-masked]
Date: Thu, 20 Nov 2003 07:29:17 +1100

One way around this is to publish the IPv4 address as mapped
	addresses in the AAAA records and only look for A records
	if there are no mapped records.  For this to work in the
	long term a cut off date for looking for A records when
	there are no mapped IPv4 addresses in the answer would
	have to be set.

	A zone verifier would check for inconsistancies between the
	A / AAAA records and correct / report them.  Correcting
	could be one of "mapped from A" or "A from mapped" or "add
	missing".

	An UPDATE to a A/AAAA record would perform the corresponding
	change on the other RRset. Delete all A records would delete
	all mapped AAAA records.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Rob Austein <[email-masked]>
Date: Wed, 19 Nov 2003 15:30:33 -0500

> can back-design whatever mechanism we want to use for the query part.

Is it just me, or have others started to wonder whether this thread
feeds back into DNSSECbis Q-21?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 21:06:00 +0000

> ...
> Now, if there's neither an AAAA (maybe it really doesn't exist) nor a
> NODATA (which has expired), you can only learn the NODATA from an
> authoritative server.  NODATA will expire frequently, so you'll have
> to ask an authoritative server again and again, although the A RR will
> still sit in your cache.

but that's how it would be anyway, since these are AAAA queries we're
talking about.  in what way will we have made this case worse?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Nov 2003 20:22:24 -0000

This circle of problems would never have occurred if IPv6 addresses had
simply been returned as 16-byte A records.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Nov 2003 16:12:09 -0500

-----BEGIN PGP SIGNED MESSAGE-----

I'd rather that we just defined a QTYPE of "all" which just returns
everything. Given IPSECKEY and SSHKEY and other possible stuff, this
just makes sense to me. Particularly for the client stub resolver to do.

Special rules about A/AAAA just seem short-sighted to me.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 Nov 2003 23:12:05 +0000

> Special rules about A/AAAA just seem short-sighted to me.

check the working group minutes from DNSIND, where an EDNS1 proposal
was shot down on the basis of complexity around this exact issue.  if
you think we're ready to move forward on multiple qtype matches where
the cache may have only seen one qtype even though others exist, such
that an RRD flag is required to force a fetch against the authority
server, then you're living in a dream world.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 21 Nov 2003 18:51:10 -0500

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

-Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Nov 2003 00:20:08 -0000

Kevin Darcy writes:
> We already have QTYPE=*, but it has been rendered unreliable because BIND

BIND is under no obligation to support your delusions regarding QTYPE=*.
RFC 1034, section 6.2.2, has a clear example of a cache providing _some_
of the SRI-NIC.ARPA records in response to a SRI-NIC.ARPA QTYPE=* query.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 21 Nov 2003 20:51:53 -0500

>of the SRI-NIC.ARPA records in response to a SRI-NIC.ARPA QTYPE=* query.
In response to a *non-recursive* (RD=0) query, yes (see the second 
sentence of the Section 6.2 intro). That doesn't disprove my point in 
the slightest. I certainly wouldn't expect a resolver to provide 
recursion that wasn't requested in the first place...

- Kevin

---

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

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

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.

---

From: Kevin Darcy <[email-masked]>
Date: Sat, 22 Nov 2003 00:22:27 -0500

Paul Vixie wrote:

>recurse.  
Yes, you're correct. My statement swept too broadly. Recursion will 
happen if nothing is cached for the name.

>however, if it has learned an rrset it will return that rrset even
Right, and _this_ is the part that makes QTYPE=* queries too unreliable, 
since the query results might vary depending on the vicissitudes of 
whatever the caching server happens to have cached at what time. 
Granted, there will always be an irreducible amount of "unreliability" 
whenever one takes caching into consideration, but this should not IMO 
extend beyond the TTL constraints of any *given* RRset. What the current 
behavior does is extend the unreliablity of QTYPE=* queries *across* 
RRsets of differing TTL scales (i.e. just because an RRset with a high 
TTL sits in a cache, it inhibits the resolver's ability to fetch other 
RRsets with possibly much smaller TTLs in response to QTYPE=* queries of 
the same name). 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.

>and the working group minutes from DNSIND.
I did dig back through the archives, and saw a message from you 
(<[email-masked] 
<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. As far 
as I can tell, there has been no attempt to clarify QTYPE=* recursivity 
independently of the EDNS1 proposal.

Even having read that old thread, I still don't see the insurmountable 
complexity, in protocol terms, in requiring resolvers to honor their 
recursion obligations with respect to QTYPE=* queries. Either you can 
respond from cached data, or you recurse, same as for any other QTYPE. 
The only complexity that comes to mind is in the implementation's 
housekeeping mechanisms i.e. it needs to keep an independent accounting 
of QTYPE=* queries in order to confirm whether and when 
synthesis-from-cache for subsequent QTYPE=* queries of the same name is 
legitimate. But that is, as they say, merely a matter of programming...

(In the relatively unusual case where a previously-unknown RRset gets 
into the cache before the most recent QTYPE=* pseudo-cache-entry for the 
same name expires (with its expiration to be based on the lowest 
associated RRset's TTL), I'd say just take the conservative approach and 
flush the obviously-invalid pseudo-cache-entry. Folks who rapidly create 
and delete whole RRsets on the fly will just have to tolerate the extra 
traffic this will generate for QTYPE=* queries)

                                                            - Kevin

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 22 Nov 2003 18:07:23 +0900

Kevin Darcy;

> happen if nothing is cached for the name.

What happens if an answer of an empty set for a previous non-wildcard
query is cached for the name?

						Masataka Ohta

---

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
> <http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01448.html>
> 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: 22 Nov 2003 18:17:28 +0000

> query is cached for the name?

this was one of the concerns expressed by the wg when it killed RRD and
QDCOUNT>1.  negative caching gets a LOT more complicated when the query
that produced the cached result has to match the query being answered.
-- 
Paul Vixie

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 24 Nov 2003 22:36:32 -0500

>and all extant implementations are fully interoperable regarding QTYPE=*.
Paul,
         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). Just as partial-RRset answers were outlawed 
in in RFC 2181, partial answers at owner-name level (i.e. with RRsets 
missing) should never IMO be returned to recursive QTYPE=* queries either.

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.

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.

                           - Kevin

---

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!

> 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: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 25 Nov 2003 13:27:26 -0500

</co-chair>
>that is, after all, the defining difference between _de_facto_ standards 

None of the implementations IMHO violate the standard.
QTYPE=* is a debugging tool only.

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

         Olafur

---

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

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

> 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

---

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

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

>| authoritative for SRI-NIC.ARPA, the responses might be:
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.

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

---

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

---

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.

---

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

Paul Vixie wrote:

> if RD=1 QTYPE=* meant what you wish it meant, then this would be used all 

If RD=1 were interpreted as it usually is, the cache would answer from the
results of a previous qtype=* query. So it wouldn't really be useful for
'get me the latest' because the normal behavior would only get the cached
results, not the authoritative data.

---

From: Robert Elz <[email-masked]>
Date: Wed, 26 Nov 2003 16:20:36 +0700

Date:        Tue, 25 Nov 2003 22:59:19 -0500
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

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

What is a "known incomplete answer"?   How can the cache possibly know
whether what is cached is complete or not?   The effect of enforcing the
protocol that you're suggesting should be enforced, is that any QTYPE=* RD=1
query must be sent to an auth server, and the reply forwarded back to the
client - a cache could cache the results, but not for use in any later
QTYPE=* query, only specific queries.

Since caches are a primary object in the DNS, and everything is designed
around making caches effective, it is almost impossible to conceive that
a query that explicitly avoids the cache could possibly have been intended.

If the client wants to defeat caching, let the client talk directly to an
auth server for the name (and do the extra work to find that server).
Explicitly requiring caches to defeat their reason for existing would be
absurd.

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

They're not being dropped, they simply aren't available at the server
queried to ask.   I'm actually somewhat skeptical of having a cache to
a QTYPE=* request of the auth server if it has no data about the name,
I think I'd prefer to have it simply return NODATA in that case (or
NXDOMAIN if it knows the name doesn't exist) - the only real problem
with that would be the possibility of getting a NODATA for a name which
really doesn't exist (or perhaps a NXDOMAIN for a name that does if
that was the selected response to an ANY query for a name not in the cache).

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

Nothing says why it was originally specified, in fact, it isn't clear
that there was any reason at all, other than "this looks nice and easy"
(which turned out to be wrong on both counts - if t hat was the explanation).

I support leaving QTYPE=* defined as it has been implemented everywhere.
Return any data in the server receiving the query (ignoring RD if there
is any such data) - if there is none, then send a non-auth NODATA (or a
referral, I guess, that would be better) (again regardless of RD).
Implementations that choose to honour RD when there is no data are OK,
as from the outside no-one can tell if the data existed before the
query or only after it was received - so returning the answer from a
query is OK (as I guess is an implementation which actually always does
a query of the auth server when RD=1 - though I'd never deploy such
a thing).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Nov 2003 23:29:27 -0000

> QTYPE=* is a debugging tool only.

QTYPE=* can be used to check for CNAME records. RFC 1034 prohibits
non-CNAME records at a name that has a CNAME record, so if QTYPE=*
returns any non-CNAME records then there are no CNAME records.

This is widely used in Internet mail: clients check for CNAME records
and use them to rewrite SMTP MAIL/RCPT commands. Clients that fail to do
this are in violation of RFC 1123.

(In theory, QTYPE=CNAME would also work. In practice, QTYPE=CNAME
triggers an old BIND bug---see http://cr.yp.to/im/cname.html---so
QTYPE=* is the de-facto standard solution.)

All of this is changing. We mail implementors have agreed that this SMTP
rewriting is a bad thing; meanwhile, many DNS proposals violate the RFC
1034 non-CNAME prohibition. So a three-step transition is in progress:

   (1) mail administrators will stop relying on SMTP rewriting; and then
   (2) clients will stop looking specially for CNAME records; and then
   (3) the RFC 1034 non-CNAME prohibition can be safely violated.

In the meantime, however, the statement that ``QTYPE=* is a debugging
tool only'' is simply wrong.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Nov 2003 23:35:40 -0000

Kevin, could you please explain _exactly_ how you think a cache should
handle recursive QTYPE=* queries?

Suppose, for example, that a name has a 3600-second A record and a
60-second MX record. The cache receives a QTYPE=* query for that name.
Two minutes later, it receives another. What happens?

If you're going to use words such as ``incomplete'' in your answer,
please define those words first.

---

From: Robert Elz <[email-masked]>
Date: Thu, 27 Nov 2003 15:59:19 +0700

Date:        26 Nov 2003 23:35:40 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Suppose, for example, that a name has a 3600-second A record and a
  | 60-second MX record. The cache receives a QTYPE=* query for that name.
  | Two minutes later, it receives another. What happens?

Kevin, if you respond to this - also explain what happens when the
cache receives a QTYPE=* query 30 seconds after the initial query
(with all of the same config as above).

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 27 Nov 2003 09:34:48 -0600

> (with all of the same config as above).

Easiest approach to making these queries cachable is to synchronize the
TTLs of all the RRs in the response, and set a flag somewhere that a
qtype=* query was made for the owner name. If there's any RRs for that
name in memory, then you've got all of the RRs.

This wouldn't be the first qtype to require extra processing. Being a
little different doesn't mean impossible.

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 Nov 2003 18:16:11 +0700

Date:        Thu, 27 Nov 2003 09:34:48 -0600
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Easiest approach to making these queries cachable is to synchronize the
  | TTLs of all the RRs in the response, and set a flag somewhere that a
  | qtype=* query was made for the owner name. If there's any RRs for that
  | name in memory, then you've got all of the RRs.

Aside from all the extra mechanism you'd have to assume was existing
in the cache, before you could safely use this, this simply does not
work.

Assuming that all TTLs were already the same (the way people used to make 
master files, with the only TTL setting being the copy out of the SOA.minimum
field), so the cache doesn't have to force it, this still doesn't work.

Let that common TTL be 3600.   Do a query at time X, get all the RR's.
At time X+200 the auth servers all add a new RR to the name queried.
Now, at X+500, send a QTYPE=* query (RD=1) (again) to the cache for
the same name.   Is the new RR included in the reply or not?   If not,
does the answer include all the RR's, as has been demanded that it
include?   If it does, how does it get there?

This problem doesn't exist for normal (single type) queries, as the
TTL is a promise (mostly ignored by admins, but that's not the
protocol's fault) that the data will returned will remain valid for
TTL seconds.   It isn't even a problem for negative answers, as those
include the SOA, and the SOA.minimum is supposed to indicate just how
long you can cache a non-existence report.

But here, we get neither - we have no TTL for the RR (RRset) of the
new RR, so nothing to rely upon.   We have no SOA so no information
on how long we can hand out "doesn't exist" information.

kre

---

From: Bruce Campbell <[email-masked]>
Date: Fri, 28 Nov 2003 17:04:49 +0100 (CET)

On Fri, 28 Nov 2003, Robert Elz wrote:

> the same name.   Is the new RR included in the reply or not?

Assuming the cache has not requeried between X and X+500, the X+200 RR
will not be in the cache or in the answer supplied.

> If not, does the answer include all the RR's, as has been demanded that
> it include?

The answer contains all of the RR's as of the previous time that the cache
queried the auth nameservers (time X), as expected.  For the cache to have
knowledge of RRs added since the previous time, it must have requeried for
the information, thus defeating the purpose of having a cache.

So any answers for QTYPE=* that are fulfilled by a cache are only valid
for when the cache last made that query, and may bear little, if any,
relationship to the current RR set for QTYPE=* returned by the auth
servers.

For situations where there isn't a common TTL, after the expiration of the
shortest TTL, the cache should forget that all those RRs were the result
of QTYPE=* (ie, remove the association between them) and then let them
expire in their own individual time as per normal.

--==--
Bruce.

---

From: Greg Hudson <[email-masked]>
Date: Sat, 29 Nov 2003 01:02:34 -0500

> returns any non-CNAME records then there are no CNAME records.

Pardon my confusion here.  Let's say that we have

  foo.example.com CNAME bar.example.com
  bar.example.com MX 0 baz.example.com
  baz.example.com A 1.2.3.4

If I make a query to a recursive nameserver for foo.example.com MX, I
should see the CNAME and MX records in the answer section, as far as I
know.  I can do my SMTP rewriting by looking at the value of the CNAME
record.  Why do I have to do a * query?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2003 19:05:00 -0000

Greg Hudson writes:
> I make a query to a recursive nameserver for foo.example.com MX
  [ then the response shows whether foo.example.com has a CNAME record ]

That's just as hard to parse as *, sometimes slower, and never faster.
What point are you trying to make?

If you're thinking ``I get the CNAME information for free because I'm
doing an MX query anyway,'' you're correct for RCPT commands---but the
RFC 1123 non-CNAME requirement also applies to MAIL commands.