| 1 |
broken packets |
|---|
| 2 |
|
|---|
| 3 |
Setup: |
|---|
| 4 |
|
|---|
| 5 |
For the broken packets test we used a secure delegation to 'b.ws.nsec3.org' to Packet-server. Packet-server is not an authoritative server in itself, but uses pre-compiled responses to answer requests. The packet-server resides on ns4.infra.ws.nsec3.org. |
|---|
| 6 |
|
|---|
| 7 |
The participants used validators v1, v7 and v9. These were capable of understanding NSEC3, and configured with a trust anchor for ws.nsec3.org. Other implementations were used as well, but since this test focussed on nsec3 validation, we do not include it in this report. |
|---|
| 8 |
|
|---|
| 9 |
Structure of the packets: |
|---|
| 10 |
|
|---|
| 11 |
The packets itself are mostly responses that miss some part of the authenticated denial proof. Exceptions are the packets that are ambiguous, for instance returning a NODATA for type A, while existence of A is reflected in the NSEC3 type list. |
|---|
| 12 |
|
|---|
| 13 |
The broken packets are in 10 different sets, what follows is a general description of the sets |
|---|
| 14 |
|
|---|
| 15 |
Set A. NXDOMAIN |
|---|
| 16 |
|
|---|
| 17 |
An NXDOMAIN response was created containing three NSEC3 records. One showing the Closest Encloser (CE), one proving the Closest Encloser (NC), and one proving the absence of the wildcard at the Closest Encloser (NW). The different responses in this set show none, one, two or all three records. |
|---|
| 18 |
|
|---|
| 19 |
Set B. standard NODATA |
|---|
| 20 |
|
|---|
| 21 |
A standard NODATA response contains one NSEC3, showing the absence of a type for that name. One response is a NODATA, but the NSEC3 shows the presence of the type. One response shows a different NSEC3. One shows the presence of the CNAME type. |
|---|
| 22 |
|
|---|
| 23 |
Set C. Wildcard NODATA |
|---|
| 24 |
|
|---|
| 25 |
A wildcard NODATA response contains thee NSEC3s. The CE, the NC and the NSEC3 at the wildcard showing that the type does not exist for the wildcard. The different responses in this set show none, one, two or all three records |
|---|
| 26 |
|
|---|
| 27 |
Set D. Wildcard expansion |
|---|
| 28 |
|
|---|
| 29 |
A wildcard expansion has two NSEC3s. The CE and the NC. The different responses in this set show none, one or two NSEC3s. |
|---|
| 30 |
|
|---|
| 31 |
set E. Referrals to unsigned zones |
|---|
| 32 |
|
|---|
| 33 |
A delegation to unsigned zones contain an NSEC3 that shows the absence of the DS record. One response shows a missing NSEC3, one response shows an NSEC3 with the DS bit set. |
|---|
| 34 |
|
|---|
| 35 |
set F. Referrals to opted out unsigned zones. |
|---|
| 36 |
|
|---|
| 37 |
An opted out delegation contains two NSEC3s. One shows the CE, the other the NC, with the OO bit set. The responses contain zero or one NSEC3, and one with the OO bit clear. |
|---|
| 38 |
|
|---|
| 39 |
set G. NSEC3s from multiple chains. |
|---|
| 40 |
|
|---|
| 41 |
This is an NXDOMAIN response where the three NSEC3s have different parameters. |
|---|
| 42 |
|
|---|
| 43 |
set H. skewed NSEC3 |
|---|
| 44 |
|
|---|
| 45 |
These responses contain NSEC3s where the ownername sorts after the next hashed ownername. |
|---|
| 46 |
|
|---|
| 47 |
set I. same name |
|---|
| 48 |
|
|---|
| 49 |
These responses contain NSEC3s where the ownername is equal to the next hashed ownername |
|---|
| 50 |
|
|---|
| 51 |
set J. multiple labels NXDOMAIN |
|---|
| 52 |
|
|---|
| 53 |
These responses contain the responses similar to A, but the CE is not the ownername. Furthermore these contain responses with the DNAME bit in the CE, and a combination of other proofs. |
|---|
| 54 |
|
|---|
| 55 |
What follows is a matrix that shows where the actual results differ from the expected results |
|---|
| 56 |
|
|---|
| 57 |
|
|---|
| 58 |
|
|---|
| 59 |
|
|---|
| 60 |
|
|---|
| 61 |
|
|---|
