BIND 10 #2752: define and implement ZoneDataUpdater::delete()

[BIND 10 Development]

#2752: define and implement ZoneDataUpdater::delete()
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |                       Status:  new
            Priority:  medium        |                    Milestone:  Next-
           Component:  data source   |  Sprint-Proposed
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         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:1 vorner]:
 > The origin node should never become empty. Who should check if it is OK
 to delete such RRset (such as NS or SOA)?

 Actually, it's an open question.  One tricky point is that wherever we
 (or whoever) do this check, it will be quite difficult to revert to
 the original state of zone (we may notice an attempt of deleting SOA
 RR after making a bunch of modifications; even if we record all the
 history of changes and try to cancel them, it won't be free from
 failures).

 Meanwhile, I guess such invalid operations should have been rejected
 at a higher layer or other processes.  It should be the case for
 IXFR-in, and we can (and actually should regardless of this issue)
 extend DDNS to check that condition before committing the changes.
 If and when we add other UI of modifying in-memory data such as via
 bindctl, we can also implement pre-commit check at a higher layer.
 So, I guess we can generally assume the given set of changes preserves
 the validity of the zone.  And, if so, I believe we can do the same as
 we do for the entire load: check the zone after applying a set of
 changes just in case, and, if it fails (note that it basically
 shouldn't), we disable the entire zone rather than trying to cancel
 the changes.

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