[dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -02
Alfred Hönes <ah@TR-Sys.de> Fri, 09 March 2012 13:23 UTC
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD6D21F8483 for <dnsext@ietfa.amsl.com>; Fri, 9 Mar 2012 05:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.535
X-Spam-Level:
X-Spam-Status: No, score=-98.535 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ8-d3RwaQL0 for <dnsext@ietfa.amsl.com>; Fri, 9 Mar 2012 05:23:37 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id C98E821F8645 for <dnsext@ietf.org>; Fri, 9 Mar 2012 05:23:35 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA149339206; Fri, 9 Mar 2012 14:20:06 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA28674; Fri, 9 Mar 2012 14:20:04 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201203091320.OAA28674@TR-Sys.de>
To: dnsext@ietf.org
Date: Fri, 09 Mar 2012 14:20:04 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 09 Mar 2012 07:27:25 -0800
Cc: vixie@isc.org, Ed.Lewis@neustar.biz, fweimer@bfk.de
Subject: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 13:23:38 -0000
For quick information, below I present some excerpts from the draft, giving: o the newly added Ack clause; o Appendix B, the essential change summary since RFC 1995; and o Appendix C, which presents the list discussion evaluation and change record since version -02. My apologies again for not being able to respond in time to the postings of last summer; I hope this summary represents a valid substitute for belated answer messages to all the list participants listed in the quoted new paragraph of the Acknowledgements Section. -------- excerpts from draft-ah-dnsext-rfc1995bis-ixfr-03 -------- 11. Acknowledgements [...] {newly added:} Discussions of the draft on the dnsext list have directed the evolution of this document; in particular, we acknowledge (in alphabetical order) Mark Andrews, Brian Dickson, Shane Kerr, Edward Lewis, Josh Littlefield, Masataka Ohta, Paul Vixie, and Wouter Wijngaards for their comments and reviews. [...] Appendix B. Substantial Changes Since RFC 1995 This is a summary of the substantial changes since RFC 1995 [RFC1995]. o Corrected a few technical flaws: incorrect comparison with AXFR; improper impled requirement of performing SOA query over UDP; improper reference to transfer of partial RRs in a response message corrected (to be read as transfer of partial RRsets in a response message -- as it has always been understood by implementers, since STD 13 requires only entire RRs to be present in DNS messages). o New specification based on the revised AXFR specification, RFC 5936 [RFC5936]. o Many clarifications and details supplied, text vastly reorganized and expanded, but no (intentional) technical deviation from the previous specification, as understood by implementers. o Addition of new IXFR-ONLY protocol variant, based on operational experience and perceived need. o Major additions to Security Considerations. o Historical example dropped (incompatible with IESG policy on examples). Instead, abstract examples have been added to Section 2. Appendix C. Evaluation of List Discussion, Draft Changes since -02 [[ Temporary Section, to be deleted in next draft version. ]] The previous (-02) version of this draft has been extensively discussed on the dnsext mailing list during the June through August 2011 timeframe. Due to temporary unavailability of the primary author, the concensus-building based on that discussion is summed up below, instead of flooding the mailing list with a bunch of (very belated) response messages. Messages are quoted below as "{msgNNNNN}", based on the message numbers (NNNNN -- a 5-digit number) assigned in the list archive using URIs following the pattern <http://www.ietf.org/mail-archive/web/dnsext/current/msgNNNNN.html>. {msg11353}, item 1: It is claimed frequently that IETF documents are too "microscopic" in their perspective and do not give the "glue" context information allowing even a non-specialized reader to see how the specified functionality relates to other parts of protocols, deployment, and common usage. Therefore, like in the kindred AXFR document, RFC 5936, context information for the invocation of IXFR is given in the draft -- btw, in a style that resembles descriptions given in the basic DNS Standards, RFCs 1034 and 1035. If zones don't change, and no NOTIFYs are sent, IXFR isn't needed. As RFC 1996 (NOTIFY) indicates, NOTIFY was intended as the primary trigger for IXFR requests, and that's what this draft re-states from the perspective of IXFR. Minor editorial changes have been performed. {msg11353}, item 2, {msg11359} and more messages down the thread: As has been pointed out by Brian D. (et al.) in {msg11354}, {msg11363} (and follow-up discussion), the term "Fallback to AXFR" describes IXFR server behavior specified in RFC 1995 and present in all major DNS server implementations. Overall, substantial discussion apparently has been caused by confusion about the (admittedly a bit colloquial) term "Fallback to AXFR". Another thread on this behavior was started by Mark A. ({msg11373} ff.). To clarify and resolve this issue, a definition for this term has been added to Section 1.4. The justification for clarifications to the present IXFR specification and the need for interoperably specified IXFR-ONLY has been reinforced by several contributors, e.g. Brian D., Mark A., and Masataka O. ({msg11354}, {msg11355}, {msg11356}, {msg11365}, ff.). We have not found any indications in the draft text where the detailed specification of (classical) IXFR would contradict RFC 1995, and it has been indicated on the list that the draft also correctly reflects the on-the-wire IXFR behavior of all major implementations represented by active participants on the list. {msg11353}, final item: IMO, RFC 1995 would have deserved at least 3 Technical Errata and roughly a dozen Editorial Errata, and it lacks a lot of precidion, so we agree that a refresh of this original specification should be welcome. The suggested additional test by DNSSEC-aware IXFR clients of the RRSIG(SOA) RRset now is mentioned in a newly added paragraph of Section 7.1 (that section is referred to in the Security Considerations). {msg11373}, {msg11374} and follow-ups: The draft already represents in detail the different possible responses on an IXFR query that have been inherent in RFC 1995. If (and only if) the IXFR server can respond with a single DNS response packet, the IXFR transaction can be carried out successfully over UDP, and hence is a "single response mechanism". Otherwise, the IXFR client has to be redirected to TCP, as described in (RFC 1995 and) the draft. This is independent of whether the IXFR server then has to fall back to full-zone transfer. There might be a (very unlikely) corner case, where the IXFR server wants to fall back to full-zone transfer *and* this transfer can be performed in a single response packet. Admittedly, that's rather unlikely, and in this case, IXFR-ONLY behavior would be causing additional overhead and message exchanges. Therefore, clauses has been added to Section 2 and Section 3.2 that in this corner case, the response to IXFR-ONLY MAY be a full-zone transfer over UDP, for the sake of overall performance. Otherwise, no significant changes to the text have been performed in this respect. {msg11376} ff.: Aborting an IXFR session over TCP likely does not waste so much resources on the IXFR client side (which initiates the premature closing of the TCP connection), but it takes much more time for the IXFR server to be notified of this closure, and up to then, it will have wasted resources to generate and buffer response packets that will either never be received or not even sent. Further, if a persistent TCP connection is desired, e.g. for an IXFR client that regularly has to update numerous zones from the same (candidate) IXFR server, re-establishment and subsequent TCP slow-start of a new TCP connection will be actually detrimental to the overall zone update performance. This is another reason why IXFR-ONLY promises substantial performance improvements that cannot be achieved without protocol enhancements. Since only modern DNS implementations are expected to implement IXFR-ONLY (which are expected to support EDNS anyway), because extended message sizes are very useful for IXFR in general (which also requires EDNS), and to reduce the pressure on the narrow basic RCODE namespace (only 5 codepoints still available for assignment), the draft now assumes that an extended RCODE value for CannotIXFR will suffice. The running text and IANA Considerations have been adjusted accordingly. Consequentially, the draft now specifies that an IXFR-ONLY query without an OPT RR will be rejected by the IXFR server with FormErr. Paul V. ({msg13379}) pointed out the detriments of message sizes above 16k (loss of ability to perform message compression). Added Note to Section 3 explaining this hint. A few adjustments regarding use of RFC 2119 language have been performed. Appendix B, which sums up the important changes since RFC 1995, has been added, as needed per IESG policy. References have been updated. Numerous editorial changes and enhancements have been applied. Vertical spacing tweeked to avoid dangling orphan lines at page breaks. ------ end of excerpts from draft-ah-dnsext-rfc1995bis-ixfr-03 ------ Please review the changes and/or the entire document if you haven't before. Comments are welcome in response to this message, on dnsext and/or in off-list messages to the authors. The next steps for this draft should be discussed in a parallel thread that will be started immediately, with suitable Subject: . Kind regards, Alfred.
- [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- ch… Alfred Hönes
- Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -… Alfred Hönes
- Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -… Masataka Ohta