Subject: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt]

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 13 Aug 2002 11:05:37 -0500

Subject: I-D ACTION:draft-hall-qtype-addr-00.txt
From: [email-masked]
To: IETF-Announce: ;
Date: Tue, 13 Aug 2002 07:27:41 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: The ADDR DNS Query-Type
	Author(s)	: E. Hall
	Filename	: draft-hall-qtype-addr-00.txt
	Pages		: 7
	Date		: 12-Aug-02
	
This document defines a DNS query-type for 'all IP address 
resource records,' specifically including any A and AAAA resource 
records which may be bound to the queried domain name. This query-
type would allow IPv6-aware applications to issue a single query 
and determine the capabilities of the remote host, rather than 
having to issue a second query for A resource records in those 
cases where no AAAA resource records are available.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hall-qtype-addr-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hall-qtype-addr-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hall-qtype-addr-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Aug 2002 16:44:47 +0000

> 	Title		: The ADDR DNS Query-Type

please don't.

when rfc1886 was proposed, several of us strongly recommended that "A" RR's
be included as additional data when a "AAAA" query was answered.  in the
same way and for the same reason as we include "A"'s in the additional data
section when answering "MX" or "NS" queries.

we were shot down.  the reason given was "this is only useful during the
transition period to V6, after which it's wasted complexity and wasted
bandwidth."

if you want this functionality, you'll have to answer that objection.
(my answer to this objection was EDNS's ability to ask multiple questions
in a single query, but this was shot down for a separate set of reasons.)

--
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: Tue, 13 Aug 2002 12:04:19 -0500

on 8/13/2002 11:44 AM Paul Vixie wrote:

> when rfc1886 was proposed, several of us strongly recommended that "A"
> RR's be included as additional data when a "AAAA" query was answered.
> in the same way and for the same reason as we include "A"'s in the
> additional data section when answering "MX" or "NS" queries.
>
> we were shot down.  the reason given was "this is only useful during
> the transition period to V6, after which it's wasted complexity and
> wasted bandwidth."

I would agree with that assessment. The argument doesn't apply when it has
been explicitly requested, however.

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Aug 2002 17:10:08 +0000

> been explicitly requested, however.

your proposal makes the request implicit, and runs afoul of the same "this
will still be in use long after the v4->v6 transition is over" problem.  if
we're going to pay in complexity for something like ADDR, then let's pay the
same price but get something way more general.  below, see EDNS1 (expired),
and note that we could very easily excerpt just the parts that deal with
multiple questions in a query and push the rest of the swill into EDNS2 (as
was already done when the original EDNS proposal was split into EDNS0/EDNS1):

--------

   DNSIND Working Group                                         Paul Vixie
   INTERNET-DRAFT                                                      ISC
   <draft-dnsind-edns1-03.txt>                                  June, 1999

                          Extensions to DNS (EDNS1)

   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

   Abstract

      This document specifies a number of extensions within the Extended
      DNS framework defined by [EDNS0], including several new extended
      label types and the ability to ask multiple questions in a single
      request.

   1 - Rationale and Scope

   1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see
   [RFC1035]) which provides for larger message sizes, additional label
   types, and new message flags.

   1.2. This document makes use of the EDNS extension mechanisms to add
   several new extended label types and message options, and the ability to
   ask multiple questions in a single request.

   Expires December 1999                                           [Page 1]

   INTERNET-DRAFT                    EDNS1                        June 1999

   2 - Affected Protocol Elements

   2.1. Compression pointers are 14 bits in size and are relative to the
   start of the DNS Message, which can be 64KB in length.  14 bits restrict
   pointers to the first 16KB of the message, which makes labels introduced
   in the last 48KB of the message unreachable by compression pointers.  A
   longer pointer format is needed.

   2.2. DNS Messages are limited to 65535 octets in size when sent over
   TCP.  This acts as an effective maximum on RRset size, since multiple
   TCP messages are only possible in the case of zone transfers.  Some
   mechanism must be created to allow normal DNS responses (other than zone
   transfers) to span multiple DNS Messages when TCP is used.

   2.3. Multiple queries in a question section have not been supported in
   DNS due the applicability of some DNS Message Header flags (such as AA)
   and of the RCODE field only to a single QNAME, QTYPE, and QCLASS.
   Multiple questions per request are desirable, and some way of asking
   them must be made available.

   3 - Extended Label Types

   3.1. In [EDNS0], the ``0 1'' label type was specified to denote an
   extended label type, whose value is encoded in the lower six bits of the
   first octet of a label, and an extended label type of ``1 1 1 1 1 1''
   was further reserved for use in future multibyte extended label types.

   3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended
   compression pointer, such that the following two octets comprise a
   16-bit compression pointer in network byte order.  Like the normal
   compression pointer, this pointer is relative to the start of the DNS
   Message.

   3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit
   string label as described in [CRAW98].

   3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long
   local compression pointer'' as described in [KOCH98].

   Expires December 1999                                           [Page 2]

   INTERNET-DRAFT                    EDNS1                        June 1999

   4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags
   are structured as follows:

                    +0 (MSB)                            +1 (LSB)
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0: |         EXTENDED-RCODE        |            VERSION            |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      2: |MD |FM |RRD|LM |                       Z                       |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  (As
                   defined by [EDNS0].)

   VERSION         Indicates the implementation level of whoever sets it.
                   Full conformance with the draft standard version of this
                   specification is version ``1.''  Note that both
                   requestors and responders should set this to the highest
                   level they implement, that responders should send back
                   RCODE=BADVERS and that requestors should be prepared to
                   probe using lower version numbers if they receive an
                   RCODE=BADVERS.

   MD              ``More data'' flag.  Valid only in TCP streams where
                   message ordering and reliability are guaranteed.  This
                   flag indicates that the current message is not the
                   complete request or response, and should be aggregated
                   with the following message(s) before being considered
                   complete.  Such messages are called ``segmented.''  It
                   is an error for the RCODE (including the EXTENDED-
                   RCODE), AA flag, or DNS Message ID to differ among
                   segments of a segmented message.  It is an error for TC
                   to be set on any message of a segmented message.  Any
                   given RR must fit completely within a message, and all
                   messages will both begin and end on RR boundaries.  Each
                   section in a multipart message must appear in normal
                   message order, and each section must be complete before
                   later sections are added.  All segments of a message
                   must be transmitted contiguously, without interleaving
                   of other messages.

   FM              ``First match'' flag.  Notable only when multiple
                   questions are present.  If set in a request, questions
                   will be processed in wire order and the first question
                   whose answer would have NOERROR AND ANCOUNT>0 is treated

   Expires December 1999                                           [Page 3]

   INTERNET-DRAFT                    EDNS1                        June 1999

                   as if it were the only question in the query message.
                   Otherwise, questions can be processed in any order and
                   all possible answer records will be included in the
                   response.  Response FM should be ignored by requestors.

   RRD             ``Recursion really desired'' flag.  Notable only when a
                   request is processed by an intermediate name server
                   (``forwarder'') who is not authoritative for the zone
                   containing QNAME, and where QTYPE=ANY or QDCOUNT>1.  If
                   set in a request, the intermediate name server can only
                   answer using unexpired cached answers (either positive
                   or negative) which were atomically acquired using (a)
                   the same QTYPE or set of QTYPEs present in the current
                   question and whose TTLs were each minimized to the
                   smallest among them when first cached, and (b) the same
                   FM and LM settings present in the current question.

   LM              ``Longest match'' flag.  If this flag is present in a
                   query message, then for any question whose QNAME is not
                   fully matched by zone or cache data, the longest
                   trailing label-bounded suffix of the QNAME for which
                   zone or cache data is present will be eligible for use
                   as an answer.  Note that an intervening wildcard name
                   shall supercede this behaviour and the rules described
                   in [RFC1034 4.3.2, 4.3.3] shall apply, except that the
                   owner name of the answer will be the wildcard name
                   rather than the QNAME.  Any of: QTYPE=ANY, or
                   QCLASS=ANY, or QCOUNT>1, shall be considered an error if
                   the LM flag is set.

                   If LM is set in a request, then LM has meaning in the
                   response as follows: If the content of the response
                   would have been different without the LM flag being set
                   on the request, then the response LM will be set; If the
                   content of the response was not determined or affected
                   by the request LM, then the response LM will be cleared.
                   If the request LM was not set, then the response LM is
                   not meaningful and should be set to zero by responders
                   and ignored by requestors.

   Z               Set to zero by senders and ignored by receivers, unless
                   modified in a subsequent specification.

   Expires December 1999                                           [Page 4]

   INTERNET-DRAFT                    EDNS1                        June 1999

   5 - Multiple Questions for QUERY

   5.1. If QDCOUNT>1, multiple questions are present.  All questions must
   be for the same QNAME and QCLASS; only the QTYPE is allowed to vary.  It
   is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.

   5.2. RCODE and AA apply to all RRs in the answer section having the
   QNAME that is shared by all questions in the question section.  AA
   applies to all matching answers, and will not be set unless the exact
   original request was processed by an authoritative server and the
   response forwarded in its entirety.

   5.3. If a multiple question request is processed by an intermediate
   server and the authority server does not support multiple questions, the
   intermediate server must generate an answer iteratively by making
   multiple requests of the authority server.  In this case, AA must never
   be set in the final answer due to lack of atomicity of the contributing
   authoritative responses.

   5.4. If iteratively processing a multiple question request using an
   authority server which can only process single question requests, if any
   contributing request generates a SERVFAIL response, then the final
   response's RCODE should be SERVFAIL.

   6 - Acknowledgements

   Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
   Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton,
   and Michael Graff were each instrumental in creating this specification.

   7 - References

   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
              Specification,'' RFC 1035, USC/Information Sciences
              Institute, November 1987.

   [EDNS0]    P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft
              draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998

   [CRAW98]   M. Crawford, ``Binary Labels in the Domain Name System,''
              Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March
              1998.

   [KOCH98]   P. Koch, ``A New Scheme for the Compression of Domain
              Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt.

   Expires December 1999                                           [Page 5]

   INTERNET-DRAFT                    EDNS1                        June 1999

              IETF DNSIND, March 1998.

   8 - Author's Address

                 Paul Vixie
                    Internet Software Consortium
                    950 Charter Street
                    Redwood City, CA 94063
                    +1 650 779 7001
                    <[email-masked]>

   Expires December 1999                                           [Page 6]


