BIND 10 #1210: IXFR system test specification

[BIND 10 Development]

#1210: IXFR system test specification
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  stephen
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20111011
  critical                           |            Resolution:
                  Component:  xfrin  |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  6
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => stephen


Comment:

 Hello

 Replying to [comment:12 stephen]:
 > > Well, can a zone contain multiple RRs with the exactly same data? If
 not, the „addition“ of the same data would be NOP (since the zone would be
 kind of set, not zone and such RR would be already there).
 > Considering the recent discussions on bind10-dev, apparently not. (Or at
 least, the zone should not contain multiple RRs with exactly the same
 data.)
 >
 > For that reason, I think a test in the presence of multiple identical
 RRs would have little point as we would be testing behaviour in the
 presence of a behaviour which is incorrect (it is against
 [http://tools.ietf.org/html/rfc2181 RFC 2181]) and which we want to
 eliminate.

 I believe we didn't understand each other correctly. I do not propose to
 explicitly put multiple same RRs into the zone. I propose to:
  * Put `www.example.org. A 192.0.2.1` into the zone.
  * Apply diff:
 {{{
 - www.example.org. A 192.0.2.1
 + www.example.org. A 192.0.2.1
 }}}

 This is completely correct, even if it is NOP. This way, the only instance
 is removed first and then returned again. The result is we get the
 original data in the zone.

 If the additions would be applied first (the wrong behaviour), we would
 get a zone with two identical records, which is wrong by itself. But they
 would either get collapsed to single one, or the remove would delete both,
 so we would detect a wrong (empty) zone.

 And I got another idea where the order might matter. What should we do if
 we are asked to remove an RR that is not in the zone? If we have an empty
 zone and the same diff arrives, we should first apply the remove (which
 does nothing), then add the single record. If it would be the other way
 around, it would be first added and then removed, resulting in empty zone.

 Is what I mean little bit more clearer?

 Thanks

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