| 1 |
AXFR-Tests (zone loading and transferring) |
|---|
| 2 |
|
|---|
| 3 |
o Setup |
|---|
| 4 |
We set up a chain of authoritative servers that had master/slave relations to each other. Some of these servers understood NSEC3 (the first one, to read the zone file) and some intermediate servers did not understand NSEC3 (but were RFC 3597 ready). The zone was transferred to the slaves down the chain by means of AXFR. This way the behaviour of NSEC3 unaware servers when presented with an NSEC3 zone became subject to the test. A second objective was to test the behaviour when the NSEC3 parameters were changed and the zone was transferred to the secondaries. The secondaries that were NSEC3 aware were expected to detect the parameter change. The chain of servers is shown below. |
|---|
| 5 |
|
|---|
| 6 |
Tested AXFR down this chain |
|---|
| 7 |
1. A1 |
|---|
| 8 |
2. A2 |
|---|
| 9 |
3. A3 |
|---|
| 10 |
4. A4 |
|---|
| 11 |
5. A5 |
|---|
| 12 |
6. A1 |
|---|
| 13 |
|
|---|
| 14 |
The A1 server implementation was both used at the start and end, so it got to be both a master and a slave in this sequence (as every other server). |
|---|
| 15 |
|
|---|
| 16 |
o Structure of the zones |
|---|
| 17 |
Two zones were used for this test, both originating from the previous signing test. The first zone was "empty", consisting only of the SOA RR, the NS RRs and the necessary DNSSEC RRSets. The second zone was more populated, called "full", and is available for reference at <place URL here?>. |
|---|
| 18 |
|
|---|
| 19 |
This "full" zones contained wildcards, delegations and Empty Non Terminals. |
|---|
| 20 |
|
|---|
| 21 |
Both zones were signed with NSEC3. |
|---|
| 22 |
|
|---|
| 23 |
o Queries we sent |
|---|
| 24 |
|
|---|
| 25 |
The zones at the servers were checked: |
|---|
| 26 |
* We sent AXFR queries to every server in the chain with an NSEC3 aware querying tool, normalized and sorted the output to eventually hash it by MD5. |
|---|
| 27 |
* Also, we sent queries to solicit NXDOMAIN responses to the NSEC3 capable servers in the chain. These servers would only be capable of including the NSEC3 RRs in the response if they had detected the NSEC3 parameters. |
|---|
| 28 |
|
|---|
| 29 |
After some time we updated the "full" zone to a new serial number, and changed the NSEC3 parameter set inside this zone. After sending down this modified zone down the chain of servers, we repeated the tests mentioned above. |
|---|
| 30 |
|
|---|
| 31 |
o Expected results |
|---|
| 32 |
|
|---|
| 33 |
The NSEC3 unaware servers in between should treat the NSEC3 and NSEC3PARAM records as unknown RR data (as of RFC 3597). Direct queries should be answered, including AXFR queries from their slaves. No other special handling is to be expected. This would still enable the NSEC3 aware servers to enable authenticated denial for the zone, even though the zone is transferred to them via the NSEC3 unaware servers. The zone must not change in transit (a.k.a "the telephone game"). |
|---|
| 34 |
|
|---|
| 35 |
The NSEC3 aware servers must detect the parameter change and adapt to give correct NSEC3 RRs in NXDOMAIN responses. |
|---|
| 36 |
|
|---|
| 37 |
o Actual results |
|---|
| 38 |
|
|---|
| 39 |
All the AXFRed zones could be verified to be equal to each other and also matched the original master zone file (after normalization to sort the entries), except that the AXFR responses showed the SOA RR twice, as usual. |
|---|
| 40 |
|
|---|
| 41 |
After the zone update all servers successfully transferred the new zone from their respective masters, and queries were answered correctly with NXDOMAIN and (updated) NSEC3 records. The AXFRs from the servers again showed the correct zone, i.e. same result as after the first distribution down the server chain. |
|---|
| 42 |
|
|---|
| 43 |
o Conclusion/discussion |
|---|
| 44 |
|
|---|
| 45 |
The tested servers are either NSEC3 aware or RFC 3597 compliant and treat NSEC3 and NSEC3PARAM as unknown RR types where necessary. This enables the NSEC3 aware servers to operate correctly, and these NSEC3 aware servers detect the parameter update correctly. In conclusion, the test is passed by all participating implementations. |
|---|
