wiki:DhcpDdnsTesting

DHCP DDNS Testing

Within Kea, it is possible to configure the server to add and remove entries from specific DNS zones as clients acquire and release leases. This task is accomplished by the DHCP DDNS server (aka the "D2" server) acting on information passed to it from the DHCPv4 and DHCPv6 servers.

This document outlines the main system tests for that component and serves as a guide for the implementation of these tests.

1. Overview

Testing that the DDNS code works correctly can be broken down into three main areas:

  1. Unit tests of the DDNS components.
  2. Checking that the DDNS system works as expected in normal cases.
  3. Checking that the DDNS system copes with exceptions.

All sets of tests have to be repeated twice, once for the DHCPv4 server, and once for the DHCPv6 server.

Units tests have been written as part of the development and have been independently reviewed; they are run as part of the build process. The document concerns itself with the latter two cases, normal cases and exceptions.

1.1. Explanation of Operation

Before describing test cases, a broad outline of the operation of the DHCP DDNS server is helpful.

The request from the DHCP client to a DHCP server can contain any of the following pieces of identifying information.

  1. Nothing - the client is only identified by a DUID or MAC address.
  2. Hostname - this is a V4-only option and the client is simply identifying a name.
  3. FQDN - this is both a V4 and a V6 option and specifies the name that the client wants.

