Re: I-D ACTION:draft-iab-dns-choices-00.txt
Paul Vixie <vixie@vix.com> Wed, 20 October 2004 15:40 UTC
Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15545 for <dnsext-archive@lists.ietf.org>; Wed, 20 Oct 2004 11:40:59 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKIXY-000B9U-8o for namedroppers-data@psg.com; Wed, 20 Oct 2004 15:38:16 +0000
Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKIXP-000B8L-0X for namedroppers@ops.ietf.org; Wed, 20 Oct 2004 15:38:07 +0000
Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C2B9913E12 for <namedroppers@ops.ietf.org>; Wed, 20 Oct 2004 15:38:06 +0000 (GMT) (envelope-from vixie@sa.vix.com)
From: Paul Vixie <vixie@vix.com>
To: namedroppers@ops.ietf.org
Subject: Re: I-D ACTION:draft-iab-dns-choices-00.txt
In-Reply-To: Message from Edward Lewis <Ed.Lewis@neustar.biz> of "Wed, 20 Oct 2004 11:17:59 -0400." <a06110402bd9c27abc7b2@[192.35.166.53]>
X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1
Date: Wed, 20 Oct 2004 15:38:06 +0000
Message-Id: <20041020153806.C2B9913E12@sa.vix.com>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
> >what do you all think NOW? > > Since you've asked. ;) > > I think that it's not all bad. The current practice does achieve the > goals of minimizing latency, allowing the migration from v4 to v6 (and > vice versa) to occur at the edges, is backward compatible with older > software, and is resilient. if a AAAA response comes in without A RRs in the additional data section and you happen to need them then (and only then) do you have to do another query (for the A RRset). if the servers you're talking to don't support qdcount>1 then you'll have to do multiple queries. both proposals were opportunistic and ended in good balance other than the leftover complexity of having to support qdcount>1 even after IPv4's dead; however, other possibilities exist, like querying for both MX+AAAA, or SRV+AAAA, in various applications like mail transports. so the complexity would not have been truly wasted even after IPv4's dead. > Had we pursued multiple queries in a message, we'd have had to deal with > the issue of partial results - like, if one query was for (foo.example. IN > A) and the other was for (bar.example. IN A) and foo.example. existed and > bar.example. did not, how is a half name error returned? Who knows - had > we travelled down that road would the WG be wrapped around the axle over > AAAAbis by now? the proposal was for qdcount>1, all qname's the same, all qclass's the same, and variant qtype. so your multiple-qname scenario was under prior restraint. > Had we thrown the AAAA in the additional section, we may have had problems > with the older pass-through servers that might not have known to add the > AAAA's when it was needed (answering from a non-authoritative source). > We'd have been creating a new type with "special considerations." the proposal didn't put the AAAA into the additional section, it put A RR's there on qtype=AAAA. just like A RR's go into the additional section on qtype=MX (though there it's the target rather than the owner name). are you reading what i'm writing, ed? > Summarizing the above - we now have empirical evidence of a pitfall of the > option chosen (which I prefer over anticipated concerns) and we have two > other options that haven't faced a test. i don't like your summary. "fear was mongered, several good solutions were quashed, and we got our comeuppance" is a much better summary. but it's just possible that i'm bitter about this, or twisted, or perhaps both. > One untried option is a new RR type (e.g., NSADDR) which may have all > the glue in one RDATA (one large RDATA section). EDNS0 solves size > problems and we could do this as a "try this one, then fallback" for > backwards compat. Oops - there's that phrase "then fallback". Maybe > not wise course either. > > I'd say that I'm happy with the bird in hand, even if it leaves me with > guano, than the two birds in the tree. I would be happier with the two > birds in the tree, but I have to keep asking if the effort to obtain them > is worth it considering what I already have. there are really two questions here. one is just out of bitterness and it goes something "did we do the right thing?" and we all agree it's irrelevant. the other question, though, is relevant: "should we do something different?" with that in mind, here's the current EDNS1 draft, last revised two years ago, containing the qdcount>1 proposal. the historians among y'all know that this text was excised from EDNS0 in order to trim down EDNS0 into something the world could understand and agree on. i apologize for the length -- it's three pages. but the third page is just the references. note that ISC's name has changed since this was last troff'd. --- DNSIND Working Group Paul Vixie INTERNET-DRAFT ISC <draft-ietf-dnsext-edns1-03.txt> August, 2002 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 [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 - Affected Protocol Elements 2.1. 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 - 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: |md |FM |RRD|lm | 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. Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. 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 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. 4.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. 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 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671, IETF DNSIND, September 1998 6 - Author's Address Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063 +1.650.779.7001 <vixie@isc.org> Expires March 2003 [Page 4] --- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Robert Elz
- Re: I-D ACTION:draft-iab-dns-choices-00.txt bmanning
- Re: I-D ACTION:draft-iab-dns-choices-00.txt bmanning
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Paul Vixie
- RE: I-D ACTION:draft-iab-dns-choices-00.txt Hallam-Baker, Phillip
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Alex Bligh
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Pekka Savola
- RE: I-D ACTION:draft-iab-dns-choices-00.txt Hallam-Baker, Phillip
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Mark Andrews
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Edward Lewis
- RE: I-D ACTION:draft-iab-dns-choices-00.txt Hallam-Baker, Phillip
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Edward Lewis
- RE: I-D ACTION:draft-iab-dns-choices-00.txt Hallam-Baker, Phillip
- RE: I-D ACTION:draft-iab-dns-choices-00.txt Hallam-Baker, Phillip
- RE: I-D ACTION:draft-iab-dns-choices-00.txt Hallam-Baker, Phillip
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Robert Elz
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Michael Richardson
- Re: I-D ACTION:draft-iab-dns-choices-00.txt Paul Vixie