--------

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 13 Aug 2002 12:51:05 -0500

on 8/13/2002 12:10 PM Paul Vixie wrote:

> your proposal makes the request implicit,

explicit

> and runs afoul of the same "this will still be in use long after the
> v4->v6 transition is over"

This is true if the requesting application continues to *DESIRE* both
RRsets long after the transition is complete. If the requesting
application only wants AAAA, then they can query for AAAA only and get
that RRset alone. Nothing is imposed upon them.

You can't say the same for that the ~"just include A" counter-proposal,
which *is* perpetual and uninvited.

> if we're going to pay in complexity for something like ADDR,
> then let's pay the same price but get something way more general.

I agree with this statement in principle. I'll re-read the draft and
comment on it separately.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 14 Aug 2002 14:38:23 -0500

on 8/13/2002 12:10 PM Paul Vixie wrote:

> if we're going to pay in complexity for something like ADDR, then let's
> pay the same price but get something way more general. below, see EDNS1
> (expired), and note that we could very easily excerpt just the parts
> that deal with multiple questions in a query

> be for the same QNAME and QCLASS; only the QTYPE is allowed to vary.
> It is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.
>
> server and the authority server does not support multiple questions,
> the intermediate server must generate an answer iteratively by making
>  be set in the final answer due to lack of atomicity of the
> contributing authoritative responses.
>
> authority server which can only process single question requests, if
> any contributing request generates a SERVFAIL response, then the final

This needs a lot more discussion and fleshing out. Are partial answers
acceptable (as with a cache that has temporarily lost external
connectivity)? Is it possible to indicate positive answers, NODATA and
referrals in the same message? How would the "recursion really desired"
flag interact with all of this?

In general, I think it is a good idea, but I'm not completely convinced
that it's possible. It is not nearly as simple as QTYPEADDR, but it
certainly does offer longer term rewards due to its generalized nature, if
it is feasible at all.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Aug 2002 01:17:06 +0000

> > ...
> This needs a lot more discussion and fleshing out.

i've been waiting several years got someone to discuss this with.  thank you!

> Are partial answers acceptable (as with a cache that has temporarily
> lost external connectivity)?

this depends on the setting of RRD and whether iteration is being done.  if
iteration is being done because the authority server is known not to handle
QDCOUNT>1, then any SERVFAIL causes the underlying QDCOUNT>1 question to be
answered with SERVFAIL.  temporary loss of connectivity signals SERVFAIL.

(i consider the document to already be clear on this point.)

> Is it possible to indicate positive answers, NODATA

yes.  if you get some answer RR's matching some of the QTYPEs but no RR's
matching one or more of the QTYPEs then you know the missing ones are NODATA.

(i will upgrade the wording on this point.)

> and referrals in the same message?

no.  if there are NS RR's then there will be a referral, no matter what other
RR's are also present.  if there are no NS RR's then the answer will not be
a referral, no matter what RR types are present and what QTYPEs are present.

(i will upgrade the wording on this point.)

> How would the "recursion really desired" flag interact with all of this?

only in regards to yout first question above ("partial answers acceptable?")

> certainly does offer longer term rewards due to its generalized nature, if

i'll take that as an invitation to split EDNS1-old into EDNS1-current and
EDNS2-current, where EDNS2-current will be all the stuff in EDNS1-old that's
not directly competitive to QTYPE=ADDR.  (that's how EDNS0 was born and EDNS1
was shelved... but then there was EDNS0.5, appears to be on track to /dev/null)

(done.  updated EDNS1 and EDNS2 are about to be sent to the drafts editor.)

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 14 Aug 2002 23:20:48 -0500

on 8/14/2002 8:17 PM Paul Vixie wrote:

> this depends on the setting of RRD and whether iteration is being done.
> if iteration is being done because the authority server is known not to
> handle QDCOUNT>1, then any SERVFAIL causes the underlying QDCOUNT>1
> question to be answered with SERVFAIL.  temporary loss of connectivity
> signals SERVFAIL.

I realized the error condition about five minutes later, and was wondering
if I'd get pants'd for it. Thanks for keeping the faith alive.

Here is the scenario I want to trip:

  client asks for A, AAAA and MX
  server has A cached
  server has AAAAA NODATA cached
  server has no information about MX and can't/won't go get it

It is possible that the server would have learned A and AAAA through some
other means (such as glue data, although this doesn't really work with the
NODATA part), while also refusing to fetch the MX RR.

Signalling the difference between NODATA and referral is pretty difficult,
since the client would interpret the referral as being applicable to both
AAAA and MX equally. This may be okay, since the only likely harm would be
a larger followup question. Tell me it's okay.

> i'll take that as an invitation to split EDNS1-old into EDNS1-current
> and EDNS2-current, where EDNS2-current will be all the stuff in
> EDNS1-old that's not directly competitive to QTYPE=ADDR.

You lost me. I'll read the new stuff and try to catch up.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Aug 2002 06:31:59 +0000

>   server has AAAA NODATA cached

first off, the promiscuous-cache model practiced by bind4/bind8 is *wrong*,
and glue should not be generally cached nor ever upgraded to an answer.  glue
is like the evil slime that sticks to your shoes in a movie theater, and
should only be reused if to satisfy requirements for additional data during
the marshalling of an answer to the same query whose original forwarding
caused that glue to be received in the first place.

that's not germane to the subject, but i didn't want to let the moment pass.

second, if the client can't or won't go get it, that means the response to a
normal query (QDCOUNT=1, QTYPE=MX) would be SERVFAIL, which according to both
the old (1999) and new (today) EDNS1 documents, would cause SERVFAIL to be
signalled to the QDCOUNT>1 requestor.  so in order to go deeper on this one,
you'll have to explain what you mean, exactly, by "can't" and/or "won't".

> a larger followup question. Tell me it's okay.

it's ok, but not for that reason.  a referral can only come from an authority
server.  the section of the document you are worrying about is talking about
intermediate recursive/caching servers ("full resolvers" in RFC1035 lingo.)

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 15 Aug 2002 09:37:11 -0500

on 8/15/2002 1:31 AM Paul Vixie wrote:

> first off, the promiscuous-cache model practiced by bind4/bind8 is
> *wrong*

It still happens with bind9x. I'll send you a dig-dump offlist.

> second, if the client can't or won't go get it, that means the response
>  to a normal query (QDCOUNT=1, QTYPE=MX) would be SERVFAIL

In the second example, "won't get it" was meant to imply RA=0

---

From: Greg Hudson <[email-masked]>
Date: 15 Aug 2002 19:26:43 -0400

> transition period to V6, after which it's wasted complexity and wasted

That's pretty funny.  God forbid that we should write code which will
only be useful for two or three decades.

(Wasted bandwidth?  It's only wasted bandwidth if there are A records to
return, right?)

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Aug 2002 02:37:27 +0000

