Re: [dnsext] draft-ietf-dnsext-rfc1995bis-ixfr -- questions on s3.2.3

[Andreas Gustafsson <[e-mail]>]

Alfred,

You wrote:
> As already indicated in the draft, there are a few specific
> conditions where the interpreation of an IXFR response cannot be
> disambiguated until (and if) the next response message arrives,
> unless IXFR servers are required to packetize their responses
> in a manner that allows immediate disambiguation at the client.
> Waiting (in corner cases) for another response message in a given
> IXFR session in order to eventually determine the status of the
> response requires the IXFR client to set a timeout and wait -- as
> a normal protocol operation.  All such timeouts are generally
> regarded as detrimental, and in particular detrimental to the
> performance optimization we have as a target goal for IXFR.

Waiting for additional messages to arrive (with a timeout for error
recovery) is a standard part of any protocol involving multi-message
responses and should not be considered detrimental as such.  The
detrimental case would be if a client could not determine in advance
whether or not the server is going to send another message, and had to
resort to using a timeout as a way of detecting the end of the
response as part of normal protocol operation.  The IXFR protocol as
specified in RFC 1995 does *not* require clients to resort to such
methods; it is always possible for an RFC 1995 client to unambiguously
determine whether or not the server will send an additional message.

Digging in the archives, I found a draft from an earlier effort to
produce an update to the IXFR specification, back in 2000:

  http://tools.ietf.org/html/draft-ietf-dnsext-ixfr-01

Quoting that draft:

   A slave receiving an IXFR response needs to classify it as one of the
   following four cases:

      UDP-overflow     An indication that the transfer will not fit in a
                       UDP packet and should be retried over TCP

      up-to-date       An indication that the serial number of the
                       request is current and no transfer is necessary

      incremental      An incremental transfer

      nonincremental   A full zone transfer

   Performing this classification requires some care.  For example,
   UDP-overflow responses differ from UDP up-to-date responses only in
   the value of the SOA serial number.  Also, to distinguish between a
   nonincremental and an incremental transfer, the slave needs to
   receive the first two response RRs and check whether the second one
   is a SOA.  If the master chose to transmit each RR in a separate TCP
   message, this involves waiting for a second TCP response message.  On
   the other hand, in the case of an up-to-date response, the slave must
   not wait for a second TCP message as doing so would cause it to hang
   waiting for a message the master will never send.  Therefore, the
   slave must examine the first message and eliminate the possibility
   that it is a TCP up-to-date response before it attempts to receive a
   second message.

   Slaves must not attempt to classify a response based on incidental
   information such as the presence or absence of a question section,
   the QTYPE field of a possible question section, or the number of
   response RRs in a TCP response message.

   An example algorithm for classifying IXFR responses appears in
   Appendix A.

> Therefore, unless strong consensus to the contrary arises quickly,
> the next draft version will contain a more precise description of
> what conditions indicate the end of an IXFR response, and how the
> different kinds of IXFR responses are to be disambiguated.

I suggest doing the latter by reusing the above quoted text from
draft-ietf-dnsext-ixfr-01, and/or the pseudocode from its Appendix A.

> But this needs to impose on IXFR servers a very few new, specific,
> stronger requirements for the packetization of their responses.
> These conditions already are in the draft, but the text will be
> revised to distinguish the new requirements and spell out the
> rationale.

I still say there is no actual need to introduce any such new
packetization requirements.

Regards,
-- 
Andreas Gustafsson, [e-mail]