BIND 10 #1261: IXFR-in protocol handling

[BIND 10 Development]

#1261: IXFR-in protocol handling
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20111011
  blocker                            |            Resolution:
                  Component:  xfrin  |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:5 vorner]:

 > I'm not going to review it, but I'm reading the code to know how to
 integrate #1262. Is it OK to commit the diff after each sequence?
 Shouldn't the whole transfer be atomic?

 We (briefly) discussed this in the parent ticket (#1212) and we were
 not sure about that.
 http://bind10.isc.org/ticket/1212#comment:7

 If I understand it correctly, this is what BIND 9 does, too.  I posted
 an email to bind-users asking for a clarification, but I've not got
 any response:
 https://lists.isc.org/pipermail/bind-users/2011-October/085161.html

 As mentioned in that email message, this may not necessarily break
 what RFC1995 says, depending on the interpretation of "all the
 differences" and "older/newer version".

 For now, I suggest keeping the current code and adding the following
 note to the XfrinState class documentation:

 {{{
     Note that changes are committed for every "difference sequence"
     (i.e. changes for one SOA update).  This means when an IXFR response
     contains multiple difference sequences and something goes wrong
     after several commits, these changes have been published and visible
     to clients even if the IXFR session is subsequently aborted.
     It is not clear if this is valid in terms of the protocol
 specification.
     Section 4 of RFC 1995 states:

        An IXFR client, should only replace an older version with a newer
        version after all the differences have been successfully processed.

     If this "replacement" is for the changes of one difference sequence
     and "all the differences" mean the changes for that sequence, this
     implementation strictly follows what RFC states.  If this is for
     the entire IXFR response (that may contain multiple sequences),
     we should implement it with one big transaction and one final commit
     at the very end.

     For now, we implement it with multiple smaller commits for two
     reasons.  First, this is what BIND 9 does, and we generally port
     the implementation logic here.  BIND 9 has been supporting IXFR
     for many years, so the fact that it still behaves this way
     probably means it at least doesn't cause a severe operational
     problem in practice.  Second, especially because BIND 10 would
     often use a database backend, a larger transaction could cause an
     undesirable effects, e.g. suspending normal lookups for a longer
     period depending on the characteristics of the database.  Even if
     we find something wrong in a later sequeunce and abort the
     session, we can start another incremental update from what has
     been validated, or we can switch to AXFR to replace the zone
     completely.
 }}}

-- 
Ticket URL: <http://bind10.isc.org/ticket/1261#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development