wiki:IxfrSystemTests

IXFR Test Specification

Introduction

This document lists the systems tests required to check that BIND 10 IXFR conforms to the specification for incremental transfers described in RFC 1995. The specification has been translated into a detailed requirements document and the tests are made against that.

System Test Specification

This section outlines the tests required to check the requirements listed in the detailed requirements document. It does not mandate how the tests should be carried out, only the broad outline of the tests. In brackets after the description of each test is the requirement number(s) covered by the test.

IXFR-out Tests

These are tests of BIND 10 acting as a master for a slave server.

Notes:

  • This set of tests should be repeated for all DNS classes supported by BIND 10. At the time of writing (October 2011), BIND 10 only supports the IN class.

Test Set 1

Preconditions
A BIND 10 system has been pre-loaded with a zone (serial "n") and a number of previous versions of the zone with serial numbers that should not be consecutive (e.g "n - 2", "n - 4" and "n - 6" etc.). The zone should be large enough that it does not fit within an single UDP packet. The changes should be such that the two most recent deltas can be included within a single UDP packet, but that all deltas cannot be.

Tests

  1. Send a UDP IXFR request with the serial number set higher than the current version of the zone. The server should respond with a single UDP packet containing its SOA (2/4).
  2. Send a UDP IXFR request with the serial number set to the same as the current version of the zone. The server should respond with a single UDP packet containing its SOA (2/4).
  3. Send a UDP IXFR request with the serial number set to the SOA of the serial number of the previous version of the zone (n - 2). The server should respond with a single UDP packet containing the most recent difference. (2/5/b, 4/2, 4/3)
  4. Send a UDP IXFR request with the serial number set to the serial number of the version before the previous version of the zone (n - 4). The server should respond with a single UDP packet containing the most recent two differences (n - 2, n - 4). The difference sequences in the answer ascending order of SOA sequence number(2/5/b, 4/2, 4/3, 4/5)
  5. Send a UDP IXFR request with the serial number set to the serial number of the earliest version of the zone available. The server should respond with a single UDP packet containing its SOA (2/5/c).
  6. Send a UDP IXFR request with the serial number set to the serial number earlier than that of the zone, but not equal to the serial of one of the differences (e.g. n - 15). The server should respond with a single UDP packet containing its SOA (6/5).
  7. Send a TCP IXFR request with the serial number set to the serial number of the last but two zone (n - 6). The server should respond with a TCP response containing all differences (n - 2, n - 4, n - 6). The difference sequences in the answer ascending order of SOA sequence number(2/5/a, 2/5/b, 4/2, 4/3, 4/5)

Test Set 2

Preconditions
A BIND 10 system has been pre-loaded with a zone (serial "n") and a number of previous versions of the zone with serial numbers that should not be consecutive (e.g "n - 2", "n - 4" and "n - 6" etc.). The zone should be small enough that it fits within an single UDP packet, but the number of deltas large enough that they do not all fit within a single packet.

Tests

  1. Send a UDP IXFR request with the serial number set to the serial number earlier than that of the zone, but not equal to the serial of one of the differences (e.g. n - 3). The server should respond with a single UDP packet containing the entire zone (6/5, 4/1).
  2. Send a UDP IXFR request with the serial number set to the serial number of a version of the zone such that the number of RRs added and removed in the deltas is more that the number of RRs in the zone. The server should respond with a single UDP packet containing the entire zone (6/5, 4/1, 5/2/a).
  3. Send a UDP IXFR request with the serial number set to the serial number of the earliest version of the zone. The server should respond with a single UDP packet containing the SOA of the zone (6/5, 4/1, 5/2/a).

IXFR-in Tests

These are tests of BIND 10 acting as a slave to a master server.

Test Set 1

Preconditions
A BIND 9 system has been pre-loaded with a zone (serial "n") and a number of previous versions of the zone with serial numbers that should not be consecutive (e.g "n - 2", "n - 4" and "n - 6" etc.). The zone should be large enough that it does not fit within an single UDP packet. The changes should be such that the two most recent deltas can be included within a single UDP packet, but that all deltas cannot be.

Suitable logging for IXFR should be configured.

A client BIND 10 system configured for IXFR set up with the last-but two version of the zone.

Tests

  1. Get the BIND 9 system to send a NOTIFY to the system under test. The system under test should respond with an IXFR request and the server with a single IXFR reply. Upon completion, the system under test should contain the latest copy of the zone. (2/6/a, 2/6/c, 3/1, 4/7)

