BIND 10 #1331: Extend the ZoneUpdater class to support adding diffs

[BIND 10 Development]

#1331: Extend the ZoneUpdater class to support adding diffs
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111122
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  4
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:         |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:12 vorner]:

 About the latest code:

 - There was a typo that breaks compile.  Fixed and pushed.
 - In zone.h, is this "...look like an IXFR"?
 {{{
     /// If journaling was requested when getting this updater, it might
 reject
     /// to add the RRset if the squence doesn't look like and IXFR (see
 }}}
   (didn't notice that in the previous review).  Also, I guess we should
 now
   change "might reject" to "will reject".  Applies to both addRRset() and
   deleteRRset().

 > Replying to [comment:11 jinmei]:
 > > forgot to mention this: do we want to check when an SOA RRset is
 added/deleted
 > > it has exactly one RDATA?
 >
 > Well, I don't think such change should be related to this branch. We
 might want to check that, and check that CNAME is the only one and so on…
 >
 > This branch wouldn't be the only thing that would act strange if there
 are multiple SOA RRs (considering they would have different serial, if
 they were the same, this branch wouldn't mind). But if you think it
 should, I have no problem adding the check. Anyway, I think this should be
 checked on some different level, because we can't do a complete check
 anyway (because add „merges“ with existing data anyway).

 I don't necessarily think it should; I just wondered.  But the reason
 about this is different from other semantics errors like duplicate
 CNAME.  In the case of multiple SOA RRs, it would break the specific
 assumption of this method, that is, the resulting sequence is in the
 IXFR order.

 BIND 9 does some other consistency checks such as whether serials are
 increasing (duplicate SOA is impossible in BIND 9 due to the API
 restriction).

 I simply don't know how much we want to check here.  At least the
 duplicate SOA case shouldn't happen via ixfr-in, and the dynamic
 update server will probably ensure that doesn't happen itself, so
 maybe we can defer the decision until we see the real need for it.
 I'd leave it to you.

 Finally, in case you forget it, please check with Jeremy whether we
 want to have a changelog entry.

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