wiki:DDNSSystemTests

DDNS Test Specification

We probably want to split the BIND10-specific tests and the protocol compliance tests into separate feature tests; It is currently not possible to run a different server in our framework but it might be at some point in the future.

BIND 10 specific Tests

Module tests

These are specific to BIND 10, and should probably be implemented in a different feature file.

Preconditions A BIND 10 system has been configured *not* to run b10-ddns. It is be preloaded with an in-memory zone, read from the database, with a SOA SERIAL value of n. If b10-ddns does have configuration yet, the loaded zone should *not* be in it. If it has ACL configuration, it should be such that updates would be accepted from the client running the tests.

Tests

  • The SERIAL value of the SOA in the zone should be n
  • The b10-ddns module should not be running
  1. Send a DDNS Update for the zone with a SERIAL of n + 1
    • The server's response should be REFUSED (or should it be NOTIMPL?)
    • The SERIAL value of the SOA in the zone should be n
  2. Update the configuration to run b10-ddns.
    • The b10-ddns module should now be running.
  3. Send a DDNS Update with a SOA record with SERIAL n + 2
    • The server's response should be REFUSED
    • The SERIAL value of the SOA in the zone should be n
  4. Update the configuration so that b10-ddns will support updates for the zone
  5. Send a DDNS Update with a SOA record with SERIAL n + 3
    • The response should be NOERROR
    • The SERIAL value of the SOA in the zone should be n + 3
  6. Send a command to stop b10-ddns (without removing it from the configuration, i.e. it should be restarted)
  7. Wait for b10-ddns to be restarted
  8. Send a DDNS Update with a SOA record with SERIAL n + 4
    • The response should be NOERROR
    • The SERIAL value of the SOA in the zone should be n + 4
  9. Send a command to stop b10-auth (without removing it from the configuration, i.e. it should be restarted)
  10. Send a DDNS Update with a SOA record with SERIAL n + 5
    • The response should be NOERROR
    • The SERIAL value of the SOA in the zone should be n + 5
  11. Update the configuration to no longer run b10-ddns
  12. Send a DDNS Update for the zone with a SERIAL of n + 6
    • The server's response should be REFUSED (or should it be NOTIMPL?)
    • The SERIAL value of the SOA in the zone should be n + 5

(Note: this test also checks that the in-memory datasource is updated after a DDNS update. We may want to split that to a separate test.) (Note2: this will currently fail at at least step 8)

ACL tests

Preconditions A BIND 10 system has been configured to run b10-ddns. It has been preloaded with a zone of class IN with a SOA SERIAL value of n. b10-ddns has said zone enabled for dynamic updates, and the ACL is set to accept updates from the client running the tests.

Tests

  1. Send a DDNS Update message for the zone, which adds an RR that is not present in the zone yet
    • The response should be NOERROR
    • The SOA SERIAL value should be n + 1
    • The new record should be present in the zone.
  2. Send a bindctl command to update the ACL to refuse the client running the tests
  3. Send a DDNS Update message for the zone, which adds an RR that is not present in the zone yet
    • The response should be REFUSED
    • The SOA SERIAL value should be n + 1
    • The new record should be present in the zone.
  4. Send a bindctl command to update the ACL to allow the client running the tests
  5. Send a DDNS Update message for the zone, which adds an RR that is not present in the zone yet
    • The response should be NOERROR
    • The SOA SERIAL value should be n + 2
    • The new record should be present in the zone.

Xfrout tests

Preconditions A BIND 10 system has been configured to run b10-ddns and b10-xfrout. It has been preloaded with a zone of class IN with a SOA SERIAL value of n. b10-ddns has said zone enabled for dynamic updates, and the ACL is set to accept updates from the client running the tests. b10-xfrout has been configured to send notifies for this zone. A second server is set up to be a secondary for this zone.

Tests

  1. Send a DDNS Update message for the zone, which adds an RR that is not present in the zone yet
    • The response should be NOERROR
    • The SOA SERIAL value should be n + 1
    • The new record should be present in the zone.
    • The SOA SERIAL value at the second server should also be n + 1
    • The new record should be present in the zone at the second server.

General Protocol Compliance Tests

SOA Serial tests

Preconditions A BIND 10 system has been configured to run DDNS, and has been preloaded with a zone (serial "n"). DDNS is enabled for said zone. If it has ACL configuration, it should be such that updates would be accepted from the client running the tests.

Tests

  1. Send a DDNS Update which contains a record that does not yet exist (e.g. add_1_1 IN A), and no SOA record (Section 3.6).
    • The server's response should be NOERROR.
    • After processing, the SOA's SERIAL value should be n + 1, and the new record should be present.
  2. Send a DDNS Update which contains a record that does not yet exist (e.g. add_1_2 IN A), and which adds a SOA record that has a SERIAL value n + 2 (Section 3.6).
    • The server's response should be NOERROR.
    • After processing, the SOA's SERIAL value should be n + 2, and the new record should be present.
  3. Send a DDNS Update which contains a record that does not yet exist (e.g. add_1_3 IN A), and which adds a SOA record that has a SERIAL value n - 1 (Section 3.6).
    • The server's response should be NOERROR.
    • After processing, the SOA's SERIAL value should be n + 2, and the new record should be present.
  4. Send a DDNS Update which contains a record that does not yet exist (e.g. add_1_4 IN A), and which *deletes* the SOA record (Sections 3.4.2.4 and 3.6).
    • The server's response should be NOERROR.
    • After processing, there should be a new SOA record which has a SERIAL value of n + 3.
  5. Send a DDNS Update which contains no data at all (Section 3.6).
    • The server's response should be NOERROR.
    • After processing, there should be no changes, and the SOA record of the zone should still have a SERIAL value of n + 3.
  6. Send a DDNS Update which deletes the SOA record, but contains no other differences (Sections 3.4.2.4 and 3.6).
    • The server's response should be NOERROR.
    • After processing, there should be no changes, and the zone should still have a SERIAL value of n + 3. (Is this true? or should it be n+4 now?)
  7. Send a DDNS Update which adds a SOA record with a SERIAL value of n - 1 (Section 3.6).
    • The server's response should be NOERROR.
    • After processing, there should be no changes, and the zone should still have a SERIAL value of n + 3. (Same question as for 7.)
  8. Send a DDNS Update which adds a SOA record with a SERIAL value of MAX-1 (232 - 1) (No specific section, this is setup for test 9)
    • The server's response should be NOERROR.
    • After processing, there should be no changes, and the zone should still have a SERIAL value of MAX-1
  9. Send a DDNS Update which adds a record that does not exist yet (e.g. add_1_9 IN A) (Section 7.11)
    • The server's response should be NOERROR.
    • After processing, there should be no changes, and the zone should still have a SERIAL value of 1 (and not 0).

(Note: if 5, 6 and 7 are correct tests as described here, they will fail, every update operation that succeeds will increase the serial, even without any actual zone changes, in effect we have implemented option 1 of section 3.6, while i think we should implement 2) (Note: if the backend zone is reset between these tests, the mentioned serial values need to be updated) (Note: what is supposed to happen if the SOA serial is explicitely set to 0 by an update? Also change to 1?)

Zone Section Tests

Preconditions A BIND 10 system has been configured to run b10-ddns. It has been preloaded with a zone of class IN with a SOA SERIAL value of n, and a second zone for which it is not the primary master (serial m). b10-ddns has said zone enabled for dynamic updates, and the ACL is set to accept updates from the client running the tests.

Tests

  1. Send a DDNS Update message that has 2 records in the Zone Section, and which adds a new record that does not exist yet (Section 3.1.1).
    • The response should be FORMERR
    • The SOA SERIAL value of the zone should be n
    • The new record should not be present in the zone
  2. Send a DDNS Update message that has a record of class IN and type A in the Zone Section, and which adds a new record that does not exist yet (Section 3.1.1).
    • The response should be FORMERR
    • The SOA SERIAL value of the zone should be n
    • The new record should not be present in the zone
  3. Send a DDNS Update message that has a record of class CH in the Zone Section, but is otherwise similar to the zone's SOA. The update should also add a record that does not exist yet (Section 3.1.1).
    • The response should be NOTAUTH
    • The SOA SERIAL value of the zone should be n
    • The new record should not be present in the zone
  4. Send a DDNS Update that has a record of class IN and type SOA in the Zone Section, but which has a different name than the zone served. The update should also add a record that does not exist yet (Section 3.1.1).
    • The response should be NOTAUTH
    • The SOA SERIAL value of the zone should be n
    • The new record should not be present in the zone
  5. Send a DDNS Update that has a record of class IN, type SOA, and name of the zone. The update should add a record that does not exist yet (Sections 3.4.2.2 and 3.6).
    • The response should be NOERROR
    • The SOA SERIAL value of the zone should be n + 1
    • The new record should be present in the zone
  6. Send a DDNS Update that has a record of class IN, type SOA, and name of the second (non-primary master) zone, which adds a record that does not exist yet.
    • The response should be NOTIMP
    • The SOA SERIAL value of the secondary zone should be m
    • The new record should not be present in the secondary zone

(Note: For test 6, what the server should really do is forward the update to the primary master (Section 3.1.1 and 6), if we implement that, we should remove the test from this test set and create a new test set with an added primary master.)

Prerequisite section tests

Failures in prerequisites

Preconditions A BIND 10 system has been configured to run b10-ddns. It has been preloaded with a zone (class IN) with a SOA SERIAL value of n. b10-ddns has said zone enabled for dynamic updates, and the ACL is set to accept updates from the client running the tests.

Tests

  1. Send a DDNS Update message for the zone, with an RR in the prerequisite section that has an out-of-zone name given the zone section. The update adds a record that does not exist yet (Section 3.2)
    • The response should be NOTZONE
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  2. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, has class ANY, RDLENGTH 0, but TTL 1. The update adds a record that does not exist yet (Section 3.2.1)
    • The response should be FORMERR
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  3. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, has class ANY, TTL 0, but RDLENGTH 1. The update adds a record that does not exist yet (Section 3.2.1)
    • The response should be FORMERR
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  4. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, class ANY, type ANY, TTL 0, rdlength 0, and has a name that does not exist in the zone. The update adds a record that does not exist yet (Section 3.2.1)
    • The response should be NXDOMAIN
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  5. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, class ANY, type A, TTL 0, rdlength 0, and has a name that exists in the zone, but has no A record in the zone. The update adds a record that does not exist yet (Section 3.2.1)
    • The response should be NXRRSET
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  6. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, class NONE, RDLENGTH 0, but TTL 1. The update adds a record that does not exist yet (Section 3.2.2)
    • The response should be FORMERR
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  7. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, class NONE, TTL 0, but RDLENGTH 1. The update adds a record that does not exist yet (Section 3.2.2)
    • The response should be FORMERR
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  8. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, class NONE, type ANY, TTL 0, rdlength 0, and has a name that exists in the zone. The update adds a record that does not exist yet (Section 3.2.2)
    • The response should be YXDOMAIN
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  9. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, class NONE, type A, TTL 0, rdlength 0, and has a name that exists in the zone, which has an A record. The update adds a record that does not exist yet (Section 3.2.2)
    • The response should be YXRRSET
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  10. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, class IN, but TTL 1. The update adds a record that does not exist yet (Section 3.2.3)
    • The response should be FORMERR
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.
  11. Send a DDNS Update message for the zone, with an RR in the prerequisite section that is in-zone, class IN, but TTL 0, and a name and type that exists in the zone, but with different RDATA entries. The update adds a record that does not exist yet (Section 3.2.3)
    • The response should be NXRRSET
    • The SOA SERIAL value should be n
    • The new record should not be present in the zone.

Success in prerequisites

Preconditions A BIND 10 system has been configured to run b10-ddns. It has been preloaded with a zone (class IN) with a SOA SERIAL value of n. b10-ddns has said zone enabled for dynamic updates, and the ACL is set to accept updates from the client running the tests.

Tests

  1. Send a DDNS Update message for the zone, with the following RRs in the prerequisite section (all in-zone):
    1. Class ANY, type ANY, TTL 0, no rdata, name that exists.
    2. Class ANY, type A, TTL 0, no rdata, name that exists and has an A record.
    3. Class NONE, type ANY, TTL 0, no rdata, name that does not exist.
    4. Class NONE, type A, TTl 0, no rdata, name that exists, but has no A record.
    5. Class IN, type A, TTl 0, name and rdata that matches an existing RRset.
  • The response should be NOERROR
  • The SOA SERIAL value should be n + 1
  • The new record should be present in the zone.

Update section tests

Prescan failures

Preconditions A BIND 10 system has been configured to run b10-ddns. It has been preloaded with a zone of class IN with a SOA SERIAL value of n. b10-ddns has said zone enabled for dynamic updates, and the ACL is set to accept updates from the client running the tests.

Tests

  1. Send a DDNS Update message for the zone, with an RR in the update section of class CH (Section 3.4)
    • The response should be FORMERR
  2. Send a DDNS Update message for the zone, with an RR in the update section that has an out-of-zone name given the zone section (Section 3.4)
    • The response should be NOTZONE
  3. Send a DDNS Update message for the zone, with an RR in the update section of class NONE, and type ANY (Section 3.4.1)
    • The response should be FORMERR
  4. Send a DDNS Update message for the zone, with an RR in the update section of class ANY, and TTL 1 (Section 3.4.1)
    • The response should be FORMERR
  5. Send a DDNS Update message for the zone, with an RR in the update section of class NONE, and TTL 1 (Section 3.4.1)
    • The response should be FORMERR
  6. Send a DDNS Update message for the zone, with an RR in the update section of class ANY, TTL 0, but RDLENGTH 1 (Section 3.4.1)
    • The response should be FORMERR
  7. Send a DDNS Update message for the zone, with an RR in the update section of class ANY, RRType AXFR, TTL 0, rdlength 0 (Section 3.4.1)
    • The response should be FORMERR

(Note: we should also test actual updates (after prescan succeeded). Basic cases are covered in earlier tests, but there are a lot of special cases here, deleting apex NS set, special matching rules for specific types, etc. Currently these are left out but if we want to have RFC compliance tests, we will need to add them.) (Note: we should probably repeat 7 for all meta types, including MAILA and MAILB)

DDNS over TCP tests

Preconditions A BIND 10 system has been configured to run b10-ddns. It has been preloaded with a zone of class IN with a SOA SERIAL value of n. b10-ddns has said zone enabled for dynamic updates, and the ACL is set to accept updates from the client running the tests.

  1. Send a DDNS Update message for the zone over TCP, which adds a record that does not exist yet.
    • The response should be NOERROR
    • The SOA SERIAL value should be n + 1
    • The new record should be present in the zone.

DDNS and IXFR tests

(not sure if we should consider this BIND 10 only)

Preconditions A BIND 10 system has been configured to run b10-ddns. It has been preloaded with a zone of class IN with a SOA SERIAL value of n. b10-ddns has said zone enabled for dynamic updates, and the ACL is set to accept updates from the client running the tests.

Tests

  1. Send a DDNS Update message for the zone, which adds a record that does not exist yet.
    • The response should be NOERROR
    • The SOA SERIAL value should be n + 1
    • The new record should be present in the zone.
  2. Send an IXFR query with SOA SERIAL n
    • The response should contain the IXFR differences from SOA SERIAL n to n+1, i.e. the record that got added in step 1.
  3. Send a DDNS Update message for the zone, which deletes the record added in step 1
    • The response should be NOERROR
    • The SOA SERIAL value should be n + 2
    • The new record should be present in the zone.
  4. Send an IXFR query with SOA SERIAL n + 1
    • The response should contain the IXFR differences from SOA SERIAL n to n+1, i.e. the record that got deleted in step 3.

Broken zone test

Preconditions A BIND 10 system has been configured to run b10-ddns, it has been preloaded with a zone, but said zone has no SOA record.

Tests

  1. Send a DDNS Update message for the zone, which adds a record that does not exist yet.
    • The response should be SERVFAIL
    • Querying the zone should result in SERVFAIL
  2. Send a DDNS Update message for the zone, which adds a SOA record
    • The response should be SERVFAIL
    • Querying the zone should result in SERVFAIL

(Note: We may want to consider recovery from this situation; in that case, the second test should result in a correct zone and both the update and the query should succeed.)

Possible additional tests

Here are some tests that are not completely defined just yet (and for functionality that is probably not implemented just yet)

  • Test that the addition of an NS record that needs glue but does not have it fails (BIND 9 seems to answer REFUSED in that scenario):
    # inserting an NS record without a corresponding A or AAAA record should fail
    $NSUPDATE -l -p 5300 -k ns1/session.key > nsupdate.out 2>&1 << END && status=1
    update add other.nil. 600 in ns ns3.other.nil.
    send
    END
    grep REFUSED nsupdate.out > /dev/null 2>&1 || status=1
    
  • Test what happens if the database backend has a zone without a SOA record.
  • Test what happens if we reuse a TCP connection for multiple UPDATES
  • Test what happens if we start a vast number of tcp connections without closing them
Last modified 5 years ago Last modified on Jun 5, 2012, 8:47:50 AM