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      |
-------------------------------------+-------------------------------------

Comment (by stephen):

 > Should I read the RFC as well just to make sure you didn't miss anything
 as well?
 Might be useful.

 > It says the class must be IN. Does it mean we can't use IXFR for
 different class?
 Good point. I've updated the requirements to remove reference to the IN
 class, but updated the test specification to indicate that the tests
 should carried out for each class.  (And noted that at present, BIND 10
 only supports class IN.)

 > Why are the version numbers by tens? Isn't it enough to just miss the
 one single number that is not present?
 More that when I started writing the tests I was unsure whether I needed
 to be able to specify multiple serial numbers between the serial numbers
 of two versions, so left a gap of 10.  Changes to be n-2, n-4, n-6.

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

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

 > For 4/7, can we simulate a TCP connection that gets truncated/reset? And
 see the data from the beginning didn't get stored?
 That is a test that needs to be done.  For the moment, I've added it as a
 "TODO" as this might involve a good deal of work to capture a binary data
 stream and remove the last part of it.

 > Can we check that the IXFR is sent when the SOA times out? Or is that
 too long to test? Should we mention it?
 Good point.  We can do it, just set the SOA refresh time to a small value.
 I've added a requirement for it and a test.

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