Subject: [dnsext] Re: draft-ietf-dnsext-axfr-clarify WGLC announcement

From: Andrew Sullivan <[email-masked]>
Date: Sat, 19 Dec 2009 12:22:15 -0500

Dear colleagues,

This mail initiates a three week Working Group Last Call for the WG
work item, draft-ietf-dnsext-axfr-clarify-12.txt.  The last call will
close at 17:00 EST on 2010-01-09.

Please read the document and send your comments to the mailing list.
This document has been through many revisions and has received quite a
lot of attention, but it has lived a long time and really needs
complete review.  This is especially true because it discusses a very
old part of the DNS specifications.  Because this is a clarification
document that purports to specify more completely the behaviour of
existing functionality, it is particularly important that its
correctness and completeness be evaluated by protocol experts and,
especially, implementers.

Please remember that DNSEXT has a policy that a document that has not
received supportive review by at least five DNSEXT participants will
not be sent to the IESG.  The document has been around for a long
time, and it would be a shame to let that work go to waste due to
inadequate review.  Especially in this case, I would very much like to
see more than five supportive reviews.

I will be the document shepherd for this draft.

Participants are reminded that _ad hominem_ arguments are not
permitted in DNSEXT, and are further reminded to confine themselves to
the technical merits of the draft.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andreas Gustafsson <[email-masked]>
Date: Wed, 30 Dec 2009 18:08:01 +0200

> Please read the document and send your comments to the mailing list.

The draft still needs some work.  My comments follow, organized by
section.

Section 2.1.1, Header Values (regarding the ARCOUNT field in the
AXFR request message):

      The value MAY be 0, 1 or 2.  If it is 2, the Additional section
      MUST contain both an EDNS0 [RFC2671] OPT resource record and a
      record carrying transaction integrity and authentication data,
      currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931].  If the
      value is 1, then the Additional section MUST contain either only
      an EDNS0 OPT resource record or a record carrying transaction
      integrity and authentication data.  If the value is 0, the
      Additional section MUST be empty.

This seems overly restrictive in that it would preclude future
backwards-compatible extensions where new records other than EDNS0 or
integrity/authentication records are added to the additional section,
especially given that such extensions are specifically anticipated in
the last paragraph of section 2.1.5.  

I suggest dropping the quoted text, leaving just the preceding text
"The client MUST set this field to the number of resource records
appearing in the Additional section".

Section 2.1.2, Question Section:

   The Query section of the AXFR query MUST conform to Section 4.1.2 of

The term "Query section" occurs in several places in the document;
they should all read "Question section" to be consistent with RFC1035
terminology.

Section 2.2, AXFR Response:

   An AXFR response indicates an error via a single DNS message with the
   return code set to the appropriate value for the condition

The term "return code" occurs in two places in the document; they
should both read "RCODE" or "response code" to be consistent with
RFC1035 terminology.

Section 2.2.1, "0 Message" Response:

   A legitimate "0 message" response, i.e., the client sees no response
   whatsoever, is very exceptional and controversial. Unquestionably it
   is unhealthy for there to be 0 responses in a protocol that is
   designed around a query - response paradigm over an unreliable
   transport.  The lack of a response could be a sign of underlying
   network problems and cause the protocol state machine to react
   accordingly.  However, AXFR uses TCP and not UDP, eliminating
   undetectable network errors.

   A "0 message response" is reserved for situations in which the server
   has a reason to suspect that the query is sent for the purpose of
   abuse.  Due to the use of this being so controversial, a "0 message
   response" is not being defined as a legitimate part of the protocol
   but the use of it is being acknowledged as a warning to AXFR client
   implementations.  Any earnest query has the expectation of some
   response but nevertheless may not get one.