> (Wasted bandwidth?  It's only wasted bandwidth if there are A records to

at that time we were in an environment where any one person could say "no"
and have it stick, but no set of people could be found who could say "yes"
and have it stick.

come to think of it, we're still in that environment.  (betcha none of
this matters, we'll have to wait and see what the dns directorate wants
to do, or rather, doesn't want to not do, or however that all works now.)

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Aug 2002 10:23:59 -0500

End-of-thread summary. Based on arguments made so far, a qtype ADDR would
be provably better than the existing qtype ALL, and would also be bettter
than the include-A-with-AAAA alternative.

A qtype ADDR would be slightly better than distinct queries for AAAA
followed by A, although it would be a disadvantage during any transition
period, and the resulting savings are small enough to make the benefit
unworthy of the cost. However, if a sufficient number of people end up
using qtype ALL as an alternative to double lookups, the transition costs
of qtype ADDR will have been worth it.

Paul's proposal for multiple questions is provably better due to its
generalized nature (capable of asking for MX as well as AAAA+A, for
example). That spec doesn't currently address the weird scenarios that can
occur from multiple answer types within a single message so I don't think
it's viable in it's current form. Once those descriptions and rules were
added, however, I would endorse it completely. Under the assumption that
this work will eventually happen, and given that it is more flexible, I
think that's where any subsequent discussion should focus. IMO, of course.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Aug 2002 16:31:54 +0000

> [EDNS1] doesn't currently address the weird scenarios that can occur
> from multiple answer types within a single message so I don't think
> it's viable in it's current form.

I thought that I had addressed your concerns in the rerelease of EDNS1
("August 2002" version) but I stand ready to make any further corrections.
Please let me know what clarifications or changes you think are needed.

Since it's only four pages I will include it here.  Note that this shows
one correction received privately, which was that I hadn't updated the
flags picture to account for the DO bit.  I've also reset the draft name
as directed by the drafts editor.

--------

   DNSIND Working Group                                         Paul Vixie
   INTERNET-DRAFT                                                      ISC
   <draft-ietf-dnsext-edns1-03.txt>                           August, 2002

   Status of this Memo

   Abstract

      This document specifies an extension within the Extended DNS
      framework defined by [RFC2671], providing the ability to ask multiple
      questions in a single request.

   1 - Rationale and Scope

   1.1. EDNS (see [RFC2671]) specifies an extension mechanism to DNS (see
   [RFC1035]) which provides for larger message sizes, additional label
   types, and new message flags.

   1.2. This document makes use of the EDNS extension mechanisms to add the
   ability to ask multiple questions in a single request.

   Expires March 2003                                              [Page 1]

   INTERNET-DRAFT                    EDNS1                     August, 2002

   2.1. Multiple queries in a question section have not been supported in

   3 - OPT pseudo-RR Flags and Options

   3.1. The extended RCODE and flags are structured as follows:

                    +0 (MSB)                            +1 (LSB)
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0: |         extended-rcode        |            VERSION            |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      2: |do |FM |RRD|                         z                         |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   VERSION  Indicates the implementation level of whoever sets it.  Full
            conformance with the draft standard version of this
            specification is version ``1.''  Note that both requestors and
            responders should set this to the highest level they implement,
            that responders should send back RCODE=BADVERS and that
            requestors should be prepared to probe using lower version
            numbers if they receive an RCODE=BADVERS.

   FM       ``First match'' flag.  Notable only when multiple questions are
            present.  If set in a request, questions will be processed in
            wire order and the first question whose answer would have
            NOERROR AND ANCOUNT>0 is treated as if it were the only
            question in the query message.  Otherwise, questions can be
            processed in any order and all possible answer records will be
            included in the response.  Response FM should be ignored by
            requestors.

   RRD      ``Recursion really desired'' flag.  Notable only when a request
            is processed by an intermediate name server (``forwarder'') who
            is not authoritative for the zone containing QNAME, and where
            QTYPE=ANY or QDCOUNT>1.  If set in a request, the intermediate
            name server can only answer using unexpired cached answers
            (either positive or negative) which were atomically acquired
            using (a) the same QTYPE or set of QTYPEs present in the
            current question and whose TTLs were each minimized to the

   Expires March 2003                                              [Page 2]

   INTERNET-DRAFT                    EDNS1                     August, 2002

            smallest among them when first cached, and (b) the same FM and
            LM settings present in the current question.

   4 - Multiple Questions for QUERY

   4.1. If QDCOUNT>1, multiple questions are present.  All questions must
   be for the same QNAME and QCLASS; only the QTYPE is allowed to vary.  It
   is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.

   4.2. RCODE and AA apply to all RRs in the answer section having the

   4.3. If a multiple question request is processed by an intermediate

   4.4. If iteratively processing a multiple question request using an
   authority server which can only process single question requests, if any
   contributing request generates a SERVFAIL response, then the final
   response's RCODE should be SERVFAIL.

   4.5. An authority server processing a query for which QDCOUNT>1 will
   respond with a delegation or referral if any of the multiple QTYPEs
   present would yield such a response when QDCOUNT==1.

   4.6. An initiator can infer the absence of any RRs for one of the QTYPEs
   where QDCOUNT>1 if the response contains no RRs of that type but some
   RRs for one of the other QTYPEs present.

   Expires March 2003                                              [Page 3]

   INTERNET-DRAFT                    EDNS1                     August, 2002

   5 - References

   [RFC2671]  P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671,
              IETF DNSIND, September 1998

   6 - Author's Address

                 Paul Vixie
                    +1.650.779.7001
                    <[email-masked]>

   Expires March 2003                                              [Page 4]

--------

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 23:41:18 +0700

Date:        Mon, 19 Aug 2002 10:23:59 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | End-of-thread summary. Based on arguments made so far, a qtype ADDR would
  | be provably better than the existing qtype ALL,

Two comments on that - first, from 1035, the qtype you mean (value 255) is
* not ALL.   If it is to be represented with a name, using ANY would be a
better, as that's what it actually retrieves.

And second, being better than that qtype (however it is styled) is
precisely equivalent to being better than nothing, as qtype *
doesn't work at all for this, or any other non-debugging purpose.

  | and would also be bettter than the include-A-with-AAAA alternative.

As a summary, I fail to see where that came from.   A a protocol mod
A with AAAA makes little sense.   As an implementation hack it is just
fine (the only issue to be dealt with is making sure implementations can
handle A records in the additional section of a NODATA type response,
ie: one where the rcode==0 and answer count == 0).

Because A with AAAA can be done as an implementation hack, and backed out
the same way, it has essentially no costs.  If we assume that nodes query
for AAAA before A (which most seem to do), then it means just one round
trip to the auth server to load the cache while nodes have A records.
When nodes stop having A records, the benefit will tail away, but then
the AAAA records that were returned will generally be sufficient, and the
later A query will become rare.

  | A qtype ADDR would be slightly better than distinct queries for AAAA
  | followed by A,

I'm not sure about that even.   Look carefully at how a cache would
be supposed to implement ADDR.   If it does an ADDR query, and gets
just AAAA (or just A) records in the answer, how long can it cache the
fact that there were none of the alternative?   There's no SOA in there
from which a negative cache value might normally be taken.   Most probably
it can't add the negative cache at all.   That means that a subsequent query
to the same cache is going to either result in the same ADDR query repeated
(cache effectiveness== 0), or perhaps reading the draft very carefully,
a query for the type that wasn't cached.   Assuming the latter, two queries
to the cache will result in two queries to the auth server, which is
exactly what would have resulted from two AAAA and A pairs of queries to
the cache.   So the only time ADDR could be better is when nodes have both
AAAA and A.

  | although it would be a disadvantage during any transition
  | period, and the resulting savings are small enough to make the benefit
  | unworthy of the cost.

I agree with that part.

  | However, if a sufficient number of people end up
  | using qtype ALL as an alternative to double lookups, the transition costs
  | of qtype ADDR will have been worth it.

I'm not sure if that's suggesting we should do ADDR just in case
someone is dumb enough to try qtype *, or whether it is saying that
after we see people using qtype * we'll be lamenting the lack of
qtype addr.

In either case, since I forsee zero use of qtype * for this purpose,
I don't think it matters.

  | Paul's proposal for multiple questions is provably better due to its
  | generalized nature'

Yes, if we can get that right, we can get plenty of benefits, not just
for IPv6 transition, but all over the place.

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Aug 2002 13:20:06 -0500

on 8/19/2002 11:41 AM Robert Elz wrote:

> As a summary, I fail to see where that came from.   A a protocol mod A
> with AAAA makes little sense.   As an implementation hack it is just
> fine (the only issue to be dealt with is making sure implementations
> can handle A records in the additional section of a NODATA type
> response, ie: one where the rcode==0 and answer count == 0).

No, that's not the only issue. Additional issues include the potential for
message overload which can result from unsolicited extraneous data, and
future potential problems with specifications that have AAAA as additional
section processing. It's a bad idea.

> for IPv6 transition, but all over the place.

Let's move on this, and leave the other options behind, then.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Aug 2002 13:27:08 -0500

> Please let me know what clarifications or changes you think are needed.

As stated earlier, I think it needs a lot more fleshing out. It is
currently underspecified, IMO. I gave you an example of this which
degraded into an argument over what BIND 9 may or may not do, but the
underlying concerns still stand. For any situation where multiple types of
answers can be returned (with any level of feasibility), the handling of
those commingled answer types needs to be described.

Some additional discussion on retry techniques, incomplete cache sets and
so forth would also be nice. When a cache needs to fetch missing answers,
what are the requirements or issues with coordinating TTLs among the
answers, or answer types, for example.

It's just too vague for my liking. This is untested waters and it really
should be fleshed out, overspecified even, to offset the worries.

---

From: Greg Hudson <[email-masked]>
Date: 19 Aug 2002 15:27:54 -0400

On Mon, 2002-08-19 at 14:20, Eric A. Hall wrote:
> message overload which can result from unsolicited extraneous data

This is a previously solved problem.  Any time you might want to put an
RR set in the additional section (for any reason), you check if you will
overflow the packet, and if you will, you don't put the records in.

> and

I don't understand this issue.  Almost anything we do seems like it will
work out okay.  (Putting in A records when you put in AAAA records,
putting in A records only when you don't have any AAAA records to put
in, etc.)

[About multiple queries:]
> Let's move on this, and leave the other options behind, then.

That's reasonable, though if we run into a wall on EDNS1, I think
remembering A-in-additional would be worthwhile.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 Aug 2002 21:13:14 +0000

> ... For any situation where multiple types of answers can be returned
> (with any level of feasibility), the handling of those commingled
> answer types needs to be described.

please quote the unclear portion of the document and suggest an improvement.

> answers, or answer types, for example.

that's all covered in the current document, as far as i can see.  could we
hear additional voices, since eric and i appear to be at a dead end here?

> should be fleshed out, overspecified even, to offset the worries.

one of the things mr. bush tried to tell me during the preparation of 1996
and 2136 was that if you include a lot of tutorial jazz you run the risk of
having your document disagree with itself.  minimalism is best in the core
specification.  if you think a companion document which explains the model
but specifies nothing in and of itself is appropriate, then please write it.

---

From: Robert Elz <[email-masked]>
Date: Tue, 20 Aug 2002 20:31:18 +0700

Date:        Mon, 19 Aug 2002 13:20:06 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | No, that's not the only issue. Additional issues include the potential for
  | message overload which can result from unsolicited extraneous data,

This is simply silly.   First because of Greg Hudson's answer (this is
already a non-problem - at worst it would be equivalent to not implementing
the proposal, and an extra query happens) - but more significantly, if
AAAA and A records aren't going to fit in the same packet, how can ADDR
possibly work (or even a dual query with EDNS1)?   You'd have TC responses
all over the place, which is much worse than "just do an extra query".
In practice, unless you're looking up the NS list for ".", this is just
a non-issue (and that one is an issue for AAAA ignoring the A records...)

  | and
  | future potential problems with specifications that have AAAA as additional
  | section processing.

Huh?   I haven't gone back to check, but I thought that 1886 already
said that anything that requires A additional section processing, also
requires AAAA additional section processing.    And I certainly can't
imagine a specification ever (until A is just a zombie) requiring AAAA
additional section processing without A.

That is, it is already the case, that if you do a MX lookup, and discover
that
	mailsystem.example.com.
is the MX target for some domain or other, you will already get both A
and AAAA records for mailsystem in the additional section (assuming the
server has them to give, of course).

  | Let's move on this, and leave the other options behind, then.

Fine.

Just remember that A with AAAA doesn't require any movement here.   Nothing
has to be specified for that to be done - no protocol work at all.   This
is something that some implementations can simply decide would be a good idea,
and go implement it.   I kind of suspect there's been enough discussion of
it now that any implementors who feel the need can already be doing it.
If none do, that's OK...

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 09:44:08 -0500

on 8/20/2002 8:31 AM Robert Elz wrote:

> significantly, if AAAA and A records aren't going to fit in the same
> packet, how can ADDR possibly work (or even a dual query with EDNS1)?

EDNS can handle a larger message.

ADDR and EDNS both allow the sender to specifically request it, meaning
they can be prepared for it.

A system that does it sometimes but doesn't do it other times and which is
not controllable by the requester and which is undocumented is the worst
of the options.

> Just remember that A with AAAA doesn't require any movement here.

You keep saying this like it's a feature, when sympotmatically it amounts
to a bug.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Aug 2002 16:05:11 +0000

> server has them to give, of course).

we're about to change that with an updated -msgsize- draft.  without EDNS,
there will be no AAAA glue added, either for MX answers or NS referrals.

> Nothing has to be specified for that to be done - no protocol work at
> all.  This is something that some implementations can simply decide
> would be a good idea, and go implement it.  I kind of suspect there's
> been enough discussion of it now that any implementors who feel the
> need can already be doing it.  If none do, that's OK...

some versions of BIND already refuse to upgrade additional data to answers,
meaning that from a caching standpoint, putting AAAA's into the additional
data section of an A answer, or A's into the additional data section of a
AAAA answer, will not save as much network traffic as folks would like.
(eric brought to isc's attention that bind9.2 doesn't get this right, but
let me assure you all that bind9.3 *will* do the right thing in this case.)

---

From: Greg Hudson <[email-masked]>
Date: 20 Aug 2002 12:55:04 -0400

> not controllable by the requester and which is undocumented is the worst

But we already have that for, say, A records in the additional section
of an MX answer.  That's the whole point of the additional section. 
Simply claiming that it is the "worst of the options" isn't a very
strong argument when you can't demonstrate that it's bad.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 12:43:52 -0500

> strong argument when you can't demonstrate that it's bad.

This is not an applicable precedent. The A RRset which is returned in
response to an MX answer is (1) documented by the canonical specification
for MX, (2) can be expected from all servers, (3) can be expected by all
clients, and (4) has additional requirements when truncation occurs which
is also documented in the canonical specification (notably, that the NS
glue takes precedence in the truncated answer).

The just-include approach is not represented by (1), (2), or (3), and can
arguably be claimed not to mesh with (4) although I won't make this
argument at the moment.

> strong argument when you can't demonstrate that it's bad.

I only need to demonstrate that it is worse than qtype ADDR. There are two
arguments in support of this position.

First is that just-include increases the overall complexity because it
puts a burden on the servers without removing a burden from the clients
(the clients cannot rely on the presence of the information since it is
optional, and therefore must either continue issuing multiple queries, or
be tempted to use qtype ANY). Conversely, the qtype ADDR approach puts
complexity on servers but it removes complexity from the client. [both
analysis assume that deployment is widespread]

Secondarily, the nature of an undocumented server-side option makes
pointing to bugs impossible. What if they include the A data but not the
delegation glue in a truncated answer. Where is it written that they would
be wrong to do this? How can we prove otherwise?

[Bonus] DNS is fragile already. Introducing new functionality pretty much
requires that the end-points negotiate extended features. Undocumented
optional extensions which may or may not be present without client having
requested the extension is just begging for trouble. It is the worst
possible option, IMO.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 20 Aug 2002 20:43:38 +0200

> glue takes precedence in the truncated answer).

I'm not sure what the argument is here, but if you mean that a client
can simply assume it will receive A records for mail servers when
asking for MX, I don't think that approach works in the real world.

Consider for instance a server for the zone example.org returning the
MX's for example.org, say mail.foobar.net and www.barfoo.net.  The
server for example.org may not know the IP addresses for
mail.foobar.net and www.barfoo.net, so it doesn't include them.  A
client shouldn't break because of this.  Is this scenario invalid
according to some specification?  Which?

---

From: Greg Hudson <[email-masked]>
Date: 20 Aug 2002 15:00:10 -0400

> glue takes precedence in the truncated answer).

As Simon pointed out, (2) and (3) are false, so you're pretty much left
with (1).  If you want to argue that "just include" should be formally
documented before implementation, then I won't disagree loudly, though I
don't particularly agree either.

> I only need to demonstrate that it is worse than qtype ADDR.

No, you need to demonstrate that it is so much worse than qtype ADDR as
to outweigh the caching problems of qtype ADDR.  (For instance, as kre
pointed out, if you do a qtype ADDR and get only A record replies, how
long can you cache that there are no AAAA records?  There is no SOA, so
you have no idea.)

Even if these problems can be solved, the solution would almost
certainly put a much larger burden on servers than "just include A
records in AAAA queries" does.

> Conversely, the qtype ADDR approach puts

It takes a long time before deployment is so widespread as to allow
clients to stop having to fall back to AAAA and a queries.  About as
long as the IPv6 migration, if that ever happens.

> be wrong to do this? How can we prove otherwise?

