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:9 stephen]:
 > > Should I read the RFC as well just to make sure you didn't miss
 anything as well?
 > Might be useful - it's a relatively short document.

 I didn't find anything you missed. The test specification could maybe be
 more explicit on when there are two SOA records in a row and when only
 one, but it does link to the type described in the RFC when needed, so
 it's not necessary.

 > > You propose to use bind9 for the tests. Isn't it easier to prepare the
 packets to answer in some files and use socat for example to send/receive
 the packets?
 > The reason for BIND 9 is that this implicitly checks that the format of
 the request is correct.  It also handles the generation of NOTIFY packets
 to the BIND 10 server that cause it to send the IXFR request.  Also, by
 loading different versions of a zone, it is possible to generate
 difference packets without the need to explicitly create the binary data.

 Well, on the other hand, Bind 9 might be wrong as well. Checking
 explicitly might be useful in some of the tests. But it is true that
 creating the binary data might take some work (as well as launching bind 9
 on the other hand). I just wanted to point out another possibility.

 > > The 4/4 says the order of changes is set. However, it also says the
 whole transaction is atomic. I think it refers to the effect on the
 resulting data in the zone. If we, for example, had a „delete this RR“ and
 then again „add this RR“, it results in a zone containing it. If it is the
 other way around, it results in a zone without. Maybe some data might test
 this?
 > I noted that requirement because it is mentioned in
 [http://tools.ietf.org/html/rfc1995 RFC 1995].  However, the only
 circumstance I can see in which it makes a difference is where the update
 comprises the deletion of a RR and the addition of an identical RR.  Then
 the action depends on whether "delete this RR" means "delete all RRs in
 the zone identical to this RR".  If so, we get the effect you describe.
 If not, and "delete this RR" means "delete the first RR matching this", it
 makes no difference.
 >
 > Thoughts?

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

 Anyway, can we add a test with this kind of data?

 Thanks

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