Test Set 2

Preconditions
As for test set 1, but with the BIND 10 system loaded with the previous-but-two (n - 6) version of the zone.

Tests

  1. Get the BIND 9 system to send a NOTIFY to the system under test. The system under test should respond with an UDP IXFR request, then a TCP IXFR request. Upon completion of the TCP response, the system under test should contain the latest copy of the zone. (2/6/e, 3/1)

Test Set 3

Preconditions
A BIND 9 system has been pre-loaded with a zone (serial "n") and set such that IXFRs are disabled.

A BIND 10 system configured for IXFR set up with the last-but two version of the zone.

Tests

  1. Get the BIND 9 system to send a NOTIFY to the system under test. The system under test should respond with an IXFR request, then an SOA request, then an AXFR request. Upon completion, the system under test should contain the latest version of the zone. (2/6/b, 3/1)

Test Set 4

Preconditions
A BIND 9 system has been pre-loaded with a zone (serial "n") and set such that IXFRs are enabled but notifications are disabled.

A BIND 10 system configured for IXFR set up with the last-but two version of the zone (which should have an SOA refresh time set to a short value).

Tests

  1. Wait for the SOA refresh time to expire. The client should send an IXFR request to the server (A/1)

Test Set 5

Preconditions
A BIND 10 system configured for IXFR set up with the last-but one (n-2) version of the zone (which should have an SOA refresh time set to a short value).

A program is running able to respond to an IXFR request with special IXFR response packets as described below.

Tests

  1. In response to the IXFR request from the BIND 10 system when the refresh time expires, send an IXFR difference sequence (with the latest SOA serial) that deletes and inserts the same record. After the exchange of packets, the contents of the zone on the system under test should be unchanged apart from the SOA serial number (4/4).

    Note: this test depends on the behaviour of BIND 10 when adding a RR to the zone that is identical to one already there. If BIND 10 allows duplicate RRs in the zone, the order of applying the RR addition and RR deletion does not matter. Otherwise processing the addition of the RR before the deletion should result in BIND 10 reporting an error.
  1. In response to the IXFR request from the BIND 10 system when the refresh time expires, send an IXFR difference sequence (with the latest SOA serial) that deletes a record that does not exist in the zone and inserts a new record. The server should report an error. (A/2)

Test Set 6

Preconditions
A program is running able to respond to a UDP IXFR request with a UDP packet containing the SOA of the current version of the zone, and to a TCP IXFR request with a an incomplete difference sequence.

A BIND 10 system configured for IXFR set up with the last-but one (n-2) version of the zone (which should have an SOA refresh time set to a short value). The system should be configured so that the IXFR master is the program described above.

Tests

  1. When the BIND 10 refresh timer expires, it should send a UDP IXFR request to the server program. It should then start a TCP IXFR session which should prematurely finish. The server log should show that the IXFR session was terminated, and the contents of the zone should be unchanged. (4/7)

Requirements Not (Directly) Tested

The following requirements are not tested as they are timing-dependent or would require excessive test code/instrumentation of the XFR code. They are best checked via unit tests and/or inspection:

2/3 Updated zone should be saved to stable storage before the client serves queries
Without instrumenting the server, it will be difficult to check that the updated zone has been saved to disk before queries are served.

2/6/d If the response to the IXFR query is a UDP packet containing an SOA...
Not clear how to force BIND 10 to perform an IXFR query without first doing a query for the SOA.

2/7/a The Server should enable UDP checksums on all responses
On modern systems, UDP checksums are enabled on a system-wide basis; this is not really something that is under the server's control.

2/7/b A client that receives an IXFR UDP packet is a checksum of 0 should retry the IXFR using TCP
UDP checksums can only be obtained through raw socket I/O, in which case the program must do its own handling of the UDP protocol. BIND 10 does not use raw socket I/O.

5/2/b The server should remove old versions of the zone if the total length of an IXFR response (from that version of the zone) would be greater than the length of an AXFR
Tested indirectly in that the response to a request an old version where an IXFR meets this condition would result in an SOA response indicating an AXFR should be tried; but without instrumenting the server, it is not possible to check that the server purges such differences.

5/3 The server may get rid of versions of the zone older than the SOA expire time
This is an optional requirement and is not implemented in BIND 10.

6/1 The server may condense multiple difference sequences into a single difference sequence
This is an optional requirement and is not implemented in BIND 10.

Last modified 6 years ago Last modified on Dec 7, 2011, 1:09:50 AM