(Technically, I don't think the answer would qualify as "truncated.")  I
don't find this issue compelling, but again, I wouldn't disagree with an
effort to document the idea.

> [Bonus] DNS is fragile already.

Not really.  It's an old and bizarre standard, but that doesn't really
make it fragile.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 14:52:35 -0500

> long can you cache that there are no AAAA records?  There is no SOA, so

How is just-include better here? I mean, qtype ADDR can be patched to
include SOA with the statement that the value applies to any missing
RRsets, and since all available RRsets would be returned, a client would
know what that means.

You can't do this with an optional undescribed tag-along service. Missing
RRsets could mean that (1) the data doesn't exist but since there's no
formalized way to indicate NODATA treat it like the cache isn't playing
along, or (2) the cache really isn't playing along. In either scenario the
just-include approach requires a followup query EVERYTIME the data isn't
provided. I would also argue that since clients aren't expecting this data
they will probably throw it away whenever it is provided (the resolver
won't have anything to pass it to or through). The complexity is twice as
large with just-include as it is with qtype ADDR.

> long as the IPv6 migration, if that ever happens.

Granted, which is why I said that qtype ADDR is a wash in comparison to
separate queries. The opposition is using the end-game of pure v6, not me.
Unfortunately for them, the end-game is more efficient with qtype ADDR,
since applications can STOP USING IT and just issue qtype AAAA when they
get there.

> Not really.  It's an old and bizarre standard, but that doesn't really

There are a lot of opportunites for problems, is all. cf the bind 9.2
comment made by paul.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 14:59:00 -0500

>>clients

> asking for MX, I don't think that approach works in the real world.

No, the argument is that clients know that it may be provided, they are
ready for it, they know what to do when it arrives. This is different
mindset from a just-include approach, where the data may show up sometimes
but not others, without being requested.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 20 Aug 2002 22:17:05 +0200

> but not others, without being requested.

MX is almost an just-include approach.  There are no guarantees it
will happen.  The application must be ready to query for MX's
addresses.  If the server happens to include some IPs in the first
reply, the application may optimize things and use that data, although
prudent resolvers may not want to do so anyway in some cases (think
cache corruption).

The only difference I can see is that there is text in a specification
suggesting servers to include A records when returning MX, to allow
for this optimization.  A similar recomendation for A/AAAA could be
written, and would perhaps even be a good idea -- I'm annoyed by the
doubled DNS delays in modern applications (queries for both A and
AAAA).  IMHO this path seems easier to get to work than a new QTYPE.

---

From: David Terrell <[email-masked]>
Date: Tue, 20 Aug 2002 16:09:25 -0700

> but not others, without being requested.

Can you posit or demonstrate a scenario where an application doing
a lookup for AAAA and getting an A record in the extra section would
be harmful?  Assuming we're specifying new, optional behavior and
that as always they can fall back to a second A query (as is done
today) -- the ADDR query seems more harmful, as it will result in
THREE round trips in the likely case of a remote resolver not
supporting it (one error, one AAAA, one A).  A in the extra data
results in no additional round trips if it's not supported.

What happens if you make an EDNS1 multiple question query and the
remote side (forwarder or authoritative server) doesn't support
ENDS1?  Three round trips?  That doesn't seem like a reasonable
upgrade path.

-- 
David Terrell            | Q. Is C an acronym? 
[email-masked]             | A. Yes, it stands for ``C''. It's another
Nebcorp Prime Minister   |    of those funky recursive acronyms.
http://wwn.nebcorp.com/  |  - "Infrequently asked questions in comp.lang.c"

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Aug 2002 19:37:57 -0500

on 8/20/2002 6:09 PM David Terrell wrote:

> Can you posit or demonstrate a scenario where an application doing a
> lookup for AAAA and getting an A record in the extra section would be
> harmful?

Again, I only have to prove that it is the worst.

> Assuming we're specifying new, optional behavior and that as always they
> can fall back to a second A query (as is done today)

Correction, will almost certainly always fallback, since even in those
situations where the A RR was provided, the application won't have
expected it. Heck, some resolvers may not even pass it along to the
application since it wasn't part of the question. The leftover benefit is
that the cache will have the data on hand to issue the next query, but
this by itself does not make anything operate more efficiently. Remember,
this is the scenario at peak deployment, and not just during deployment,
since this is being flogged as voluntary.

> ADDR query seems more harmful, as it will result in THREE round trips
> in the likely case of a remote resolver not supporting it (one error,
> one AAAA, one A).

> remote side (forwarder or authoritative server) doesn't support ENDS1?
> Three round trips?  That doesn't seem like a reasonable upgrade path.

During deployment yes, at peak no. We have deployed new RRs before (MX).
We are early enough into the IPv6 deployment to do this.

---

From: Robert Elz <[email-masked]>
Date: Wed, 21 Aug 2002 14:21:55 +0700

Date:        Tue, 20 Aug 2002 12:43:52 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I only need to demonstrate that it is worse than qtype ADDR.

No you don't, as they're not alternatives.   We could do ADDR, if we
thought it worth the effort, and still have servers supplying A when
they get an AAAA query.   If ADDR really took off, then there would be
essentially no AAAA queries, so it wouldn't matter one way or the other.
On the other hand, if clients don't bother implementing ADDR, because
it means an extra RTT waiting for the NOTIMPL error, because relatively
few deployed servers support it, then the AAAA+A approach can have some
benefits.

You can't just assume full (or close to it) deployment - there has to be
an implementable path to get us there.   That is, you somehow have to
convince resolvers to start doing ADDR queries while few servers
support the thing, otherwise they'll never appear (upgrading servers
takes a long time, upgrading resolvers takes an eternity).

  | First is that just-include increases the overall complexity because it
  | puts a burden on the servers without removing a burden from the clients

True, as has been stated before - but the aim of all of this is to
reduce the burden on the network, not on either implementation.  DNS
servers and resolvers are complex beasts now, the extra complexity to
add in A's is negligible (the code for it already exists, it just
needs to be run in one more case).   The resolver better be able to
handle the answer already, even if it just means ignoring the A's.
If resolver implementors start to see that A's are appearing with the
AAAA replies, then they will take advantage of that.

  | Conversely, the qtype ADDR approach puts
  | complexity on servers but it removes complexity from the client. [both
  | analysis assume that deployment is widespread]

Unless you assume universal deployment (which will not happen) the client
still has to be able to deal with the one old server out there which does
not implement ADDR, so it still needs the fallback logic.

  | Secondarily, the nature of an undocumented server-side option makes
  | pointing to bugs impossible. What if they include the A data but not the
  | delegation glue in a truncated answer. Where is it written that they would
  | be wrong to do this? How can we prove otherwise?

If the specs say that the delegation info should be provided, then it
should be.   If there is available glue for that, it can be included as
well, but in one of these queries, it never has to be, and in general,
is completely useless anyway.   That is needed in referals, it isn't
otherwise.

I just did an AAAA lookup for munnari.oz.au.   It happens that I got
an AAAA answer, and I got A records for munnari.oz.au in the additional
section.   (You might even imagine a server that was implemented by
someone with lots of foresight, as the server there hasn't changed since
well before this idea was floated...)

Of course, the reason for those particular A records is that munnari.oz.au
is in the NS list for itself, so the A records were part of the delegation
glue.   But, not all of the delegation glue A records were provided.
oz.au has 4 servers, there were addresses in the answer I received for only
3 of them (I am doing this query from nowhere near munnari, so this is the
kind of thing that anyone else would see).

The A records in the answer don't seem to be breaking anything... (whether
or not resolvers take any notice is a different issue).   The lack of
the glue record for the 4th server breaks nothing.

For the record, here is the answer...

; <<>> DiG 8.3 <<>> munnari.oz.au. aaaa 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6
;; QUERY SECTION:
;;      munnari.oz.au, type = AAAA, class = IN

;; ANSWER SECTION:
munnari.oz.au.          10M IN AAAA     2001:388:c02:4000::1:21

;; AUTHORITY SECTION:
oz.au.                  1d6h49m59s IN NS  mulga.cs.mu.oz.au.
oz.au.                  1d6h49m59s IN NS  dmssyd.nsw.cmis.CSIRO.au.
oz.au.                  1d6h49m59s IN NS  munnari.oz.au.
oz.au.                  1d6h49m59s IN NS  ns.UU.NET.

;; ADDITIONAL SECTION:
mulga.cs.mu.oz.au.      7h24m23s IN A   128.250.1.22
mulga.cs.mu.oz.au.      7h24m23s IN A   128.250.37.150
dmssyd.nsw.cmis.CSIRO.au.  5h36m14s IN A  130.155.16.1
munnari.oz.au.          1d6h49m59s IN A  128.250.1.21
munnari.oz.au.          1d6h49m59s IN A  128.250.22.2
munnari.oz.au.          10M IN AAAA     2001:388:c02:4000::1:21

;; Total query time: 475 msec
;; FROM: delta.cs.mu.OZ.AU to SERVER: default -- 172.30.0.9
;; WHEN: Wed Aug 21 14:13:23 2002
;; MSG SIZE  sent: 31  rcvd: 279

(and yes, this was done from deep inside a NAT'd area of the net, so the
local cache has a 1918 address...)

[Aside: the AAAA glue record there looks like a bug, I thought the
practice of repeating answers in the additional data section had been
squashed long ago...]

  | [Bonus] DNS is fragile already.

