Subject: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-03.txt (fwd)

From: Alfred Hönes <[email-masked]>
Date: Fri, 9 Mar 2012 14:10:26 +0100 (MEZ)

Folks,
I have submitted a revised version of our RFC 1995bis (IXRF) draft.

As discussed at the Maastricht (IETF 78) and Prague (IETF 80)
DNSEXT sessions, this topic is regarded as covered by the
chartered work item for DNSEXT vovering IXFR-ONLY.

The new version tries to capture the outcome of the on-list
discussion (and some internal conversations) since the posting
of the -02 version last spring, after IETF 80, in particular
the related threads on namedroppers in June/August 2011.
My apologies for the delays in the editorial work.

To allow better threading of related list submissions, I will post
two more messages regarding:

a) the changes from -02 to -03 ; and

b) the next steps with this draft.

Please review the draft and the changes and opt for the next steps
to undertake with the I-D, as will be detailed soon in these
upcoming messages.

----- Forwarded message from [email-masked] -----

> From: [email-masked]
> To: [email-masked]
> Cc: [email-masked]
> Message-Id: <[email-masked]>
> Date: Fri, 09 Mar 2012 04:12:27 -0800
> Subject: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-03.txt
>
> A new version of I-D, draft-ah-dnsext-rfc1995bis-ixfr-03.txt
> has been successfully submitted by Alfred Hoenes and posted
> to the IETF repository.
>
> Filename:        draft-ah-dnsext-rfc1995bis-ixfr
> Revision:        03
> Title:           DNS Incremental Zone Transfer Protocol (IXFR)
> Creation date:   2012-03-09
> WG ID:           Individual Submission
> Number of pages: 32
>
> Abstract:
>    The standard means within the Domain Name System protocol for
>    maintaining coherence among a zone&#39;s authoritative name servers
>    consists of three mechanisms.  Incremental Zone Transfer (IXFR) is
>    one of the mechanisms and originally was defined in RFC 1995.
>
>    This document aims to provide a more detailed and up-to-date
>    specification of the IXFR mechanism and to align it with the current
>    specification of the primary zone transfer mechanism, AXFR, given in
>    RFC 5936.  Further, based on operational experience, this document
>    juxtaposes to the original IXFR query a new query type, IXFR-ONLY,
>    that will likely be preferred over IXFR in specific deployments.
>
>    This document obsoletes and replaces RFC 1995.
>
>
> The IETF Secretariat

----- End of forwarded message from [email-masked] -----

The draft and diffs are available online at the common locations,
including the IETF Tools page:
  <http://tools.ietf.org/html/draft-ah-dnsext-rfc1995bis-ixfr-03>

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

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 9 Mar 2012 19:37:01 +0200

> I have submitted a revised version of our RFC 1995bis (IXRF) draft.

Regrettably, I haven't had time to respond to the previous versions of
the draft, but based on a quick review of the -03 version, I think it
still has problems.

In particular, Section 4 (Response Contents) specifies client behavior
where decisions are made based on an RR occurring alone in a message,
or multiple RRs occurring in the same message, which makes the
locations of the boundaries between messages significant.  For
example, the draft says:

>       An IXFR client that receives over connection-oriented transport
>       an IXFR response message (as the first response message related
>       to its IXFR query) that contains only a single SOA RR with sn_n
>       unequal to sn_o MUST discard the response message (see below).

and:

>   c.  The server serial (sn_n) differs from the client serial (sn_o)
>       sent in the Authority section of the IXFR query, and this SOA RR
>       is followed by another SOA RR in the same response message. 

The way I have always interpreted RFC 1995 is that the message
boundaries have no significance to the protocol, and that a server can
break up the ordered stream of RRs forming the IXFR response into
messages at arbitrary points without affecting client behavior.  This
interpretation seems consistent with AXFR, and with the following text
in the draft:

>   The conceptional "answer" carried in a multi-message response is the
>   concatenation of the content of the Answer sections in these response
>   messages, in the order they are sent

I don't think the current Section 4 accurately describes the behavior
of existing implementations (at least not the ones I am familiar
with), nor does it appear to be fully interoperable with those
implementations.  For example, existing servers will send a message of
the form described in the first quoted paragraph above when the second
RR in the transfer is too large to fit in the same message as the
initial SOA, and may conceivably also do it in other circumstances,
such as when that second RR exceeds the 16k compression limit.
Existing clients will accept such a response, but a client following
the draft will not.
-- 
Andreas Gustafsson, [email-masked]

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 9 Mar 2012 19:05:56 +0100 (MEZ)

Andreas,
thanks for your taking time so quickly now to look into the I-D.

Before entering into the details of later Sections,
I think we should establish a solid base.

So to start with there, my questions are:

Is the high-level description given in Section 2 ...
a)  logically correct (from your point of view) ?
b)  consistent with the terse text in RFC 1995 ?
c)  consistent observed on-the-wire format, and hence with
    implementations ?

If you disagree, please give the details.

But if that's correct, we have the problem that the established
response syntax unfortunately does not allow precise parsing
without knowledge of where the end of the response is.
Based on this insight, the draft tries to describe behavior
that depends on a minimum amount of timing/grouping requirements,
yet still allows "fast" determination of the response mode and
correct parsing of the IXFR response in all corner cases,
without having to rely on precious waiting time in order to
determine whether the last response packet received is indeed
the last response packet the server has sent.
IMO, unfortunately, not all response modes defined in RFC 1995
carry an implied "end tag" (sentinel SOA RR, as in AXFR).

So please allow me to defer going into the details below
until we have established consensus on the above basic points
as laid out in Section 2.
Once this has been done, the client's parsing behavior model
described in Section 4 can be discussed much more efficiently.

Kind regards,
  Alfred.

---

From: Andreas Gustafsson <[email-masked]>
Date: Sat, 10 Mar 2012 11:31:11 +0200

> c)  consistent observed on-the-wire format, and hence with

There are some issues with section 2 also, such as defining the
condition of a client being up-to-date as sn_o = sn_n, when it should
be sn_o >= sn_n (in the RFC 1982 sense).  But apart from that, I think
it is sufficiently correct to be used as a basis for the present
discussion regarding the significance of message boundaries in
classifying responses.

> without knowledge of where the end of the response is.

It has been a long time since I last implemented IXFR, but I think
the following procedure should work:

   If the response is over UDP, and the first RR in the response is a
   SOA whose serial is greater than the client serial, and the
   response contains no further RRs, then we have case (b) of the
   draft, "response too large for UDP".  This is the only place where
   we must determine whether or not an RR is followed by further RRs,
   and although that is not possible in the TCP case (without making
   message boundaries significant, or by resorting to timeouts or
   such), it is possible in the UDP case because UDP responses can
   only consist of a single message.

   Otherwise, examine the first RR in the response, which must be a
   SOA.  If its serial is less than or equal to the client serial, we
   have case (a), "up to date".

   Otherwise, examine the second RR in the response.  If it is not a
   SOA, we have case (d), "fallback to AXFR".

   Otherwise, we have a response beginning with two SOA RRs, which is
   case (c), with sub-cases as discussed in the draft.

Some of the sub-cases of (c) may need further discussion, but let's
first see if we can come to an agreement regarding the overall
algorithm for classifying responses into the four classes (a)
through (d) in the draft.
-- 
Andreas Gustafsson, [email-masked]