Subject: Re: [dnsext] Comments on draft-ietf-dnsext-axfr-clarify-12

From: Alfred Hönes <[email-masked]>
Date: Thu, 14 Jan 2010 21:29:53 +0100 (MEZ)

The ongoing off-list follow-up discussion (and review of older
discussion of the topic on namedroppers) has lead to tentative
text for an improved description of the content of AXFR responses
in Section 2.2 of draft-ietf-dnsext-axfr-clarify, based on a
proposal submitted by Andreas Gustafsson.  (To recall, it originally
had been requested in WGLC comments to move the original 2nd paragraph
from Section 3.1 in the -12 draft into Section 2.2 and expand on it.)

To give enough context, below is the full Section 2.2 text planned for
draft version -13, unless substantive arguments are raised against it
(changed/added lines are tagged).

-------- snip --------

2.2.  AXFR Response

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

   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.
|
|  The AXFR protocol treats the zone contents as an unordered collection
|  (or to use the mathematical term, a "set") of RRs.  Except for the
|  requirement that the transfer must begin and end with the SOA RR,
|  there is no requirement to send the RRs in any particular order or
|  grouped into response messages in any particular way.  Although
|  servers typically do attempt to send related RRs (such as the RRs
|  forming an RRset, and the RRsets of a name) as a contiguous group or,
|  when message space allows, in the same response message, they are not
|  required to do so, and clients MUST accept any ordering and grouping
|  of the non-SOA RRs.  Each RR SHOULD be transmitted only once, and
|  AXFR clients MUST ignore any duplicate RRs received.
|
|  Each AXFR response message SHOULD contain a sufficient number of RRs
|  to reasonably amortize the per-message overhead, up to the largest
|  number that will fit within a DNS message (taking the required
|  content of the other sections into account, as described below).
|
|  Some old AXFR clients expect each response message to contain only a
|  single RR.  To interoperate with such clients, the server MAY
|  restrict response messages to a single RR.  As there is no standard
|  way to automatically detect such clients, this typically requires
|  manual configuration at the server.
|
   An AXFR response indicates an error via a single DNS message with the
|  response code set to the appropriate value for the condition
|  encountered, and it is sent when the error condition is detected.
|  Such a message terminates the AXFR session; it MUST copy the Question
|  section from the AXFR query into its Question section, but the
   inclusion of the terminating SOA resource record is not necessary.

   An AXFR server may send a number of AXFR response messages free of an
   error condition before it sends the message indicating an error.

-------- snip --------

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| 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]                     |
+------------------------+--------------------------------------------+

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 15 Jan 2010 14:58:52 +0100

Hi Alfred, Ed,

I have reviewed the axfr draft -12 and seen the text below.  The
document looks good.  I support the document.

1) fill the message up to the max is a bit too short.  Use of multiple
RRs to amortize the message header is a much better line.  Please use
such language.

2) Compression to preserve case is very nice as a feature and 'cool'.
However it is not strictly necessary for interoperability (right? or
does IXFR break because of it?  Yes our IXFR-client implementation
needed fixing for that).  Hence, without interoperability as an
argument, MUST is the wrong word.  Such compression is backwards
compatible, that is ok.

Best regards,
   Wouter

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 15 Jan 2010 16:13:40 +0100 (MEZ)

> document looks good.  I support the document.

Thanks for the review.

> RRs to amortize the message header is a much better line.  Please use

I'm not sure you refer here to the revised text (see below).
Maybe you had the old 2nd paragraph of 3.1 in mind that, on request
of another WGLC review, has been moved to Section 2.2 and expanded
in the meantime.

Regarding per-message overhead:

Depending on the circumstances and the design decisions of an
implementation, there are, beyond the message header, other
components consuming space hence not available for the Answer
section: Question (MAY, but not recommended) and Additional
section (MAY: transaction security, EDNS0).

Also, the total size of the message has an impact on the overhead:
It has been argued (and explained via pointers to past discussion
on namedroppers) that, if messages grow to the theoretical limit
of 64k octets, the limited pointer size for name compression would
counter a potentially substantial amount of opportunities for name
compression; that can be regarded as additional overhead.
In fact, keeping the message size below the 2^14 octet limit for
compression pointers might achieve a much better compression rate
at average and hence reduce the total overhead.

Therefore, I believe that "amortize the per-message overhead" is
reasonable in the current text.

It has been pointed out that the aforementioned restriction of name
compression and the related tradeoff for efficiency are specific
implementation details not affecting interoperability (provided name
compression is applied correctly -- an issue not specific to AXFR)
and should not be discussed in-depth in this protocol specification.
Please tell me if you disagree, preferably giving text.

For ease of reference for readers on the list:
The most recent text changes based on other comments ended up with
the paragraph (4th para of Section 2.2) shown below.

(The entire revised version of Section 2.2 was in the posting you
referred to:
<http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00037.html>)

> argument, MUST is the wrong word.  Such compression is backwards

As a result of the on-list discussion, the tweaked text in my working
copy has substituted "SHOULD" for the "MUST" and now says (new 2nd
para of section 3.4):

|  Since the primary objective of AXFR is to enable the client to serve
|  the same zone content as the server, unlike such normal DNS responses
|  that are expected to preserve the case in the query, the actual zone
|  transfer needs to retain the case of the labels in the zone content.
|  Hence, name compression in an AXFR message SHOULD be performed in a
|  case-preserving manner, unlike how it is done for 'normal' DNS
|  responses.  That is, although when comparing a domain name for
|  matching, "a" equals "A", when comparing for the purposes of message
|  compression for AXFR, "a" is not equal to "A".  Note that this is not
|  the usual definition of name comparison in the DNS protocol and
|  represents a new understanding of the requirement on AXFR servers.

Many thanks as well to other participants for continued off-list
discussion of editorial nits and language improvements.
In particular, Niall o'Reilly has contributed significantly
during this week to textual improvements of the memo.

Kind regards,
  Alfred.

--