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

[Alfred Hönes <[e-mail]>]

Note:
  This thread actually has started on the predecessor individual
  draft, but to acoid confusion on the target of the discussion,
  I have changed the Subject to refer to the adopted WG draft,
  draft-ietf-dnsext-rfc1995bis-ixfr-00.


The questions were about the level and detail of the requirements
posed onto an IXFR server in packetizing the conceptual IXFR
response -- in all the different cases that can occur --, and how
thereby the detrimental need for IXFR clients to rely on timeouts
(to determine the outcome/state of an IXFR session, under very
specific conditions) can be avoided.

I have revisited recent messages and previous work, and tried
to arrive at the conclusions that look most reasonable and seem
to correspond to evolving consensus.

Observations and conclusions:

(1)
IXFR is intended as a more efficient method for in-band zone
synchronization than AXFR (for deployment scenarios where it
makes sense -- as explained in the draft); therefore, it seems
fair that the specification is tailored to support timely,
efficient completion of IXFR sessions under most conditions,
and that the requirements for IXFR server implementations be
at least as strong as the comparable requirements for modern
AXFR servers that fully conform to RFC 5936 (excluding the
kludges for backward compatibility still supported by that RFC).

(2)
Updated protocol specifications are not required to still contain
specific requirements, or the lack of specific requirements, if
that has been identified as a weak point in the protocol.

So an updated specification needs to be allowed to specify more
specific requirements than its predecessor, but preferably this
should be done in a manner that interoperability with legacy
implementations is assured as far as it makes sense.

Of course, legacy implementations that do not follow the more
stringent rules of the revised specification cannot claim
conformance to the new specification until they get updated
accordingly.  But that's the fate of implementations at large,
and the DNS world will not be doomed thereby.  :-)

(3)
RFC 5936, Section 2.2 (at the bottom of page 11) specifies:

|  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).

This was the consensus of the WG two years ago.

I conclude -- and that seems to be in line with feedback from
implementers -- that, to achieve the performance goal of IXFR,
rfc1995bis needs to be *at least* as strong as RFC 5936 in its
requirements in Section 3.2.3.

Therefore, unless there is strong consensus to the contrary
arising quickly, the next draft version will use uppercase
"SHOULD" in this context:

!  For multi-message IXFR responses, the conceptional answer is split
!  into segments that are sent in order.  Each segment is comprised of
!  an integer number of full RRs, and for transport efficiency, the
!> response messages SHOULD be filled up with answer RRs as much as
!  possible for the response message size chosen by the IXFR server,
!  taking into account the space needed for the other sections in the
!  messages.

(4)
Bulk IXFR runs over TCP, with potentially concurrent transactions
for different zones served by the same authoritiative servers.
Since the IXFR protocol allows very different kinds of responses
(as specified in a fully backward-compatible manner in the draft)
the most important kinds of which will consist of multiple response
messages, yet does not contain an overall length indication or a
specific, generic "end-of-response" indication for multi-message
responses, there is a clear need for:
  * rules that ensure that the kind of response can be determined
    instantaneously and without ambiguity upon receipt of the first
    response message; and
  * rules that clearly allow to determine when a received response
    message is the last one in an IXFR session.

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.

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.
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.

The core of this clarification will be a new clause added below the
text quoted in (3) above, stating (modulo wordsmithing t.b.d.):

!  If an IXFR server intends to send a conceptual IXFR response that
!  is comprised of at least two answer RRs, the first two RRs of the
!  response MUST be sent in the first response packet to allow the IXFR
!  client to immediately distinguish the kind of response coming in.
!  An IXFR server MUST NOT send over connection-oriented transport the
!  kind of (single-RR) IXFR response that indicates that the server has
!  to send a multi-packet response and hence the IXFR request needs to
!  be retried over connection-orientend transport (currently: TCP);
!  this kind of response is only allowed in response to an IXFR query
!  received over connectionless transport (currently: UDP).
!  See Section 4 for the details of the various kinds of conceptual
!  IXFR responses and how an IXFR client distinguishes these.

The verbiage already present in the draft that indicates the
necessity to anyway set up timeouts as a safeguard to protect
agains fatal conditions will be amended to say that this is also
necessary for seamless interoperation with older IXFR servers not
conforming to these new requirements, but the efficiency of IXFR
operations in specific circumstances will no longer depend on
clever heuristics to choose proper values, once the IXFR servers
used in a given deployment are updated to conform to the revised
specification, since the timeout values then will only apply in
fatal cases and can be chosen rather long for resilience reasons
without negative effects on normal protocol operation in specific
cases.



Finally, a closely related topic / question:

(5)
The example of "fallback to AXFR" in the draft (at the very end of
Section 2) currently suggests that, for efficiency at both the IXFR
server and the IXFR client, for full zone transfer (fallback to AXFR)
an IXFR server (typically) sends the zone RRs grouped by RRset.

It has been correctly observed that this ordering does not correspond
to a requirement contained in the new AXFR specification, RFC 5936.

Should this behavior be recommended/RECOMMENDED in the draft
for new IXFR server implementations?


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+