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

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

Andreas,
thanks for your additional feedback.

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

But that has not been described in RFC 1995.


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

Interesting quote; thanks! I've picked up that draft now.

But guess what I already have in my working copy
draft-ietf-dnsext-rfc1995bis-ixfr-01(alpha), in Section 4 ...

!  The possible IXFR responses can be classified into various kinds of
!  responses by the number of answer RRs in the conceptual response.
!
!  immediate-error:  empty answer, non-zero RCODE;
!
!  redirect-to-conn:  single SOA RR for sn_n > sn_o, RCODE = NoError;
!
!  you-are-current:  single SOA RR for sn_n = sn_o, RCODE = NoError;
!
!  you-are-more-recent:  single SOA RR for sn_n < sn_o, RCODE = NoError;
!
!  incremental:  multiple RRs, starting and ending with the SOA RR for
!     sn_n > sn_o, which enclose a sequence of one or more change
!     information chunks, the first of which starts with the SOA RR for
!     sn_o (which consequentially is different from sn_n);
!     this is detailed below in Section 4.1
!     (if need arises, a packetized incremental response can be aborted
!     in the second or later response message by sending an empty Answer
!     section and non-zero RCODE);
!
!  fallback-to-axfr:  multiple RRs, starting and ending with the SOA RR
!     for sn_n > sn_o, enclosing a serialization of all other RRs in the
!     zone for sn_n (which hence does not contain any other SOA RR and
!     consequentially cannot start with another SOA RR);
!     this is detailed in [RFC5936]
!     (if need arises, a packetized fallback-to-axfr response can be
!     aborted in the second or later response message by sending an
!     empty Answer section and non-zero RCODE).

... sounds very similar, isn't it?

It's consoling that independent analysis now led to comparable results
as the thinking was more than a decade ago.   :-)


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

Firstly, see above; second, -- excluding the treatment of error cases
that our draft also covers -- the only significant difference between
that pseudocode and the more detailed description in our I-D (already
being expanded upon as well in my working copy) seems to be the
requirement for the second RR to be contained in the first response
packet to avoid the waiting for the second packet before 'incremental'
can be distinguished unambiguously from 'fallback-to-axfr'.

Expect our -01 version to be uploaded by early next week
(my co-authors were busy on a conference this week).

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

According to feedback from current implementers, they seem to have no
trouble with the suggested small tightening -- in particular as it
effectively needs no additional effort in server implementations
that already follow the "SHOULD" for AXFR in RFC 5936 (to pack as
much answer RRs into the response packets as possible) and reuse
related code for IXFR.

I note that the example in Section 7 of the '2000 draft also shows
answer RR packing, which is needed anyway if the IXFR server intends
to make use of the option to send (packed) incremental (or even
fallback-to-axfr) responses in a single UDP response packet, if
they fit therein.

Best refards,
  Alfred.


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


Best regards,
  Alfred.

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext