[dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- changes since -02 [resent]

[Alfred Hönes <[e-mail]>]

Resent due to original message getting caught in moderation;
sorry for duplicates!
--------


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.