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

[Andreas Gustafsson <[e-mail]>]

Alfred,

Last week, you wrote (referring to the pseudocode in Appendix A
of http://tools.ietf.org/html/draft-ietf-dnsext-ixfr-01)

> [...] 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'.

Yes, that difference is the sticking point.

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

As I see it, the proposed requirement to send the first two RRs in the
same message isn't so much a "small tightening" as a fundamental
change to the nature of the protocol, from one defined in terms of a
sequence of RRs where message boundaries carry no meaning to one where
the message boundaries are significant.

Also, RFC 5936 doesn't actually require packing "as much answer RRs as
possible" into the response message.  It says:

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

Consider for example a server implementation that chooses to start a
new message whenever adding another RR to the current message would
cause it to grow larger than 16 kB, in order to take maximum advantage
of name compression given that compression pointers can only point
into the first 16 kB of the message.  I would consider such an
implementation compliant with the above SHOULD, but it would not meet
the proposed requirement when the second RR in the transfer is
larger than 16 kB.

Even filling the message with as many answer RRs as possible is not
always sufficient meet the proposed requirement.  When the second RR
is close to 64 kB in size, it may not fit in the same message as the
initial SOA even though it would fit in a separate message.  If
servers will be required to treat this situation as an error instead
of just sending the RRs in separate messages, code changes are needed.

RFC 5936 also says:

   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.

There are server implementations where such manual configuration
causes single-RR messages to be sent to both AXFR and IXFR clients.
A client following the decision procedure in the draft will fail to
interoperate with a server configured in this way.

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

It's not that existing servers are incapable of packing multiple RRs
per message, or that they won't do it in the typical case, but that
there are atypical cases such as transfers involving large RRs or
non-default configurations where the initial SOA can end up being
sent in a message of its own.

That said, my main objection is not to the draft's "tightening" of
what the server may send, but to the corresponding "loosening" of what
the client must accept.  In other words, whether or not servers are
required to send the first two RRs in the same message, clients should
be required to accept TCP IXFR responses divided into messages at
arbitrary RR boundaries.

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