I don't think it makes sense to talk about a "0 message response" as a
type of response distinct from that of immediately closing the TCP
connection (as discussed in section 2.3).  If the TCP connection is
not closed, a "0 message response" effectively amounts to the server
ignoring the AXFR request while keeping the TCP connection open and
continuing to respond to other requests on the same connection.  
That behavior makes no sense, and I don't believe it has ever been
implemented in any server, nor do I believe anyone has actually
requested that the standard allow it.  What has been (controversially)
implemented is specifically the action of immediately closing the TCP
connection.  Therefore, I suggest removing section 2.2.1 in its
entirety, and replacing the text in section 2.2 saying

   The AXFR response will consist of 0 or more messages.  A "0 message"
   response is covered in Section 2.2.1.

by

   The AXFR response will consist of 1 or more messages.  The case of
   a server closing the TCP connection without sending an AXFR response
   is covered in section 2.3.

Section 2.2.2, Header Values:

   e) If the implementation supports the DNS Security Extensions (DNSSEC
      -- see Section 2), then this value MUST be set according to the
      rules in RFC 4035, Section 3.1.6, "The AD and CD Bits in an
      Authoritative Response".  If the implementation does not support
      the DNS Security Extensions, then this value MUST be set to 0 and
      MUST be ignored upon receipt.

It is unclear to me what the purpose of setting the AD or CD bit in an
AXFR response is.  If there is no well-defined use for the AD and CD
bits in the AXFR client, I don't see the point in the AXFR server
setting them.  On the other hand, it seems that RFC 4035 section 3.1.6
already allows a server to always respond with CD=0 and AD=0, so while
the requirements of section 2.2.2 may not serve any real purpose, they
are at least trivial for the server implementer to comply with. :)

Section 3.1, Records to Include:

   Unless the AXFR server knows that the AXFR client is old and expects
   just one resource record per AXFR response message, an AXFR server
   SHOULD populate an AXFR response message with
   as many complete resource record sets as will fit within a DNS
   message.

This discussion belongs in section 2.2., not section 3, because it is
not about the zone contents but about the form of the response
message.  Also, the fact that some older servers can only handle
single-RR response messages needs to be clearly stated and discussed
on its own, not just mentioned in passing.

Section 4, Transport:

   Since the early days of the DNS, operators who have sets of name
   servers that are authoritative for a common set of zones found it
   desirable to be able to have multiple concurrent zone transfers in
   progress; this way a name server does not have to wait for one zone
   transfer to complete before the next could begin.  RFC 1035 did not
   exclude this possibility, but legacy implementations missed to
   support this functionality.

It's not quite true that "legacy implementations missed to support
this functionality".  DNS implementations have supported multiple
concurrent zone transfers for a long time; it's just that they have
supported them by means of multiple concurrent TCP connections rather
than by multiple concurrent AXFR sessions over a single TCP
connection.

   The remaining presence of such legacy
   implementations makes it necessary that new general purpose server
   implementation still provide options for gracefull fallback to the
   old behavior in their support of concurrent DNS transactions and AXFR
   sessions on a single TCP connection.

Surely you mean client implementations, not server implementations?
Also, "graceful" is spelled with one "l".
-- 
Andreas Gustafsson, [email-masked]

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 31 Dec 2009 18:21:29 +0000

> see more than five supportive reviews.

	I am neither a "protocol expert" nor an "implementer".

	I have carefully read draft-ietf-dnsext-axfr-clarify-12.txt,
	and believe that it is a useful document.  Its very accessible
	language and careful exposition should be helpful to all readers
	who need an explicit point of reference for what is not made
	sufficiently clear in earlier documents.  I particularly
	appreciate and welcome the care taken to identify those aspects
	of AXFR behaviour which can only be effectively addressed by
	configuration actions; I expect that this will be of valuable
	assistance to zone and server administrators.

	I found a good number of "nits", and will include these in a
	later message.

	In just one place, the intent seemed insufficiently clear.
	I believe that giving further attention to the following section
	at this stage would forestall possible future controversy.

2.3.  TCP Connection Aborts

	[...]

    An AXFR server implementor SHOULD take into consideration the dilemma
    described above when a connection is closed with an outstanding query
    in the pipeline.  For this reason, a server ought to reserve this
    course of action for situations in which it believes beyond a doubt
    that the AXFR client is attempting abusive behavior.

	Intent: is 'SHOULD' or 'RECOMMEND' needed?
	s/server ought to reserve/SHOULD reserve/? OR
	s/a server ought to reserve/
	 /it is RECOMMENDED that a server reserve/?

	I hope this helps.

	Best regards, and Happy New Year!

	Niall O'Reilly

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 31 Dec 2009 18:32:09 +0000

> close at 17:00 EST on 2010-01-09.

	Nit-list, as promised, covering spelling, ill-formed sentences,
	and problematic vocabulary or usage (IMHO, of course) ...

	[...]

Abstract

    The Domain Name System standard mechanisms for maintaining coherent
    servers for a zone consist of three elements.  One mechanism is the
    Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035.
    The definition of AXFR has proven insufficient in detail, thereby
    forcing implementations intended to be compliant to make assumptions,
    impeding interoperability.  Yet today we have a satisfactory set of
    implementations that do interoperate.  This document is a new
    definition of AXFR -- new in the sense that is it recording an
    accurate definition of an interoperable AXFR mechanism.

	s/is it recording/it records/

	[...]

1.4.  Coverage and Relationship to Original AXFR Specification

    This document concentrates on just the definition of AXFR.  Any
    effort to update the specification of the IXFR or NOTIFY mechanisms
    is left to different documents.

    The original "specification" of the AXFR sub-protocol is scattered
    through RFC 1034 and RFC 1035.  Section 2.2 of RFC 1035 (on page 5)
    depicts the scenario for which AXFR has been designed.  Section 4.3.5
    of RFC 1034 describes the zone synchronization strategies in general
    and rules for the invocation of a full zone transfer via AXFR; the
    fifth paragraph of that section contains a very short sketch of the
    AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
    flaw in that specification.  Section 3.2.3 of RFC 1035 has assigned
    the code point for the AXFR QTYPE (see Section 2.1.2 below for more
    details).
               Section 4.2 of RFC 1035 discusses the transport layer use
    of DNS and shortly explains why UDP transport is deemed inappropriate
    for AXFR;

	s/discusses the transport layer use of DNS/
	 /discusses how DNS uses the transport layer/

	s/shortly/briefly/

              the last paragraph of Section 4.2.2 gives details for the
    TCP connection management with AXFR.

	s/for the/for/

	s/with/for/
	(or some other preposition or prepositional phrase:
	 "with" is instrumental: "by means of"; not likely
	 what is intended)

	[...]

2.2.  AXFR Response

    An AXFR response that is transferring the zone's contents will
    consist of a series (which could be a series of length 1) of DNS
    messages.  In such a series, the first message MUST begin with the
    SOA resource record of the zone, the last message MUST conclude with
    the same SOA resource record.  Intermediate messages MUST NOT contain
    the SOA resource record.  The AXFR server MUST copy the Question
    section from the corresponding AXFR query message in to the first
    response message's Question section.  Subsequent messages MAY do the
    same or contain an empty Question section.

    An AXFR response indicates an error via a single DNS message with the
    return code set to the appropriate value for the condition
    encountered, sent once the error condition is detected.

	s/once/when/

	[...]

2.2.1.  "0 Message" Response

	s/earnest/legitimate/ or
	s/earnest/bona-fide/

	[...]

2.2.  Header Values

	[...]

       to the error.  For example, a malformed AXFR query or the presence
       of an EDNS0 OPT resource record sent to an old server will garner
       a FormErr(1) value.

	s/garner/result in/

	[...]

    g) The count of answer records MUST equal the number of resource
       records in the AXFR Answer Section.  When a server is aware that a
       client will only accept one resource record per response message,

	s/only accept one/accept only one/

	[...]

    h) The client MUST set this field to the number of resource records

	s/this field/the count of additional-section records/

       appearing in the Additional section.  The considerations of Note
       d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional
       Section" below for more details.

	[...]

    If an AXFR client sends a query on a TCP connection and the
    connection is closed at any point, the AXFR client MUST consider the
    AXFR session terminated.  The message ID MAY be used again on a new
    connection, even if the question and AXFR server are the same.

    Facing a dropped connection, a client SHOULD try to make some
    determination whether the connection closure was the result of
    network activity or a decision by the AXFR server.

	s/whether/as to whether/
	s/connection closure/loss of connection/
	s/or a/or due to a/

                                                        This
    determination is not an exact science.  It is up to the AXFR client
    implementor to react, but the reaction SHOULD NOT be an endless cycle
    of retries nor an increasing (in frequency) retry rate.

	s/be an endless/be either an endless/
	s/nor/or/

	[...]

3.  Zone Contents

    The objective of the AXFR session is to request and transfer the
    contents of a zone.  The objective is to permit the AXFR client to
    reconstruct the zone as it exists at the server for the given zone
    serial number.

	Avoid giving two statements of the "objective":
	s/zone.  The objective is to permit/zone, in order to permit/

	[...]

3.2.  Delegation Records

	[...]

    One issue is that in operations there are times when the NS resource
    records for a zone might be different at a cut point in the parent
    and at the apex of a zone.  Sometimes this is the result of an error
    and sometimes it is part of an ongoing change in name servers.  The
    DNS protocol is robust enough to overcome inconsistencies up to (but
    not including) there being no parent indicated NS resource record

	s/parent indicated/parent-indicated/

    referencing a server that is able to serve the child zone.  This
    robustness is one quality that has fueled the success of the DNS.
    Still, the inconsistency is an error state and steps need to be taken
    to make it apparent (if it is unplanned) and to make it clear once
    the inconsistency has been removed.

	[...]

3.3.  Glue Records

???

    As quoted in the previous section, Section 4.2.1 of RFC 1034 provides
    guidance and rationale for the inclusion of glue records as part of
    an AXFR transfer.  And, as also argued in the previous section of
    this document, even when there is an inconsistency between the
    address in a glue record and the authoritative copy of the name
    server's address, the glue resource record that is registered as part
    of the zone for that serial number is to be included.

	The intent here is clear, but the expression is very
	unfortunate.  I need to think some more before I "send text".

???

4.  Transport

	[...]

    The most common scenario is for an AXFR client to open a TCP
    connection to the AXFR server, send an AXFR query, receive the AXFR
    response, and then close the connection.  But variations of that
    most simple scenario are legitimate and likely, in particular sending

	s/likely, in particular sending/likely. In particular, sending/

    a query for the zone's SOA resource record first over the same TCP
    connection, and reusing an existing TCP connection for other queries.

    Therefore, the assumption that a TCP connection is dedicated to a
    single AXFR session is incorrect.  This wrong assumption has led to
    implementation choices that prevent either multiple concurrent zone
    transfers or the use of an open connection for other queries.

    transfer to complete before the next could begin.

	s/does/would/ OR
	s/could/can/

                                                       RFC 1035 did not

	s/missed/neglected/

	s/gracefull/graceful/

	[...]

    disruption was a spurious event, attempting to restart the connection
    would be proper.  If the disruption was caused by a failure that
    proved to be persistent, the AXFR client would be wise to not spend

	s/to not spend/not to spend/ OR
	s/to not spend/to avoid spending/

    too many resources trying to rebuild the connection.  Finally, if the
    connection was dropped because of a policy at the AXFR server (as can
    be the case with older AXFR servers), the AXFR client would be wise
    to not retry the connection.  Unfortunately, knowing which of the

	s/to not retry/not to retry/

    three cases above (momentary disruption, failure, policy) applies is
    not possible with certainty, and can only be assessed by heuristics.

	[...]

4.1.2.  AXFR server TCP

    An AXFR server MUST be able to handle multiple AXFR sessions on a
    single TCP connection, as well as handle other query/response
    transactions over it.

	s/as well as handle/as well as to handle/

	[...]

	[ends]

	IHTH

	Best regards,
	Niall O'Reilly