What fragility the DNS has all comes from configuration problems
(in the past some from implementation bugs, but that's less common now).
Nothing here is changing anything related to how operators run their
DNS servers, so nothing is likely to impact on whatever fragility you're
seeing.

There are two arguments that an implementor might choose to use for
not bothering to implement this (aside from just "I can't be bothered"
which is OK too).

One is based upon Paul's comment - if you believe that caches aren't
going to remember the A records, then the potential benefit drops.
It doesn't vanish though - the answer (complete with additional info)
will still get sent back to the requesting client.   In cases where
the same info is requested again, the cache won't have the A's, and
will need to fetch them.   The cache is less effective than it could
be, but we still get just 2 queries out of the cache, for data which
is apparently being required multiple times.

On the other hand, if it is a one off (queries needed less frequently
than the TTL of the RRs) then what the cache does is immaterial anyway,
and getting the A along with the AAAA could halve the number of these
queries to the remote servers.

That's going to mean there's a judgment issue, and once again, implementors
get to decide what they want to do (and then users get to decide which
server they will deploy).

The second reason why one might not bother with implementing this is
more compelling though I think, but it depends upon the behaviour of
resolvers.   Currently, I believe, most resolvers end up doing an AAAA
query, and then when that fails (no AAAA records are returned, I don't
mean NXDOMAIN or similar) they retry with an A query.   That means
2 RTT's to get the answer (three if they start with ADDR...).
If that's what ends up being "normal" then AAAA+A looks attractive.

On the other hand, resolvers could issue the AAAA and A queries more
or less simultaneously (two queries one after the other, I don't mean
EDNS1 here).   If that's what resolvers do, so they get the answer
back in 1 RTT, then AAAA+A is useless, the AAAA answer with A records
would only get back at about the same time as the A answer anyway.

But in any case, I have no idea why you're bothering to argue against
this.   Implementors will make their own decisions (probably based upon
customer demand).

kre

---

From: Markku Savela <[email-masked]>
Date: Wed, 21 Aug 2002 11:37:21 +0300

> From: Robert Elz <[email-masked]>

> section.

Instead of additional section, why not my other proposal: return IPv4
addresses in AAAA query as IPv6 addresses (ipv4 mapped format).

- there would be no problems with caching servers

- the answer set is always complete (the same DNS server will always
  have both A and AAAA data for the same name)

- there would be issue about what would current IPv6 implementations
  do, if IPv4 mapped addresses are returned for AAAA. I know mine
  would work just fine (as I already internally represent all IPv4 as
  IPv4-mapped). How about KAME? Microsoft?

AAAA query is relatively new and IPv6 stacks are still in developement
stage (and must be upgraded in near future anyway, becuase apparently
there are several drafts or changes in the pipeline, that will become
mandatory standards.. although I don't like some of them :-)

Thus, the handling of AAAA query could easily be changed to cope with
IPv4 mapped addressess, and to cope with existing old DNS

 - if host needs IPv4 address and AAAA reply didn't contain any IPv4
   addresses, it could issue the normal A query too.

 - further optimization, there could also be some flag or signal in
   the reply, that would say "there are no IPv4 addresses, there is no
   point trying A"

These are about the last moments to act on this. Very soon cell phones
will have IPv6 stacks and there will be millions of nodes doing
queries in some way, which will hard to change after the fact...

---

From: Robert Elz <[email-masked]>
Date: Wed, 21 Aug 2002 16:40:05 +0700

Date:        Wed, 21 Aug 2002 11:37:21 +0300
    From:        Markku Savela <[email-masked]>
    Message-ID:  <[email-masked]>

  | Instead of additional section, why not my other proposal: return IPv4
  | addresses in AAAA query as IPv6 addresses (ipv4 mapped format).

I think this has the same problem as all of the proposals to have
server created on the fly RR data - it doesn't work at all well with
dnssec.

Not certain about Microsoft, but KAME doesn't much like IPv4 mapped
IPv6 addresses I believe, and avoids them wherever possible... (one of
the KAME people might correct that if I'm wrong).

But if we really thought ...

  | Thus, the handling of AAAA query could easily be changed to cope with
  | IPv4 mapped addressess, and to cope with existing old DNS

I think we would have thought the same about A6, but apparently we
didn't...   (even the most ardent A6 supporters had given up on the
possibility of having the clients ever use it - already too late).

I don't follow the cell phone industry, but are they planning to put
dual stack in their phones, os just IPv6.   It is such a specialised
market, and such a large one, that they could do v6 alone, and force the
rest of the world that cares to communicate to simply support v6.

Doing v4 would require NAT, which would seem to be very ugly for mobile 
devices.

If they're only doing v6 then they're just going to want AAAA queries,
and methods to get A answers to them simply wouldn't matter.   If...

kre

---

From: Markku Savela <[email-masked]>
Date: Wed, 21 Aug 2002 13:14:56 +0300

> rest of the world that cares to communicate to simply support v6.

Currently there is no IPv6 in real use, but there is GPRS with iPv4. Thus
support for IPv4 is required. Future plans apparently call for IPv6,
thus that too must be supported.

So, by default the dual stack is the way to go, it will work in both
or mixed environments.

---

From: Derek Atkins <[email-masked]>
Date: 21 Aug 2002 10:39:40 -0400

> addresses in AAAA query as IPv6 addresses (ipv4 mapped format).

Dynamic construction of responses: BAD.  How do you sign it?

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Aug 2002 16:09:47 +0000

> addresses in AAAA query as IPv6 addresses (ipv4 mapped format).

Synthetic data is very touchy.  Those mapped AAAA's would have to have TTL=0,
for example, which would mean the whole AAAA RRset would be minimized to TTL
0.  I don't think this situation calls for synthetic data.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Aug 2002 16:06:04 +0000

> they get an AAAA query. ...

Gentlemen, you have both been heard to say that the EDNS1 ("QDCOUNT>1")
solution appeared viable and would be a good generic solution to this
problem.  Could we do a little deeper into that topic, and let the
alternatives ("just send A" and QTYPE=ADDR) drop for now?

Who thinks EDNS1 isn't ready for last call?  OK, state your issues --
that is, tell us all how the document should be improved.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Aug 2002 16:58:39 +0000

> that is, tell us all how the document should be improved.

here are some proposed changes which came to me privately:

60,62c60,62
< This document specifies a number of extensions within the Extended DNS
< framework defined by [EDNS0], including several new extended label types and
< the ability to ask multiple questions in a single request.
---
> This document specifies an extension within the Extended DNS framework defined
> by [RFC2671], providing the ability to ask multiple questions in a single
> request.
88c88
< 2: |md |FM |RRD|lm |                       z                       |
---
> 2: |do |FM |RRD|                          Z                        |
94c94
< both requestors and responders should set this to the highest level they
---
> both initators and responders should set this to the highest level they
96c96
< requestors should be prepared to probe using lower version numbers if they
---
> initiators should be prepared to probe using lower version numbers if they
104c104,105
< the response.  Response FM should be ignored by requestors.
---
> the response.  Response FM should be set to zero by responders, and ignored
> by initiators.
113c114,115
< same FM and LM settings present in the current question.
---
> same FM setting present in the current question.  Response RRD should
> be set to zero by responders, and ignored by initiators.
144,146c146,148
< 4.6. An initiator can infer the absence of any RRs for one of the QTYPEs
< where QDCOUNT>1 if the response contains no RRs of that type but some RRs
< for one of the other QTYPEs present.
---
> 4.6. If request FM was not set but QDCOUNT>1, then an initiator can infer the
> absence of any RRs for one of the QTYPEs if the response contains no RRs of
> that type but some RRs for one of the other QTYPEs present.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 22 Aug 2002 02:26:56 +0900

>>>>> On Wed, 21 Aug 2002 11:37:21 +0300, 
>>>>> Markku Savela <[email-masked]> said:

>> an AAAA answer, and I got A records for munnari.oz.au in the additional

In general, I think this idea is problematic.  Some people have

> - there would be no problems with caching servers

I'm not really sure about this.  Caching servers also (may) ask AAAA
RRs by themselves to follow referrals, and the answers would affect
their behavior.

>   IPv4-mapped). How about KAME? Microsoft?

I've not tested it, but according to the code, our getaddrinfo() built
with normal installation procedure seems to reject AAAA RRs that
specify IPv4-mapped IPv6 addresses.

I don't know much about Windows, but in my understanding, (at least
some previous versions of) winsock does even not have the support of
IPv4-mapped addresses (as described in RFC 2553).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Rob Austein <[email-masked]>
Date: Wed, 21 Aug 2002 13:53:54 -0400

> that is, tell us all how the document should be improved.

Apologies if this is already covered and I missed it (am a bit fuzzed
out by the head cold of the month), but don't QDCOUNT values greater
than one have the same general deployment problem as EDNS0 extended
labels?  That is, don't you have to upgrade every name server in the
resolution chain at least to EDNS0 before you can stop worrying about
getting back RCODE=1 ("Format Error")?  So we immediately run up
against the question of whether the problem we'd be solving is
important enough to be worth this kind of upgrade effort.  Yes I know
there are other reasons (eg, IPv6, DNSSEC) why old DNS software ought
to be upgraded anyway, but let's get all the issues out on the table.

On the plus side, the general approach here does at least attempt to
deal with the naming granularity problem directly, so I agree that
it's worth discussing in some detail whether we conclude that it's the
right answer or not.  I think, however, that it'd be premature to last
call this, because I don't think we yet have a crisp statement of the
problem we're trying to solve.

Backing up a bit to a more abstract level in an attempt to start down
the path towards a crisp problem statement: I think that, broadly
speaking, we have two choices when talking about the general issue of
applications that expect to need multiple RRsets with the same owner
name in quick succession:

1) We can take the approach that the application just asks for
   whatever specific RRset it needs, one RRset at a time, and assume
   that the DNS caching mechanism will do whatever it does but that
   optimization of the query process is not the client's problem; or

2) We can use an approach like what Paul is proposing in EDNS1 to let
   the client be more explict about what data it expects to need in
   the immediate future.

It would probably be worth reviewing the archives from the last time
that this draft came around; I don't know that there's anything there
that's particularly relevant to this discussion, but I'd rather learn
from history than loop.

Last, a nit in the current EDNS1 draft: the EDNS1 draft refers to the
LM flag, which is defined in the EDNS2 draft.  Based on what I think I
remember of Paul's theory about how the general EDNS framework should
evolve, I'd guess that this is just an editing oversight rather than a
deliberate cross dependency, but it would be good to confirm that.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 21 Aug 2002 20:00:46 +0200

>> that type but some RRs for one of the other QTYPEs present.

This does not rime well with DNSSEC.  How about the following?

  4.6. If request FM was not set but QDCOUNT>1, then an initiator can
  infer the absence of any RRs for one of the QTYPEs if the response
  either contains no RRs of that type but some RRs for one of the
  other QTYPEs present, or contains NXT/SIG RRs that indicate the
  absence of RRs of the QTYPE, depending on local security policy.

I don't find any discussion of how the additional field is populated
by intermediate servers.  Say I query for (foo.example.org, IN, MX
CERT), will the intermediate add any additional A records returned for
the MX query to the initial client?

---

From: Markku Savela <[email-masked]>
Date: Wed, 21 Aug 2002 21:25:07 +0300

> From: Paul Vixie <[email-masked]>

> 0.  I don't think this situation calls for synthetic data.

I was not proposing "synthetic data". What I proposed, can be
simulated manually using current name servers without any change as
follows:

  - when you enter A record for address 1.2.3.4, you also enter AAAA
    record for ::ffff:1.2.3.4

It would be a convenience feature, if some new version of server did
this implicitly.

However, I did not suggest that some intermediate server should do any
merging of AAAA query with A queries.

---

From: Rob Austein <[email-masked]>
Date: Wed, 21 Aug 2002 15:26:35 -0400

At Wed, 21 Aug 2002 21:25:07 +0300, Markku Savela wrote:
> simulated manually using current name servers without any change...

Right.  The difficulties I see  with the mapped approach are that:

a) By adding v4 addresses to the AAAA RRset, it makes the AAAA RRset
   bigger and leaves you with no way to say that you just want the
   IPv6 addresses.  That is, it has a mild flavor of the subtyping
   problem, although I will admit that IP addresses are so close to
   being the same thing as IP addresses that maybe it doesn't matter.

b) The case where a dual-stack machine is most likely to want the IPV4
   addresess is, unfortunately, also the case that's most likely not
   to have bothered supplying the mapped addresses at all.  That is,
   while you'd get some benefit from the ability to supply the mapped
   addresses for a host that's IPv6-aware but IPv4-only, the case on
   which you'd really like to get some traction is the one that's not
   playing here (IPv4 only and doesn't care about IPv6).

Neither of these issues is necessarily a showstopper.  John Klensin
and I discussed something very close to this a couple of years ago and
I still kind of like the idea.

In the final analysis, though, what I mostly care about is coming up
with the simplest set of rules that gets everybody the right answer in
every case where a right answer is possible.  So while I'm happy to
discuss other options, I still tend towards the idea that the
application should just ask for the RRsets it needs, one RRset at a
time, and let the caching take care of itself.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Aug 2002 19:23:50 +0000

> ..., don't you have to upgrade every name server in the resolution
> chain at least to EDNS0 before you can stop worrying about getting
> back RCODE=1 ("Format Error")?

yes.  however, since we expect this to last more than our lifetimes,
it is reasonable to design for (eventual) success.  it's a near thing,
since by the time EDNS1 would fully penetrate the installed base, A RR
queries could be expected to reduce in number since there would be few
non-V6 endstations and the majority of transactions will be satisfied
by a AAAA result.  the thing that tips the balance is the ability to
ask for MX and A and AAAA all together, or some day, A and AAAA and
AAAAAAAA all together.

> So we immediately run up against the question of whether the problem
> we'd be solving is important enough to be worth this kind of upgrade
> effort.

something called EDNS1 is inevitable, from a social perspective.  the
question is: have we found something that makes another crank-turn worth
the effort, or should we wait for more things or bigger things to come
along before turning this crank?  here again it's a near thing, since
something called EDNS2 is also inevitable, from a social perspective,
and EDNS2 will be inclusive of EDNS(n<2).  we could turn the crank every
year and never really miss an opportunity to get more out of the protocol.

>    optimization of the query process is not the client's problem; or

based on what we see at the root name servers, caching (statistically
speaking) just doesn't happen.  that ought to get fixed.  but i'm betting
that it's more wide spread -- that every authoritative zone, and not just
".", is getting pounded by repeated queries for both existing and non-
existing names.  if we take approach (1) then let's also embark on an
internet-wide crusade to improve dns caching.

> deliberate cross dependency, but it would be good to confirm that.

it was an oversight, and was corrected in this morning's published diffs,
which evidently crossed your letter in the post.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Aug 2002 19:31:37 +0000

> merging of AAAA query with A queries.

i apologize for misunderstanding you.  (your words were clear on this point,
upon rereading.)  

jinmei's comments are relevant to this.  getaddrinfo() does not accept
ipv4-mapped addresses.  so there would still be some implementation cost
to this proposal, though not in the protocol itself.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Aug 2002 20:37:26 +0000

>   absence of RRs of the QTYPE, depending on local security policy.

done.

> the MX query to the initial client?

how about:

4.7. Negative caching and additional data processing shall be performed as
if successive queries had been initiated with QDCOUNT=1 and successive QTYPEs.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 21 Aug 2002 15:43:34 -0500

on 8/21/2002 2:23 PM Paul Vixie wrote:
> yes.

You can avoid this if the cache forms answers by assembling discrete
components. That's how qtype ADDR avoids it. If q1 is cached but q2 is
missing, only fetch q2. With that in place, apps/users only need to
support the query at the local cache. Every other server on the Internet
can refuse to support the query and it won't matter.

There is a hole here that has to be avoided in terms of short TTLs on the
discrete answer sets. If q1 has a ttl of 3 seconds but it takes 4 seconds
to fetch q2, oops got to get q1 now, dang where did q2 go, etc.

---

From: [email-masked]
Date: Thu, 22 Aug 2002 07:44:05 +0900

>It would be a convenience feature, if some new version of server did

	no IPv4 mapped address on wire, ever, please.  i'm writing up a
	draft why it is harmful.  it is very, very, harmful.

itojun

---

From: Robert Elz <[email-masked]>
Date: Thu, 22 Aug 2002 19:26:47 +0700

Date:        Wed, 21 Aug 2002 15:43:34 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | You can avoid this if the cache forms answers by assembling discrete
  | components. That's how qtype ADDR avoids it.

As I said in a private reply to a private message, but repeat here for
the list - this is optimising the wrong thing.

What happens between client & cache is, in the grand scheme of things,
irrelevant.

None of these schemes are useful unless they work across the net, to the
auth servers.   That's where optimisation is useful (less traffic to the
auth servers, less traffic on the congested wires).

If there's a problem with a local cache, there's an easy answer - just
install another one, we don't need protocol mods to improve that part of
the universe.

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Aug 2002 10:08:49 -0500

> What happens between client & cache is, in the grand scheme of things,

Which cache? For a query against munnari.OZ.AU, my resolver asks (1) my
local forwarding cache, who asks (2) my resolving cache, who asks (3) the
root, (4) the AU servers, (5) oz.au, and then (6) munnari.oz.au.

The benefit isn't limited to the first-hop pair, but can kick in anywhere
that one of those 6 caches doesn't support the query. The minimum
requirement is for my local forwarding cache to perform this conversion
(it MUST be able to handle the query, or the query won't get used
anywhere). In the best case, all of the boxes can handle it.

In the normal case for the next 10 years, conversion will happen somewhere
in the middle. If the root servers can't handle EDNS1 messages, then it
would happen whenever any resolving cache asked the root servers. If the
root and OZ.AU servers can handle EDNS1 messages, then it would happen
whenever any resolving cach asked munnari.oz.au for info.

> auth servers.

Which this does.

---

From: Rob Austein <[email-masked]>
Date: Thu, 22 Aug 2002 15:09:49 -0400

At Thu, 22 Aug 2002 10:08:49 -0500, Eric A. Hall wrote:
> that one of those 6 caches doesn't support the query.

Your message seems fairly confused about which functions those six
entities support.  I can't tell whether I'm just misreading what you
wrote or you really don't understand this.  If I'm just confused,
please forgive the following.

Let's try using the terminology that's defined in the RFCs to identify
the functions that each entity in this scenario performs.

(1) is the combination of a caching recursive-mode resolver and a
    name server.

(2) is the combination of a caching iterative-mode resolver and a name
    server.

(3), (4), and (5) are just name servers as far as this query is
   concerned, not resolvers at all, and thus have no caches at all.
   I'm quite certain that (3) does not support recursion, I'd be
   surprised if (4) or (5) do, and certainly none of them should.

(6) is either in the same catagory as (3), (4), and (5), or is not
    involved at all, depending on what you mean by "a query against".

So the only caches that should be relevant to this are in the resolver
portions of entities (1) and (2), and at least one of us is seriously
confused about the benefit you think you're seeing.

Last, with all due respect, this QTYPE=ADDR thing just does not work,
because it's a single QTYPE that can match more than one RRset, thus
whenever the name server answering it has an associated caching
resolver, the results you get back will depend on the previous query
history of that resolver.  This is ok for debugging, but not for
operational use.  Thus, while you're certainly entitled to say your
piece, this approach demonstrably will not work, so I don't understand
why you keep bringing it up.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Aug 2002 16:07:31 -0500

>    surprised if (4) or (5) do, and certainly none of them should.

Let me answer this with the qualification that it is not relevant to the
discussion at hand. Depending on the question, one of those servers may
respond. Whether they are supposed to respond or not is a function of the
data they have, their configuration, or their bugs. (3) will indeed return
NS and A RRsets in the answer if this data is available through delegation
knowledge or glue, even though it shouldn't. (4) or (5) might if they were
also configured as secondaries or had similar bugs. I'll demonstrate this
if you want, although I'll do this off-list since it's not relevant.

The discussion is about where in the query chain fallback processing can
happen and the cost of that processing. My point is simply that QDCOUNT>1
can be converted into atomic lookups anywhere in the path, and it can
survive from resolver all the way to an authoritative server without any
conversion being required, but that at a minimum the first-hop cache has
to support it. Actually, upon further though, this latter point is in
error, since the resolver can perform the conversion on its own (see the
last message for details).

> history of that resolver.

Two things. First is that I'm not flogging qtype ADDR other than to use it
as an example of one method for caches to process multiple questions.
Secondarily, your interpretation of its model is erroneous. I'll gladly
clarify this off-list as well, if you wish.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 22 Aug 2002 19:25:38 -0400

Rob Austein wrote:

> operational use.

