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

[Niall O'Reilly <[e-mail]>]

Andrew Sullivan wrote:
> 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.

	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

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

    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

    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.

	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.

	[...]

2.3.  TCP Connection Aborts

    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.

    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.

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

                                                       RFC 1035 did not
    exclude this possibility, but legacy implementations missed to
    support this functionality.

	s/missed/neglected/

                                 The remaining presence of such legacy
    implementations makes it necessary that new general purpose server
    implementation still provide options for gracefull fallback to the

	s/gracefull/graceful/

    old behavior in their support of concurrent DNS transactions and AXFR
    sessions on a single TCP connection.

	[...]

    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