Subject: [dnsext] Polishing of draft-ietf-dnsext-axfr-clarify-13 after IETF LC

From: Alfred Hönes <[email-masked]>
Date: Wed, 10 Mar 2010 17:44:23 +0100 (MEZ)

Folks,
The IETF Last Call for draft-ietf-dnsext-axfr-clarify-13 has ended on
Monday with only a few minor points raised, and the draft is now under
IESG Evaluation.
Several ADs already have "raised their thumbs" unconditionally
(cf. <https://datatracker.ietf.org/idtracker/ballot/739/>).

I would like to sum up the planned changes that have made it into my
working copy and are awaiting approval, and explain the full rationale
behind them.

The line numbers below are those assigned by idnits for the draft
(use the  [Nits]  button on top of the document page at
  <http://tools.ietf.org/html/draft-ietf-dnsext-axfr-clarify-13>
to obtain the full numbered list of the draft).  Modified lines are
tagged with change bars ('|') in the first column below.

(1)  typos

A few typos have been corrected (lines 363 and 568: s/absense/absence/;
line 602: s/ENDS/EDNS/; consistent capitalization of "Question section"
in running text: lines 370 and 876).

(2)  improved language

As suggested in the Gen-ART review, the last sentence in Section 1.4
(lines 221-222) will be replaced by:

                                       [...].  The goal of this document
|  is to define AXFR as it is understood by the DNS community to exist
|  today.

(3)  improved language

In Section 2, the paragraph below the list of DNSSEC documents will be
made more factual in tone, as suggested by the Gen-ART review
(lines 268-270):

   These documents contain information about the syntax and semantics of
|  DNS messages.  They do not interfere with AXFR but are also helpful
   in understanding what will be carried via AXFR.

(4)  added precision and clarification

The review of SM and subsequent discussion as well as cross checking
with the basic DNSSECbis documents (RFC 4033-4035) has revealed small
parts of the text lacked precision in references to the OPT RR.

The OPT RR contains internal versioning, and as we want to get a
document that is as independent from other specifications and their
future evolution as possible, we should better not tie the OPT RR
in the language to EDNS0, unless this is specifically important in
some context.  Thus, in a few instances "EDNS0 OPT RR" is shortened
to "OPT RR" or "EDNS OPT RR", and I suggest that unnecessary uses of
"EDNS0" be consistently replaced by "EDNS", in the same way as it
has been done in RFCs 4033 thru 4035.
As Mark Andrews recently has pointed out again, EDNS version handling
is fully specified in RFC 2671 (and the rfc2671-bis draft), and it
hence is out of scope for axfr-clarify; only fallback rules from EDNS0
to non-EDNS need to be specified.

This all mostly affects the text in Sections 2.1.5 and 2.2.5.

Further, neither "EDNS0" nor "EDNS" is a resource record, so the first
paragraph of 2.2.5 needed a slight rewording for clarification.

In total, these considerations led to the following revised text
(see change bars).

- For the first two paragraphs in 2.1.5 (lines 389 through 407):

2.1.5.  Additional Section

   Currently, two kinds of resource records are defined that can appear
   in the Additional section of AXFR queries and responses: EDNS and DNS
   transaction security.  Future specifications defining RRs that can be
   carried in the Additional section of normal DNS transactions need to
   explicitly describe their use with AXFR, should that be desired.

|  The client MAY include one OPT resource record [RFC2671].  If
   the server does not support EDNS0, the client MUST send this section
   without an OPT resource record if there is a retry.  However,
   the protocol does not define an explicit indication that the server
   does not support EDNS0; that needs to be inferred by the client.
   Often, the server will return a FormErr(1) which might be related to
   the OPT resource record.  Note that, at the time of this writing,
|  only the EXTENDED-RCODE field of the OPT RR is meaningful in
|  the context of AXFR; future specifications of EDNS flags and/or
|  EDNS options must describe their usage in the context of AXFR, if
   applicable.

- For the last paragraph of 2.1.5 (lines 424-432):

   The range of permissible resource records that MAY appear in the
   Additional section might change over time.  If either a change to an
|  existing resource record (like the OPT RR for EDNS) is made or a new
   Additional section record is created, the new definitions ought to
   include a discussion on the applicability and impact upon AXFR.
   Future resource records residing in the Additional section might have
   an effect that is orthogonal to AXFR, so can ride through the session
   as opaque data.  In this case, a "wise" implementation ought to be
   able to pass these records through without disruption.

- For Note e) in Section 2.2.1 (lines 550-559):

   e) In the absence of an error, the server MUST set the value of this
      field to NoError(0).  If a server is not authoritative for the
      queried zone, the server SHOULD set the value to NotAuth(9).
      (Reminder, consult the appropriate IANA registry [DNSVALS].)  If a
      client receives any other value in response, it MUST act according
      to the error.  For example, a malformed AXFR query or the presence
|     of an OPT resource record sent to an old server will result
      in a FormErr(1) value.  This value is not set as part of the AXFR-
      specific response processing.  The same is true for other values
      indicating an error.

- for Section 2.2.5 (lines 593-611, full text shown)

2.2.5.  Additional Section

|  The contents of this section MUST follow the guidelines for the OPT,
|  TSIG, and SIG(0) RRs, or whatever other future record is possible
   here.  The contents of Section 2.1.5 apply analogously as well.

   The following considerations specifically apply to AXFR responses:

|  If the client has supplied an EDNS OPT RR in the AXFR query and if
|  the server supports EDNS as well, it SHOULD include one EDNS OPT RR
   in the first response message and MAY do so in subsequent response
|  messages (see Section 2.2); the specifications of EDNS options to be
   carried in the OPT RR may impose stronger requirements.

   If the client has supplied a transaction security resource record
   (currently a choice of TSIG and SIG(0)) and the server supports the
   method chosen by the client, it MUST place the corresponding resource
   record into the AXFR response message(s), according to the rules
   specified for that method.

(5)  additional Security Considerations

Based on the SecDir review, a new first paragraph has been added to
Section 8:

|  This document is a clarification of a mechanism outlined in RFCs 1034
|  and 1035 and as such does not add any new security considerations.
|  RFC 3833 [RFC3833] is devoted entirely to security considerations for
|  the DNS; its Section 4.3 delineates zone transfer security aspects
|  from the security threats addressed by DNSSEC.

(6)  IANA Considerations

Poor experiences in the past indicate that every single step expected
to be performed should at best be specified explicitly.
Thus, to assure timely update without additional message exchanges,
I tentatively have replaced the "NOP" paragraph in Section 9 of the
-13 version with a substantive sentence similar in style to what we
have in draft-ietf-dnsext-rfc2672bis-dname-18 (but written in a manner
that avoids changes to be made by the RFC Editor):

|  IANA has added a reference to this RFC in the AXFR (252) row of the
|  "Resource Record (RR) TYPEs" subregistry of the "Domain Name System
|  (DNS) Parameters" registry.

(7)  updates to References

Item (5) above also made necessary the addition of a new Informative
Reference entry for [RFC3833]:

|  [RFC3833]  Atkins, D., and R. Austein, "Threat Analysis of the Domain
|             Name System (DNS)", RFC 3833, August 2004.

A recent draft update also has to be reflected:

   [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and
              Implementation Notes for DNSSECbis",
|             draft-ietf-dnsext-dnssec-bis-updates-10 (work in
|             progress), March 2010.

Unless there are strong objections, these changes will go into the
next (hopefully final) draft version to be posted on request of the
responsible AD.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+