With all due respect to _you_, Rob, read the draft. Sure, "the results you get
back will depend on the previous history of that resolver", but that's true
for *any* query to a caching resolver (maybe it has a cached answer, maybe it
doesn't; maybe it has a negative cache entry, maybe it doesn't; maybe it has
cached referral information, maybe it doesn't). The plain fact that caches
have "histories" doesn't render the qtype unusable. As the draft specifies,
the caching resolver will, if configured to recurse for the query, fetch
whatever RRset it happens to be missing (A or AAAA), in order to answer the
QTYPE=ADDR question. You seem to be assuming that QTYPE=ADDR will function
identically to QTYPE=* inasmuch as it will automatically be denied recursion
(who decided that QTYPE=* should automatically be denied recursion, by the
way? AFAICT, nothing in the standards -- including the ambiguous
query/response examples in RFC 1034 -- mandates this behavior).
QTYPE=ADDR behaves differently; it's more diligent about fetching missing data
than the current implementations of QTYPE=* resolution algorithms.

Note to Eric: please use the "RRset" terminology in the document, and use it
consistently. I found the "as an individual group" and "cumulative set of
resource records" terms in the the TTL section, for instance, very confusing
until I realized you were talking about separate RRsets and combined RRsets,
respectively. Since you're basically echoing RFC 2181 in that section, it
makes sense to adopt the same terminology used in that document.

- Kevin

---

From: Rob Austein <[email-masked]>
Date: Thu, 22 Aug 2002 23:18:26 -0400

At Thu, 22 Aug 2002 19:25:38 -0400, Kevin Darcy wrote:
> 
> With all due respect to _you_, Rob, read the draft....As the draft specifies,

Oh.  You're right, I assumed that its behavior was similar to *,
MAILA, and MAILB, because that's what I thought Eric had said on the
list.  My oops.

> query/response examples in RFC 1034 -- mandates this behavior).

QTYPE=* doesn't disable recursion, it just stops as soon as it finds
anything that matches, which is not quite the same thing.

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Aug 2002 03:11:25 -0400

> internet-wide crusade to improve dns caching.

I know that:

- we have hard data on the unbelievable amount of garbage that hits
  the root name servers;

- we have theoretical work attempting to demonstrate that caching of
  leaf data (not delegations) is most useful (for web browsers) in
  the first ten or twenty minutes after being cached; and

- we're pretty sure that negative caching is under-utilized;

but do we really have data to suggest that caching isn't happening at
all on any significant scale?  If so, it's news to me, please share. :)

The thing about the above breakdown is that most of the traffic either
comes from bad practice (whether coding or operational) or from
traffic patterns that don't cache well, so it's not clear that an
optimization to the query process is going to help that much.

Improving DNS caching Internet-wide sounds like a worthy goal in any
case.

---

From: Robert Elz <[email-masked]>
Date: Fri, 23 Aug 2002 14:31:38 +0700

Date:        Thu, 22 Aug 2002 16:07:31 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The discussion is about where in the query chain fallback processing can
  | happen and the cost of that processing. My point is simply that QDCOUNT>1
  | can be converted into atomic lookups anywhere in the path, and it can
  | survive from resolver all the way to an authoritative server without any
  | conversion being required, but that at a minimum the first-hop cache has
  | to support it.

yes, but you keep missing the point.   All of this is possible, what matters
is the cost, and whether it is likely to be a benefit or not over the
life of the proposal.

The analysis of this is completely different for ADDR and for EDNS1.
ADDR is useful only while A records remain alive.   That is, the net
benefit from using it must outweigh the deployment costs.

As I showed in another message (which may have been off list, so readers
other than Eric,  & maybe Greg, might not have seen it), early in its
deployment, ADDR costs more than doing nothing.   It can double the delay
and add 50% to packet counts.   If we reach a stage where most of the net
supports ADDR, then it can save 50% of the packet costs (no delay savings
of note).

Once A vanishes, ADDR starts costing more than not having it again, though
at a smaller rate that is harder to calculate (it's because negative caches
time out faster than positive ones).   If there was no ADDR, clients by
then would be just doing AAAA as in general, all they care about is an address,
very few actually want both - the dual query is a transition mechanism to
find AAAA when it exists, but fall back to A when it doesn't.   When A is
vanishing, one presumes just about everyone will have AAAA, so the AAAA
query would return an address, and no A query would be wanted.   But if
ADDR is being used, no-one can assume that, the cache still has to go hunting
for the non-existing A records.

So, we have a period of increased costs, a period of benefit, and then
forever after, increased costs.   The period of benefit would have to be
a HUGE benefit to make this a worthwhile - and it isn't.

So, can we just forget ADDR, forever, please?

  | First is that I'm not flogging qtype ADDR other than to use it
  | as an example of one method for caches to process multiple questions.

A job which its special nature makes it particularly bad at.

EDNS1 on the other hand doesn't have these problems - the client gets to
specify the actual data wanted, and the FM flag means that the (very common)
"I only need this other record if the first one doesn't exist" semantic
can be processed (for the AAAA & A case, the cache only needs the AAAA
records, if they exist, it never needs to bother with A records, in the
common client query of "Give me AAAA if they exist, otherwise A".)

We still need to evaluate the costs of EDNS1 vs its benefits.   Just as
ADDR, it increases delay & packets while it is being deployed.   And then
it can descrease packets while it is in use.   But it has no end point,
there's no point after which it starts costing more again.   And it has
more general applicability, so this one isn't as easy to just write off
as useless.

I appreciate Rob Austein's point - just let the cache's do the work, and
if the multiple queries in EDNS1 didn't have the FM capability, but always
requested all the answers, I think that would sway me.

But it is real hard to do a "a or b or c" (as in MX, or AAAA, or A)
query using the DNS without excessive delay, or excessive waste (the
queries are either serialised, in which case you have 3 RTTs to get a
useful answer, or sent in parallel, in which case you get all three answers,
and in many cases, discard 2 of  them - wasted work for the server, and
for the network).

On balance, I think EDNS1 is worth the deployment pain, and increased
usage costs while that is happening.

kre

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Aug 2002 08:02:53 +0000

> all on any significant scale?  If so, it's news to me, please share. :)

the data at hand indicates that a great number of people do not cache
referrals, either positively or negatively.  i've provided several
(anonymized) tcpdumps to caida over the years, so let's ask them to
comment.

> optimization to the query process is going to help that much.

i completely agree.

> Improving DNS caching Internet-wide sounds like a worthy goal in any case.

yes indeed.  but it'll receive no real attention unless one of two
things happens.  (1) one more person comes forward with a design proposal
of the form "we don't need to do that because caching will take care of it"
or (2) the amount of rejected repeated useless query traffic at some root
server exceeds 1 gigabit per second.  (both of those things will happen
within my lifetime, unless i miss my guess.)

---

From: Randy Bush <[email-masked]>
Date: Fri, 23 Aug 2002 08:08:04 -0700

> all on any significant scale?  If so, it's news to me, please share. :)

hari's work at mit said the opposite, yes?  sorry, their server
is rejecting me this morning, so no url.  but there was even a
presentation at dnsops a bit ago.

randy

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 23 Aug 2002 14:21:48 -0400

> anything that matches, which is not quite the same thing.

A minor semantic distinction. It *could* recurse the QTYPE=* query if it wanted
to. It chooses not to. In this context, has it "disabled recursion" (perhaps
"declined" would have been a better word choice) or is recursion unnecessary? It
can be viewed either way.

(Obviously, it would behoove any implementation that would actually consider
recursing a QTYPE=* query to keep track of whether it already has an intact,
no-RRsets-expired answer to a previous QTYPE=* query for the same name, since in
that case it can answer from the cache just like it would for a normal QTYPE).

- Kevin

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Aug 2002 14:26:36 -0400

> presentation at dnsops a bit ago.

Jaeyeon Jung's slides from the DNSMEAS BOF in the proceedings from the
Salt Lake IETF suggest a DNS cache hit rate of 80%-86% at MIT.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Aug 2002 19:02:40 +0000

> Salt Lake IETF suggest a DNS cache hit rate of 80%-86% at MIT.

that's great but we need to know the impact on authority servers
not just the hit ratio of caching recursive forwarders.

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Aug 2002 17:37:00 -0400

> not just the hit ratio of caching recursive forwarders.

That is indeed a different study, and as far as I know it isn't one
that anybody has performed.  Work to date has concentrated on the view
from the client, the view from the root, and performance.

If somebody with a seriously-high-traffic name server two or more
levels down the tree wanted to work with some researcher who had time
and funding to look into this, it might be a good thing.

TLD data would also be interesting, but weirdness factors at TLD name
servers, while not as high as at root name servers, might still be
high enough to complicate interpretation of the data.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Aug 2002 21:53:52 -0400

At 01:26 PM 8/21/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= 
>IPv4-mapped addresses (as described in RFC 2553).

According to the documentation that I have Windows XP and later supports
4 types of compatibility addresses: ISATAP, 6to4 (RFC 3056), 6over4
(RFC 2529) and IPv4 compatible ( ::w.x.y.z). The supported getaddrinfo()
is only available on XP and later.  I don't expect any of this to be available
on WNT, W2K or any of the Win9x O/S's even with MSR's IPv6 stack or
the Win2K Technology Preview, though I could be wrong.

Maybe one of the Microsoft people could comment.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 28 Aug 2002 13:12:56 -0400

At 04:02 AM 8/23/02, Paul Vixie wrote:
>  (2) the amount of rejected repeated useless query traffic at some root

Out of curiosity, what is the current amount of query traffic on F? And
what is the percentage of useless query traffic out of the total traffic?

Danny

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Aug 2002 17:58:14 +0000

> what is the percentage of useless query traffic out of the total traffic?

we get about 6Meg of traffic of which about half is garbage.