In the first case, the DHCP server will not add anything into DNS. The second two cases are treated as the same (although if both are specified, FQDN is preferred over host name). If it ends with a "." it is treated as a fully-qualified domain name: if not, the globally-configured suffix is appended to the name and the result is used. Finally, the name part of the FQDN can be empty, in which case the DHCP server will generate a name. (Note that if the server's replace-client-name switch is set, the server will also generate a name for the client if it specifies an FQDN option, regardless of what name is in the FQDN.)

If the client supplies the FQDN option, it can ask the server not to enter information into DNS (N=1, S=0), enter it into the reverse zone only (N=0, S=0), or both the forward and reverse zones (N=0, S=1). (The letters in brackets indicate the sessions of the named bits in the FQDN "flags" field. The combination N=1,S=1 is prohibited.) It is possible for the server to override the client's request and either add or not add the information to the zone. In particular, if the override-no-update parameter is set, the server will ignore the client's "N" flag: If the override-client-update parameter is set, the server will enter information into DNS, even if the client requests that it does not (both N and S flags are zero).

The following table indicates what gets zone updated (F = Forward, R = Reverse) for different client FQDN flags and different server options if both a forward and reverse zone are defined. (The server options are abbreviated: "NU" is an abbreviation for override-no-update and "CU" an abbreviation of override-client-update):

NU=F,CU=F NU=F,CU=T NU=T,CU=F NU=T,CU=T
S=0,N=0 F, R F, R
S=0,N=1 F, R F, R
S=1,N=0 F, R F, R F, R F, R

Table 1. Effect of "override" Flags

The DDNS server is configured with a list of prefixes, each of which is associated with or more nameservers. When a name (and address) is to be entered into a zone, the DDNS server will match the name with the longest prefix. If a match is found, an update will be sent to the first server on the list. Only if this update fails due to a communications error (as opposed to a failure due to the server rejecting the instruction or failing to update the zone) will the DDNS server try other DNS servers associated with the prefix.

If no DNS servers are configured that match the client's data, nothing will be done. If server updates of the DNS are requested and only one server is configured (to match either the forward or the reverse zone), the data will be placed into that zone. If servers are configured that match both the client's forward and reverse zones, entries will be placed into both zones.

If a client explicitly releases a lease, the names will be removed from both zones (if appropriate).

If the lease expires, the name will be removed from the zone when the housekeeper runs to tidy up the database. (This has not been implemented for Kea 0.9 Alpha.)

2. Normal Use Tests

2.1. Basic Tests

This set of tests check that the code works in normal operation and honours the configuration settings. The examples here are for V4: similar tests should be created for V6.

2.1-1 Test (no name expansion)
Setup

  • A DNS server configured for the forward zone kea.example.org and the reverse zone 1.168.192.in-addr.arpa.
  • Kea configured with a single pool in the 192.168.1.0/24 range.
  • Kea configured with both overide-client-update and override-no-update set true and replace-client-name set false.
  • No domain suffix configured for the Kea client.
  • A V4 client (client0) configured with neither FQDN nor hostname.
  • A V4 client (client1) configured with a hostname of client1 (no trailing dot)
  • A V4 client (client2) configured with a hostname of client2. (with trailing dot)
  • A V4 client (client3) configured with an FQDN of client3.kea.example.org. (with trailing dot)
  • A V4 client (client4) configured at with an FQDN of client4.kea.example.org. (with trailing dot) and a hostname of host4.kea.example.org. (with trailing dot)
  • A V4 client (client5) configured with an FQDN of client5.example.net. (with trailing dot)

Execution
Where relevant, all clients send the information with the bits N=0,S=1.

  1. Set up Kea to start the DDNS server but do not add any entries to indicate DDNS servers. Acquire leases for all clients and check that nothing is added to either zone.
  2. Add the information about the kea.example.org zone to Kea. There should be no information about the reverse zone. Acquire leases for all clients, and check that only the FQDNs for client3 and client4 have been added to the zone. Check that appropriate DHCIDs have been added.
  3. Add the information about the reverse zone to Kea. There should be no information about the forward zone. Acquire a lease for the clients. Check that entries are placed into a zone corresponding to clients 1 through 5. Check that appropriate DHCIDs have been added.
  4. Set the configuration to point to the forward zone and the reverse zone. Acquire a lease for the clients. Check that the FQDNs for client3 and client4 have been added to the forward zone and that entries for the reverse zone have been added for clients 1 through 5. Check that appropriate DHCIDs have been added.

2.1-2 Test (with name expansion)
Setup
As well as the previous setup:

  • Configure the Kea server with the suffix test.kea.example.org. (with trailing dot)
  • Configure Kea to point to both the forward and reverse zone.

Execution

  1. Acquire a lease for the clients. Check that the FQDNs for client1, client3 and client4 have been added to the forward zone and that entries for the reverse zone have been added for clients 1 through 5. Check that appropriate DHCIDs have been added.

Setup
Modify the setup in the previous test:

  • Configure the Kea server with the incorrect suffix ""

Execution

  1. Acquire a lease for the clients. Check that the FQDNs for client3 and client4 have been added to the forward zone and that entries for the reverse zone have been added for clients 1 through 5. Check that appropriate DHCIDs have been added.

2.2. Extended Tests

2.2-1 Test (Using Multiple Zones)
Setup

  • Two DNS servers: one configured for the zones illustration.kea.example.org the other for the zones kea.example.org and sample.kea.example.org. Either can be configured for the reverse zone 1.168.192.in-addr.arpa.
  • Kea configured with a single pool in the 192.168.1.0/24 range.
  • The domain suffix sample.kea.example.org
  • A V4 client (client1) configured with an FQDN of client1.kea.example.org.
  • A V4 client (client2) configured with a DQDN of client2.illustration.kea.example.org
  • A V4 client (client3) configured at with an a hostname of client3.

Execution

  1. Acquire a lease for the clients. Check that entries for clients1, 2 and 3 are in the appropriate zone and that there are three entries into the reverse DNS zone. Also check that appropriate DHCIDs have been added.

2.2-2 Test (Server "Override" Flags)
Setup

  • A DNS server configured for the forward zone kea.example.org and the reverse zone 1.168.192.in-addr.arpa.
  • Kea configured with a single pool in the 192.168.1.0/24 range.

Execution

  • For each combination of the client's S and N flags and the server's override-no-update and override-client-update flag, check that the names appear as expected in the correct zones as described in Table 1.

2.2-3 Test (auto-generation of name)
Setup

  • A DNS server configured for the forward zone kea.example.org and the reverse zone 1.168.192.in-addr.arpa.
  • Kea configured with a single pool in the 192.168.1.0/24 range.
  • Kea configured with both the forward and reverse domains
  • Kea configured with both overide-client-update and override-no-update set true.
  • Kea configured with a domain suffix of kea.example.org.
  • A V4 client (client1) configured with an empty FQDN
  • A V4 client (client2) configured with the FQDN client2.kea.example.org. (with trailing dot)

Execution

  1. Acquire a lease for the clients. The name in the forward zone for client1 should be auto-generated and that for client 2 the same as the FQDN. Both clients should have entries in the reverse domain.

Setup

  • As above, but with the replace-client-name option set true.

Execution

  1. Acquire a lease for the clients. The names in the forward zone for both clients should be auto-generated, and there should be entries in the reverse zone.

2.3. Conflict Resolution

This test checks that the DDNS server handles name conflicts as per RFC 4702.

2.3-1 Test (conflict resolution)
Setup

  • A DNS server configured for the forward zone kea.example.org and the reverse zone 1.168.192.in-addr.arpa.
  • Kea configured with a single pool in the 192.168.1.0/24 range.
  • The domain suffix kea.example.org. configured in the Kea server.
  • A V4 client (client1) configured with an FQDN of client1.kea.example.org.
  • A V4 client (client2) configured with a hostname of client1. (This should have a different MAC to client 1.)

Execution

  1. Acquire a lease for client1. Check that the A record and the DHCID record appear in the zone.
  2. After a short pause, acquire a lease for client2. The name conflicts, so the DDNS updates should be refused by the server. Check that the names in the zones reflect client1. Check that the server logs an appropriate message about the name conflict.

2.4. Failure Tests

2.4-1 Test (Server fails to respond)
This checks what happens if a DNS server fails to respond.

Setup

  • A DNS server configured for the forward zone kea.example.org and the reverse zone 192.168.1.0/24.
  • Kea configured with a single pool in the 192.168.1.0/24 range. The server associated with the forward zone should point to an invalid address and the DNS server (in that order); the information for the reverse zone should do likewise.
  • A V4 client (client1) configured with an FQDN of client1.kea.example.org.

Execution

  1. Acquire a lease for client1. Check that names appear in both the forward and reverse DNS zone. Also check that appropriate DHCIDs have been added.

Setup

  • Adjust the server information associated with the forward zone so that it points to an invalid server.
  • Adjust the server information associated with the reverse zone so that it points to the valid server.

Execution

  1. Acquire a lease for client1. Check that nothing appears in either zone.

Setup

  • Adjust the server information associated with the forward zone so that it points to an valid server. Add the name client1.kea.example.org to it with an A record pointing to 192.168.254.1.

Execution

  1. Acquire a lease for client1. Check that nothing appears in either zone. (The forward update should have failed because the name was already there - this will cause the reverse update not to be attempted).

2.4-1 Test (Invalid host name)
This checks what happens if client supplies an invalid host name or FQDN.

3. Cross-Reference to Requirements

This section links the tests above with the requirement they test, as listed in the DDNS Requirements page.

Requirement No. Test Number Notes
Specification of DDNS Servers
2.1.1 Test by inspection
2.1.2 Test by inspection
2.1.3 Test by inspection
2.1.4
2.1.5 Test by inspection
Determination of Client Name (V4)
2.2.1.1 2.1-1 Tested in V4 version of this test
2.2.1.2
2.2.1.3 2.1-1 Tested in V4 version of this test
2.2.1.4 2.2-2 Tested in V4 version of this test
2.2.1.5 2.2-2 Tested in V4 version of this test
2.2.1.6
2.2.1.7
2.2.1.8
2.2.1.9 2.1-1 Tested in V4 version of this test
2.2.1.10 2.2-3 Tested in V4 version of this test
2.2.1.11
Determination of Client Name (V6)
2.2.2.1 2.1-1 Tested in V6 version of this test
2.2.2.2 2.2-2 Tested in V6 version of this test
2.2.2.3 2.2-2 Tested in V6 version of this test
2.2.2.4
2.2.2.5 2.2-3 Tested in V6 version of this test
2.2.2.6
Performing the DDNS Update
2.3.1.1
2.3.1.2 2.1-1, 2.3-1 Will need to add a test to engineer a conflict of names
2.3.1.3 May need to set up two zones with one server for each, and disable the server for one before starting it half-way through the test. Do the lease requests appear to complete immediately, and do the pending updates appear in the server that was started late?
2.3.1.4 Use "dig" to look at the TTLs of the RRs added to the zones
Lease Expiration
2.3.2.1
2.3.2.2
2.3.2.3
2.3.2.4
Miscellaneous
2.3.3.1
2.3.3.2
Management
2.4.1
Other Requirements
2.5.1
Last modified 3 years ago Last modified on Jun 3, 2014, 2:07:21 PM