CloudHost/zonemaster.es
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add full Zonemaster stack with Docker and Spanish UI

Browse Source 
- Clone all 5 Zonemaster component repos (LDNS, Engine, CLI, Backend, GUI)
- Dockerfile.backend: 8-stage multi-stage build LDNS→Engine→CLI→Backend
- Dockerfile.gui: Astro static build served via nginx
- docker-compose.yml: backend (internal) + frontend (port 5353)
- nginx.conf: root redirects to /es/, /api/ proxied to backend
- zonemaster-gui/config.ts: defaultLanguage set to 'es' (Spanish)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Malin
2026-04-21 08:19:24 +02:00
commit 8d4eaa1489
1567 changed files with 204155 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
zonemaster/docs/public/specifications/README.md Normal file
View File

@@ -0,0 +1,9 @@
# Specifications
* [Test Cases](tests/README.md): contains the specifications of the *Test Cases*
that the Zonemaster implementation is based on.
* [Test types](test-types/README.md): contains the specification of *Test Types*,
currently only for undelegated tests.
* [Test zones](test-zones/README.md): contains the specifications of *Test Zones*
for the verification of Test Case implementation.

7
zonemaster/docs/public/specifications/test-types/README.md Normal file
View File

@@ -0,0 +1,7 @@
# Test Types
This directory contains **Test Type** specifications, currently only
specification for undelegated tests.
* [undelegated-test.md](undelegated-test.md)

48
zonemaster/docs/public/specifications/test-types/undelegated-test.md Normal file
View File

@@ -0,0 +1,48 @@
# Undelegated tests
## Objective
The purpose of an undelegated test is to test a possible future delegation
before it is put in production. Hence, while testing an undelegated test,
extra information (such as name servers, IP addresses) must be provided
as input, and Zonemaster should run the test cases with the provided
information.
## Specification
An undelegated test should mimic the a delegated test. The information for the
test must be provided when starting the test.
An undelegated test can be run on a already delegated domain, but then
Zonemaster must disregard the specific information for that domain found
in public DNS.
Information that is part of the delegation must be provided with the initiation of
the test. That following information is used for the undelegated test:
* Domain (zone) to be tested. Mandatory information.
* NS records. No NS records may be looked up before the test
starts, the complete RR set must be provided. Mandatory information.
* Glue records. The IP addresses of the name server names that belong to the delegated
zone or below must be provided. They must not be looked up before the test starts. If
not provided or only partly provided, the information will be treated as an incomplete
delegation.
* DS records. If no DS records are provided, then it is assumed that there are no DS
records for the zone. They must not be looked up.
* Name server addresses. Addresses of name server names that belong to the delegated
zone is covered under "glue records" above. Addresses of other name servers may be
provided, of else they are looked up. If at least one address (IPv4 or IPv6) is provided
for a name server, then no further lookup shall be done for that name during the
test (neither IPv4 nor IPv6).
The complete set of "NS records", the "Glue records" and the "DS records" is considered
to be equivalent to what must be provided by the delegating zone, and replaces that, if
the delegation exists. If the delegation does not exists, the provided set works as if
the delegation existed.
The Name server addresses provided, if any, are considered to replace the real IP
addresses for those name server names.

8
zonemaster/docs/public/specifications/test-zones/Address-TP/README.md Normal file
View File

@@ -0,0 +1,8 @@
# Specification of test scenarios for Address-TP
Test scenario specifications are available for:
* Address01 *not yet available*
* Address02 *not yet available*
* [Address03](address03.md)

216
zonemaster/docs/public/specifications/test-zones/Address-TP/address01.md Normal file
View File

@@ -0,0 +1,216 @@
# Specification of test scenarios for ADDRESS01
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
## Background
See the [test zone README file].
## Test Case
This document specifies defined test scenarios for test case [ADDRESS01].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [ADDRESS01] is run on a test zone.
The message tags are defined in the test case ([ADDRESS01]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test zone README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`address01.xa`) and that subdomain having the same name as the
scenario. The names of those zones are given in section
"[Zone setup for test scenarios]" below.
## All tags
The test case can output any of these message tags, but not necessarily in any combination.
- A01_ADDR_NOT_GLOBALLY_REACHABLE
- A01_DOCUMENTATION_ADDR
- A01_GLOBALLY_REACHABLE_ADDR
- A01_LOCAL_USE_ADDR
- A01_NO_GLOBALLY_REACHABLE_ADDR
- A01_NO_NAME_SERVERS_FOUND
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
| Scenario name | Mandatory message tag | Forbidden message tags |
|:--------------------|:------------------------------------------------------------------------------------------------------------|:-----------------------|
| GOOD-1 | A01_GLOBALLY_REACHABLE_ADDR | 2) |
| MIXED-LOCAL-DOC-1 | A01_LOCAL_USE_ADDR, A01_DOCUMENTATION_ADDR, A01_GLOBALLY_REACHABLE_ADDR | 2) |
| MIXED-LOCAL-DOC-2 | A01_LOCAL_USE_ADDR, A01_DOCUMENTATION_ADDR, A01_GLOBALLY_REACHABLE_ADDR | 2) |
| MIXED-LOCAL-OTHER-1 | A01_LOCAL_USE_ADDR, A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_GLOBALLY_REACHABLE_ADDR | 2) |
| MIXED-LOCAL-OTHER-2 | A01_LOCAL_USE_ADDR, A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_GLOBALLY_REACHABLE_ADDR | 2) |
| MIXED-DOC-OTHER-1 | A01_DOCUMENTATION_ADDR, A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_GLOBALLY_REACHABLE_ADDR | 2) |
| MIXED-DOC-OTHER-2 | A01_DOCUMENTATION_ADDR, A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_GLOBALLY_REACHABLE_ADDR | 2) |
| MIXED-ALL-1 | A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_DOCUMENTATION_ADDR, A01_LOCAL_USE_ADDR, A01_GLOBALLY_REACHABLE_ADDR | 2) |
| MIXED-ALL-2 | A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_DOCUMENTATION_ADDR, A01_LOCAL_USE_ADDR, A01_GLOBALLY_REACHABLE_ADDR | 2) |
| ALL-NON-REACHABLE | A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_LOCAL_USE_ADDR, A01_DOCUMENTATION_ADDR, A01_NO_GLOBALLY_REACHABLE_ADDR | 2) |
| NO_NAME_SERVERS | A01_NO_NAME_SERVERS_FOUND | 2) |
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory message tags"
## Zone setup for test scenarios
Assumptions for the scenario specifications unless otherwise specified for
the specific scenario:
* The child zone is `SCENARIO.address01.xa`.
* There is no zone file or zone data for the child zone.
* For each scenario zone there are two NS records (ns\[1-2]).
* All NS are in-bailiwick
* All NS have both IPv4 and IPv6 addresses
* All required glue are present in the delegation.
* EDNS, version 0, is included in all responses on queries with EDNS.
* EDNS is not included in responses on queries without EDNS.
| Address designation | Meaning |
|:-----------------------|:------------------------------------------------------------------------------------------------------|
| OK | Globally routable, public IPv4 address or global IPv6 address (not from any special purpose registry) |
| OK_SPECIAL | Globally routable IPv4 or IPv6 address from one of the special purpose registries |
| LOCAL_USE_ADDR | Address part of range used for private networks (loopback, RFC1918, Provider shared, etc.) |
| DOCUMENTATION_ADDR | Address part of range used for documentation purposes |
| NOT_GLOBALLY_REACHABLE | Address part of any other range listed as not globally reachable |
Designations are based on the address block ranges from the
[Special purpose IPv4 addresses] and [Special purpose IPv6 addresses] registries.
### GOOD-1
The "happy path". Everything is fine.
* Zone: good-1.address01.xa
* ns1
* IPv4 address OK
* IPv6 address OK
* ns2
* IPv4 address OK_SPECIAL
* IPv6 address OK_SPECIAL
### MIXED-LOCAL-DOC-1
* Zone: mixed-local-doc-1.address01.xa
* ns1
* IPv4 address LOCAL_USE_ADDR
* IPv6 address OK
* ns2
* IPv4 address OK
* IPv6 address DOCUMENTATION_ADDR
### MIXED-LOCAL-DOC-2
* Zone: mixed-local-doc-2.address01.xa
* ns1
* IPv4 address DOCUMENTATION_ADDR
* IPv6 address OK
* ns2
* IPv4 address OK
* IPv6 address LOCAL_USE_ADDR
### MIXED-DOC-OTHER-1
* Zone: mixed-doc-other-1.address01.xa
* ns1
* IPv4 address DOCUMENTATION_ADDR
* IPv6 address OK
* ns2
* IPv4 address OK
* IPv6 address NOT_GLOBALLY_REACHABLE
### MIXED-DOC-OTHER-2
* Zone: mixed-doc-other-2.address01.xa
* ns1
* IPv4 address NOT_GLOBALLY_REACHABLE
* IPv6 address OK
* ns2
* IPv4 address OK
* IPv6 address DOCUMENTATION_ADDR
### MIXED-LOCAL-OTHER-1
* Zone: mixed-local-other-1.address01.xa
* ns1
* IPv4 address LOCAL_USE_ADDR
* IPv6 address OK
* ns2
* IPv4 address OK
* IPv6 address NOT_GLOBALLY_REACHABLE
### MIXED-LOCAL-OTHER-2
* Zone: mixed-local-other-2.address01.xa
* ns1
* IPv4 address NOT_GLOBALLY_REACHABLE
* IPv6 address OK
* ns2
* IPv4 address OK
* IPv6 address LOCAL_USE_ADDR
### MIXED-ALL-1
* Zone: mixed-all-1.address01.xa
* ns1
* IPv4 address LOCAL_USE_ADDR
* IPv6 address OK
* ns2
* IPv4 address DOCUMENTATION_ADDR
* IPv6 address NOT_GLOBALLY_REACHABLE
### MIXED-ALL-2
* Zone: mixed-all-2.address01.xa
* ns1
* IPv4 address NOT_GLOBALLY_REACHABLE
* IPv6 address LOCAL_USE_ADDR
* ns2
* IPv4 address OK
* IPv6 address DOCUMENTATION_ADDR
### ALL-NON-REACHABLE
All addresses of all nameservers falls within one of the address blocks listed
as not globally reachable. Delegation contains three name servers to cover all
combinations of defined address block types.
* Zone: all-non-reachable.address01.xa
* ns1
* IPv4 address LOCAL_USE_ADDR
* IPv6 address NOT_GLOBALLY_REACHABLE
* ns2
* IPv4 address DOCUMENTATION_ADDR
* IPv6 address LOCAL_USE_ADDR
+ ns3
* IPv4 address NOT_GLOBALLY_REACHABLE
* IPv6 address DOCUMENTATION_ADDR
### NO_NAME_SERVERS
No delegation for the zone and the zone does not exist.
* Zone: no-name-servers.address01.xa
* No delegation
* No zone
[ADDRESS01]: ../../tests/Address-TP/address01.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Special purpose IPv4 addresses]: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml
[Special purpose IPv6 addresses]: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml
[Test zone README file]: ../README.md
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

249
zonemaster/docs/public/specifications/test-zones/Address-TP/address03.md Normal file
View File

@@ -0,0 +1,249 @@
# Specification of Test Scenarios for Address03
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test scenarios and setup of test zones]
## Background
See the [test scenario README file].
## Test Case
This document specifies defined test scenarios for test case [Address03].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [Address03] is run on a test zone.
The message tags are defined in the test case ([Address03]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`address03.xa`) and that subdomain having the same name as
the scenario. The names of those zones are given in section "[Test scenarios
and setup of test zones]" below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [Address03] for the specification of the tags.
* NAMESERVER_IP_PTR_MATCH
* NAMESERVER_IP_PTR_MISMATCH
* NAMESERVER_IP_WITHOUT_REVERSE
* NO_RESPONSE_PTR_QUERY
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
| Scenario name | Mandatory message tags | Forbidden message tags |
|:---------------------------|:------------------------------|:----------------------------------------------------|
| ALL-NS-HAVE-PTR-1 | NAMESERVER_IP_PTR_MATCH | 2) |
| ALL-NS-HAVE-PTR-2 | NAMESERVER_IP_PTR_MATCH | 2) |
| NO-NS-HAVE-PTR | NAMESERVER_IP_WITHOUT_REVERSE | 2) |
| INCOMPLETE-PTR-1 | NAMESERVER_IP_WITHOUT_REVERSE | 2) |
| INCOMPLETE-PTR-2 | NAMESERVER_IP_WITHOUT_REVERSE | 2) |
| NON-MATCHING-NAMES | NAMESERVER_IP_PTR_MISMATCH | 2) |
| PTR-IS-GOOD-CNAME-1 | NAMESERVER_IP_PTR_MATCH | 2) |
| PTR-IS-GOOD-CNAME-2 | NAMESERVER_IP_PTR_MATCH | 2) |
| PTR-IS-DANGLING-CNAME | NAMESERVER_IP_WITHOUT_REVERSE | 2) |
| PTR-IS-ILLEGAL-CNAME | NAMESERVER_IP_WITHOUT_REVERSE | NAMESERVER_IP_PTR_MATCH, NAMESERVER_IP_PTR_MISMATCH |
| PTR-RESOLUTION-NO-RESPONSE | NO_RESPONSE_PTR_QUERY | NAMESERVER_IP_PTR_MATCH, NAMESERVER_IP_PTR_MISMATCH |
| PTR-RESOLUTION-SERVFAIL | NO_RESPONSE_PTR_QUERY | NAMESERVER_IP_PTR_MATCH, NAMESERVER_IP_PTR_MISMATCH |
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory message tags"
## Test scenarios and setup of test zones
### Default zone configuration
Unless otherwise specified in the specific scenario specification, the test zone
for the scenario will follow the default setup as stated below. The `child zone`
is the zone to be tested for the scenario.
* The child zone is `SCENARIO.address03.xa`.
* There is a zone file for the child zone.
* The child zone is delegated to two out-of-bailiwick name servers.
* Both name servers have the same content.
* The authoritative name servers for the zone all have an IPv4 and an IPv6
address, and the reverse zones contain a single PTR resource record
matching their names for all of their addresses.
* The NS record set in the child zone is consistent with the parent zone’s
delegation.
* The parent zone is `address03.xa`.
* It is served by two in-bailiwick NS (ns1.address03.xa and
ns2.address03.xa).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue in the delegation of the parent
zone.
* The records matching glue in the zone are identical to the glue records.
* All authoritative name servers for the scenario’s child zones have names
matching ns\<NUMBER\>.child.address03.xa. These name servers’s names are
abbreviated by leaving out address03.xa from their names.
* All responses will have the AA bit set.
* All responses will have the [RCODE Name] "NoError".
### ALL-NS-HAVE-PTR-1
A happy path: a zone whose name server IP addresses have single and correct
PTR records.
* Zone: all-ns-have-ptr-1.address03.xa
* Delegated to: ns1.child and ns2.child.
### ALL-NS-HAVE-PTR-2
Another happy path: like ALL-NS-HAVE-PTR-1, but for one of the name servers,
both its IPv4 and IPv6 addresses have multiple PTR records. In each PTR
resource record set, one of the PTR records matches the name server’s name.
* Zone: all-ns-have-ptr-2.address03.xa
* Delegated to: ns1.child and ns3.child.
* ns3.child’s IP addresses have multiple PTR records, among which one points
to ns3.child.
### NO-NS-HAVE-PTR
None of the name server’s IP addresses have PTR records at all. For one of
them, NODATA is returned on PTR query; for the other, NXDOMAIN is returned.
* Zone: no-ns-have-ptr.address03.xa
* Delegated to: ns4.child and ns5.child.
* ns4.child’s IP addresses have no PTR records; the reverse zone is
configured to provoke NODATA responses on PTR queries by making the
expected node an empty non-terminal.
* ns5.child’s IP addresses have no PTR records; the reverse zone is
configured to provoke NXDOMAIN responses on PTR queries.
### INCOMPLETE-PTR-1
For one of the name servers, the PTR record is missing for its IPv4 address.
* Zone: incomplete-ptr-1.address03.xa
* Delegated to: ns1.child and ns6.child.
* ns6.child’s IPv4 address has no PTR record, but its IPv6 address does.
### INCOMPLETE-PTR-2
For one of the name servers, the PTR record is missing for its IPv6 address.
* Zone: incomplete-ptr-2.address03.xa
* Delegated to: ns1.child and ns7.child.
* ns7.child’s IPv4 address has a PTR record, but its IPv6 address does not.
### NON-MATCHING-NAMES
Both name server’s IP addresses have one or more PTR records, but none
matching the name server name.
* Zone: non-matching-names.address03.xa
* Delegated to: ns8.child and ns9.child.
* ns8.child’s IP addresses have a single PTR record, but its hostname in
RDATA is different from the name server’s name.
* ns9.child’s IP addresses have more than one PTR record, and each of them
has a hostname in RDATA different from the name server’s name.
### PTR-IS-GOOD-CNAME-1
The reverse name of one of the name servers’ IP address has an alias (CNAME)
whose target, with a PTR record, is in the same reverse zone.
* Zone: ptr-is-good-cname-1.address03.xa
* Delegated to: ns1.child and ns10.child.
* ns10.child’s IP addresses have reverse names that are aliased (CNAME) to
another name in the same zone. In other words, resolving the PTR resource
records for their IP addresses returns a CNAME resource record and the PTR
record after walking the CNAME chain.
### PTR-IS-GOOD-CNAME-2
The reverse name of one of the name servers’ IP address has an alias (CNAME)
whose target, with a PTR record, is in a different zone.
* Zone: ptr-is-good-cname-2.address03.xa
* Delegated to: ns1.child and ns11.child.
* ns11.child’s IP addresses have reverse names that are aliased (CNAME) to
another name in a different zone. In other words, resolving the PTR
resource records for their IP addresses returns only a CNAME resource
record, and another query for the name at the target of the CNAME resource
record is needed.
### PTR-IS-DANGLING-CNAME
The reverse name of one of the name servers’ IP address has an alias (CNAME)
whose target does not exist.
* Zone: ptr-is-dangling-cname.address03.xa
* Delegated to: ns5.child and ns12.child.
* ns5.child is configured as described in the NO-NS-HAVE-PTR scenario.
* ns12.child’s IP addresses have reverse names that are aliased to a
nonexistent node. In other words, there is a CNAME pointing to a node
that does not exist.
### PTR-IS-ILLEGAL-CNAME
One of the name servers has IP addresses whose reverse names contain more than
one CNAME resource record.
* Zone: ptr-is-illegal-cname.address03.xa
* Delegated to: ns4.child and ns13.child.
* ns4.child is configured as described in the NO-NS-HAVE-PTR scenario.
* ns13.child’s IP addresses have reverse names that give two CNAME
resource records.
Whether or not NO_RESPONSE_PTR_QUERY is allowed to be outputted is
intentionally left unspecified.
### PTR-RESOLUTION-NO-RESPONSE
One of the name servers has IP addresses whose reverse names fail to resolve
because the authoritative name server for the reverse zone does not respond.
One of the name servers’ IP addresses fail to resolve to PTR records because
an attempt at querying corresponding node in the `in-addr.arpa` or `ip6.arpa`
subtrees returns no response.
* Zone: ptr-resolution-no-response.address03.xa
* Delegated to: ns1.child and ns14.child.
* Querying the PTR records for ns14.child’s IP addresses return no response.
Whether or not NAMESERVER_IP_WITHOUT_REVERSE is allowed to be outputted is
intentionally left unspecified.
### PTR-RESOLUTION-SERVFAIL
One of the name servers has IP addresses whose reverse names fail to resolve
because the authoritative name server for the reverse zone gives a response
whose [RCODE Name] is neither "NoError" nor "NXDomain".
* Zone: ptr-resolution-no-response.address03.xa
* Delegated to: ns1.child and ns15.child.
* Querying the PTR records for ns15.child’s IP addresses return a "ServFail"
response.
Whether or not NAMESERVER_IP_WITHOUT_REVERSE is allowed to be outputted is
intentionally left unspecified.
[ADDRESS03]: ../../tests/Address-TP/address03.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[test scenario README file]: ../README.md
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones

7
zonemaster/docs/public/specifications/test-zones/Basic-TP/README.md Normal file
View File

@@ -0,0 +1,7 @@
# Specification of test scenarios for Basic-TP
Test scenario specifications are available for:
* [Basic01](basic01.md)
* [Basic02](basic02.md)
* Basic03 *not yet available*

502
zonemaster/docs/public/specifications/test-zones/Basic-TP/basic01.md Normal file
View File

@@ -0,0 +1,502 @@
# Specification of test zones for Basic01
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
## Background
See the [test zone README file].
## Test Case
This document specifies defined test zones for test case [Basic01].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [Basic01] is run on a test zone.
The message tags are defined in the test case ([Basic01]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test zone README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain (or lower
zone) delegated from the base name (`basic01.xa`) and that subdomain having the
same name as the scenario. The names of those zones are given in section
"[Zone setup for test scenarios]" below.
## All tags
The test case can output any of these message tags, but not necessarily in any combination.
* B01_CHILD_FOUND
* B01_CHILD_IS_ALIAS
* B01_INCONSISTENT_ALIAS
* B01_INCONSISTENT_DELEGATION
* B01_NO_CHILD
* B01_PARENT_DISREGARDED
* B01_PARENT_FOUND
* B01_PARENT_NOT_FOUND
* B01_PARENT_UNDETERMINED
* B01_ROOT_HAS_NO_PARENT
* B01_SERVER_ZONE_ERROR
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:-------------------------|:----------------------------------------------------------------------------------|:----------------------
GOOD-1 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
GOOD-MIXED-1 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
GOOD-MIXED-2 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
GOOD-PARENT-HOST-1 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
GOOD-GRANDPARENT-HOST-1 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
GOOD-UNDEL-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
GOOD-MIXED-UNDEL-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
GOOD-MIXED-UNDEL-2 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
NO-DEL-UNDEL-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
NO-DEL-MIXED-UNDEL-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
NO-DEL-MIXED-UNDEL-2 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
NO-CHILD-1 | B01_NO_CHILD, B01_PARENT_FOUND | 2)
NO-CHILD-2 | B01_NO_CHILD, B01_PARENT_FOUND | 2)
NO-CHLD-PAR-UNDETER-1 | B01_NO_CHILD, B01_PARENT_FOUND, B01_PARENT_UNDETERMINED | 2)
CHLD-FOUND-PAR-UNDET-1 | B01_CHILD_FOUND, B01_PARENT_FOUND, B01_PARENT_UNDETERMINED | 2)
CHLD-FOUND-INCONSIST-1 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
CHLD-FOUND-INCONSIST-2 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
CHLD-FOUND-INCONSIST-3 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
CHLD-FOUND-INCONSIST-4 | B01_CHILD_IS_ALIAS, B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND| 2)
CHLD-FOUND-INCONSIST-5 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
CHLD-FOUND-INCONSIST-6 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
CHLD-FOUND-INCONSIST-7 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
CHLD-FOUND-INCONSIST-8 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
CHLD-FOUND-INCONSIST-9 | B01_CHILD_IS_ALIAS, B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND| 2)
CHLD-FOUND-INCONSIST-10 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
NO-DEL-UNDEL-NO-PAR-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
NO-DEL-UNDEL-PAR-UND-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
NO-CHLD-NO-PAR-1 | B01_NO_CHILD, B01_PARENT_NOT_FOUND, B01_SERVER_ZONE_ERROR | 2)
CHILD-ALIAS-1 | B01_CHILD_IS_ALIAS, B01_NO_CHILD, B01_PARENT_FOUND | 2)
CHILD-ALIAS-2 | B01_CHILD_IS_ALIAS, B01_NO_CHILD, B01_INCONSISTENT_ALIAS, B01_PARENT_FOUND | 2)
ZONE-ERR-GRANDPARENT-1 | B01_CHILD_FOUND, B01_PARENT_FOUND, B01_SERVER_ZONE_ERROR | 2)
ZONE-ERR-GRANDPARENT-2 | B01_CHILD_FOUND, B01_PARENT_FOUND, B01_SERVER_ZONE_ERROR | 2)
ZONE-ERR-GRANDPARENT-3 | B01_CHILD_FOUND, B01_PARENT_FOUND, B01_SERVER_ZONE_ERROR | 2)
ROOT-ZONE | B01_CHILD_FOUND, B01_ROOT_HAS_NO_PARENT | 2)
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory message tags"
## Zone setup for test scenarios
Assumptions for the scenario specifications unless otherwise specified for
the specific scenario:
* The child zone is `child.parent.SCENARIO.basic01.xa`.
* It is delegated to two name servers, `ns1-delegated-child.basic01.xa`
and `ns2-delegated-child.basic01.xa`.
* The name server names have A and AAAA records to avoid non-relevant error
messages.
* There is no zone file or zone data for the child zone.
* If there is an undelegated "version" of the child zone, it is
referred to `ns3-undelegated-child.basic01.xa` and
`ns4-undelegated-child.basic01.xa`.
* The name server names have A and AAAA records to avoid non-relevant error
messages.
* There is no zone file or zone data for the undelegated "version".
* The parent zone is `parent.SCENARIO.basic01.xa`.
* It is served by two in-bailiwick NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* The delegation from the grand parent has the same NS with complete glue.
* The grandparent zone is `SCENARIO.basic01.xa`.
* It is served by two in-bailiwick NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* The delegation from the SCENARIO zone has the same NS with complete glue.
* Responds with a A record for the zone on query for A.
* Responds with a AAAA record for the zone on query for AAAA.
* All responses are authoritative with [RCODE Name] "NoError"
* EDNS, version 0, is included in all responses on queries with EDNS.
* EDNS is not included in responses on queries without EDNS.
* Standard test zone root is used.
* In all cases, delegation and zone are consistent.
* Same NS.
* Any required glue matches address records in zone.
* No extra address records for the NS names.
### GOOD-1
A "happy path". Everything is fine.
* Zone: child.parent.good-1.basic01.xa
### GOOD-MIXED-1
One grandparent server also serves parent zone.
* Zone: child.parent.good-mixed-1.basic01.xa
* Parent zone `parent.good-mixed-1.basic01.xa` is served by `ns1`, `ns2` and on
`ns4.good-mixed-1.basic01.xa`.
* Grandparent zone `good-mixed-1.basic01.xa` is served on `ns1` and `ns4`.
### GOOD-MIXED-2
One parent server also hosts the child zone.
* Zone: child.parent.good-mixed-2.basic01.xa
* Child zone is served by `ns1`, `ns2` and
`ns4.parent.good-mixed-2.basic01.xa`.
* Child zone exists.
* There is a zone file for the child zone, and that is loaded on the child
zone name servers.
* Parent zone `parent.good-mixed-2.basic01.xa` is served by `ns1` and `ns4`.
### GOOD-PARENT-HOST-1
The child is hosted on parent servers only.
* Zone: child.parent.good-parent-host-1.basic01.xa
* Child zone is served by `ns1.parent.good-parent-host-1.basic01.xa` and
`ns2.parent.good-parent-host-1.basic01.xa`.
* There is a zone file for the child zone.
### GOOD-GRANDPARENT-HOST-1
The child is hosted on grandparent servers only.
* Zone: child.parent.good-grandparent-host-1.basic01.xa
* Child zone is served by `ns1.good-grandparent-host-1.basic01.xa` and
`ns2.good-grandparent-host-1.basic01.xa`.
* There is a zone file for the child zone.
### GOOD-UNDEL-1
The child zone is delegated, but there is also an undelegated version which is
the one tested.
* Zone: child.parent.good-undel-1.basic01.xa
* Child zone is delegated, but there is also an undelegated version.
* There are no zone files for child (delegated or undelegated).
* Undelegated data:
* ns3-undelegated-child.basic01.xa
* ns4-undelegated-child.basic01.xa
### GOOD-MIXED-UNDEL-1
The child zone is delegated, but there is also an undelegated version which is
the one tested. One grandparent server, in the delegated tree, also serves
parent zone.
* Zone: child.parent.good-mixed-undel-1.basic01.xa
* Parent zone `parent.good-mixed-undel-1.basic01.xa` is served by `ns1`, `ns2` and on
`ns4.good-mixed-undel-1.basic01.xa`.
* Grandparent zone `good-mixed-undel-1.basic01.xa` is served on `ns1` and `ns4`.
* Child zone is delegated, but there is also an undelegated version.
* No child zone exists.
* Undelegated data:
* ns3-undelegated-child.basic01.xa
* ns4-undelegated-child.basic01.xa
### GOOD-MIXED-UNDEL-2
The child zone is delegated, but there is also an undelegated version. One parent
server also serves the delegated child zone.
* Zone: child.parent.good-mixed-undel-2.basic01.xa
* Child zone is served by `ns1`, `ns2` and
`ns6.parent.good-mixed-undel-2.basic01.xa`.
* Child zone exists.
* Parent zone `parent.good-mixed-undel-2.basic01.xa` is served by `ns1` and
`ns6`.
* Child zone is delegated, but there is also an undelegated version, but no
zone for the undelegated version.
* Undelegated data:
* ns3-undelegated-child.basic01.xa
* ns4-undelegated-child.basic01.xa
### NO-DEL-UNDEL-1
The child zone is not delegated, but there is an undelegated version.
* Zone: child.parent.no-del-undel-1.basic01.xa
* Undelegated data:
* ns3-undelegated-child.basic01.xa
* ns4-undelegated-child.basic01.xa
### NO-DEL-MIXED-UNDEL-1
The child zone is not delegated, but there is an undelegated version that is
tested. One grandparent server also serves the parent zone.
* Zone: child.parent.no-del-mixed-undel-1.basic01.xa
* Parent zone `parent.no-del-mixed-undel-1.basic01.xa` is served by `ns1`, `ns2` and on
`ns4.no-del-mixed-undel-1.basic01.xa`.
* Grandparent zone `no-del-mixed-undel-1.basic01.xa` is served on `ns1` and `ns4`.
* Child zone is not delegated, but there is an undelegated version, but no zone file.
* Undelegated data:
* ns3-undelegated-child.basic01.xa
* ns4-undelegated-child.basic01.xa
### NO-DEL-MIXED-UNDEL-2
The child zone is not delegated, but there is an undelegated version that is
tested. One grandparent server also serves the parent zone. There are extra empty
nodes between the zone cuts.
* Zone: child.w.x.parent.y.z.no-del-mixed-undel-2.basic01.xa
* Parent zone `parent.y.z.no-del-mixed-undel-2.basic01.xa` is served by `ns1`,
`ns2` and on `ns4.no-del-mixed-undel-2.basic01.xa`.
* Grandparent zone `no-del-mixed-undel-2.basic01.xa` is served on `ns1` and `ns4`.
* There are no zone cuts at `w`, `x`, `y` and `z`.
* Child zone is not delegated, but there is also an undelegated version, but no
zone file.
* Undelegated data:
* ns3-undelegated-child.basic01.xa
* ns4-undelegated-child.basic01.xa
### NO-CHILD-1
The child zone is not delegated. Parent zone returns NXDOMAIN.
* Zone: child.parent.no-child-1.basic01.xa
* Child zone does not exist and is not served by any NS.
### NO-CHILD-2
The child zone is not delegated. Parent zone returns NODATA.
* Zone: child.parent.no-child-2.basic01.xa
* Child zone does not exist and is not served by any NS.
* The name child.parent.no-child-2.basic01.xa exists as a TXT record.
### NO-CHLD-PAR-UNDETER-1
The child zone is not delegated. One grandparent NS lacks delegation of parent
and return NXDOMAIN of child. The parent zone lacks delegation of child.
* Zone: child.parent.no-chld-par-undeter-1.basic01.xa
* Child zone does not exist is not served by any NS.
* Grandparent `ns1` lacks delegation of parent.
* Grandparent `ns2` has delegation of parent (to both parent NS).
* Parent zone lacks delegation of child.
### CHLD-FOUND-PAR-UNDET-1
The child zone is delegated from one grandparent NS and from the parent zone.
* Zone: child.parent.chld-found-par-undet-1.basic01.xa
* Grandparent `ns1` has delegation of child but lacks delegation of parent.
* Grandparent `ns2` has delegation of parent (to both parent NS).
* Parent zone has delegation of child.
### CHLD-FOUND-INCONSIST-1
The child is delegated from one parent NS. The other responds with NXDOMAIN.
* Zone: child.parent.chld-found-inconsist-1.basic01.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child (NXDOMAIN).
### CHLD-FOUND-INCONSIST-2
The child is delegated from one parent NS. On the other there is an CNAME
response.
* Zone: child.parent.chld-found-inconsist-2.basic01.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, and has a CNAME on that name,
pointing at `no-child.parent.chld-found-inconsist-2.basic01.xa`, which has
two address records (A and AAAA) with the IP addresses of child `ns2`.
### CHLD-FOUND-INCONSIST-3
The child is delegated from one parent NS. On the other there is a CNAME
to another name, and that other name is delegated.
* Zone: child.parent.chld-found-inconsist-3.basic01.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, and has a CNAME on the name,
pointing at `sister.parent.chld-found-inconsist-3.basic01.xa`, which is
delegated to `ns1-delegated-child.basic01.xa` and
`ns2-delegated-child.basic01.xa`.
* Zone `sister` does not exist.
### CHLD-FOUND-INCONSIST-4
The child is delegated from one parent NS. On the other there is a DNAME to
another name.
* Zone: child.parent.chld-found-inconsist-4.basic01.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` has a DNAME on `child` pointing at
`sister.parent.chld-found-inconsist-4.basic01.xa` which is delegated to
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
* Zone `sister` does not exist.
### CHLD-FOUND-INCONSIST-5
The child is delegated from one parent NS. On the other there is a NODATA
response.
* Zone: child.parent.chld-found-inconsist-5.basic01.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, instead `child` has two address
records (A and AAAA) with the IP addresses of child `ns2`.
### CHLD-FOUND-INCONSIST-6
The child is delegated from one parent NS, which is also NS for the child.
On the other there is an NXDOMAIN response.
* Zone: child.parent.chld-found-inconsist-6.basic01.xa
* Parent `ns1` has normal delegation of child to the two child NS.
* Parent `ns2` lacks delegation of child (NXDOMAIN).
* Child shares `ns1.parent.chld-found-inconsist-6.basic01.xa` with parent.
* Child also uses child `ns2`.
* Child exists with a zone.
### CHLD-FOUND-INCONSIST-7
The child is delegated from one parent NS, which is also NS for the child. On the
other there is a CNAME response.
* Zone: child.parent.chld-found-inconsist-7.basic01.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, and has a CNAME on that name,
pointing at `no-child.parent.chld-found-inconsist-7.basic01.xa`, which has
two address records (A and AAAA) with the IP addresses of child `ns2`.
* Child shares `ns1.parent.chld-found-inconsist-7.basic01.xa` with parent.
* Child also uses `ns2`.
* Child exists with a zone.
### CHLD-FOUND-INCONSIST-8
The child is delegated from one parent NS, which is also NS for the child. On
the other there is a CNAME to another name, and that other name is delegated.
* Zone: child.parent.chld-found-inconsist-8.basic01.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, and has a CNAME on the name,
pointing at `sister.parent.chld-found-inconsist-8.basic01.xa`, which is
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
* Zone `sister` does not exist.
* Child shares `ns1.parent.chld-found-inconsist-8.basic01.xa` with parent.
* Child also uses `ns2`.
* Child exists with a zone.
### CHLD-FOUND-INCONSIST-9
The child is delegated from one parent NS, which is also NS for the child. On
the other there is a DNAME to another name.
* Zone: child.parent.chld-found-inconsist-9.basic01.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` has a DNAME on `child` pointing at
`sister.parent.chld-found-inconsist-9.basic01.xa` which is delegated to
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
* Zone `sister` does not exist.
* Child shares `ns1.parent.chld-found-inconsist-9.basic01.xa` with parent.
* Child also uses `ns2`.
* Child exists with a zone.
### CHLD-FOUND-INCONSIST-10
The child is delegated from one parent NS, which is also NS for the child. On the
other there is a NODATA response.
* Zone: child.parent.chld-found-inconsist-10.basic01.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, instead `child` has two address
records (A and AAAA) with the IP addresses of child `ns2`.
* Child shares `ns1.parent.chld-found-inconsist-10.basic01.xa` with parent.
* Child also uses `ns2`.
* Child exists with a zone.
### NO-DEL-UNDEL-NO-PAR-1
The child is not delegated, but there is undelegated data to test. Both
grandparent NS return SERVFAIL.
* Zone: child.parent.no-del-undel-no-par-1.basic01.xa
* Grandparent `ns1` and `ns2` both return SERVFAIL.
* No need of parent zone.
* Child zone is not delegated, but there is an undelegated version.
* Undelgated data:
* ns3-undelegated-child.basic01.xa
* ns4-undelegated-child.basic01.xa
### NO-DEL-UNDEL-PAR-UND-1
The child is not delegated, but there is an undelegated data to test. One
grandparent NS lacks delegation of parent and return NXDOMAIN of child. The
parent zone lacks delegation of child.
* Zone: child.parent.no-del-undel-par-und-1.basic01.xa
* Child zone does not exist is not served by any NS.
* Grandparent `ns1` lacks delegation of parent.
* Grandparent `ns2` has delegation of parent (to both parent NS).
* Parent zone lacks delegation of child.
* Child zone is not delegated, but there is an undelegated version.
* Undelegated data:
* ns3-undelegated-child.basic01.xa
* ns4-undelegated-child.basic01.xa
### NO-CHLD-NO-PAR-1
The child is not delegated. Both grandparent NS return SERVFAIL.
* Zone: child.parent.no-chld-no-par-1.basic01.xa
* Grandparent `ns1` and `ns2` both return SERVFAIL.
* No need of parent zone.
* Child zone is not delegated, and there is no undelegated data.
* No need of child zone.
### CHILD-ALIAS-1
The child zone does not exist, instead there is a DNAME in the parent zone.
* Zone: child.parent.child-alias-1.basic01.xa
* Parent has a DNAME on `child` pointing at
`sister.parent.child-alias-1.basic01.xa` which is delegated to
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
* Zone `sister` does not exist.
### CHILD-ALIAS-2
The child zone does not exist, instead there is a DNAME in the parent zone,
however, different DNAME targets in the two parents.
* Zone: child.parent.child-alias-2.basic01.xa
* On `ns1` parent has a DNAME on `child` pointing at
`sister.parent.child-alias-2.basic01.xa` which is delegated to
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
* Zone `sister` does not exist.
* On `ns2` parent has a DNAME on `child` pointing at
`brother.parent.child-alias-2.basic01.xa` which is delegated to
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
* Zone `brother` does not exist.
### ZONE-ERR-GRANDPARENT-1
Grandparent `ns2` responds with AA bit unset on queries for grandparent zone.
* Zone: child.parent.zone-err-grandparent-1.basic01.xa
* Normal response on grandparent `ns1`.
* Grandparent `ns2` responds with AA bit unset on queries for the
grandparent zone.
### ZONE-ERR-GRANDPARENT-2
Grandparent `ns2` responds with NODATA on NS query for grandparent zone.
* Zone: child.parent.zone-err-grandparent-2.basic01.xa
* Normal response on grandparent `ns1`.
* Grandparent `ns2` responds with NODATA on NS query for the
grandparent zone.
### ZONE-ERR-GRANDPARENT-3
Grandparent `ns2` responds with wrong owner name on NS
on query for grandparent zone NS.
* Zone: child.parent.zone-err-grandparent-3.basic01.xa
* Normal response on grandparent `ns1`.
* Grandparent `ns2` responds with other owner name on NS query for
`zone-err-grandparent-3.basic01.xa`:
* Owner name `oncle.zone-err-grandparent-3.basic01.xa` instead.
### ROOT-ZONE
Test on the standard root zone.
* Zone: .
* No special zone files are to be created.
[Basic01]: ../../tests/Basic-TP/basic01.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../README.md
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

416
zonemaster/docs/public/specifications/test-zones/Basic-TP/basic02.md Normal file
View File

@@ -0,0 +1,416 @@
# Specification of Test Scenarios for Basic02
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test scenarios and setup of test zones](#test-scenarios-and-setup-of-test-zones)
## Background
See the [test scenario README file].
## Test Case
This document specifies defined test scenarios for test case [Basic02].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [Basic02] is run on a test zone.
The message tags are defined in the test case ([Basic02]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone or zones for each test scenario in this document is a subdomain
(or lower zone) delegated from the base name (`basic02.xa`) and that subdomain
having the same name as the scenario. The names of those zones are given in
section "[Test scenarios and setup of test zones]" below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [Basic02] for the specification of the tags.
* B02_AUTH_RESPONSE_SOA
* B02_NO_DELEGATION
* B02_NO_WORKING_NS
* B02_NS_BROKEN
* B02_NS_NOT_AUTH
* B02_NS_NO_IP_ADDR
* B02_NS_NO_RESPONSE
* B02_UNEXPECTED_RCODE
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:------------------------------|:-------------------------------------------|:----------------------
GOOD-1 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-2 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-1 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-2 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-3 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-4 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-5 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-6 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-7 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-8 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-9 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-10 | B02_AUTH_RESPONSE_SOA | 2)
GOOD-UNDEL-11 | B02_AUTH_RESPONSE_SOA | 2)
MIXED-1 | B02_AUTH_RESPONSE_SOA | 2)
NO-DELEGATION-1 | B02_NO_DELEGATION | 2)
NS-BROKEN-1 | B02_NS_BROKEN, B02_NO_WORKING_NS | 2)
NS-NOT-AUTH-1 | B02_NS_NOT_AUTH, B02_NO_WORKING_NS | 2)
NS-NO-IP-1 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
NS-NO-IP-2 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
NS-NO-IP-3 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
NS-NO-IP-UNDEL-1 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
NS-NO-IP-UNDEL-2 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
NS-NO-RESPONSE-1 | B02_NS_NO_RESPONSE, B02_NO_WORKING_NS | 2)
UNEXPECTED-RCODE-1 | B02_UNEXPECTED_RCODE, B02_NO_WORKING_NS | 2)
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory message tags"
## Test scenarios and setup of test zones
### Default zone configuration
Unless otherwise specified in the specific scenario specification, the test zone
or zones for the scenario will follow the default setup as stated below. The
`child zone` is the zone to be tested for the scenario.
`basic02.xb` is a zone for out-of-bailiwick name servers for applicable
scenario.
* The child zone is `SCENARIO.basic02.xa`.
* It is delegated to two name servers, `ns1.SCENARIO.basic02.xa`
and `ns2.SCENARIO.basic02.xa`.
* The name server names have A and AAAA records to avoid non-relevant error
messages.
* The delegation of the child zone is complete with glue records.
* There is a zone file for the child zone.
* All child zone servers give the same response.
* All responses will have the AA bit set.
* All responses will have the [RCODE Name] "NoError".
* NS and any glue matches NS and authoritative address records in zone.
* If NS are out of bailiwick, the names are defined in another zone with correct
A and AAAA records.
### GOOD-1
A "happy path". Everything is fine.
* Zone: good-1.basic02.xa
* Zone is set up as default.
### GOOD-2
Like GOOD-1 but name servers are out-of-bailiwick.
* Zone: good-1.basic02.xa
* ns1 is ns1.good-2.basic02.xb.
* ns2 is ns2.good-2.basic02.xb.
* Delegation is without glue.
### Overview of the GOOD-UNDEL-x scenarios
Scenario name | Delegated zone | Undelegated data
:--------------|:------------------------------|:--------------------
GOOD-UNDEL-1 | no delegation | IB with glue
GOOD-UNDEL-2 | no delegation | OOB without glue, NS names are defined
GOOD-UNDEL-3 | IB, no response | OOB without glue, NS names are defined
GOOD-UNDEL-4 | IB, no glue | OOB without glue, NS names are defined
GOOD-UNDEL-5 | IB, no glue | IB with glue
GOOD-UNDEL-6 | OOB, no response | IB with glue
GOOD-UNDEL-7 | OOB, no address records | OOB with glue, NS names are undefined
GOOD-UNDEL-8 | IB, no response | IB, IP redefined
GOOD-UNDEL-9 | OOB, no response | OOB, IP redefined
GOOD-UNDEL-10 | OOB, SERVFAIL/REFUSED | OOB
GOOD-UNDEL-11 | OOB, cannot look addr up | OOB, IP through lookup
### GOOD-UNDEL-1
The zone is not delegated. Undelegated data provides a working zone.
* Zone: good-undel-1.basic02.xa
* The zone is not delegated.
* Else, the zone from undelegated data is set up as default.
* Undelegated data:
* ns1.good-undel-1.basic02.xa/IPv4
* ns1.good-undel-1.basic02.xa/IPv6
* ns2.good-undel-1.basic02.xa/IPv4
* ns2.good-undel-1.basic02.xa/IPv6
### GOOD-UNDEL-2
The zone is not delegated. Undelegated data provides a working zone. NS are
out-of-bailiwick.
* Zone: good-undel-2.basic02.xa
* The zone is not delegated.
* The undelegated data has out-of-bailiwick name servers without glue.
* Normal lookup provides IP addresses for the name server names.
* Else, the zone from undelegated data is set up as default.
* Undelegated data:
* ns1.good-undel-2.basic02.xb
* ns2.good-undel-2.basic02.xb
### GOOD-UNDEL-3
Delegated zone does not respond. There is a working zone from undelegated data.
Those NS are out-of-bailiwick.
* Zone: good-undel-3.basic02.xa
* The name servers in delegation are ns1 and ns2.
* Name servers from delegation do not respond.
* The undelegated data has out-of-bailiwick name servers without glue.
* Normal lookup provides IP addresses for the name server names.
* Else, the zone from undelegated data is set up as default.
* Undelegated data:
* ns3.good-undel-3.basic02.xb
* ns4.good-undel-3.basic02.xb
### GOOD-UNDEL-4
Delegation of zone lacks glue. There is a working zone from undelegated data.
Those NS are out-of-bailiwick.
* Zone: good-undel-4.basic02.xa
* The name servers in delegation are ns1 and ns2.
* There is no glue for ns1 and ns2.
* The undelegated data has out-of-bailiwick name servers without glue.
* Normal lookup provides IP addresses for the name server names.
* Else, the zone from undelegated data is set up as default.
* Undelegated data:
* ns1.good-undel-4.basic02.xb
* ns2.good-undel-4.basic02.xb
### GOOD-UNDEL-5
Delegation of zone lacks glue. There is a working zone from undelegated data.
* Zone: good-undel-5.basic02.xa
* The name servers in delegation ns1 and ns2.
* There is no glue for ns1 and ns2.
* The undelegated data has the same NS names with glue.
* Else, the zone from undelegated data is set up as default.
* Undelegated data:
* ns1.good-undel-5.basic02.xa/IPv4
* ns1.good-undel-5.basic02.xa/IPv6
* ns2.good-undel-5.basic02.xa/IPv4
* ns2.good-undel-5.basic02.xa/IPv6
### GOOD-UNDEL-6
Zone is delegated to out-of-bailiwick NS, but with no response. There is a
working zone from undelegated data.
* Zone: good-undel-6.basic02.xa
* The name servers in delegation are ns1.good-undel-6.basic02.xb and
ns2.good-undel-6.basic02.xb.
* Normal lookup provides IP addresses for the name server names.
* The servers in delegation do not respond.
* The zone from undelegated data is set up as default.
* Undelegated data:
* ns3.good-undel-6.basic02.xa/IPv4
* ns3.good-undel-6.basic02.xa/IPv6
* ns4.good-undel-6.basic02.xa/IPv4
* ns4.good-undel-6.basic02.xa/IPv6
### GOOD-UNDEL-7
Zone is delegated to out-of-bailiwick NS, but with no IP for NS. There is a
working zone from undelegated data, also out-of-bailiwick.
* Zone: good-undel-7.basic02.xa
* The name servers in delegation are ns1.good-undel-7.basic02.xb and
ns2.good-undel-7.basic02.xb.
* ns1 and ns2 are defined, but with no address records.
* The NS in undelegated data use names that are not defined.
* The zone from undelegated data is set up as default.
* Undelegated data:
* ns3.good-undel-7.basic02.xb/IPv4
* ns3.good-undel-7.basic02.xb/IPv6
* ns4.good-undel-7.basic02.xb/IPv4
* ns5.good-undel-7.basic02.xb/IPv6
### GOOD-UNDEL-8
Zone is delegated, but no response from the NS of delegation. There is a working
zone from undelegated data.
* Zone: good-undel-8.basic02.xa
* The name servers in delegation are dns1 and dns2.
* There is no response from dns1 and dns2.
* The NS in undelegated data use the same NS names with other IP addresses.
* Else, the zone from undelegated data is set up as default.
* Undelegated data:
* dns1.good-undel-8.basic02.xa/IPv4
* dns1.good-undel-8.basic02.xa/IPv6
* dns2.good-undel-8.basic02.xa/IPv4
* dns2.good-undel-8.basic02.xa/IPv6
### GOOD-UNDEL-9
Zone is delegated to out-of-bailiwick NS, but with no response. There is a
working zone from undelegated data.
* Zone: good-undel-9.basic02.xa
* The name servers in delegation are dns1.good-undel-9.basic02.xb and
dns2.good-undel-9.basic02.xb.
* Normal lookup provides IP addresses for the name server names.
* The servers in delegation do not respond.
* The NS in undelegated data use the same NS names with other IP addresses.
* The zone from undelegated data is set up as default.
* Undelegated data:
* dns1.good-undel-9.basic02.xb/IPv4
* dns1.good-undel-9.basic02.xb/IPv6
* dns2.good-undel-9.basic02.xb/IPv4
* dns2.good-undel-9.basic02.xb/IPv6
### GOOD-UNDEL-10
Zone is delegated to out-of-bailiwick NS, but with SERVFAIL or REFUSED response.
There is a working zone from undelegated data, also out-of-bailiwick.
* Zone: good-undel-10.basic02.xa
* The name servers in delegation are ns1.good-undel-10.basic02.xb and
ns2.good-undel-10.basic02.xb.
* Normal lookup provides IP addresses for the name server names.
* The servers in delegation respond with SERVFAIL (ns1) or REFUSED (ns2).
* The NS in undelegated data use other IP addresses.
* The zone from undelegated data is set up as default.
* Undelegated data:
* ns3.good-undel-10.basic02.xb/IPv4
* ns3.good-undel-10.basic02.xb/IPv6
* ns4.good-undel-10.basic02.xb/IPv4
* ns4.good-undel-10.basic02.xb/IPv6
### GOOD-UNDEL-11
Zone is delegated to out-of-bailiwick NS whose names are in a zone that is
not reachable (addresses cannot be looked up). There is a working zone from
undelegated data, also out-of-bailiwick.
* Zone: good-undel-11.basic02.xa
* The name servers in delegation are ns1.delegated.good-undel-11.basic02.xb
and ns2.delegated.good-undel-11.basic02.xb.
* Normal lookup fails to provides IP addresses for the name server names
since zone delegated.good-undel-11.basic02.xb cannot be reached.
* delegated.good-undel-11.basic02.xb is delegated to dns1 and dns2 relative
to that domain.
* There is no actual zone for the delegated data (not needed).
* The zone from undelegated data is set up as default.
* The addresses for the NS for the undelegated zone are found via lookup.
* Undelegated data:
* ns3.good-undel-11.basic02.xb
* ns4.good-undel-11.basic02.xb
### MIXED-1
The zone is delegated to four NS, of which ns1 responds correctly, ns2 does
not respond, ns3 returns SERVFAIL and ns4 is not authoritative.
* Zone: mixed-1.basic02.xa
* The zone is set-up as default, but with four NS (ns1-4).
* ns1 gives correct response.
* ns2 does not respond.
* ns3 returns SERVFAIL on all queries.
* ns4 returns all responses with AA flag unset.
### NO-DELEGATION
There is no delegation for the zone.
* Zone: no-delegation.basic02.xa
* No zone.
* No name servers.
* No delegation.
### NS-BROKEN-1
The servers for the zone do not respond with SOA record on SOA query.
* Zone: ns-broken-1.basic02.xa
* No SOA record in response from ns1 and ns2.
* RCODE is NOERROR and AA bit is set.
### NS-NOT-AUTH-1
The servers for the zone do not give authoritative responses.
* Zone: ns-not-auth-1.basic02.xa
* AA bit is unset in responses from ns1 and ns2.
### NS-NO-IP-1
The delegation is without glue.
* Zone: ns-no-ip-1.basic02.xa
* There is no glue in delegation for ns1 and ns2.
* No zone is set up.
### NS-NO-IP-2
The name server are out-of-bailiwick but have no address records.
* Zone: ns-no-ip-2.basic02.xa
* ns1 and ns2 are out-of-bailiwick.
* ns1 is ns1.ns-no-ip-2.basic02.xb.
* ns2 is ns2.ns-no-ip-2.basic02.xb.
* ns1 and ns2 exist as names, but have no address records.
* No zone is set up.
### NS-NO-IP-3
The name server are out-of-bailiwick but the names are not defined.
* Zone: ns-no-ip-3.basic02.xa
* ns1 and ns2 are out-of-bailiwick.
* ns1 is ns1.ns-no-ip-3.basic02.xb.
* ns2 is ns2.ns-no-ip-3.basic02.xb.
* ns1 and ns2 do not exist as names.
* No zone is set up.
### NS-NO-IP-UNDEL-1
The delegated zone works correctly. The undelegated data has in-bailiwick NS
without glue.
* Zone: ns-no-ip-undel-1.basic02.xa
* ns1 and ns2 serves a working zone.
* The undelegated data uses the same NS names but without glue.
* There is no need for a zone for undelegated data.
* Undelegated data:
* ns1.ns-no-ip-undel-1.basic02.xa
* ns2.ns-no-ip-undel-1.basic02.xa
### NS-NO-IP-UNDEL-2
The delegated zone works correctly. The undelegated data has out-of-bailiwick NS
without glue. The NS names have no address records.
* Zone: ns-no-ip-undel-2.basic02.xa
* ns1 and ns2 serves a working zone.
* The undelegated data uses out-of-bailiwick NS.
* NS names exists.
* NS names do not resolve to address records.
* There is no need for a zone for undelegated data.
* Undelegated data:
* ns1.ns-no-ip-undel-2.basic02.xb
* ns2.ns-no-ip-undel-2.basic02.xb
### NS-NO-RESPONSE-1
The name servers do not respond on the queries.
* Zone: ns-no-response-1.basic02.xa
* ns1 and ns2 do not respond to queries.
* No zone is set up.
### UNEXPECTED-RCODE-1
The name servers respond with NXDOMAIN, REFUSED or SERVFAIL on SOA query.
* Zone: unexpected-rcode-1.basic02.xa
* ns1 responds with NXDOMAIN.
* ns2 responds with REFUSED.
* ns3 responds with SERVFAIL.
* No actual zone exists.
[Basic02]: ../../tests/Basic-TP/basic02.md
[test scenario README file]: ../README.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones

6
zonemaster/docs/public/specifications/test-zones/Connectivity-TP/README.md Normal file
View File

@@ -0,0 +1,6 @@
# Specification of test scenarios for Connectivity-TP
Test scenario specifications are available for:
* [Connectivity04](connectivity04.md)

301
zonemaster/docs/public/specifications/test-zones/Connectivity-TP/connectivity04.md Normal file
View File

@@ -0,0 +1,301 @@
# Specification of Test Scenarios for Connectivity04
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test scenarios and setup of test zones]
## Background
See the [test scenario README file].
## Test Case
This document specifies defined test scenarios for test case [Connectivity04].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [Connectivity04] is run on a test zone.
The message tags are defined in the test case ([Connectivity04]) and the
scenarios are defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone or zones for each test scenario in this document is a subdomain
(or lower zone) delegated from the base name (`connectivity04.xa`) and that subdomain
having the same name as the scenario. The names of those zones are given in
section "[Test scenarios and setup of test zones]" below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [Connectivity04] for the specification of the tags.
* CN04_EMPTY_PREFIX_SET
* CN04_ERROR_PREFIX_DATABASE
* CN04_IPV4_DIFFERENT_PREFIX
* CN04_IPV4_SAME_PREFIX
* CN04_IPV4_SINGLE_PREFIX
* CN04_IPV6_DIFFERENT_PREFIX
* CN04_IPV6_SAME_PREFIX
* CN04_IPV6_SINGLE_PREFIX
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:------------------------|:----------------------------------------------------------------------------------|:--------------------
GOOD-1 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
GOOD-2 | CN04_IPV4_DIFFERENT_PREFIX | 2)
GOOD-3 | CN04_IPV6_DIFFERENT_PREFIX | 2)
EMPTY-PREFIX-SET-1 | CN04_EMPTY_PREFIX_SET | 2)
EMPTY-PREFIX-SET-2 | CN04_EMPTY_PREFIX_SET | 2)
ERROR-PREFIX-DATABASE-1 | CN04_ERROR_PREFIX_DATABASE | 2)
ERROR-PREFIX-DATABASE-2 | CN04_ERROR_PREFIX_DATABASE | 2)
ERROR-PREFIX-DATABASE-3 | CN04_ERROR_PREFIX_DATABASE | 2)
ERROR-PREFIX-DATABASE-6 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX, CN04_ERROR_PREFIX_DATABASE| 2)
ERROR-PREFIX-DATABASE-7 | CN04_ERROR_PREFIX_DATABASE | 2)
ERROR-PREFIX-DATABASE-8 | CN04_ERROR_PREFIX_DATABASE | 2)
HAS-NON-ASN-TXT-1 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
HAS-NON-ASN-TXT-2 | CN04_EMPTY_PREFIX_SET | 2)
IPV4-ONE-PREFIX-1 | CN04_IPV4_SAME_PREFIX, CN04_IPV4_SINGLE_PREFIX | 2)
IPV4-TWO-PREFIXES-1 | CN04_IPV4_SAME_PREFIX, CN04_IPV4_DIFFERENT_PREFIX | 2)
IPV6-ONE-PREFIX-1 | CN04_IPV6_SAME_PREFIX, CN04_IPV6_SINGLE_PREFIX | 2)
IPV6-TWO-PREFIXES-1 | CN04_IPV6_SAME_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
IPV4-SINGLE-NS-1 | CN04_IPV4_SINGLE_PREFIX, CN04_IPV4_DIFFERENT_PREFIX | 2)
IPV6-SINGLE-NS-1 | CN04_IPV6_SINGLE_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
DOUBLE-PREFIX-1 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
DOUBLE-PREFIX-2 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory message tags"
## Test scenarios and setup of test zones
### Default zone configuration
Unless otherwise specified in the specific scenario specification, the test zone
or zones for the scenario will follow the default setup as stated below. The
`child zone` is the zone to be tested for the scenario.
* The child zone is `SCENARIO.connectivity04.xa`.
* It is delegated to out-of-bailiwick NS, specified per scenario.
* The names of the NS exist in the parent zone.
* The NS for a child will only reply to NS query and do that
consistently.
* The parent zone is `connectivity04.xa`.
* It is served by two in-bailiwick NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* All responses will have the [RCODE Name] "NoError".
### GOOD-1
Everything is fine.
* Zone: good-1.connectivity04.xa
* 2 NS.
* Both with IPv4 and IPv6.
* Each NS IP in different prefixes.
### GOOD-2
Everything is fine. IPv4 only.
* Zone: good-2.connectivity04.xa
* 2 NS.
* IPv4 only.
* Each NS IP in different prefixes.
### GOOD-3
Everything is fine. IPv6 only.
* Zone: good-3.connectivity04.xa
* 2 NS.
* IPv4 only.
* Each NS IP in different prefixes.
### EMPTY-PREFIX-SET-1
No ASN data (NXDOMAIN).
* Zone: empty-prefix-set-1.connectivity04.xa
* 1 NS.
* IPv4 and IPv6 on NS.
* The ASN-lookup returns [RCODE Name] NXDOMAIN.
### EMPTY-PREFIX-SET-2
No ASN data (NODATA).
* Zone: empty-prefix-set-2.connectivity04.xa
* 1 NS.
* IPv4 and IPv6 on NS.
* The ASN-lookup returns no TXT record (NODATA).
### ERROR-PREFIX-DATABASE-1
No ASN data due to SERVFAIL.
* Zone: error-prefix-database-1.connectivity04.xa
* 1 NS.
* IPv4 and IPv6 on NS.
* The ASN-lookup returns SERVFAIL.
### ERROR-PREFIX-DATABASE-2
No ASN data due to REFUSED.
* Zone: error-prefix-database-2.connectivity04.xa
* 1 NS.
* IPv4 and IPv6 on NS.
* The ASN-lookup returns REFUSED.
### ERROR-PREFIX-DATABASE-3
No ASN data, no DNS response at all.
* Zone: error-prefix-database-3.connectivity04.xa
* 1 NS.
* IPv4 and IPv6 on NS.
* The ASN-lookup returns no DNS response (no response at all).
### ERROR-PREFIX-DATABASE-4
(Renamed)
### ERROR-PREFIX-DATABASE-5
(Renamed)
### ERROR-PREFIX-DATABASE-6
Extra ASN lookup TXT record with wrong IP prefix.
* Zone: error-prefix-database-6.connectivity04.xa
* 2 NS.
* Both with IPv4 and IPv6.
* Each NS IP in different prefixes.
* For one NS (both IPs) the ASN lookup returns an extra TXT with an IP prefix
that does not match the IP address.
### ERROR-PREFIX-DATABASE-7
ASN lookup TXT record with wrong IP prefix.
* Zone: error-prefix-database-7.connectivity04.xa
* 1 NS.
* IPv4 and IPv6 on NS.
* The ASN-lookup returns one TXT record for both IP with an IP prefix that
does not match the IP address.
### ERROR-PREFIX-DATABASE-8
ASN lookup gives no TXT-record but a CNAME.
* Zone: error-prefix-database-8.connectivity04.xa
* 1 NS.
* IPv4 and IPv6 on NS.
* The ASN-lookup returns no TXT record for both IP but a CNAME record.
### HAS-NON-ASN-TXT-1
IPv4 and IPv6. Extra non-ASN lookup TXT record.
* Zone: has-non-asn-txt-1.connectivity04.xa
* 2 NS.
* Both NS with IPv4 and IPv6.
* Each NS IP in different prefixes.
* For one NS (both IPs) the ASN lookup returns an extra TXT record with the
text "This is not ASN data".
### HAS-NON-ASN-TXT-2
No ASN data, some other TXT record.
* Zone: has-non-asn-txt-2.connectivity04.xa
* 1 NS.
* IPv4 and IPv6 on NS.
* The ASN-lookup returns one TXT record for both IP with the string
"This is not ASN data".
### IPV4-ONE-PREFIX-1
All NS IPs in the same prefix. IPv4 only.
* Zone: ipv4-one-prefix-1.connectivity04.xa
* 2 NS.
* IPv4 only.
* Both NS in the same prefix.
### IPV4-TWO-PREFIXES-1
Two NS in the same prefix. One NS in its own prefix. IPv4 only.
* Zone: ipv4-two-prefixes-1.connectivity04.xa
* 3 NS.
* IPv4 only.
* Two NS in the same prefix.
* One NS in its own prefix.
### IPV6-ONE-PREFIX-1
All NS IPs in the same prefix. IPv6 only.
* Zone: ipv6-one-prefix-1.connectivity04.xa
* 2 NS.
* Ipv6 only.
* Both NS in the same prefix.
### IPV6-TWO-PREFIXES-1
Two NS in the same prefix. One NS in its own prefix. IPv6 only.
* Zone: ipv6-two-prefixes-1.connectivity04.xa
* 3 NS.
* IPv6 only.
* Two NS in the same prefix.
* One NS in its own prefix.
### IPV4-SINGLE-NS-1
One NS, IPv4 only.
* Zone: ipv4-single-ns-1.connectivity04.xa
* 1 NS.
* IPv4 only.
### IPV6-SINGLE-NS-1
One NS, IPv6 only.
* Zone: ipv6-single-ns-1.connectivity04.xa
* 1 NS.
* IPv6 only.
### DOUBLE-PREFIX-1
The IP addresses of the NS are announced from both a larger prefix and a more
specific one.
* Zone: double-prefix-1.connectivity04.xa
* 2 NS
* IPv4 and IPv6.
* The two IPv4 addresses are announced in one large (less specific) prefix that includes
both NS IP addresses.
* Each NS IP address is also announced in a more specific prefix only including
that IP address.
* Same with IPv6.
### DOUBLE-PREFIX-2
The IP addresses of the NS are announced in a larger (less specific) prefix that
includes both NS IP. The addresses of one NS are also announced in more
specific prefixes.
* Zone: double-prefix-2.connectivity04.xa
* 2 NS
* IPv4 and IPv6.
* The two IPv4 addresses are announced in one large (less specific) prefix that
includes both IP addresses.
* The address of one of the NS is also announced in a more specific prefix.
* Same with IPv6.
[Connectivity04]: ../../tests/Connectivity-TP/connectivity04.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test scenario README file]: ../README.md
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones

7
zonemaster/docs/public/specifications/test-zones/Consistency-TP/README.md Normal file
View File

@@ -0,0 +1,7 @@
# Specification of test zones for Consistency-TP
Test zone specifications are available for:
* [CONSISTENCY05](consistency05.md)
* [CONSISTENCY06](consistency06.md)

282
zonemaster/docs/public/specifications/test-zones/Consistency-TP/consistency05.md Normal file
View File

@@ -0,0 +1,282 @@
# Specification of test zones for CONSISTENCY05
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
## Background
See the [test zone README file].
## Test Case
This document specifies defined test zones for test case [CONSISTENCY05].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [CONSISTENCY05] is run on a test zone.
The message tags are defined in the test case ([CONSISTENCY05]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test zone README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`consistency05.xa`) and that subdomain having the same name as the
scenario. The names of those zones are given in section
"[Zone setup for test scenarios]" below.
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:-------------------------|:---------------------------------|:-------------------------------------------
ADDRESSES-MATCH-1 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
ADDRESSES-MATCH-2 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
ADDRESSES-MATCH-3 | ADDRESSES_MATCH, CHILD_NS_FAILED | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, NO_RESPONSE
ADDRESSES-MATCH-4 | ADDRESSES_MATCH, CHILD_NS_FAILED | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, NO_RESPONSE
ADDRESSES-MATCH-5 | ADDRESSES_MATCH, NO_RESPONSE | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED
ADDRESSES-MATCH-6 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
ADDRESSES-MATCH-7 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
ADDR-MATCH-DEL-UNDEL-1 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
ADDR-MATCH-DEL-UNDEL-2 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
ADDR-MATCH-NO-DEL-UNDEL-1 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
ADDR-MATCH-NO-DEL-UNDEL-2 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
CHILD-ZONE-LAME-1 | CHILD_ZONE_LAME, NO_RESPONSE | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_NS_FAILED, ADDRESSES_MATCH
CHILD-ZONE-LAME-2 | CHILD_ZONE_LAME, CHILD_NS_FAILED | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, ADDRESSES_MATCH, NO_RESPONSE
IB-ADDR-MISMATCH-1 | IN_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD | OUT_OF_BAILIWICK_ADDR_MISMATCH, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
IB-ADDR-MISMATCH-2 | IN_BAILIWICK_ADDR_MISMATCH | OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
IB-ADDR-MISMATCH-3 | IN_BAILIWICK_ADDR_MISMATCH, NO_RESPONSE | OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
IB-ADDR-MISMATCH-4 | IN_BAILIWICK_ADDR_MISMATCH | OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
EXTRA-ADDRESS-CHILD | EXTRA_ADDRESS_CHILD | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
OOB-ADDR-MISMATCH | OUT_OF_BAILIWICK_ADDR_MISMATCH | IN_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
## Zone setup for test scenarios
Assumptions for the scenario specifications unless otherwise specified for
the specific scenario:
* For each scenario zone there are two name servers configured.
* Both NS (ns1 and ns2) are equal in delegation and in zone.
* Both NS are in-bailiwick
* Both NS have both IPv4 and IPv6 addresses
* All required glue are present in the delegation.
* All glue exactly matches the authoritative address records in correct
zone (not more and not less records).
* All NS IP addresses respond with identical zone content.
* Responds with a A record for the zone on query for A.
* Responds with a AAAA record for the zone on query for AAAA.
* All responses are authoritative with [RCODE Name] "NoError"
* EDNS, version 0, is included in all responses on queries with EDNS.
* EDNS is not included in responses on queries without EDNS.
* In undelegated data, `IPv4` and `IPv6`, respectively, are placeholders for the
actual IP addresses used for the scenario. They are to be found where the data
is specified.
* If no placeholder is given with the name server name, then no IP address is
given and might be looked up.
* The format for undelegated data follow the format used for `zonemaster-cli`
(after `--ns`).
### ADDRESSES-MATCH-1
The "happy path". Everything is fine.
* Zone: addresses-match-1.consistency05.xa
### ADDRESSES-MATCH-2
Also the "happy path". Out-of-bailiwick NS this time. And no glue.
* Zone: addresses-match-2.consistency05.xa
* Both ns1 and ns2 are out-of-bailiwick under the xb tree.
* ns1 is "ns1.addresses-match-2.consistency05.xb"
* ns2 is "ns2.addresses-match-2.consistency05.xb"
* Delegation is without glue.
* The zone has no address records for the NS names
* The "addresses-match-2.consistency05.xb" zone has a full set of the
address records for ns1 and ns2.
### ADDRESSES-MATCH-3
One NS does not give AA answer, but else fine.
* Zone: addresses-match-3.consistency05.xa
* ns1 responds with AA flag unset.
### ADDRESSES-MATCH-4
One NS does give SERVFAIL response, but else fine.
* Zone: addresses-match-4.consistency05.xa
* ns1 responds with [RCODE Name] "ServFail".
### ADDRESSES-MATCH-5
One NS does not respond, but else fine.
* Zone: addresses-match-5.consistency05.xa
* ns1 gives no response at all.
### ADDRESSES-MATCH-6
Also "happy path". Out-of-bailiwick NS, but with glue.
* Zone: child.addresses-match-6.consistency05.xa
* Both ns1 and ns2 are out-of-bailiwick
* ns1 is "ns1.sibbling.addresses-match-6.consistency05.xa"
* ns2 is "ns2.sibbling.addresses-match-6.consistency05.xa"
* Delegation is with glue.
* The test zone ("child") has no address records for the NS names, but the
"sibbling" zone has full set of address records.
### ADDRESSES-MATCH-7
Also "happy path". NS in subdomain.
* Zone: addresses-match-7.consistency05.xa
* ns1 is "ns1.subdomain.addresses-match-7.consistency05.xa."
* ns2 is "ns2.subdomain.addresses-match-7.consistency05.xa."
* Delegation is with glue.
* "subdomain.addresses-match-7.consistency05.xa" is delegated to the same
ns1 and ns2.
* ns1 and ns2 are defined with address records in the "subdomain" zone.
### ADDR-MATCH-DEL-UNDEL-1
Also the "happy path". But there is an undelegated zone to be tested.
* Zone: addr-match-del-undel-1.consistency05.xa
* Delegated zone on ns1 and ns2.
* Undelegated zone on ns3 and ns4.
* Delegated zone has neither ns1, ns2, ns3 nor ns4 as address records.
* Undelegated zone has neither ns1 nor ns2 as an address record, but it
has both ns3 and ns4 as address records.
* Undelgated data:
* ns3.addr-match-del-undel-1.consistency05.xa/IPv4
* ns3.addr-match-del-undel-1.consistency05.xa/IPv6
* ns4.addr-match-del-undel-1.consistency05.xa/IPv4
* ns4.addr-match-del-undel-1.consistency05.xa/IPv6
### ADDR-MATCH-DEL-UNDEL-2
Also the "happy path". But there is an undelegated zone to be tested, and its
NS are out-of-bailiwick.
* Zone: addr-match-del-undel-2.consistency05.xa
* Delegated zone on ns1 and ns2.
* Undelegated zone on "ns3.addr-match-del-undel-2.consistency05.xb" and
"ns4.addr-match-del-undel-2.consistency05.xb".
* Delegated and undelegated zone, respectively, do not have neither ns1 nor ns2
as an address record.
* Undelegated data:
* ns3.addr-match-del-undel-2.consistency05.xb
* ns4.addr-match-del-undel-2.consistency05.xb
### ADDR-MATCH-NO-DEL-UNDEL-1
Also the "happy path". No delegation but there is an undelegated zone to be
tested.
* Zone: addr-match-no-del-undel-1.consistency05.xa
* No delegated zone.
* Undelegated zone on ns1 and ns2.
* Undelegated data:
* ns1.addr-match-no-del-undel-1.consistency05.xa/IPv4
* ns1.addr-match-no-del-undel-1.consistency05.xa/IPv6
* ns2.addr-match-no-del-undel-1.consistency05.xa/IPv4
* ns2.addr-match-no-del-undel-1.consistency05.xa/IPv6
### ADDR-MATCH-NO-DEL-UNDEL-2
Also the "happy path". No delegation but there is an undelegated zone to be
tested. NS are out-of-bailiwick.
* Zone: addr-match-no-del-undel-2.consistency05.xa
* No delegated zone.
* Undelegated zone on "ns3.addr-match-no-del-undel-2.consistency05.xb" and
"ns4.addr-match-no-del-undel-2.consistency05.xb".
* Undelegated data:
* ns3.addr-match-no-del-undel-2.consistency05.xb
* ns4.addr-match-no-del-undel-2.consistency05.xb
### CHILD-ZONE-LAME-1
Lame. No NS responds.
* Zone: child-zone-lame-1.consistency05.xa
* ns1 and ns2 do not respond.
### CHILD-ZONE-LAME-2
Lame. One NS non-AA and one NS SERVFAIL.
* Zone: child-zone-lame-2.consistency05.xa
* ns1 responses with AA bit unset.
* ns2 responds with [RCODE Name] "ServFail".
### IB-ADDR-MISMATCH-1
For one NS (in-bailiwick), the addresses in the glue do not match those in the
authoritative data from the zone.
* Zone: ib-addr-mismatch-1.consistency05.xa
* ns2 is defined in the zone, but with different addresses (IPv4 and IPv6),
i.e. not the same as in glue.
* Both ns2 servers (IP address sets from glue and child, respectively) must
give identical DNS responses.
### IB-ADDR-MISMATCH-2
For one NS (in-bailiwick), address records exist in the glue, but not in the
authoritative data for the zone.
* Zone: ib-addr-mismatch-2.consistency05.xa
* ns2 is not defined in the zone, i.e. there are no address records for ns2
(IPv4 or IPv6) in the zone.
### IB-ADDR-MISMATCH-3
For ns2 (in-bailiwick), there is no NS for ns2 and the glue does not match any
address records in the zone. Furthermore, ns2 does not respond.
* Zone: ib-addr-mismatch-3.consistency05.xa
* There is no NS record with ns2 in RDATA.
* ns2 is not defined in the zone, i.e. there are no address records for ns2
(IPv4 or IPv6) in the zone.
* ns2 does not respond (but it is in the delegation)
### IB-ADDR-MISMATCH-4
Both NS are in-bailiwick and exist with correct glue in the delegation, but there
are no address records in the zone matching the glue records.
* Zone: ib-addr-mismatch-4.consistency05.xa
* Neither ns1 nor ns2 are defined in the zone as address records.
* The correct NS records are in the zone.
### EXTRA-ADDRESS-CHILD
Child zone has one extra address record on the NS name.
* Zone: extra-address-child.consistency05.xa
* The zone has address records for ns2 that match glue, but in addition
the zone has extra A and AAAA records for ns2.
* Both ns2 servers (both sets of IP addresses from child) must give identical
DNS responses.
### OOB-ADDR-MISMATCH
For one NS (out-of-bailiwick, but with glue) glue does not match AA address
response.
* Zone: child.oob-addr-mismatch.consistency05.xa
* Both ns1 and ns2 are out-of-bailiwick
* ns1 is "ns1.sibbling.oob-addr-mismatch.consistency05.xa"
* ns2 is "ns2.sibbling.oob-addr-mismatch.consistency05.xa"
* Delegation is with glue.
* The test zone ("child") has no address records for the NS names.
* The "sibling" zone has full set of address records
* ns1 in the "sibling" zone matches the addresses of glue.
* ns2 in the "sibling" zone does not match the addresses of glue.
* All IP addresses of ns1 and ns2 must serve identical versions of the zone.
[CONSISTENCY05]: ../../tests/Consistency-TP/consistency05.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../README.md
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

162
zonemaster/docs/public/specifications/test-zones/Consistency-TP/consistency06.md Normal file
View File

@@ -0,0 +1,162 @@
# Specification of test zones for CONSISTENCY06
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
## Background
See the [test zone README file].
## Test Case
This document specifies defined test zones for test case [CONSISTENCY06].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [CONSISTENCY06] is run on a test zone.
The message tags are defined in the test case ([CONSISTENCY06]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test zone README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`consistency06.xa`) and that subdomain having the same name as the
scenario. The names of those zones are given in section
"[Zone setup for test scenarios]" below.
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:------------------------------|:-------------------------------------|:-------------------------------------------
ONE-SOA-MNAME-1 | ONE_SOA_MNAME | NO_RESPONSE, NO_RESPONSE_SOA_QUERY, MULTIPLE_SOA_MNAMES
ONE-SOA-MNAME-2 | ONE_SOA_MNAME, NO_RESPONSE | NO_RESPONSE_SOA_QUERY, MULTIPLE_SOA_MNAMES
ONE-SOA-MNAME-3 | ONE_SOA_MNAME, NO_RESPONSE_SOA_QUERY | NO_RESPONSE, MULTIPLE_SOA_MNAMES
ONE-SOA-MNAME-4 | ONE_SOA_MNAME, NO_RESPONSE | NO_RESPONSE_SOA_QUERY, MULTIPLE_SOA_MNAMES
MULTIPLE-SOA-MNAMES-1 | MULTIPLE_SOA_MNAMES | NO_RESPONSE, NO_RESPONSE_SOA_QUERY, ONE_SOA_MNAME
MULTIPLE-SOA-MNAMES-2 | MULTIPLE_SOA_MNAMES,NO_RESPONSE | NO_RESPONSE_SOA_QUERY, ONE_SOA_MNAME
MULT-SOA-MNAMES-NO-DEL-UNDEL-1 | MULTIPLE_SOA_MNAMES | NO_RESPONSE, NO_RESPONSE_SOA_QUERY, ONE_SOA_MNAME
MULT-SOA-MNAMES-NO-DEL-UNDEL-2 | MULTIPLE_SOA_MNAMES | NO_RESPONSE, NO_RESPONSE_SOA_QUERY, ONE_SOA_MNAME
NO-RESPONSE | NO_RESPONSE | NO_RESPONSE_SOA_QUERY, MULTIPLE_SOA_MNAMES, ONE_SOA_MNAME
## Zone setup for test scenarios
Assumptions for the scenario specifications unless otherwise specified for
the specific scenario:
* For each scenario zone there are two name servers configured.
* Both NS (ns1 and ns2) are equal in delegation and in zone.
* Both NS are in-bailiwick
* Both NS have both IPv4 and IPv6 addresses
* All required glue are present in the delegation.
* All NS IP addresses respond with identical zone content.
* All queries for SOA are responded with a SOA record in an
authoritative answer.
* ns1 and ns2 respond with identical SOA records.
* All responses, to zone content, are authoritative with
[RCODE Name] "NoError"
* EDNS, version 0, is included in all responses on queries with EDNS.
* EDNS is not included in responses on queries without EDNS.
* In undelegated data, `IPv4` and `IPv6`, respectively, are placeholders for the
actual IP addresses used for the scenario. They are to be found where the data
is specified.
* If no placeholder is given with the name server name, then no IP address is
given and might be looked up.
* The format for undelegated data follow the format used for `zonemaster-cli`
(after `--ns`).
### ONE-SOA-MNAME-1
The "happy path". Everything is fine.
* Zone: one-soa-mname-1.consistency06.xa.
### ONE-SOA-MNAME-2
Not so "happy path". One name server does not respond.
* Zone: one-soa-mname-2.consistency06.xa.
* ns1 gives no response at all.
### ONE-SOA-MNAME-3
Not so "happy path". One name server responds without SOA
* Zone: one-soa-mname-3.consistency06.xa.
* ns1 responds, but with no SOA record in the answer section
(maybe answering but not having the zone).
### ONE-SOA-MNAME-4
Not so "happy path". One name server does not respond. That ns is also missing in
the zone.
* Zone: one-soa-mname-4.consistency06.xa.
* ns2 gives no response at all.
* ns2 is missing in the zone (but available in the delegation)
### MULTIPLE-SOA-MNAMES-1
Different SOA MNAME on the servers
* Zone: multiple-soa-mnames-1.consistency06.xa.
* MNAME in SOA on ns1 equal to ns1
* MNAME in SOA on ns2 equal to ns2
### MULTIPLE-SOA-MNAMES-2
Different SOA MNAME on two servers and a third not responding server
* Zone: multiple-soa-mnames-2.consistency06.xa.
* MNAME in SOA on ns1 equal to ns1
* MNAME in SOA on ns2 equal to ns2
* Also delegated to ns3, for which there is no response.
### MULT-SOA-MNAMES-NO-DEL-UNDEL-1
Zone not delegated, but there is an undelegated version. Different SOA MNAME on
the servers.
* Zone: mult-soa-mnames-no-del-undel-1.consistency06.xa.
* MNAME in SOA on ns1 equal to ns1
* MNAME in SOA on ns2 equal to ns2
* Undelegated data:
* ns1.mult-soa-mnames-no-del-undel-1.consistency06.xa/IPv4
* ns1.mult-soa-mnames-no-del-undel-1.consistency06.xa/IPv6
* ns2.mult-soa-mnames-no-del-undel-1.consistency06.xa/IPv4
* ns2.mult-soa-mnames-no-del-undel-1.consistency06.xa/IPv6
### MULT-SOA-MNAMES-NO-DEL-UNDEL-2
Zone not delegated, but there is an undelegated version. Different SOA MNAME on
the servers. NS are out-of-bailiwick.
* Zone: mult-soa-mnames-no-del-undel-2.consistency06.xa.
* NS are out-of-bailiwick, "ns3.mult-soa-mnames-no-del-undel-2.consistency06.xb"
and "ns4.mult-soa-mnames-no-del-undel-2.consistency06.xb".
* MNAME in SOA on ns3 equal to ns3
* MNAME in SOA on ns4 equal to ns4
* Undelegated data:
* ns3.mult-soa-mnames-no-del-undel-2.consistency06.xb
* ns4.mult-soa-mnames-no-del-undel-2.consistency06.xb
### NO-RESPONSE
No name server responds.
* Zone: no-response.consistency06.xa.
* ns1 gives no response at all.
* ns2 gives no response at all.
[CONSISTENCY06]: ../../tests/Consistency-TP/consistency06.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../README.md
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

11
zonemaster/docs/public/specifications/test-zones/DNSSEC-TP/README.md Normal file
View File

@@ -0,0 +1,11 @@
# Specification of test scenarios for DNSSEC-TP
Test scenario specifications are available for:
* [DNSSEC01](dnssec01.md)
* [DNSSEC03](dnssec03.md)
* [DNSSEC05](dnssec05.md)
* [DNSSEC07](dnssec07.md)
* [DNSSEC10](dnssec10.md)
* [DNSSEC16](dnssec16.md)

311
zonemaster/docs/public/specifications/test-zones/DNSSEC-TP/dnssec01.md Normal file
View File

@@ -0,0 +1,311 @@
# Specification of Test Scenarios for DNSSEC01
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test scenarios and setup of test zones]
## Background
See the [test scenario README file].
## Test Case
This document specifies defined test scenarios for test case [DNSSEC01].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [DNSSEC01] is run on a test zone. The
message tags are defined in the test case ([DNSSEC01]) and the scenarios are
defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone or zones for each test scenario in this document is a subdomain
(or lower zone) delegated from the base name (`dnssec01.xa`) and that subdomain
having the same name as the scenario. The names of those zones are given in
section "[Test scenarios and setup of test zones]" below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [DNSSEC01] for the specification of the tags.
* DS01_DS_ALGO_2_MISSING
* DS01_DS_ALGO_DEPRECATED
* DS01_DS_ALGO_NOT_DS
* DS01_DS_ALGO_OK
* DS01_DS_ALGO_PRIVATE
* DS01_DS_ALGO_RESERVED
* DS01_DS_ALGO_UNASSIGNED
* DS01_NO_RESPONSE
* DS01_PARENT_SERVER_NO_DS
* DS01_PARENT_ZONE_NO_DS
* DS01_ROOT_N_NO_UNDEL_DS
* DS01_UNDEL_N_NO_UNDEL_DS
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
| Scenario name | Mandatory tags | Forbidden tags |
|:----------------------|:---------------------------------------------------------------|:---------------|
| ALGO-DEPRECATED-1 | DS01_DS_ALGO_DEPRECATED, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-DEPRECATED-3 | DS01_DS_ALGO_DEPRECATED, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-NOT-DS-0 | DS01_DS_ALGO_NOT_DS, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-OK-2 | DS01_DS_ALGO_OK | 2) |
| ALGO-OK-4 | DS01_DS_ALGO_OK, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-OK-5 | DS01_DS_ALGO_OK, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-OK-6 | DS01_DS_ALGO_OK, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-PRIVATE-253 | DS01_DS_ALGO_PRIVATE, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-PRIVATE-254 | DS01_DS_ALGO_PRIVATE, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-RESERVED-128 | DS01_DS_ALGO_RESERVED, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-RESERVED-188 | DS01_DS_ALGO_RESERVED, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-RESERVED-252 | DS01_DS_ALGO_RESERVED, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-UNASSIGNED-7 | DS01_DS_ALGO_UNASSIGNED, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-UNASSIGNED-67 | DS01_DS_ALGO_UNASSIGNED, DS01_DS_ALGO_2_MISSING | 2) |
| ALGO-UNASSIGNED-127 | DS01_DS_ALGO_UNASSIGNED, DS01_DS_ALGO_2_MISSING | 2) |
| MIXED-ALGO-1 | DS01_DS_ALGO_DEPRECATED, DS01_DS_ALGO_PRIVATE, DS01_DS_ALGO_OK | 2) |
| SHARED-IP-1 | DS01_DS_ALGO_OK | 2) |
| SHARED-IP-2 | DS01_DS_ALGO_OK | 2) |
| NO-RESPONSE-1 | DS01_NO_RESPONSE | 2) |
| NO-VALID-RESPONSE-1 | DS01_NO_RESPONSE | 2) |
| PARENT-SERVER-NO-DS-1 | DS01_PARENT_SERVER_NO_DS, DS01_DS_ALGO_OK | 2) |
| PARENT-ZONE-NO-DS-1 | DS01_PARENT_ZONE_NO_DS | 2) |
| UNDEL-NO-UNDEL-DS-1 | DS01_UNDEL_N_NO_UNDEL_DS | 2) |
| UNDEL-WITH-UNDEL-DS-1 | DS01_DS_ALGO_OK | 2) |
| ROOT-NO-UNDEL-DS-1 | DS01_ROOT_N_NO_UNDEL_DS | 2) |
| ROOT-WITH-UNDEL-DS-1 | DS01_DS_ALGO_OK | 2) |
* (1) All tags except for those specified as "Forbidden tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory tags"
## Test scenarios and setup of test zones
### Default zone configuration
Unless otherwise specified in the specific scenario specification, the test zone
or zones for the scenario will follow the default setup as stated below. The
`child zone` is the zone to be tested for the scenario.
* The child zone is `SCENARIO.dnssec01.xa`.
* It is delegated to two name servers, `ns1.SCENARIO.dnssec01.xa`
and `ns2.SCENARIO.dnssec01.xa`.
* The name server names have A and AAAA records to avoid non-relevant error
messages.
* The delegation of the child zone is to an OOB NS.
* NS can be resolved through the `dnssec01.xa` zone.
* There is a zone file for the child zone.
* All child zone servers give the same response.
* The only responses that can be assumed are queries for
* NS
* SOA
* The parent zone will respond with one DS record per child zone.
* The parent zone is `dnssec01.xa`.
* It is served by two in-bailiwick NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* All responses will have the AA bit set.
* All responses will have the [RCODE Name] "NoError".
* The DS digest algorithm is 2 unless specified for the scenario.
* The DS record can be technically invalid. Only the format is valid and
only the digest algorithm value is checked.
* The zone is not signed.
### ALGO-DEPRECATED-1
The DS digest algorithm number is 1
* Zone: algo-deprecated-1.dnssec01.xa.
* The algorithm of the DS digest in the response is 1.
### ALGO-DEPRECATED-3
The DS digest algorithm number is 3
* Zone: algo-deprecated-3.dnssec01.xa.
* The algorithm of the DS digest in the response is 3.
### ALGO-RESERVED-128
The DS digest algorithm number is 128
* Zone: algo-reserved-128.dnssec01.xa.
* The algorithm of the DS digest in the response is 128.
### ALGO-RESERVED-188
The DS digest algorithm number is 188
* Zone: algo-reserved-188.dnssec01.xa.
* The algorithm of the DS digest in the response is 188.
### ALGO-RESERVED-252
The DS digest algorithm number is 252
* Zone: algo-reserved-252.dnssec01.xa.
* The algorithm of the DS digest in the response is 252.
### ALGO-UNASSIGNED-7
The DS digest algorithm number is 7
* Zone: algo-unassigned-7.dnssec01.xa.
* The algorithm of the DS digest in the response is 7.
### ALGO-UNASSIGNED-67
The DS digest algorithm number is 67
* Zone: algo-unassigned-67.dnssec01.xa.
* The algorithm of the DS digest in the response is 67.
### ALGO-UNASSIGNED-127
The DS digest algorithm number is 127
* Zone: algo-unassigned-127.dnssec01.xa.
* The algorithm of the DS digest in the response is 127.
### ALGO-PRIVATE-253
The DS digest algorithm number is 253
* Zone: algo-private-253.dnssec01.xa.
* The algorithm of the DS digest in the response is 253.
### ALGO-PRIVATE-254
The DS digest algorithm number is 254
* Zone: algo-private-254.dnssec01.xa.
* The algorithm of the DS digest in the response is 254.
### ALGO-NOT-DS-0
The DS digest algorithm number is 0
* Zone: algo-not-ds-0.dnssec01.xa.
* The algorithm of the DS digest in the response is 0.
### ALGO-OK-2
The DS digest algorithm number is 2
* Zone: algo-ok-2.dnssec01.xa.
* The algorithm of the DS digest in the response is 2.
### ALGO-OK-4
The DS digest algorithm number is 4
* Zone: algo-ok-4.dnssec01.xa.
* The algorithm of the DS digest in the response is 4.
### ALGO-OK-5
The DS digest algorithm number is 5
* Zone: algo-ok-5.dnssec01.xa.
* The algorithm of the DS digest in the response is 5.
### ALGO-OK-6
The DS digest algorithm number is 6
* Zone: algo-ok-6.dnssec01.xa.
* The algorithm of the DS digest in the response is 6.
### MIXED-ALGO-1
Three DS with different algorithms.
* Zone: mixed-algo-1.dnssec01.xa.
* The response has three DS with different algorithms:
* 1
* 2
* 253
### SHARED-IP-1
Two parent name servers resolv to the same IP address.
* Zone: child.shared-ip-1.dnssec01.xa.
* The parent zone is "shared-ip-1.dnssec01.xa" and the grandparent zone is
"dnssec01.xa".
* The parent is delegated to IB ns1a and ns1b with the same IPv4 and IPv6
addresses.
### SHARED-IP-2
Delegation of parent does not use the same name server name as parent zone.
* Zone: child.shared-ip-2.dnssec01.xa.
* The parent zone is "shared-ip-2.dnssec01.xa" and the grandparent zone is
"dnssec01.xa".
* The parent is delegated to IB ns1 and ns2, but in the parent zone the names
are dns1 and dns2.
* ns1 and dns1 resolve to the same IP addresses.
* ns2 and dns2 resolve to the same IP addresses.
### NO-RESPONSE-1
No response from any of the servers on the DS query.
* Zone: child.no-response-1.dnssec01.xa.
* No response at all from parent ns1 and ns2.
### NO-VALID-RESPONSE-1
No valid response from any of the servers on the DS query.
* Zone: child.no-valid-response-1.dnssec01.xa.
* Response from parent ns1 has RCODE SERVFAIL.
* Response from parent ns2 has RCODE REFUSED.
* Child zone does not exist
### PARENT-SERVER-NO-DS-1
No DS from parent ns1.
* Zone: child.parent-server-no-ds-1.dnssec01.xa.
* Response from parent ns1 is NODATA (no DS).
* Response from parent ns2 is normal.
### PARENT-ZONE-NO-DS-1
No DS from neither parent ns1 nor parent ns2.
* Zone: parent-zone-no-ds-1.dnssec01.xa.
* Responses from parent ns1 and parent ns2 are NODATA (no DS).
### UNDEL-NO-UNDEL-DS-1
Zone is not delegated, but undelegated data is provided. No DS.
* Zone: undel-no-undel-ds-1.dnssec01.xa.
* The zone is not delegated, but there is undelegated data.
* ns1 and ns2 are OOB.
* No undelegated DS is provided.
### UNDEL-WITH-UNDEL-DS-1
Zone is not delegated, but undelegated data is provided with DS.
* Zone: undel-with-undel-ds-1.dnssec01.xa.
* The zone is not delegated, but there is undelegated data.
* ns1 and ns2 are OOB.
* Undelegated DS is provided.
### ROOT-NO-UNDEL-DS-1
Zone is the root zone, and no undelegated DS is provided.
* Zone: "."
* ns1 and ns2 are IB.
* The zone exists.
### ROOT-WITH-UNDEL-DS-1
Zone is the root zone, and undelegated DS is provided.
* Zone: "."
* ns1 and ns2 are IB.
* The zone exists.
[DNSSEC01]: ../../tests/DNSSEC-TP/dnssec01.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test scenario README file]: ../README.md
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones

197
zonemaster/docs/public/specifications/test-zones/DNSSEC-TP/dnssec03.md Normal file
View File

@@ -0,0 +1,197 @@
# Specification of test zones for DNSSEC03
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
* [Terminology](#terminology)
## Background
See the [test zone README file].
## Test Case
This document specifies defined test zones for test case [DNSSEC03].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [DNSSEC03] is run on a test zone. The
message tags are defined in the test case ([DNSSEC03]) and the scenarios are
defined below.
The test scenarios are structured as stated in the [test zone README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`dnssec03.xa`) and that subdomain having the same name as the
scenario except where the test domain must be the root zone, a TLD or a domain
under `.arpa`. The names of those zones are given in section
"[Zone setup for test scenarios]" below.
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tags | Forbidden message tags
:----------------------------|:--------------------------------------------------|:-------------------------------------------
NO-DNSSEC-SUPPORT | DS03_NO_DNSSEC_SUPPORT | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
NO-NSEC3 | DS03_NO_NSEC3 | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NO_DNSSEC_SUPPORT, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
GOOD-VALUES | DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
ERR-MULT-NSEC3 | DS03_ERR_MULT_NSEC3, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
BAD-VALUES | DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD | DS03_ERR_MULT_NSEC3, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
INCONSISTENT-VALUES | DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD | DS03_ERR_MULT_NSEC3, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
NSEC3-OPT-OUT-ENABLED-TLD | DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
SERVER-NO-DNSSEC-SUPPORT | DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
SERVER-NO-NSEC3 | DS03_SERVER_NO_NSEC3, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
UNASSIGNED-FLAG-USED | DS03_UNASSIGNED_FLAG_USED, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
ERROR-RESPONSE-NSEC-QUERY | DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED, DS03_ERROR_RESPONSE_NSEC_QUERY | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_NO_RESPONSE_NSEC_QUERY
NO-RESPONSE-NSEC-QUERY | DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NO_RESPONSE_NSEC_QUERY | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY
ERROR-NSEC-QUERY | DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED
## Zone setup for test scenarios
Assumptions for the scenario specifications, unless stated otherwise for the
specific scenario:
1. Each zone is hosted by two NS, ns1 and ns2.
2. Both ns have equal hosting.
3. NS in delegation is equal to NS in zone.
4. All responses are authoritative.
5. RRSIG in responses are disregarded.
6. The actual owner name of the NSEC3 record will not be verified.
7. The record type list of the NSEC3 record will not be verified.
8. The zone is to respond with one SOA record with the zone name as owner name
on SOA query.
9. The zone is to respond with one DNSKEY record with the zone name as owner
name on DNSKEY query.
10. The zone is to respond with one NSEC3 record with a hash owner name in
authority section on NSEC query (note, NSEC not NSEC3). NODATA response.
11. The NSEC3 record is to have the following settings:
* Hash algo = 1
* Flags = 0
* Iteration = 0
* Salt = "-" (no salt)
### NO-DNSSEC-SUPPORT
No DNSSEC support in the zone.
* Zone: "no-dnssec-support.dnssec03.xa."
* No DNSKEY in query for DNSKEY (9).
### NO-NSEC3
No NSEC3 support in the zone.
* Zone: "no-nsec3.dnssec03.xa."
* No NSEC3 in query for NSEC (10).
### GOOD-VALUES
Happy path
* Zone: "good-values.dnssec03.xa."
### ERR-MULT-NSEC3
Strange response with two NSEC3 records.
* Zone: "err-mult-nsec3.dnssec03.xa."
* Two NSEC3 records, with different hash owner name are to be included in the
response. RDATA can be identical. (10)
### BAD-VALUES
The NSEC3 record has values no permitted by RFC 9276, see the specification of
test case [DNSSEC03].
* Zone: "bad-values.dnssec03.xa."
* The following values in NSEC3 (11):
* Hash algo = 2
* Flags = 1
* Iteration = 1
* Salt = "8104"
### INCONSISTENT-VALUES
The NSEC3 records returned from the two NS are not equal.
* Zone: "inconsistent-values.dnssec03.xa."
* Both NS give the same owner name of the NSEC3 record, but
ns1 gives standard values, whereas ns2 responds with an NSEC3 record with
the following values: (2, 11)
* Hash algo = 2
* Flags = 1
* Iteration = 1
* Salt = "8104"
### NSEC3-OPT-OUT-ENABLED-TLD
On a TLD, opt-out just gives an INFO message.
* Zone: "nsec3-opt-out-enabled-tld-dnssec03." (TLD)
* NSEC3 record with the following value: (11)
* Flags = 1
### SERVER-NO-DNSSEC-SUPPORT
One NS of two does not support DNSSEC (no DNSKEY)
* Zone: "server-no-dnssec-support.dnssec03.xa"
* ns2 does not return any DNSKEY record on DNSKEY query (2, 9)
### SERVER-NO-NSEC3
One NS of two does not have NSEC3
* Zone: "server-no-nsec3.dnssec03.xa"
* ns2 does not return any NSEC3 record on NSEC query (2, 10)
### UNASSIGNED-FLAG-USED
Unassigned flag used.
* Zone: "unassigned-flag-used.dnssec03.xa"
* NSEC3 record with the following value: (11)
* Flags = 2
### ERROR-RESPONSE-NSEC-QUERY
Error in response from one NS on NSEC query.
* Zone: "error-response-nsec-query.dnssec03.xa"
* Normal response on DNSKEY query from ns1.
* RCODE name SERVFAIL on NSEC query from ns1.
* Normal responses from ns2.
### NO-RESPONSE-NSEC-QUERY
No response from one NS on NSEC query.
* Zone: "no-response-nsec-query.dnssec03.xa"
* Normal responses from ns1.
* Normal response on DNSKEY query from ns2.
* No response on NSEC query from ns2.
### ERROR-NSEC-QUERY
No response and error in response on NSEC query, respectively, from two NS.
* Zone: "error-nsec-query.dnssec03.xa"
* Normal response on DNSKEY query from ns1 and ns2.
* RCODE name SERVFAIL on NSEC query from ns1.
* No response on NSEC query from ns2.
[DNSSEC03]: ../../tests/DNSSEC-TP/dnssec03.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../README.md
[Well Formed CDS Record]: #terminology
[Well Formed DNSKEY Record]: #terminology
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

350
zonemaster/docs/public/specifications/test-zones/DNSSEC-TP/dnssec05.md Normal file
View File

@@ -0,0 +1,350 @@
# Specification of Test Scenarios for DNSSEC05
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test scenarios and setup of test zones]
## Background
See the [test scenario README file].
## Test Case
This document specifies defined test scenarios for test case [DNSSEC05].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [DNSSEC05] is run on a test zone. The
message tags are defined in the test case ([DNSSEC05]) and the scenarios are
defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone or zones for each test scenario in this document is a subdomain
(or lower zone) delegated from the base name (`dnssec05.xa`) and that subdomain
having the same name as the scenario. The names of those zones are given in
section "[Test scenarios and setup of test zones]" below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [DNSSEC05] for the specification of the tags.
* DS05_ALGO_DEPRECATED
* DS05_ALGO_NOT_RECOMMENDED
* DS05_ALGO_NOT_ZONE_SIGN
* DS05_ALGO_OK
* DS05_ALGO_PRIVATE
* DS05_ALGO_RESERVED
* DS05_ALGO_UNASSIGNED
* DS05_NO_RESPONSE
* DS05_SERVER_NO_DNSSEC
* DS05_ZONE_NO_DNSSEC
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
| Scenario name | Mandatory message tags | Forbidden message tags |
|:------------------------|:--------------------------------------------------------------|:-----------------------|
| ALGO-DEPRECATED-1 | DS05_ALGO_DEPRECATED | 2) |
| ALGO-DEPRECATED-3 | DS05_ALGO_DEPRECATED | 2) |
| ALGO-DEPRECATED-5 | DS05_ALGO_DEPRECATED | 2) |
| ALGO-DEPRECATED-6 | DS05_ALGO_DEPRECATED | 2) |
| ALGO-DEPRECATED-7 | DS05_ALGO_DEPRECATED | 2) |
| ALGO-DEPRECATED-12 | DS05_ALGO_DEPRECATED | 2) |
| ALGO-NOT-RECOMMENDED-10 | DS05_ALGO_NOT_RECOMMENDED | 2) |
| ALGO-NOT-ZONE-SIGN-0 | DS05_ALGO_NOT_ZONE_SIGN | 2) |
| ALGO-NOT-ZONE-SIGN-2 | DS05_ALGO_NOT_ZONE_SIGN | 2) |
| ALGO-NOT-ZONE-SIGN-252 | DS05_ALGO_NOT_ZONE_SIGN | 2) |
| ALGO-OK-8 | DS05_ALGO_OK | 2) |
| ALGO-OK-13 | DS05_ALGO_OK | 2) |
| ALGO-OK-14 | DS05_ALGO_OK | 2) |
| ALGO-OK-15 | DS05_ALGO_OK | 2) |
| ALGO-OK-16 | DS05_ALGO_OK | 2) |
| ALGO-OK-17 | DS05_ALGO_OK | 2) |
| ALGO-OK-23 | DS05_ALGO_OK | 2) |
| ALGO-PRIVATE-253 | DS05_ALGO_PRIVATE | 2) |
| ALGO-PRIVATE-254 | DS05_ALGO_PRIVATE | 2) |
| ALGO-RESERVED-4 | DS05_ALGO_RESERVED | 2) |
| ALGO-RESERVED-9 | DS05_ALGO_RESERVED | 2) |
| ALGO-RESERVED-11 | DS05_ALGO_RESERVED | 2) |
| ALGO-RESERVED-123 | DS05_ALGO_RESERVED | 2) |
| ALGO-RESERVED-251 | DS05_ALGO_RESERVED | 2) |
| ALGO-RESERVED-255 | DS05_ALGO_RESERVED | 2) |
| ALGO-UNASSIGNED-20 | DS05_ALGO_UNASSIGNED | 2) |
| ALGO-UNASSIGNED-122 | DS05_ALGO_UNASSIGNED | 2) |
| MIXED-ALGO-1 | DS05_ALGO_DEPRECATED, DS05_ALGO_NOT_RECOMMENDED, DS05_ALGO_OK | 2) |
| NO-RESPONSE-1 | DS05_NO_RESPONSE | 2) |
| NO-RESPONSE-2 | DS05_NO_RESPONSE | 2) |
| SERVER-NO-DNSSEC-1 | DS05_SERVER_NO_DNSSEC, DS05_ALGO_OK | 2) |
| SHARED-IP-1 | DS05_ALGO_OK | 2) |
| ZONE-NO-DNSSEC-1 | DS05_ZONE_NO_DNSSEC | 2) |
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory message tags"
## Test scenarios and setup of test zones
### Default zone configuration
Unless otherwise specified in the specific scenario specification, the test zone
or zones for the scenario will follow the default setup as stated below. The
`child zone` is the zone to be tested for the scenario.
* The child zone is `SCENARIO.dnssec05.xa`.
* It is delegated to two name servers, `ns1.SCENARIO.dnssec05.xa`
and `ns2.SCENARIO.dnssec05.xa`.
* The name server names have A and AAAA records to avoid non-relevant error
messages.
* The delegation of the child zone is to an OOB NS.
* NS can be resolved through the `dnssec05.xa` zone.
* There is a zone file for the child zone.
* All child zone servers give the same response.
* The only responses that can be assumed are queries for
* DNSKEY
* NS
* SOA
* The zone will respond with one DNSKEY record.
* The parent zone is `dnssec05.xa`.
* It is served by two in-bailiwick NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* All responses will have the AA bit set.
* All responses will have the [RCODE Name] "NoError".
* The DNSKEY algorithm is 13 unless specified for the scenario.
* The DNSKEY record can be technically invalid. Only the format is valid and
only the algorithm value is checked.
* The zone is not signed.
### ALGO-DEPRECATED-1
The DNSKEY algo is 1
* Zone: "algo-deprecated-1.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 1.
### ALGO-DEPRECATED-3
The DNSKEY algo is 3
* Zone: "algo-deprecated-3.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 3.
### ALGO-DEPRECATED-5
The DNSKEY algo is 5
* Zone: "algo-deprecated-5.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 5.
### ALGO-DEPRECATED-6
The DNSKEY algo is 6
* Zone: "algo-deprecated-6.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 6.
### ALGO-DEPRECATED-7
The DNSKEY algo is 7
* Zone: "algo-deprecated-7.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 7.
### ALGO-DEPRECATED-12
The DNSKEY algo is 12
* Zone: "algo-deprecated-12.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 12.
### ALGO-RESERVED-4
The DNSKEY algo is 4
* Zone: "algo-reserved-4.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 4.
### ALGO-RESERVED-9
The DNSKEY algo is 9
* Zone: "algo-reserved-9.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 9.
### ALGO-RESERVED-11
The DNSKEY algo is 11
* Zone: "algo-reserved-11.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 11.
### ALGO-RESERVED-123
The DNSKEY algo is 123
* Zone: "algo-reserved-123.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 123.
### ALGO-RESERVED-251
The DNSKEY algo is 251
* Zone: "algo-reserved-251.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 251.
### ALGO-RESERVED-255
The DNSKEY algo is 255
* Zone: "algo-reserved-255.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 255.
### ALGO-UNASSIGNED-20
The DNSKEY algo is 20
* Zone: "algo-unassigned-17.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 17.
### ALGO-UNASSIGNED-122
The DNSKEY algo is 122
* Zone: "algo-unassigned-122.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 122.
### ALGO-PRIVATE-253
The DNSKEY algo is 253
* Zone: "algo-private-253.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 253.
### ALGO-PRIVATE-254
The DNSKEY algo is 254
* Zone: "algo-private-254.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 254.
### ALGO-NOT-ZONE-SIGN-0
The DNSKEY algo is 0
* Zone: "algo-not-zone-sign-0.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 0.
### ALGO-NOT-ZONE-SIGN-2
The DNSKEY algo is 2
* Zone: "algo-not-zone-sign-2.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 2.
### ALGO-NOT-ZONE-SIGN-252
The DNSKEY algo is 252
* Zone: "algo-not-zone-sign-252.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 252.
### ALGO-NOT-RECOMMENDED-10
The DNSKEY algo is 10
* Zone: "algo-not-recommended-10.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 10.
### ALGO-OK-8
The DNSKEY algo is 8
* Zone: "algo-ok-8.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 8.
### ALGO-OK-13
The DNSKEY algo is 13
* Zone: "algo-ok-13.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 13.
### ALGO-OK-14
The DNSKEY algo is 14
* Zone: "algo-ok-14.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 14.
### ALGO-OK-15
The DNSKEY algo is 15
* Zone: "algo-ok-15.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 15.
### ALGO-OK-16
The DNSKEY algo is 16
* Zone: "algo-ok-16.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 16.
### ALGO-OK-17
The DNSKEY algo is 17
* Zone: "algorithm-ok-17.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 17.
### ALGO-OK-23
The DNSKEY algo is 23
* Zone: "algorithm-ok-23.dnssec05.xa."
* The algorithm of the DNSKEY in the response is 23.
## MIXED-ALGO-1
Three DNSKEY with different algorithms.
* Zone: "mixed-algo-1.dnssec05.xa."
* The response has three DNSKEY with different algorithms:
* 7
* 10
* 13
### NO-RESPONSE-1
No valid response from any of the servers.
* Zone: "no-response-1.dnssec05.xa."
* No response at all from ns1.
* Response from ns2 does not have the AA bit set.
### NO-RESPONSE-2
No valid response from any of the servers.
* Zone: "no-response-2.dnssec05.xa."
* Response from ns1 has RCODE SERVFAIL.
* Response from ns2 has RCODE REFUSED.
### SERVER-NO-DNSSEC-1
No DNSKEY from ns1.
* Zone: "server-no-dnssec-1.dnssec05.xa."
* Response from ns1 is NODATA (no DNSKEY).
* Response from ns2 is normal.
### SHARED-IP-1
Two NS names, but only one IP. IPv4 only.
* Zone: "shared-ip-1.dnssec05.xa."
* ns1a and ns1b are in bailiwick, but use the same IP.
* IPv4 only.
* The message should list both name server names, both with the same IP.
### ZONE-NO-DNSSEC-1
No DNSKEY from neither ns1 nor ns2.
* Zone: "zone-no-dnssec-1.dnssec05.xa."
* Responses from ns1 and ns2 are NODATA (no DNSKEY).
[DNSSEC05]: ../../tests/DNSSEC-TP/dnssec05.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test scenario README file]: ../README.md
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

204
zonemaster/docs/public/specifications/test-zones/DNSSEC-TP/dnssec07.md Normal file
View File

@@ -0,0 +1,204 @@
# Specification of Test Scenarios for DNSSEC07
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test scenarios and setup of test zones]
## Background
See the [test scenario README file].
## Test Case
This document specifies defined test scenarios for test case [DNSSEC07].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [DNSSEC07] is run on a test zone. The
message tags are defined in the test case ([DNSSEC07]) and the scenarios are
defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone or zones for each test scenario in this document is a subdomain
(or lower zone) delegated from the base name (`dnssec07.xa`) and that subdomain
having the same name as the scenario. The names of those zones are given in
section "[Test scenarios and setup of test zones]" below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [DNSSEC07] for the specification of the tags.
* DS07_DS_FOR_SIGNED_ZONE
* DS07_DS_ON_PARENT_SERVER
* DS07_INCONSISTENT_DS
* DS07_INCONSISTENT_SIGNED
* DS07_NON_AUTH_RESPONSE_DNSKEY
* DS07_NOT_SIGNED
* DS07_NOT_SIGNED_ON_SERVER
* DS07_NO_DS_ON_PARENT_SERVER
* DS07_NO_DS_FOR_SIGNED_ZONE
* DS07_NO_RESPONSE_DNSKEY
* DS07_SIGNED
* DS07_SIGNED_ON_SERVER
* DS07_UNEXP_RCODE_RESP_DNSKEY
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
| Scenario name | Mandatory tags | Forbidden tags |
|:---------------------------|:---------------------------------------------------------------------------------------------------------------------|:---------------|
| SIGNED-AND-DS-1 | DS07_DS_FOR_SIGNED_ZONE, DS07_DS_ON_PARENT_SERVER, DS07_SIGNED, DS07_SIGNED_ON_SERVER | 2) |
| SIGNED-NO-DS-1 | DS07_NO_DS_ON_PARENT_SERVER, DS07_NO_DS_FOR_SIGNED_ZONE, DS07_SIGNED, DS07_SIGNED_ON_SERVER | 2) |
| INCONSIST-SIGNED-AND-DS-1 | DS07_DS_ON_PARENT_SERVER, DS07_INCONSISTENT_SIGNED, DS07_NOT_SIGNED_ON_SERVER, DS07_SIGNED_ON_SERVER | 2) |
| INCONSIST-SIGNED-NO-DS-1 | DS07_INCONSISTENT_SIGNED, DS07_NOT_SIGNED_ON_SERVER, DS07_NO_DS_ON_PARENT_SERVER, DS07_SIGNED_ON_SERVER | 2) |
| SIGNED-AND-INCONSIST-DS-1 | DS07_DS_ON_PARENT_SERVER, DS07_INCONSISTENT_DS, DS07_NO_DS_ON_PARENT_SERVER, DS07_SIGNED, DS07_SIGNED_ON_SERVER | 2) |
| UNSIGNED-AND-DS-1 | DS07_NOT_SIGNED, DS07_NOT_SIGNED_ON_SERVER | 2) |
| UNSIGNED-NO-DS-1 | DS07_NOT_SIGNED, DS07_NOT_SIGNED_ON_SERVER | 2) |
| NON-AUTH-RESPONSE-DNSKEY-1 | DS07_NON_AUTH_RESPONSE_DNSKEY, DS07_SIGNED, DS07_SIGNED_ON_SERVER, DS07_DS_ON_PARENT_SERVER, DS07_DS_FOR_SIGNED_ZONE | 2) |
| NO-RESPONSE-DNSKEY-1 | DS07_SIGNED, DS07_SIGNED_ON_SERVER, DS07_NO_RESPONSE_DNSKEY, DS07_DS_ON_PARENT_SERVER, DS07_DS_FOR_SIGNED_ZONE | 2) |
| UNEXP-RCODE-RESP-DNSKEY-1 | DS07_SIGNED, DS07_SIGNED_ON_SERVER, DS07_UNEXP_RCODE_RESP_DNSKEY, DS07_DS_ON_PARENT_SERVER, DS07_DS_FOR_SIGNED_ZONE | 2) |
* (1) All tags except for those specified as "Forbidden tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory tags"
## Test scenarios and setup of test zones
### Default zone configuration
Unless otherwise specified in the specific scenario specification, the test zone
or zones for the scenario will follow the default setup as stated below. The
`child zone` is the zone to be tested for the scenario.
* The child zone is `SCENARIO.dnssec07.xa`.
* It is delegated to two name servers, `ns1.SCENARIO.dnssec07.xa`
and `ns2.SCENARIO.dnssec07.xa`.
* The name server names have A and AAAA records to avoid non-relevant error
messages.
* The delegation of the child zone is to an IB NS.
* There is a zone file for the child zone.
* All child zone servers give the same response.
* The only responses, with data queried for, to the child zone that can be assumed are queries for
* NS
* SOA
* DNSKEY
* Response on DNSKEY query will include RRSIG, others will not.
* The parent zone is `dnssec07.xa`.
* It is served by two in-bailiwick NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* The parent zone will respond with one DS record per child zone.
* The only responses to the parent zone that can be assumed are queries for
* NS
* SOA
* DNSKEY
* delegation of the child
* DS for child
* Response on DS query will include RRSIG, others will not.
* All responses will have the AA bit set.
* All responses will have the [RCODE Name] "NoError".
* The DS digest algorithm is 2.
* The DS will not correctly match DNSKEY.
* The zones are not signed.
### SIGNED-AND-DS-1
All is good with signed zone and DS record in parent.
* Zone: signed-and-ds-1.dnssec07.xa.
* All default settings.
### SIGNED-NO-DS-1
The child zone is signed, but no DS in parent.
* Zone: signed-no-ds-1.dnssec07.xa.
* The child zone has default settings.
* The parent zone has no DS for the child zone.
### INCONSIST-SIGNED-AND-DS-1
The child is signed on ns1 but not on ns2.
* Zone: inconsist-signed-and-ds-1.dnssec07.xa.
* Response from ns1 with DNSKEY.
* Response from ns2 without DNSKEY.
### INCONSIST-SIGNED-NO-DS-1
The child is signed on ns1 but not on ns2.
* Zone: inconsist-signed-no-ds-1.dnssec07.xa.
* Response from ns1 with DNSKEY.
* Response from ns2 without DNSKEY.
* Parent provides no DS.
### SIGNED-AND-INCONSIST-DS-1
Parent provides DS on one server, but not the other.
* Zone: child.signed-and-inconsist-ds-1.dnssec07.xa.
* Grandparent zone is dnssec07.xa.
* Parent zone is signed-and-inconsist-ds-1.dnssec07.xa.
* ns1 provides DS, ns2 does not.
* Child zone is child.signed-and-inconsist-ds-1.dnssec07.xa.
* Child zone is signed.
### UNSIGNED-AND-DS-1
Both NS respond with no DNSKEY. Parent has NS but it is disregarded.
* Zone: unsigned-and-ds-1.dnssec07.xa.
* ns1 and ns2 respond with NO DATA on DNSKEY query.
* Parent provides DS record, but it is not expected to be queried for.
### UNSIGNED-NO-DS-1
Both NS respond with no DNSKEY. Parent has NS but it is disregarded.
* Zone: unsigned-no-ds-1.dnssec07.xa.
* ns1 and ns2 respond with NODATA on DNSKEY query.
* Parent provides no DS record, but it is not expected to be queried for.
### NON-AUTH-RESPONSE-DNSKEY-1
One server responds with non-authoritative DNSKEY response.
* Zone: non-auth-response-dnskey-1.dnssec07.xa.
* ns1 responds with AA bit unset on DNSKEY query.
* Other queries have normal responses.
* Normal responses from ns2.
### NO-RESPONSE-DNSKEY-1
One server does not respond on DNSKEY query.
* Zone: no-response-dnskey-1.dnssec07.xa.
* ns1 does not respond on the DNSKEY query.
* Other queries have normal responses.
* Normal responses from ns2.
### UNEXP-RCODE-RESP-DNSKEY-1
One server give unexpected RCODE in response on DNSKEY query.
* Zone: unexp-rcode-resp-dnskey-1.dnssec07.xa.
* ns1 responds with RCODE REFUSED on the DNSKEY query.
* Other queries have normal responses.
* Normal responses from ns2.
[DNSSEC07]: ../../tests/DNSSEC-TP/dnssec07.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test scenario README file]: ../README.md
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones

634
zonemaster/docs/public/specifications/test-zones/DNSSEC-TP/dnssec10.md Normal file
View File

@@ -0,0 +1,634 @@
# Specification of Test Scenarios for DNSSEC10
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test scenarios and setup of test zones]
## Background
See the [test scenario README file].
## Test Case
This document specifies defined test scenarios for test case [DNSSEC10].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [DNSSEC10] is run on a test zone.
The message tags are defined in the test case ([DNSSEC10]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone or zones for each test scenario in this document is a subdomain
(or lower zone) delegated from the base name (`dnssec10.xa`) and that subdomain
having the same name as the scenario. The names of those zones are given in
section "[Test scenarios and setup of test zones]" below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [DNSSEC10] for the specification of the tags.
* DS10_ALGO_NOT_SUPPORTED_BY_ZM
* DS10_ERR_MULT_NSEC
* DS10_ERR_MULT_NSEC3
* DS10_ERR_MULT_NSEC3PARAM
* DS10_EXPECTED_NSEC_NSEC3_MISSING
* DS10_HAS_NSEC
* DS10_HAS_NSEC3
* DS10_INCONSISTENT_NSEC
* DS10_INCONSISTENT_NSEC3
* DS10_INCONSISTENT_NSEC_NSEC3
* DS10_MIXED_NSEC_NSEC3
* DS10_NSEC3PARAM_GIVES_ERR_ANSWER
* DS10_NSEC3PARAM_MISMATCHES_APEX
* DS10_NSEC3PARAM_QUERY_RESPONSE_ERR
* DS10_NSEC3_ERR_TYPE_LIST
* DS10_NSEC3_MISMATCHES_APEX
* DS10_NSEC3_MISSING_SIGNATURE
* DS10_NSEC3_NODATA_MISSING_SOA
* DS10_NSEC3_NODATA_WRONG_SOA
* DS10_NSEC3_NO_VERIFIED_SIGNATURE
* DS10_NSEC3_RRSIG_EXPIRED
* DS10_NSEC3_RRSIG_NOT_YET_VALID
* DS10_NSEC3_RRSIG_NO_DNSKEY
* DS10_NSEC3_RRSIG_VERIFY_ERROR
* DS10_NSEC_ERR_TYPE_LIST
* DS10_NSEC_GIVES_ERR_ANSWER
* DS10_NSEC_MISMATCHES_APEX
* DS10_NSEC_MISSING_SIGNATURE
* DS10_NSEC_NODATA_MISSING_SOA
* DS10_NSEC_NODATA_WRONG_SOA
* DS10_NSEC_NO_VERIFIED_SIGNATURE
* DS10_NSEC_QUERY_RESPONSE_ERR
* DS10_NSEC_RRSIG_EXPIRED
* DS10_NSEC_RRSIG_NOT_YET_VALID
* DS10_NSEC_RRSIG_NO_DNSKEY
* DS10_NSEC_RRSIG_VERIFY_ERROR
* DS10_SERVER_NO_DNSSEC
* DS10_ZONE_NO_DNSSEC
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:------------------------------|:-----------------------------------------------------------------------------|:--------------------
GOOD-NSEC-1 | DS10_HAS_NSEC | 2)
GOOD-NSEC-2 | DS10_HAS_NSEC | 2)
GOOD-NSEC-3 | DS10_HAS_NSEC | 2)
GOOD-NSEC3-1 | DS10_HAS_NSEC3 | 2)
GOOD-NSEC3-2 | DS10_HAS_NSEC3 | 2)
GOOD-NSEC3-3 | DS10_HAS_NSEC3 | 2)
ALGO-NOT-SUPP-BY-ZM-1 | DS10_ALGO_NOT_SUPPORTED_BY_ZM, DS10_HAS_NSEC | 2)
ALGO-NOT-SUPP-BY-ZM-2 | DS10_ALGO_NOT_SUPPORTED_BY_ZM, DS10_HAS_NSEC3 | 2)
BAD-SERVERS-BUT-GOOD-NSEC-1 | DS10_HAS_NSEC | 2)
ERR-MULT-NSEC-1 | DS10_ERR_MULT_NSEC, DS10_HAS_NSEC | 2)
ERR-MULT-NSEC-2 | DS10_ERR_MULT_NSEC, DS10_HAS_NSEC | 2)
ERR-MULT-NSEC3-1 | DS10_ERR_MULT_NSEC3, DS10_HAS_NSEC3 | 2)
ERR-MULT-NSEC3PARAM-1 | DS10_ERR_MULT_NSEC3PARAM, DS10_HAS_NSEC3 | 2)
EXP-NSEC-NSEC3-MISS-1 | DS10_EXPECTED_NSEC_NSEC3_MISSING | 2)
INCONSISTENT-NSEC-1 | DS10_INCONSISTENT_NSEC, DS10_HAS_NSEC | 2)
INCONSISTENT-NSEC3-1 | DS10_INCONSISTENT_NSEC3, DS10_HAS_NSEC3 | 2)
INCONSIST-NSEC-NSEC3-1 | DS10_INCONSISTENT_NSEC_NSEC3 | 2)
INCONSIST-NSEC-NSEC3-2 | DS10_INCONSISTENT_NSEC_NSEC3, DS10_INCONSISTENT_NSEC, DS10_INCONSISTENT_NSEC3| 2)
MIXED-NSEC-NSEC3-1 | DS10_MIXED_NSEC_NSEC3 | 2)
MIXED-NSEC-NSEC3-2 | DS10_MIXED_NSEC_NSEC3 | 2)
NSEC3PARAM-GIVES-ERR-ANSWER-1 | DS10_NSEC3PARAM_GIVES_ERR_ANSWER, DS10_HAS_NSEC3, DS10_INCONSISTENT_NSEC3 | 2)
NSEC3PARAM-GIVES-ERR-ANSWER-2 | DS10_NSEC3PARAM_GIVES_ERR_ANSWER, DS10_EXPECTED_NSEC_NSEC3_MISSING, DS10_INCONSISTENT_NSEC3, DS10_HAS_NSEC3 | 2)
NSEC3PARAM-MISMATCHES-APEX-1 | DS10_NSEC3PARAM_MISMATCHES_APEX, DS10_HAS_NSEC3 | 2)
NSEC3PARAM-Q-RESPONSE-ERR-1 | DS10_NSEC3PARAM_QUERY_RESPONSE_ERR, DS10_HAS_NSEC3, DS10_INCONSISTENT_NSEC3 | 2)
NSEC3PARAM-Q-RESPONSE-ERR-2 | DS10_NSEC3PARAM_QUERY_RESPONSE_ERR, DS10_HAS_NSEC3, DS10_INCONSISTENT_NSEC3 | 2)
NSEC3PARAM-Q-RESPONSE-ERR-3 | DS10_NSEC3PARAM_QUERY_RESPONSE_ERR, DS10_EXPECTED_NSEC_NSEC3_MISSING, DS10_INCONSISTENT_NSEC3 | 2)
NSEC3-ERR-TYPE-LIST-1 | DS10_NSEC3_ERR_TYPE_LIST, DS10_HAS_NSEC3 | 2)
NSEC3-ERR-TYPE-LIST-2 | DS10_NSEC3_ERR_TYPE_LIST, DS10_HAS_NSEC3 | 2)
NSEC3-MISMATCHES-APEX-1 | DS10_NSEC3_MISMATCHES_APEX, DS10_HAS_NSEC3 | 2)
NSEC3-MISSING-SIGNATURE-1 | DS10_NSEC3_MISSING_SIGNATURE, DS10_HAS_NSEC3 | 2)
NSEC3-NODATA-MISSING-SOA-1 | DS10_NSEC3_NODATA_MISSING_SOA, DS10_HAS_NSEC3 | 2)
NSEC3-NODATA-WRONG-SOA-1 | DS10_NSEC3_NODATA_WRONG_SOA, DS10_HAS_NSEC3 | 2)
NSEC3-NO-VERIFIED-SIGNATURE-1 | DS10_NSEC3_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC3, DS10_NSEC3_RRSIG_NO_DNSKEY | 2)
NSEC3-NO-VERIFIED-SIGNATURE-2 | DS10_NSEC3_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC3, DS10_NSEC3_RRSIG_EXPIRED | 2)
NSEC3-NO-VERIFIED-SIGNATURE-3 | DS10_NSEC3_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC3, DS10_NSEC3_RRSIG_NOT_YET_VALID | 2)
NSEC3-NO-VERIFIED-SIGNATURE-4 | DS10_NSEC3_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC3, DS10_NSEC3_RRSIG_VERIFY_ERROR | 2)
NSEC-ERR-TYPE-LIST-1 | DS10_NSEC_ERR_TYPE_LIST, DS10_HAS_NSEC | 2)
NSEC-ERR-TYPE-LIST-2 | DS10_NSEC_ERR_TYPE_LIST, DS10_HAS_NSEC | 2)
NSEC-GIVES-ERR-ANSWER-1 | DS10_NSEC_GIVES_ERR_ANSWER, DS10_HAS_NSEC, DS10_INCONSISTENT_NSEC | 2)
NSEC-GIVES-ERR-ANSWER-2 | DS10_NSEC_GIVES_ERR_ANSWER, DS10_EXPECTED_NSEC_NSEC3_MISSING, DS10_INCONSISTENT_NSEC, DS10_HAS_NSEC | 2)
NSEC-MISMATCHES-APEX-1 | DS10_NSEC_MISMATCHES_APEX, DS10_HAS_NSEC | 2)
NSEC-MISMATCHES-APEX-2 | DS10_NSEC_MISMATCHES_APEX, DS10_HAS_NSEC | 2)
NSEC-MISSING-SIGNATURE-1 | DS10_NSEC_MISSING_SIGNATURE, DS10_HAS_NSEC | 2)
NSEC-NODATA-MISSING-SOA-1 | DS10_NSEC_NODATA_MISSING_SOA, DS10_HAS_NSEC | 2)
NSEC-NODATA-WRONG-SOA-1 | DS10_NSEC_NODATA_WRONG_SOA, DS10_HAS_NSEC | 2)
NSEC-NO-VERIFIED-SIGNATURE-1 | DS10_NSEC_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC, DS10_NSEC_RRSIG_NO_DNSKEY | 2)
NSEC-NO-VERIFIED-SIGNATURE-2 | DS10_NSEC_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC, DS10_NSEC_RRSIG_EXPIRED | 2)
NSEC-NO-VERIFIED-SIGNATURE-3 | DS10_NSEC_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC, DS10_NSEC_RRSIG_NOT_YET_VALID| 2)
NSEC-NO-VERIFIED-SIGNATURE-4 | DS10_NSEC_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC, DS10_NSEC_RRSIG_VERIFY_ERROR | 2)
NSEC-QUERY-RESPONSE-ERR-1 | DS10_NSEC_QUERY_RESPONSE_ERR, DS10_HAS_NSEC, DS10_INCONSISTENT_NSEC | 2)
NSEC-QUERY-RESPONSE-ERR-2 | DS10_NSEC_QUERY_RESPONSE_ERR, DS10_HAS_NSEC, DS10_INCONSISTENT_NSEC | 2)
NSEC-QUERY-RESPONSE-ERR-3 | DS10_NSEC_QUERY_RESPONSE_ERR, DS10_EXPECTED_NSEC_NSEC3_MISSING, DS10_INCONSISTENT_NSEC | 2)
SERVER-NO-DNSSEC-1 | DS10_SERVER_NO_DNSSEC, DS10_HAS_NSEC | 2)
SERVER-NO-DNSSEC-2 | DS10_SERVER_NO_DNSSEC, DS10_HAS_NSEC3 | 2)
ZONE-NO-DNSSEC-1 | DS10_ZONE_NO_DNSSEC | 2)
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory message tags"
## Test scenarios and setup of test zones
### Default zone configuration
Unless otherwise specified in the specific scenario specification, the test zone
or zones for the scenario will follow the default setup as stated below. The
`child zone` is the zone to be tested for the scenario.
* The child zone is `SCENARIO.dnssec10.xa`.
* It is delegated to two name servers, `ns1.SCENARIO.dnssec10.xa`
and `ns2.SCENARIO.dnssec10.xa`.
* The name server names have A and AAAA records to avoid non-relevant error
messages.
* The delegation of the child zone is complete with glue records.
* There is a zone file for the child zone.
* All child zone servers give the same response.
* The responses are either with NSEC record (NSEC zone) or NSEC3 record (NSEC3
zone), not mixed.
* The parent zone is `dnssec10.xa`.
* It is served by two in-bailiwick NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* If the child zone is an NSEC zone:
* Responds with an NSEC response on the NSEC3PARAM query.
* Responds with an NSEC record in answer section on the NSEC query.
* If the child zone is an NSEC3 zone:
* Responds with an NSEC3 response on the NSEC query.
* Responds with an NSEC3PARAM record in answer section on the NSEC3PARAM query.
* All responses will have the AA bit set.
* All responses will have the [RCODE Name] "NoError".
### GOOD-NSEC-1
An NSEC zone and a "happy path". Everything is fine.
* Zone: good-nsec-1.dnssec10.xa
### GOOD-NSEC-2
An NSEC zone and a "happy path". Everything is fine besides that the zone
is served on NS names with the same IP addresses which is fine for this test
case.
* Zone: good-nsec-2.dnssec10.xa
* The zone is delegated to ns1a, ns1b and ns1c.
* All three share the same IPv4 and IPv6 address, respectively.
### GOOD-NSEC-3
An NSEC zone and a "happy path". Everything is fine besides that the NS names
in delegation and zone are different. Fine for this test case.
* Zone: good-nsec-3.dnssec10.xa
* Zone NS are to dns1 and dns2.
* dns1 has the same IP addresses as ns1
* dns2 has the same IP addresses as ns2
### GOOD-NSEC3-1
An NSEC3 zone and a "happy path". Everything is fine.
* Zone: good-nsec3-1.dnssec10.xa
### GOOD-NSEC3-2
An NSEC3 zone and a "happy path". Everything is fine besides that the zone
is served on NS names with the same IP addresses which is fine for this test
case.
* Zone: good-nsec3-2.dnssec10.xa
* The zone is delegated to ns1a, ns1b and ns1c.
* All three share the same IPv4 and IPv6 address, respectively.
### GOOD-NSEC3-3
An NSEC3 zone and a "happy path". Everything is fine besides that the NS names
in delegation and zone are different. Fine for this test case.
* Zone: good-nsec3-3.dnssec10.xa
* Zone NS are to dns1 and dns2.
* dns1 has the same IP addresses as ns1
* dns2 has the same IP addresses as ns2
### ALGO-NOT-SUPP-BY-ZM-1
An NSEC zone. Unknown algorithm of a DNSKEY.
* Zone: algo-not-supp-by-zm-1.dnssec10.xa
* There is an extra RRSIG for the NSEC record (as the response to the
NSEC3PARAM query).
* That RRSIG has been created by [algorithm 255][IANA registry], which is
an unsupported private algorithm.
* A matching DNSKEY ([algorithm 255][IANA registry]) is available.
* For this test scenario a fake signature and a fake public key are used.
* The extra DNSKEY is in the DNSKEY RRset which is resigned by the valid
KSK.
### ALGO-NOT-SUPP-BY-ZM-2
An NSEC3 zone. Unknown algorithm of a DNSKEY.
* Zone: algo-not-supp-by-zm-2.dnssec10.xa
* There is an extra RRSIG for the NSEC3 record (as the response to the
NSEC query).
* That RRSIG has been created by [algorithm 255][IANA registry], which is
an unsupported private algorithm.
* A matching DNSKEY ([algorithm 255][IANA registry]) is available.
* For this test scenario a fake signature and a fake public key are used.
* The extra DNSKEY is in the DNSKEY RRset which is resigned by the valid
KSK.
### BAD-SERVERS-BUT-GOOD-NSEC-1
An NSEC zone. Everything is fine except some non-responsive servers.
* Zone: bad-servers-but-good-nsec-1.dnssec10.xa
* The child zone is delegated to ns1, ns2, ns3, ns4 and ns5, all
in-bailiwick with correct glue.
* ns1 and ns2 are correct and work as they should.
* ns3 does not respond on DNSKEY query.
* ns4 responds with REFUSED on DNSKEY query.
* ns5 responds with AA unset on DNSKEY query.
### ERR-MULT-NSEC-1
An NSEC zone. An extra NSEC record is returned on the NSEC3PARAM query.
* Zone: err-mult-nsec-1.dnssec10.xa
* An extra NSEC record is returned in the response to the NSEC3PARAM query.
* The extra NSEC record has the same owner name, but different value in
"Next Domain Name" field.
* RRSIG is recalculated.
### ERR-MULT-NSEC-2
An NSEC zone. An extra NSEC record is returned on the NSEC query.
* Zone: err-mult-nsec-2.dnssec10.xa
* An extra NSEC record is returned in the response to the NSEC query.
* The extra NSEC record has the same owner name, but different value in
"Type List" field.
* RRSIG is recalculated.
### ERR-MULT-NSEC3-1
An NSEC3 zone. An extra NSEC3 record is returned.
* Zone: err-mult-nsec3-1.dnssec10.xa
* An extra NSEC3 record is returned in the response to the NSEC query.
* The extra NSEC3 record has the same hash owner name, but different value in
"Next Hashed Owner Name" field.
* The NSEC3 RRset has been signed with a valid RRSIG.
### ERR-MULT-NSEC3PARAM-1
An NSEC3 zone. An extra NSEC3PARAM record is returned.
* Zone: err-mult-nsec3param-1.dnssec10.xa
* An extra NSEC3PARAM record is returned in the response to the NSEC query.
* The extra NSEC3PARAM record has the same owner name, but different number
of iterations.
* The NSEC3PARAM RRset has been signed with a valid RRSIG.
### EXP-NSEC-NSEC3-MISS-1
A zone without NSEC and NSEC3. There is no NSEC or NSEC3 function.
* Zone: exp-nsec-nsec3-miss-1.dnssec10.xa
* The NSEC query gives a NODATA response with no NSEC or NSEC3 record.
* The NSEC3PARAM query gives a NODATA response with no NSEC or NSEC3 record.
### INCONSISTENT-NSEC-1
An NSEC zone. Some errors in NSEC handling.
* Zone: inconsistent-nsec-1.dnssec10.xa
* ns1 includes no NSEC record in the NODATA response on the NSEC3PARAM query.
* ns2 includes no NSEC record in the NODATA response on the NSEC query.
### INCONSISTENT-NSEC3-1
An NSEC3 zone. Some errors in NSEC3 handling.
* Zone: inconsistent-nsec3-1.dnssec10.xa
* ns1 includes no NSEC3 record in the NODATA response on the NSEC query.
* ns2 includes no NSEC3PARAM or NSEC3 record in the NODATA response on the
NSEC3PARAM query.
### INCONSIST-NSEC-NSEC3-1
Mixing beteen NSEC and NSEC3.
* Zone: inconsist-nsec-nsec3-1.dnssec10.xa
* ns1 holds an NSEC version of the zone.
* ns2 holds an NSEC3 version of the zone.
### INCONSIST-NSEC-NSEC3-2
NSEC on one server and NSEC3 on the other plus errors in NSEC and NSEC3 handling.
* Zone: inconsist-nsec-nsec3-2.dnssec10.xa
* ns1 holds an NSEC version of the zone.
* It responds with a NODATA respond without NSEC record on the NSEC3PARAM
query.
* It does respond with an NSEC record to the NSEC query.
* ns2 holds an NSEC3 version of the zone.
* It responds with a NODATA respond without NSEC3 record on the NSEC query.
* It does respond with an NSEC3PARAM record to the NSEC3PARAM query.
### MIXED-NSEC-NSEC3-1
Servers gives both NSEC and NSEC3
* Zone: mixed-nsec-nsec3-1.dnssec10.xa
* The zone gives an NSEC record in response to NSEC query.
* The zone gives an NSEC3PARAM record in response to the NSEC3PARAM query.
### MIXED-NSEC-NSEC3-2
Servers gives both NSEC and NSEC3
* Zone: mixed-nsec-nsec3-2.dnssec10.xa
* The zone gives a NODATA response with NSEC3 record in response to NSEC
query.
* The zone gives a NODATA response with NSEC record in response to the
NSEC3PARAM query.
### NSEC3PARAM-GIVES-ERR-ANSWER-1
An NSEC3 zone. Error in response to NSEC3PARAM query.
* Zone: nsec3param-gives-err-answer-1.dnssec10.xa
* The zone gives a TXT record, but no NSEC3PARAM record, in response to the
NSEC3PARAM query.
### NSEC3PARAM-GIVES-ERR-ANSWER-2
An NSEC3 zone. Error in response to NSEC3PARAM query on ns1. No NSEC or NSEC3 on
ns2.
* Zone: nsec3param-gives-err-answer-1.dnssec10.xa
* On ns1, the zone gives a TXT record, but no NSEC3PARAM record, in response to
the NSEC3PARAM query.
* On ns2, the zone gives NODATA responses without NSEC or NSEC3 record for both
the NSEC3PARAM query and the NSEC query.
### NSEC3PARAM-MISMATCHES-APEX-1
An NSEC3 zone. The owner name of the NSEC3PARAM record is erroneous.
* Zone: nsec3param-mismatches-apex-1.dnssec10.xa
* The owner name of the NSEC3PARAM record in response to the NSEC3PARAM query is
erroneous and does not match apex.
* The owner name is `sub.nsec3param-mismatches-apex-1.dnssec10.xa` instead of
expected `nsec3param-mismatches-apex-1.dnssec10.xa`.
## NSEC3PARAM-Q-RESPONSE-ERR-1
An NSEC3 zone. Error in response to NSEC3PARAM query.
* Zone: nsec3param-q-response-err-1.dnssec10.xa
* No DNS response on the NSEC3PARAM query.
## NSEC3PARAM-Q-RESPONSE-ERR-2
An NSEC3 zone. Error in response to NSEC3PARAM query.
* Zone: nsec3param-q-response-err-2.dnssec10.xa
* The response on the NSEC3PARAM query has the [RCODE Name] "REFUSED".
## NSEC3PARAM-Q-RESPONSE-ERR-3
An NSEC3 zone. Error in response to NSEC3PARAM query on ns1. No NSEC or NSEC3 on
ns2.
* Zone: nsec3param-q-response-err-3.dnssec10.xa
* The response from ns1 on the NSEC3PARAM query has the AA flag unset.
* On ns2, the zone gives NODATA responses without NSEC or NSEC3 record for both
the NSEC3PARAM query and the NSEC query.
### NSEC3-ERR-TYPE-LIST-1
An NSEC3 zone. The type list of the NSEC3 record is erroneous.
* Zone: nsec3-err-type-list-1.dnssec10.xa
* The type list of the NSEC3 record includes NSEC.
### NSEC3-ERR-TYPE-LIST-2
An NSEC3 zone. The type list of the NSEC3 record is erroneous.
* Zone: nsec3-err-type-list-2.dnssec10.xa
* The type list of the NSEC3 record misses RRSIG.
### NSEC3-MISMATCHES-APEX-1
An NSEC3 zone. The hash owner name of the NSEC3 record is erroneous.
* Zone: nsec3-mismatches-apex-1.dnssec10.xa
* The hash owner name of the NSEC3 record in response to the NSEC query is
erroneous and does not match apex.
### NSEC3-MISSING-SIGNATURE-1
An NSEC3 zone. The RRSIG is missing
* Zone: nsec3-missing-signature-1.dnssec10.xa
* There is no RRSIG for the NSEC3 record in the response with NSEC3 record.
### NSEC3-NODATA-MISSING-SOA-1
An NSEC3 zone. The SOA record is missing in the NODATA response.
* Zone: nsec3-nodata-missing-soa-1.dnssec10.xa
* In the NODATA response to the NSEC query the SOA record is missing.
### NSEC3-NODATA-WRONG-SOA-1
An NSEC3 zone. In the NODATA response the SOA record has the wrong owner name.
* Zone: nsec3-nodata-wrong-soa-1.dnssec10.xa
* The owner name of the SOA record in the NODATA response to the NSEC query
is `sub.nsec3-nodata-wrong-soa-1.dnssec10.xa` instead of expected
`nsec3-nodata-wrong-soa-1.dnssec10.xa`.
### NSEC3-NO-VERIFIED-SIGNATURE-1
An NSEC3 zone. The RRSIG for the NSEC3 record cannot be verified.
* Zone: nsec3-no-verified-signature-1.dnssec10.xa
* The RRSIG record for the NSEC3 record in the NODATA response to the NSEC
query cannot be verified.
* There is no matching DNSKEY for the RRSIG for the NSEC3 record.
### NSEC3-NO-VERIFIED-SIGNATURE-2
An NSEC3 zone. The RRSIG for the NSEC3 record cannot be verified.
* Zone: nsec3-no-verified-signature-2.dnssec10.xa
* The RRSIG record for the NSEC3 record in the NODATA response to the NSEC
query cannot be verified.
* The RRSIG has expired, i.e. the current date-time is beyond the last valid
date-time.
### NSEC3-NO-VERIFIED-SIGNATURE-3
An NSEC3 zone. The RRSIG for the NSEC3 record cannot be verified.
* Zone: nsec3-no-verified-signature-3.dnssec10.xa
* The RRSIG record for the NSEC3 record in the NODATA response to the NSEC
query cannot be verified.
* The RRSIG it not yet valid, i.e. the current date-time is before the first
valid date-time.
### NSEC3-NO-VERIFIED-SIGNATURE-4
An NSEC3 zone. The RRSIG for the NSEC3 record cannot be verified.
* Zone: nsec3-no-verified-signature-4.dnssec10.xa
* The RRSIG record for the NSEC3 record in the NODATA response to the NSEC
query cannot be verified.
* The RRSIG signature does not match the NSEC record and appointed DNSKEY.
### NSEC-ERR-TYPE-LIST-1
An NSEC zone. The type list of the NSEC record is erroneous.
* Zone: nsec-err-type-list-1.dnssec10.xa
* The type list of the NSEC record includes NSEC3PARAM.
### NSEC-ERR-TYPE-LIST-2
An NSEC zone. The type list of the NSEC record is erroneous.
* Zone: nsec-err-type-list-2.dnssec10.xa
* The type list of the NSEC record misses RRSIG.
### NSEC-GIVES-ERR-ANSWER-1
An NSEC zone. Error in response to NSEC query.
* Zone: nsec-gives-err-answer-1.dnssec10.xa
* The zone gives a TXT record, but no NSEC record, in response to the NSEC
query.
### NSEC-GIVES-ERR-ANSWER-2
An NSEC zone. Error in response to NSEC query on ns1. No NSEC or NSEC3 on ns2.
* Zone: nsec-gives-err-answer-2.dnssec10.xa
* On ns1, the zone gives a TXT record, but no NSEC record, in response to the
NSEC query.
* On ns2, the zone gives NODATA responses without NSEC or NSEC3 record for both
the NSEC3PARAM query and the NSEC query.
### NSEC-MISMATCHES-APEX-1
An NSEC zone. The owner name of the NSEC record is errouneous.
* Zone: nsec-mismatches-apex-1.dnssec10.xa
* The owner name of the NSEC record in response to the NSEC3PARAM query is
errouneous and does not match apex.
* The owner name is `sub.nsec-mismatches-apex-1.dnssec10.xa` instead of
expected `nsec-mismatches-apex-1.dnssec10.xa`.
### NSEC-MISMATCHES-APEX-2
An NSEC zone. The owner name of the NSEC record is errouneous.
* Zone: nsec-mismatches-apex-2.dnssec10.xa
* The owner name of the NSEC record in response to the NSEC query is
errouneous and does not match apex.
* The owner name is `sub.nsec-mismatches-apex-2.dnssec10.xa` instead of
expected `nsec-mismatches-apex-2.dnssec10.xa`.
### NSEC-MISSING-SIGNATURE-1
An NSEC zone. The RRSIG is missing.
* Zone: nsec-missing-signature-1.dnssec10.xa
* There is no RRSIG for the NSEC record in the response with NSEC record on the
NSEC3PARAM query.
### NSEC-NODATA-MISSING-SOA-1
An NSEC zone. The SOA record is missing in the NODATA response.
* Zone: nsec-nodata-missing-soa-1.dnssec10.xa
* In the NODATA response to the NSEC3PARAM query the SOA record is missing.
### NSEC-NODATA-WRONG-SOA-1
An NSEC zone. In the NODATA response the SOA record has the wrong owner name.
* Zone: nsec-nodata-wrong-soa-1.dnssec10.xa
* The owner name of the SOA record in the NODATA response to the NSEC3PARAM
query is `sub.nsec-nodata-wrong-soa-1.dnssec10.xa` instead of expected
`nsec-nodata-wrong-soa-1.dnssec10.xa`.
### NSEC-NO-VERIFIED-SIGNATURE-1
An NSEC zone. The RRSIG for the NSEC record cannot be verified.
* Zone: nsec-no-verified-signature-1.dnssec10.xa
* The RRSIG record for the NSEC record in the NODATA response to the NSEC3PARAM
query cannot be verified.
* There is no matching DNSKEY for the RRSIG for that NSEC record.
### NSEC-NO-VERIFIED-SIGNATURE-2
An NSEC zone. The RRSIG for the NSEC record cannot be verified.
* Zone: nsec-no-verified-signature-2.dnssec10.xa
* The RRSIG record for the NSEC record in the NODATA response to the NSEC3PARAM
query cannot be verified.
* The RRSIG has expired, i.e. the current date-time is beyond the last valid
date-time.
### NSEC-NO-VERIFIED-SIGNATURE-3
An NSEC zone. The RRSIG for the NSEC record cannot be verified.
* Zone: nsec-no-verified-signature-3.dnssec10.xa
* The RRSIG record for the NSEC record in the NODATA response to the NSEC3PARAM
query cannot be verified.
* The RRSIG it not yet valid, i.e. the current date-time is before the first
valid date-time.
### NSEC-NO-VERIFIED-SIGNATURE-4
An NSEC zone. The RRSIG for the NSEC record cannot be verified.
* Zone: nsec-no-verified-signature-4.dnssec10.xa
* The RRSIG record for the NSEC record in the NODATA response to the NSEC3PARAM
query cannot be verified.
* The RRSIG signature does not match the RRSIG record and appointed DNSKEY.
### NSEC-QUERY-RESPONSE-ERR-1
An NSEC zone. Error in response to NSEC query.
* Zone: nsec-query-response-err-1.dnssec10.xa
* No DNS response on the NSEC query.
### NSEC-QUERY-RESPONSE-ERR-2
An NSEC zone. Error in response to NSEC query.
* Zone: nsec-query-response-err-2.dnssec10.xa
* The response on the NSEC query has the [RCODE Name] "REFUSED".
### NSEC-QUERY-RESPONSE-ERR-3
An NSEC zone. Error in response to NSEC query on ns1. No NSEC or NSEC3 in
responses from ns2.
* Zone: nsec-query-response-err-3.dnssec10.xa
* The response from ns1 on the NSEC query has the AA flag unset.
* On ns2, the zone gives NODATA responses without NSEC or NSEC3 record for both
the NSEC3PARAM query and the NSEC query.
### SERVER-NO-DNSSEC-1
An NSEC zone. No DNSKEY in response from ns1. Normal response from ns2.
* Zone: server-no-dnssec-1.dnssec10.xa
* The answer section in response from ns1 on the DNSKEY query is empty. Unsigned
NODATA response without NSEC or NSEC3.
* The NSEC and NSEC3PARAM queries are irrelevant, but they also give a Unsigned
NODATA response without NSEC or NSEC3 on ns1.
### SERVER-NO-DNSSEC-2
An NSEC3 zone. No DNSKEY in response from ns1. Normal response from ns2.
* Zone: server-no-dnssec-2.dnssec10.xa
* The answer section in response from ns1 on the DNSKEY query is empty. Unsigned
NODATA response without NSEC or NSEC3.
* The NSEC and NSEC3PARAM queries are irrelevant, but they also give a Unsigned
NODATA response without NSEC or NSEC3 on ns1.
### ZONE-NO-DNSSEC-1
No DNSKEY in response.
* Zone: zone-no-dnssec-1.dnssec10.xa
* The answer section in response on the DNSKEY query is empty. Unsigned NODATA
response without NSEC or NSEC3.
* The NSEC and NSEC3PARAM queries are irrelevant, but they also give a Unsigned
NODATA response without NSEC or NSEC3.
[DNSSEC10]: ../../tests/DNSSEC-TP/dnssec10.md
[IANA registry]: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test scenario README file]: ../README.md
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones

190
zonemaster/docs/public/specifications/test-zones/DNSSEC-TP/dnssec16.md Normal file
View File

@@ -0,0 +1,190 @@
# Specification of test zones for DNSSEC16
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
* [Terminology](#terminology)
## Background
See the [test zone README file].
## Test Case
This document specifies defined test zones for test case [DNSSEC16].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [DNSSEC16] is run on a test zone. The
message tags are defined in the test case ([DNSSEC16]) and the scenarios are
defined below.
The test scenarios are structured as stated in the [test zone README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`dnssec16.xa`) and that subdomain having the same name as the
scenario except where the test domain must be the root zone, a TLD or a domain
under `.arpa`. The names of those zones are given in section
"[Zone setup for test scenarios]" below.
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tags | Forbidden message tags
:----------------------------|:--------------------------------------------------|:-------------------------------------------
CDS-INVALID-RRSIG | DS16_CDS_INVALID_RRSIG | DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
CDS-MATCHES-NO-DNSKEY | DS16_CDS_MATCHES_NO_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
CDS-MATCHES-NON-SEP-DNSKEY | DS16_CDS_MATCHES_NON_SEP_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
CDS-MATCHES-NON-ZONE-DNSKEY | DS16_CDS_MATCHES_NON_ZONE_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
CDS-NOT-SIGNED_BY_CDS | DS16_CDS_NOT_SIGNED_BY_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
CDS-SIGNED-BY-UNKNOWN-DNSKEY | DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
CDS-UNSIGNED | DS16_CDS_UNSIGNED, DS16_CDS_NOT_SIGNED_BY_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
CDS-WITHOUT-DNSKEY | DS16_CDS_WITHOUT_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
DELETE-CDS | DS16_DELETE_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
DNSKEY-NOT-SIGNED-BY-CDS | DS16_DNSKEY_NOT_SIGNED_BY_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_MIXED_DELETE_CDS
MIXED-DELETE-CDS | DS16_MIXED_DELETE_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS
NO-CDS | (none) | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
NOT-AA | (none) | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
VALID-CDS | (none) | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
## Zone setup for test scenarios
Assumptions for the scenario specifications:
* Only CDS or DNSKEY records in apex are considered.
* Unless stated otherwise, all name servers respond authoritatively with
[RCODE Name] "NoError" on all queries.
* Unless stated otherwise, all name servers respond authoritatively with (or
without) CDS records on CDS queries and DNSKEY records on DNSKEY queries,
respectively.
* Unless stated otherwise, all RRSIGs are present where expected and are valid.
* Each zone is served by two nameservers and both respond consistently.
* No DS record is published at parent zone (`dnssec16.xa`).
### CDS-INVALID-RRSIG
* Zone: "cds-invalid-rrsig.dnssec16.xa."
* The zone has a [Well Formed DNSKEY Record] (key 1).
* The zone has one [Well Formed CDS Record], that matches key 1, but the RRSIG
of the CDS RRset has expired.
### CDS-MATCHES-NO-DNSKEY
* Zone: "cds-matches-no-dnskey.dnssec16.xa."
* The zone has one [Well Formed DNSKEY Record] (key 1).
* The zone has one [Well Formed CDS Record] that matches key 1.
* The zone has a second [Well Formed CDS Record] that matches no key by key
tag.
### CDS-MATCHES-NON-SEP-DNSKEY
* Zone: "cds-matches-non-sep-dnskey.dnssec16.xa."
* The zone has a [Well Formed DNSKEY Record], but flag bit 15 is unset (key
1).
* The zone has one [Well Formed CDS Record] that matches key 1.
### CDS-MATCHES-NON-ZONE-DNSKEY
* Zone: "cds-matches-non-zone-dnskey.dnssec16.xa."
* The zone has one [Well Formed DNSKEY Record] (key 1).
* The zone has a second [Well Formed DNSKEY Record], but flag bit 7 is unset
and the key has not signed the DNSKEY RRset (key 2).
* The zone has one [Well Formed CDS Record] and matches key 1 (CDS 1).
* The zone has a second [Well Formed CDS Record], matching key 2, but the key
has not signed the CDS RRset.
### CDS-NOT-SIGNED-BY-CDS
* Zone: "cds-not-signed-by-cds.dnssec16.xa."
* The zone has two [Well Formed DNSKEY Record] (key 1 and 2).
* The zone has one [Well Formed CDS Record] that matches key 1.
* The zone has a second [Well Formed CDS Record] that matches key 2, but its
DNSKEY has not signed the CDS RRset.
### CDS-SIGNED-BY-UNKNOWN-DNSKEY
* Zone: "cds-signed-by-unknown-dnskey.dnssec16.xa."
* The zone has a [Well Formed DNSKEY Record] (key 1).
* The zone has one [Well Formed CDS Record], and it matches key 1.
* The CDS RRset has an additional RRSIG that matches no DNSKEY by key tag.
### CDS-UNSIGNED
* Zone: "cds-unsigned.dnssec16.xa."
* The zone has a [Well Formed DNSKEY Record] (key 1).
* The zone has one [Well Formed CDS Record], and it matches key 1, but the CDS
RRset is not signed.
### CDS-WITHOUT-DNSKEY
* Zone: "cds-without-dnskey.dnssec16.xa."
* The zone has no DNSKEY.
* The zone has one [Well Formed CDS Record] that matches no DNSKEY.
### DELETE-CDS
* Zone: "delete-cds.dnssec16.xa."
* The zone has a [Well Formed DNSKEY Record].
* The zone has one CDS RR that is a Delete CDS.
### DNSKEY-NOT-SIGNED-BY-CDS
* Zone: "dnskey-not-signed-by-cds.dnssec16.xa."
* The zone has a [Well Formed DNSKEY Record] (key 1), but the key has not
signed the DNSKEY RRset.
* The zone has one [Well Formed CDS Record], and it matches key 1.
### MIXED-DELETE-CDS
* Zone: "mixed-delete-cds.dnssec16.xa."
* The zone has a [Well Formed DNSKEY Record] (key 1).
* The zone has one [Well Formed CDS Record], and it matches key 1.
* The zone has a second CDS RR that is a Delete CDS.
### NO-CDS
* Zone: "no-cds.dnssec16.xa."
* The name servers give no CDS RRset on CDS query (NODATA).
### NOT-AA
* Zone: "not-aa.dnssec16.xa."
* The name servers give non-AA response on CDS queries.
### VALID-CDS
* Zone: "valid-cds.dnssec16.xa."
* The zone has a [Well Formed DNSKEY Record] (key 1).
* The zone has one [Well Formed CDS Record], and it matches key 1.
## Terminology
* "Well Formed DNSKEY Record" - The term is used, in this document, for a DNSKEY
record that meets the following requirements:
* It is a DNSKEY record in apex.
* It uses algorithm 10 (RSA/SHA-512) with a 2048-bit key length, see
[DNSSEC05] and [DNSSEC14].
* Flag bit 7 (zone key) and bit 15 (SEP) are set.
* The DNSKEY RRset has been signed by the key and the RRSIG is valid.
* "Well Formed CDS Record" - The term is used, in this document, for a CDS record
that meets the following requirements:
* It is a CDS record in apex.
* It uses hash digest 2 (SHA-256), see [DNSSEC01].
* Its digest is a digest of a [Well Formed DNSKEY Record].
* The CDS RRset has been signed by the its DNSKEY and the RRSIG is valid.
[DNSSEC01]: ../../tests/DNSSEC-TP/dnssec01.md
[DNSSEC05]: ../../tests/DNSSEC-TP/dnssec05.md
[DNSSEC14]: ../../tests/DNSSEC-TP/dnssec14.md
[DNSSEC16]: ../../tests/DNSSEC-TP/dnssec16.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../README.md
[Well Formed CDS Record]: #terminology
[Well Formed DNSKEY Record]: #terminology
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

8
zonemaster/docs/public/specifications/test-zones/Delegation-TP/README.md Normal file
View File

@@ -0,0 +1,8 @@
# Specification of test scenarios for Delegation-TP
Test scenario specifications are available for:
* [Delegation01](delegation01.md)
* [Delegation02](delegation02.md)
* [Delegation03](delegation03.md)

245
zonemaster/docs/public/specifications/test-zones/Delegation-TP/delegation01.md Normal file
View File

@@ -0,0 +1,245 @@
# Specification of test Scenarios for Delegation01
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test zone setup]
## Background
See the [test scenario README file].
## Test Case
This document specifies test scenarios for test case [Delegation01].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are output when [Delegation01] is run on a test zone.
The message tags are defined in the test case ([Delegation01]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`delegation01.xa`) and that subdomain having the same name as
the scenario. The names of those zones are given in section
[Test zone setup] below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [Delegation01] for the specification of the tags.
* ENOUGH_IPV4_NS_CHILD
* ENOUGH_IPV4_NS_DEL
* ENOUGH_IPV6_NS_CHILD
* ENOUGH_IPV6_NS_DEL
* ENOUGH_NS_CHILD
* ENOUGH_NS_DEL
* NOT_ENOUGH_IPV4_NS_CHILD
* NOT_ENOUGH_IPV4_NS_DEL
* NOT_ENOUGH_IPV6_NS_CHILD
* NOT_ENOUGH_IPV6_NS_DEL
* NOT_ENOUGH_NS_CHILD
* NOT_ENOUGH_NS_DEL
* NO_IPV4_NS_CHILD
* NO_IPV4_NS_DEL
* NO_IPV6_NS_CHILD
* NO_IPV6_NS_DEL
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:-----------------------------|:---------------------------------------------------------|:-------------------------------------------
ENOUGH-1 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
ENOUGH-2 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
ENOUGH-3 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
ENOUGH-DEL-NOT-CHILD | ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_DEL, NOT_ENOUGH_IPV4_NS_CHILD, NOT_ENOUGH_IPV6_NS_CHILD, NOT_ENOUGH_NS_CHILD | 2)
ENOUGH-CHILD-NOT-DEL | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV6_NS_CHILD, ENOUGH_NS_CHILD, NOT_ENOUGH_IPV4_NS_DEL, NOT_ENOUGH_IPV6_NS_DEL, NOT_ENOUGH_NS_DEL | 2)
IPV6-AND-DEL-OK-NO-IPV4-CHILD | ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV4_NS_CHILD | 2)
IPV4-AND-DEL-OK-NO-IPV6-CHILD | ENOUGH_IPV4_NS_DEL, ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV6_NS_CHILD | 2)
NO-IPV4-1 | ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV4_NS_CHILD, NO_IPV4_NS_DEL | 2)
NO-IPV4-2 | ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV4_NS_CHILD, NO_IPV4_NS_DEL | 2)
NO-IPV4-3 | ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV4_NS_CHILD, NO_IPV4_NS_DEL | 2)
NO-IPV6-1 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV6_NS_CHILD, NO_IPV6_NS_DEL | 2)
NO-IPV6-2 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV6_NS_CHILD, NO_IPV6_NS_DEL | 2)
NO-IPV6-3 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV6_NS_CHILD, NO_IPV6_NS_DEL | 2)
MISMATCH-DELEGATION-CHILD-1 | ENOUGH_IPV4_NS_CHILD, NOT_ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, NOT_ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
MISMATCH-DELEGATION-CHILD-2 | NOT_ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, NOT_ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
1\) All tags except for those specified as "Forbidden message tags" (no
instances for these test scenarios)
2\) All tags except for those specified as "Mandatory message tags"
## Test zone setup
Assumptions for the scenario specifications unless otherwise specified for the
specific scenario:
* For each scenario zone there are two name servers configured.
* Both name servers (ns1 and ns2) are equal in delegation and in zone.
* Both name servers are in-bailiwick.
* Both name servers have both IPv4 and IPv6 addresses.
* All required glue records are present in the delegation.
* All glue exactly match the authoritative address records in correct zone
(not more and not less records).
* All name server IP addresses respond with identical zone content.
### ENOUGH-1
This is the main happy path.
* Zone: enough-1.delegation01.xa
### ENOUGH-2
This is also a happy path. Out-of-bailiwick.
* Zone: enough-2.delegation01.xa
* Both ns1 and ns2 are out-of-bailiwick.
* ns1 is "ns1.enough-2.delegation01.xb"
* ns2 is "ns2.enough-2.delegation01.xb"
* Delegation is without glue.
* The test zone ("child") has no address records for the name server names.
* The "delegation01.xb" zone has the full set of address records.
### ENOUGH-3
This is also a happy path. Also out-of-bailiwick, but with sibling glue.
* Zone: enough-3.delegation01.xa
* Both ns1 and ns2 are out-of-bailiwick
* ns1 is "ns1.enough-3.sibling.delegation01.xa"
* ns2 is "ns2.enough-3.sibling.delegation01.xa"
* Delegation is with glue.
* The child zone has no address records for the name server names.
* The two name servers are defined directly in the parent zone with full set of
address records.
### ENOUGH-DEL-NOT-CHILD
Only one name server in child zone.
* Zone: enough-del-not-child.delegation01.xa
* The child zone defines only one name server, ns1.
* Delegation is complete.
### ENOUGH-CHILD-NOT-DEL
Only one name server in delegation.
* Zone: enough-child-not-del.delegation01.xa
* The delegation has only one name server, for ns1.
* The child has two name servers with full set of address records.
### IPV6-AND-DEL-OK-NO-IPV4-CHILD
No IPv4 in zone.
* Zone: ipv6-and-del-ok-no-ipv4-child.delegation01.xa
* No A records for ns1 and ns2 in zone.
* Delegation is complete.
### IPV4-AND-DEL-OK-NO-IPV6-CHILD
No IPv6 in zone.
* Zone: ipv4-and-del-ok-no-ipv6-child.delegation01.xa
* No AAAA records for ns1 and ns2 in zone.
* Delegation is complete.
### NO-IPV4-1
No IPv4 in delegation or zone.
* Zone: no-ipv4-1.delegation01.xa
* No A glue for ns1 and ns2.
* No A records in zone for ns1 and ns2.
### NO-IPV4-2
No IPv4 in delegation or zone. Out-of-bailiwick name servers and no glue.
* Zone: no-ipv4-2.delegation01.xa
* Both ns1 and ns2 are out-of-bailiwick under the xb tree.
* ns1 is "ns1.no-ipv4-2.delegation01.xb"
* ns2 is "ns2.no-ipv4-2.delegation01.xb"
* Delegation is without glue.
* The test zone ("child") has no address records for the name server names
* The "delegation01.xb" zone has full set of address records for this.
* AAAA only, not A
### NO-IPV4-3
No IPv4 in delegation or zone. Out-of-bailiwick name servers, but with sibling
glue.
* Zone: no-ipv4-3.delegation01.xa
* Both ns1 and ns2 are out-of-bailiwick
* ns1 is "ns1.no-ipv4-3.sibling.delegation01.xa"
* ns2 is "ns2.no-ipv4-3.sibling.delegation01.xa"
* Delegation is with glue.
* The child zone has no address records for the name server names
* The sibling names have full sets of address records.
* AAAA only, not A.
### NO-IPV6-1
No IPv6 in delegation or zone.
* Zone: no-ipv6-1.delegation01.xa
* No AAAA glue for ns1 and ns2.
* No AAAA records in zone for ns1 and ns2.
### NO-IPV6-2
No IPv6 in delegation or zone. Out-of-bailiwick name servers and no glue.
* Zone: no-ipv6-2.delegation01.xa
* Both ns1 and ns2 are out-of-bailiwick under the xb tree.
* ns1 is "ns1.no-ipv6-2.delegation01.xb"
* ns2 is "ns2.no-ipv6-2.delegation01.xb"
* Delegation is without glue.
* The test zone ("child") has no address records for the name servers names
* The "delegation01.xb" zone has full set of address records for this.
* A only, not AAAA
### NO-IPV6-3
No IPv6 in delegation or zone. Out-of-bailiwick name servers, but with sibling
glue.
* Zone: no-ipv6-3.delegation01.xa
* Both ns1 and ns2 are out-of-bailiwick
* ns1 is "ns1.no-ipv6-3.sibling.delegation01.xa"
* ns2 is "ns2.no-ipv6-3.sibling.delegation01.xa"
* Delegation is with glue.
* The child zone has no address records for the name server names
* The sibling names has full set of address records.
* A only, not AAAA.
### MISMATCH-DELEGATION-CHILD-1
Missing glue, only IPv4 on ns1 and only IPv6 on ns2.
* Zone: mismatch-delegation-child-1.delegation01.xa
* Only IPv4 glue on ns1.
* Only IPv6 glue on ns2.
* Full set in zone.
### MISMATCH-DELEGATION-CHILD-2
The zone has only IPv4 on ns1 and only IPv6 on ns2.
* Zone: mismatch-delegation-child-2.delegation01.xa
* Only IPv4 on ns1 in zone.
* Only IPv6 on ns2 in zone.
* Full set in delegation.
[Delegation01]: ../../tests/Delegation-TP/delegation01.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test scenario README file]: ../README.md
[Test zone setup]: #test-zone-setup

214
zonemaster/docs/public/specifications/test-zones/Delegation-TP/delegation02.md Normal file
View File

@@ -0,0 +1,214 @@
# Specification of test Scenarios for Delegation02
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test zone setup]
## Background
See the [test scenario README file].
## Test Case
This document specifies test scenarios for test case [Delegation02].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are output when [Delegation02] is run on a test zone.
The message tags are defined in the test case ([Delegation02]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`delegation02.xa`) and that subdomain having the same name as
the scenario. The names of those zones are given in section [Test zone setup]
below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [Delegation02] for the specification of the tags.
* DEL_DISTINCT_NS_IP
* CHILD_DISTINCT_NS_IP
* DEL_NS_SAME_IP
* CHILD_NS_SAME_IP
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:-----------------------------|:-----------------------------------------|:-------------------------------------------
ALL-DISTINCT-1 | DEL_DISTINCT_NS_IP, CHILD_DISTINCT_NS_IP | 2)
ALL-DISTINCT-2 | DEL_DISTINCT_NS_IP, CHILD_DISTINCT_NS_IP | 2)
ALL-DISTINCT-3 | DEL_DISTINCT_NS_IP, CHILD_DISTINCT_NS_IP | 2)
DEL-NON-DISTINCT | DEL_NS_SAME_IP, CHILD_DISTINCT_NS_IP | 2)
DEL-NON-DISTINCT-UND | DEL_NS_SAME_IP, CHILD_DISTINCT_NS_IP | 2)
CHILD-NON-DISTINCT | DEL_DISTINCT_NS_IP, CHILD_NS_SAME_IP | 2)
CHILD-NON-DISTINCT-UND | DEL_DISTINCT_NS_IP, CHILD_NS_SAME_IP | 2)
NON-DISTINCT-1 | DEL_NS_SAME_IP, CHILD_NS_SAME_IP | 2)
NON-DISTINCT-2 | DEL_NS_SAME_IP, CHILD_NS_SAME_IP | 2)
NON-DISTINCT-3 | DEL_NS_SAME_IP, CHILD_NS_SAME_IP | 2)
1\) All tags except for those specified as "Forbidden message tags" (no
instances for these test scenarios)
2\) All tags except for those specified as "Mandatory message tags"
## Test zone setup
Assumptions for the scenario specifications unless otherwise specified for the
specific scenario:
* For each scenario zone there are two name servers configured.
* Both name servers (ns1 and ns2) are equal in delegation and in zone.
* Both name servers are in-bailiwick.
* Both name servers have both IPv4 and IPv6 addresses.
* All addresses are distinct.
* All required glue are present in the delegation.
* All glue exactly matches the authoritative address records in correct zone
(not more and not less records).
* All name server IP addresses respond with identical zone content.
### ALL-DISTINCT-1
This is the happy path.
* Zone: all-distinct-1.delegation02.xa
### ALL-DISTINCT-2
This is also a happy path. Out-of-bailiwick.
* Zone: all-distinct-2.delegation02.xa
* Both ns1 and ns2 are out-of-bailiwick under the xb tree.
* ns1 is "ns1.all-distinct-2.delegation02.xb"
* ns2 is "ns2.all-distinct-2.delegation02.xb"
* Delegation is without glue.
* The test zone has no address records for the name server names.
* The "delegation02.xb" zone has full set of address records for this scenario.
### ALL-DISTINCT-3
This is also a happy path. Also out-of-bailiwick, but with sibling glue.
* Zone: all-distinct-3.delegation02.xa
* Both ns1 and ns2 are out-of-bailiwick
* ns1 is "ns1.all-distinct-3.sibling.delegation02.xa"
* ns2 is "ns2.all-distinct-3.sibling.delegation02.xa"
* Delegation is with glue.
* The test zone ("child") has no address records for the name server names.
* The "delegation02.xa" zone has full set of address records for this scenario.
### DEL-NON-DISTINCT
The glue records use the same IP addresses.
* Zone: del-non-distinct.delegation02.xa
* The name servers are ns1a and ns1b
* ns1a and ns1b in the delegation (glue) have the same IPv4 and IPv6
addresses, respectively.
* ns1a and ns1b have distinct addresses in the zone (IPv4 and IPv6,
respectively).
### DEL-NON-DISTINCT-UND
The glue records use the same IP addresses. The zone is undelegated.
* Zone: del-non-distinct-und.delegation02.xa
* The zone is undelegated.
* name servers are ns1a and ns1b
* ns1a and ns1b in the delegation (glue) have the same IPv4 and IPv6
addresses, respectively.
* ns1a and ns1b have distinct addresses in the zone (IPv4 and IPv6,
respectively).
* Undelegated data:
* ns1a.del-non-distinct-und.delegation02.xa/IPv4
* ns1a.del-non-distinct-und.delegation02.xa/IPv6
* ns1b.del-non-distinct-und.delegation02.xa/IPv4
* ns1b.del-non-distinct-und.delegation02.xa/IPv6
### CHILD-NON-DISTINCT
The address records in the zone use the same IP addresses.
* Zone: child-non-distinct.delegation02.xa
* name servers are ns1a and ns1b
* ns1a and ns1b in the delegation (glue) have distinct addresses (IPv4 and
IPv6, respectively).
* ns1a and ns1b have the same addresses in the zone, IPv4 and IPv6,
respectively.
### CHILD-NON-DISTINCT-UND
The address records in the zone use the same IP addresses.
* Zone: child-non-distinct-und.delegation02.xa
* The zone is undelegated.
* name servers are ns1a and ns1b
* ns1a and ns1b in the delegation (glue) have distinct addresses (IPv4 and
IPv6, respectively).
* ns1a and ns1b have the same addresses in the zone, IPv4 and IPv6,
respectively.
* Undelegated data:
* ns1a.child-non-distinct-und.delegation02.xa/IPv4
* ns1a.child-non-distinct-und.delegation02.xa/IPv6
* ns1b.child-non-distinct-und.delegation02.xa/IPv4
* ns1b.child-non-distinct-und.delegation02.xa/IPv6
### NON-DISTINCT-1
The address records in both delegation and zone use the same IP addresses.
* Zone: non-distinct-1.delegation02.xa
* name servers are ns1a, ns1b and ns2
* ns1a and ns1b in the delegation (glue) have the same IPv4 and IPv6
addresses, respectively.
* ns1a and ns1b have the same addresses in the zone, IPv4 and IPv6,
respectively.
* ns2 has a distinct address both in delegation and in zone.
### NON-DISTINCT-2
The name servers in both delegation and zone refer to the same IP addresses. The
names are out-of-bailiwick.
* Zone: non-distinct-2.delegation02.xa
* name servers are ns1a, ns1b and ns2, and are out-of-bailiwick under the xb
tree.
* ns1a is "ns1a.non-distinct-2.delegation02.xb"
* ns1b is "ns1a.non-distinct-2.delegation02.xb"
* ns2 is "ns2.non-distinct-2.delegation02.xb"
* Delegation is without glue.
* ns1a and ns1b have the same addresses, IPv4 and IPv6, respectively.
* ns2 has distinct addresses (IPv4 and IPv6).
* The test zone has no address records for the name server names.
* The "delegation02.xb" zone has full set of address records for this scenario.
### NON-DISTINCT-3
The name servers in both delegation and zone refer to the same IP addresses. The
names are out-of-bailiwick, but with sibling glue.
* Zone: non-distinct-3.delegation02.xa
* name servers are ns1a, ns1b and ns2, and are out-of-bailiwick.
* ns1a is "ns1a.non-distinct-3.sibling.delegation02.xa"
* ns1b is "ns1a.non-distinct-3.sibling.delegation02.xa"
* ns2 is "ns2.non-distinct-3.sibling.delegation02.xa"
* Delegation has sibling glue.
* ns1a and ns1b have the same addresses, IPv4 and IPv6, respectively.
* ns2 has distinct addresses (IPv4 and IPv6).
* The test zone has no address records for the name server names.
* The "delegation02.xa" zone has full set of address records for this scenario.
[Delegation02]: ../../tests/Delegation-TP/delegation02.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[test scenario README file]: ../README.md
[Test zone setup]: #test-zone-setup

124
zonemaster/docs/public/specifications/test-zones/Delegation-TP/delegation03.md Normal file
View File

@@ -0,0 +1,124 @@
# Specification of test Scenarios for Delegation03
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test zone setup]
## Background
See the [test scenario README file].
## Test Case
This document specifies test scenarios for test case [Delegation03].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are output when [Delegation03] is run on a test zone.
The message tags are defined in the test case ([Delegation03]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`delegation03.xa`) and that subdomain having the same name as the
scenario. The names of those zones are given in section
[Test zone setup] below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [Delegation03] for the specification of the tags.
* REFERRAL_SIZE_OK
* REFERRAL_SIZE_TOO_LARGE
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:-----------------------------|:-----------------------------------------|:-------------------------------------------
REFERRAL-SIZE-OK-1 | REFERRAL_SIZE_OK | 2)
REFERRAL-SIZE-OK-2 | REFERRAL_SIZE_OK | 2)
REFERRAL-SIZE-TOO-LARGE-1 | REFERRAL_SIZE_TOO_LARGE | 2)
REFERRAL-SIZE-TOO-LARGE-2 | REFERRAL_SIZE_TOO_LARGE | 2)
1\) All tags except for those specified as "Forbidden message tags" (no
instances for these test scenarios)
2\) All tags except for those specified as "Mandatory message tags"
## Test zone setup
Assumptions for the scenario specifications unless otherwise specified for the
specific scenario:
* For each scenario zone there are two name server configured.
* Both name servers are in-bailiwick.
* Both name servers have both IPv4 and IPv6 addresses.
* All addresses are distinct.
* All required glue are present in the delegation.
* There is no actual zone or zone file, only a delegation.
* For these scenarios only the delegation is needed.
### REFERRAL-SIZE-OK-1
This is the happy path.
* Zone: referral-size-ok-1.delegation03.xa.
### REFERRAL-SIZE-OK-2
Referral is large, but not too large. The name servers are in-bailiwick.
* Zone: referral-size-ok-2.delegation03.xa.
* ns1 is "ns1.ipv4-large-but-not-too-large.referral-size-ok-2.delegation03.xa".
* ns1 is "ns1.ipv6-large-but-not-too-large.referral-size-ok-2.delegation03.xa".
* ns2 is "ns2.ipv4-large-but-not-too-large.referral-size-ok-2.delegation03.xa".
* ns2 is "ns2.ipv6-large-but-not-too-large.referral-size-ok-2.delegation03.xa".
### REFERRAL-SIZE-TOO-LARGE-1
Referral is too large and name servers are in-bailiwick.
* Zone: referral-size-too-large-1.delegation03.xa
* Name server names are relative to the zone name:
* ns1 is "ns1.1abcdefghijklmnopqrstuv.1defghijkl"
* ns2 is "ns2.2abcdefghijklmnopqrstuv.2defghijkl"
* ns3 is "ns3.2abcdefghijklmnopqrstuv.3defghijkl"
* ns4 is "ns4.2abcdefghijklmnopqrstuv.4defghijkl"
* ns5 is "ns5.2abcdefghijklmnopqrstuv.5defghijkl"
### REFERRAL-SIZE-TOO-LARGE-2
Referral is too large and name servers are out-of-bailiwick with no glue.
* Zone: referral-size-too-large-2.delegation03.xa
* The zone is delegated to ns1, ns2, ns3 and ns4.
* ns1 is "ns1.1abcdefghijklmnopqrstuvwxyz.1abcdefghijklmnopqrstuvwxy.1abcdefghijklmnopqrstuvw.referral-size-too-large-2.delegation03.xb"
* ns2 is "ns2.2abcdefghijklmnopqrstuvwxyz.2abcdefghijklmnopqrstuvwxy.2abcdefghijklmnopqrstuvw.referral-size-too-large-2.delegation03.xb"
* ns3 is "ns3.3abcdefghijklmnopqrstuvwxyz.3abcdefghijklmnopqrstuvwxy.3abcdefghijklmnopqrstuvw.referral-size-too-large-2.delegation03.xb"
* ns4 is "ns4.4abcdefghijklmnopqrstuvwxyz.4abcdefghijklmnopqrstuvwxy.4abcdefghijklmnopqrstuvw.referral-size-too-large-2.delegation03.xb"
* Delegation is without glue.
* The test zone has no address records for the name server names.
* The "delegation03.xb" zone has full set of address records (IPv4 and IPv6).
[Delegation03]: ../../tests/Delegation-TP/delegation03.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[test scenario README file]: ../README.md
[Test zone setup]: #test-zone-setup

18
zonemaster/docs/public/specifications/test-zones/Engine/README.md Normal file
View File

@@ -0,0 +1,18 @@
# Specification of test scenarios for Zonemaster-Engine Perl modules
This document structure contains test scenario specifications for
Zonemaster-Engine Perl Modules, except for test scenarios for [Test Case]
implementations and implementation of [MethodsV2], which are found in sibling
structures.
The test scenarios found here are for various Perl modules. The specifications
are split by Perl module, and sometimes further split by area.
The following specifications are available:
* [Recursor-PM](Recursor-PM/README.md)
[Test Case]: ../../tests/README.md
[MethodsV2]: ../../tests/MethodsV2.md

320
zonemaster/docs/public/specifications/test-zones/Engine/Recursor-PM/CNAME.md Normal file
View File

@@ -0,0 +1,320 @@
# Specification of test zones for the CNAME functions in Recursor.pm
## Table of contents
* [Background](#background)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
## Background
See the [test zone README file] which is for test case base test zones. Since
this specifies test zones for code it is not fully applicable.
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
the code should be tested.
## Test zone name
The test zone for these scenarios is `cname.recursor.engine.xa`. Subdomain and
subzones are created. The names are given in section
"[Zone setup for test scenarios]" below.
## Test scenarios
Scenario name | Expected output
:----------------------------|:---------------------------------------------------------------------------------------------
GOOD-CNAME-1 | True and tags `CNAME_START`, `CNAME_FOLLOWED_IN_ZONE`
GOOD-CNAME-2 | True and tags `CNAME_START`, `CNAME_FOLLOWED_IN_ZONE`
GOOD-CNAME-CHAIN | True and tags `CNAME_START`, `CNAME_FOLLOWED_IN_ZONE`
GOOD-CNAME-OUT-OF-ZONE | True and tags `CNAME_START`, `CNAME_FOLLOWED_OUT_OF_ZONE`
NXDOMAIN-VIA-CNAME | True and tags `CNAME_START`, `CNAME_FOLLOWED_OUT_OF_ZONE`
NODATA-VIA-CNAME | True and tags `CNAME_START`, `CNAME_FOLLOWED_OUT_OF_ZONE`
MULT-CNAME | Undefined and tags `CNAME_START`, `CNAME_MULTIPLE_FOR_NAME`
LOOPED-CNAME-IN-ZONE-1 | Undefined and tags `CNAME_START`, `CNAME_LOOP_INNER`
LOOPED-CNAME-IN-ZONE-2 | Undefined and tags `CNAME_START`, `CNAME_LOOP_INNER`
LOOPED-CNAME-IN-ZONE-3 | Undefined and tags `CNAME_START`, `CNAME_LOOP_INNER`
LOOPED-CNAME-OUT-OF-ZONE | Undefined and tags `CNAME_START`, `CNAME_LOOP_OUTER`
TOO-LONG-CNAME-CHAIN | Undefined and tags `CNAME_START`, `CNAME_RECORDS_TOO_MANY`
TARGET-NO-MATCH-CNAME | Undefined and tags `CNAME_START`, `CNAME_NO_MATCH`
BROKEN-CNAME-CHAIN | Undefined and tags `CNAME_START`, `CNAME_RECORDS_CHAIN_BROKEN`
WRONG-CNAME-OWNER-NAME | False and no tags
EXTRA-CNAME-IN-ANSWER | False and no tags
## Zone setup for test scenarios
Assumptions for the scenario specifications, unless stated otherwise for the
specific scenario:
* The `cname.recursor.engine.xa` zone is used for all scenarios.
* Relative names are under `cname.recursor.engine.xa.`.
* The query name is given by the scenario.
* Query type is assumed to be `A`.
* In the zone, the query name always has a `CNAME` record.
* The zone is set up on one NS, ns1.
* The [RCODE Name] in the response is NoError.
### GOOD-CNAME-1
The query name will resolve to one `A` record via one CNAME.
* Query name: "good-cname-1.cname.recursor.engine.xa"
* To be found in the answer section:
```
good-cname-1 CNAME good-cname-1-target
good-cname-1-target A 127.0.0.1
```
### GOOD-CNAME-2
The query name will resolve to two `A` record via one CNAME.
* Query name: "good-cname-2.cname.recursor.engine.xa"
* To be found in the answer section:
```
good-cname-2 CNAME good-cname-2-target
good-cname-2-target A 127.0.0.1
good-cname-2-target A 127.0.0.2
```
### GOOD-CNAME-CHAIN
The query name will resolve to two `A` record via three CNAME.
* Query name: "good-cname-chain.cname.recursor.engine.xa"
* To be found in the answer section:
```
good-cname-chain CNAME good-cname-chain-two
good-cname-chain-two CNAME good-cname-chain-three
good-cname-chain-three CNAME good-cname-chain-target
good-cname-chain-target A 127.0.0.1
```
### GOOD-CNAME-OUT-OF-ZONE
The query name will resolve to an `A` record via a CNAME in the zone with a
target that points at a subzone, and a delegation to that sub zone.
* For all queries
* The two zones, `cname.recursor.engine.xa` and
`goodsub.cname.recursor.engine.xa`, are hosted on different IP addresses.
* "x", "y" and "z" in the IP addresses in the configuration below are to be
set in the configuration of the test zones.
* Query name: "good-cname-out-of-zone.cname.recursor.engine.xa"
* Servers: NS of `cname.recursor.engine.xa`.
* Answer, authority and additional sections, respectively, to be found in the
response:
```
;; ANSWER SECTION:
good-cname-out-of-zone CNAME target.goodsub
;; AUTHORITY SECTION:
goodsub NS ns1.goodsub
;; ADDITIONAL SECTION:
ns1.goodsub A 127.x.y.z
ns1.goodsub AAAA fda1:b2:c3::127:x:y:z
```
* Query name: "target.goodsub.cname.recursor.engine.xa"
* Servers: NS of `goodsub.cname.recursor.engine.xa`.
* To be found in the answer section:
```
target.goodsub A 127.0.0.1
```
### NXDOMAIN-VIA-CNAME
The query name exists, but as CNAME record. The target name of CNAME does not
exist.
* Query name: "nxdomain-via-cname.cname.recursor.engine.xa"
* The [RCODE Name] in the response is NxDomain.
* The target of the CNAME, `nxdomain-via-cname-target` does not exist in the
zone and is not delegated.
* SOA of "cname.recursor.engine.xa" to be found in authority section.
* To be found in the answer section:
```
nxdomain-via-cname CNAME nxdomain-via-cname-target
```
### NODATA-VIA-CNAME
The query name exists, but as CNAME record. The target name of CNAME exists, but
not with any A record.
* Query name: "nodata-via-cname.cname.recursor.engine.xa"
* The target of the CNAME, `nodata-via-cname-target`, exists in the zone but
has neither `A` or `CNAME` record, and is not delegated.
* SOA of "cname.recursor.engine.xa" to be found in authority section.
* To be found in the answer section:
```
nodata-via-cname CNAME nodata-via-cname-target
```
### MULT-CNAME
The query name exists, but as CNAME, as two CNAME records.
* Query name: "mult-cname.cname.recursor.engine.xa"
* To be found in the answer section:
```
mult-cname CNAME mult-cname-target-1
mult-cname CNAME mult-cname-target-2
mult-cname-target-1 A 127.0.0.1
mult-cname-target-2 A 127.0.0.2
```
## LOOPED-CNAME-IN-ZONE-1
The query name will point at a CNAME record with the same target as owner name.
* Query name: "looped-cname-in-zone-1.cname.recursor.engine.xa"
* To be found in the answer section:
```
looped-cname-in-zone-1 CNAME looped-cname-in-zone-1
```
## LOOPED-CNAME-IN-ZONE-2
The query name will point at a CNAME, which points at a second CNAME,
which points to a third CNAME whose target name is the same as the
owner name of the second CNAME.
* Query name: "looped-cname-in-zone-2.cname.recursor.engine.xa"
* To be found in the answer section:
```
looped-cname-in-zone-2 CNAME looped-cname-in-zone-2-a
looped-cname-in-zone-2-a CNAME looped-cname-in-zone-2-b
looped-cname-in-zone-2-b CNAME looped-cname-in-zone-2-a
```
## LOOPED-CNAME-IN-ZONE-3
The query name will point at a CNAME, which points at a second CNAME whose target
name is the same as the owner name of the first CNAME.
* Query name: "looped-cname-in-zone-3.cname.recursor.engine.xa"
* To be found in the answer section:
```
looped-cname-in-zone-3 CNAME looped-cname-in-zone-3-next
looped-cname-in-zone-3-next CNAME looped-cname-in-zone-3
```
## LOOPED-CNAME-OUT-OF-ZONE
The query name will point at a CNAME record, but in a sub zone, and the target
name of the CNAME record will point at another CNAME record in another sub zone,
and the target name of the second CNAME record will point at the first.
* For all four queries
* The three zones `cname.recursor.engine.xa`, `sub2.cname.recursor.engine.xa`
and `sub3.cname.recursor.engine.xa` are hosted on different IP addresses.
* "x", "y" and "z" in the IP addresses in the configuration below are to be
set in the configuration of the test zones.
* Query name: "looped-cname-out-of-zone.sub2.cname.recursor.engine.xa"
* Servers: NS of `cname.recursor.engine.xa`.
* Authority and additional sections, respectively, to be found in the
response:
```
;; AUTHORITY SECTION:
sub2 NS ns1.sub2
;; ADDITIONAL SECTION:
ns1.sub2 A 127.x.y.z
ns1.sub2 AAAA fda1:b2:c3::127:x:y:z
```
* Query name: "looped-cname-out-of-zone.sub2.cname.recursor.engine.xa"
* Servers: NS of `sub2.cname.recursor.engine.xa`.
* To be found in the answer section:
```
looped-cname-out-of-zone.sub2 CNAME looped-cname-out-of-zone.sub3
```
* Query name: "looped-cname-out-of-zone.sub3.cname.recursor.engine.xa"
* Servers: NS of `cname.recursor.engine.xa`.
* Relative names are under `cname.recursor.engine.xa.`.
* Authority and additional sections, respectively, to be found in the
response:
```
;; AUTHORITY SECTION:
sub3 NS ns1.sub3
;; ADDITIONAL SECTION:
ns1.sub3 A 127.x.y.z
ns1.sub3 AAAA fda1:b2:c3::127:x:y:z
```
* Query name: "looped-cname-out-of-zone.sub3.cname.recursor.engine.xa"
* Servers: NS of `sub3.cname.recursor.engine.xa`.
* To be found in the answer section:
```
looped-cname-out-of-zone.sub3 CNAME looped-cname-out-of-zone.sub2
```
### TOO-LONG-CNAME-CHAIN
The query name will resolve to one `A` record via ten CNAME records which is
above the limit.
* Query name: "too-long-cname-chain.cname.recursor.engine.xa"
* To be found in the answer section:
```
too-long-cname-chain CNAME too-long-cname-chain-two
too-long-cname-chain-two CNAME too-long-cname-chain-three
too-long-cname-chain-three CNAME too-long-cname-chain-four
too-long-cname-chain-four CNAME too-long-cname-chain-five
too-long-cname-chain-five CNAME too-long-cname-chain-six
too-long-cname-chain-six CNAME too-long-cname-chain-seven
too-long-cname-chain-seven CNAME too-long-cname-chain-eight
too-long-cname-chain-eight CNAME too-long-cname-chain-nine
too-long-cname-chain-nine CNAME too-long-cname-chain-ten
too-long-cname-chain-ten CNAME too-long-cname-chain-target
too-long-cname-chain-target A 127.0.0.1
```
### TARGET-NO-MATCH-CNAME
The CNAME target name does not match the owner name of the `A` record.
* Query name: "target-no-match-cname.cname.recursor.engine.xa"
* To be found in the answer section:
```
target-no-match-cname CNAME target-no-match-cname-two
target-no-match-cname-target A 127.0.0.1
```
### BROKEN-CNAME-CHAIN
The CNAME chain is broken between first and second CNAME records.
* Query name: "broken-cname-chain.cname.recursor.engine.xa"
* To be found in the answer section:
```
broken-cname-chain CNAME broken-cname-chain-two
broken-cname-chain-three CNAME broken-cname-chain-target
broken-cname-chain-target A 127.0.0.1
```
### WRONG-CNAME-OWNER-NAME
The owner name of the CNAME in the response does not match query name.
* Query name: "wrong-cname-owner-name.cname.recursor.engine.xa"
* To be found in the answer section:
```
wrong-cname-owner-name-1 CNAME wrong-cname-owner-name-target
wrong-cname-owner-name-target A 127.0.0.1
```
### EXTRA-CNAME-IN-ANSWER
There is an extra CNAME record with an owner name not matching the query name
besides the `A` record matching query name.
* Query name: "extra-cname-in-answer.cname.recursor.engine.xa"
* To be found in the answer section:
```
extra-cname-in-answer A 127.0.0.1
extra-cname-in-answer-1 CNAME extra-cname-in-answer-2
```
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../../README.md
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

6
zonemaster/docs/public/specifications/test-zones/Engine/Recursor-PM/README.md Normal file
View File

@@ -0,0 +1,6 @@
# Specification of test scenarios for Recursor.pm Perl module
The following specifications are available:
* [CNAME](CNAME.md)

29
zonemaster/docs/public/specifications/test-zones/MethodsV2/README.md Normal file
View File

@@ -0,0 +1,29 @@
# Specification of test scenarios for MethodsV2
This document structure contains test scenario specifications for [MethodsV2],
which is not a Test Case module. Instead it is a collection of Method
specifications referred to by the Test Case specifications and implemented by
Perl methods used in the implementations of the Test Cases.
The purpose of the test scenarios for [MethodsV2] is to verify that the
implementation of the methods matches the specifications.
Test scenarios specification for the following methods are available:
* [Get parent NS IP addresses]
* [Get delegation NS names and IP addresses]
* [Get zone NS names and IP addresses]
Test scenarios specification:
* [Specification of test scenarios for MethodsV2](methodsv2.md)
Test scenarios for [Test Case] implementations and test scenarios for Perl
modules in Zonemaster-Engine are not in this structure. Instead they can
be found in sibling structures.
[Get delegation NS names and IP addresses]: ../../tests/MethodsV2.md#method-get-delegation-ns-names-and-ip-addresses
[Get parent NS IP addresses]: ../../tests/MethodsV2.md#method-get-parent-ns-ip-addresses
[Get zone NS names and IP addresses]: ../../tests/MethodsV2.md#method-get-zone-ns-names-and-ip-addresses
[MethodsV2]: ../../tests/MethodsV2.md
[Test Case]: ../../tests/README.md

695
zonemaster/docs/public/specifications/test-zones/MethodsV2/methodsv2.md Normal file
View File

@@ -0,0 +1,695 @@
# Specification of test scenarios for MethodsV2
## Table of contents
* [Background](#background)
* [Test scenarios](#test-scenarios)
* [Public methods](#public-methods)
* [Test zone names](#test-zone-names)
* [Test scenarios and setup of test zones]
## Background
See the [test zone README file] which is for test case base test zones. Since
this document specifies test zones for a [MethodsV2] Method, it is not fully
applicable.
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts for the
Methods. See [the implementation of the scenarios] for the latest version of the
implementation of the MethodsV2 scenarios.
## Public methods
[MethodsV2] provides the following public methods:
* For parent zone:
* Get parent NS names and IP addresses
* Get parent NS IP addresses
* For delegation:
* Get delegation NS names and IP addresses
* Get delegation NS IP addresses
* Get delegation NS names
* For zone information:
* Get zone NS names and IP addresses
* Get zone NS names
* Get zone NS IP addresses
### Data type
All methods can return one of the following data types:
* Empty set
* Non-empty set
* Undefined set
The non-empty set from the following methods consists of unique IP addresses,
IPv4, IPv6 or both (e.g "127.40.4.21" and "fda1:b2:c3::21" are valid):
* Get parent NS IP addresses
* Get delegation NS IP addresses
* Get zone NS IP addresses
The non-empty set from the following methods consists of unique name server
names (e.g. "ns1.example.xa" and "ns2.example.xb" are valid):
* Get delegation NS names
* Get zone NS names
The non-empty set from the following methods consists of unique pairs of name
server name and its IP address (IPv4 or IPv6). The IP address cannot be blank
(e.g. "ns1.example.xa/127.40.4.21" and "ns1.example.xa/fda1:b2:c3::21" are
valid but "ns1.example.xa" is not):
* Get parent NS names and IP addresses
The non-empty set from the following methods consists of unique pairs of name
server name and its IP address (IPv4 or IPv6). The IP address can be left blank
(e.g. "ns1.example.xa/127.40.4.21", "ns1.example.xa/fda1:b2:c3::21" and
"ns1.example.xa" are valid):
* Get delegation NS names and IP addresses
* Get zone NS names and IP addresses
### Data defined for the scenarios
Both *Get delegation NS IP addresses* and *Get delegation NS names* can be
derived from *Get delegation NS names and IP addresses*.
Both *Get zone NS IP addresses* and *Get zone NS names* can be derived from
*Get zone NS names and IP addresses*.
*Get parent NS IP addresses* can be derived from *Get parent NS names and IP
addresses*.
Consequently, for the scenarios defined in this document the expected data is only
defined for the following three methods:
* Get parent NS names and IP addresses
* Get delegation NS names and IP addresses
* Get zone NS names and IP addresses
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`methodsv2.xa`) and that subdomain having the same name as
the specific scenario. The names of those zones are given in section
"[Test scenarios and setup of test zones]" below.
## Test scenarios and setup of test zones
### Default zone configuration
Assumptions for the scenario specifications unless otherwise specified for
the specific scenario:
* The child zone is `child.parent.SCENARIO.methodsv2.xa`.
* It is served by two IB (in-bailiwick) NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* The delegation from the parent has the same NS with complete glue.
* The parent zone is `parent.SCENARIO.methodsv2.xa`.
* It is served by two IB NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* The delegation from the grandparent has the same NS with complete glue.
* The grandparent zone is `SCENARIO.methodsv2.xa`.
* It is served by two IB NS (ns1 and ns2).
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* The delegation from the SCENARIO zoen has the same NS with complete glue.
* Responds with a A record for the zone on query for A.
* Responds with a AAAA record for the zone on query for AAAA.
* All responses are authoritative with [RCODE Name] "NoError".
* EDNS, version 0, is included in all responses on queries with EDNS.
* EDNS is not included in responses on queries without EDNS.
* Standard root is used.
* In all cases, delegation and zone are consistent.
* Same NS
* Any required glue matches address records in zone. No extra address
records.
### GOOD-1
A "happy path". Everything is fine.
* Zone: child.parent.good-1.methodsv2.xa
* Just defaults
### GOOD-2
A "happy path". Everything is fine. Child has out-of-bailiwick name servers
only.
* Zone: child.parent.good-2.methodsv2.xa
* Child NS are out-of-bailiwick but not shared with grandparent zone.
* ns5.good-2.methodsv2.xa
* ns6.good-2.methodsv2.xa
* No glue
### GOOD-3
A "happy path". Everything is fine. Child has both in-bailiwick and
out-of-bailiwick name servers.
* Zone: child.parent.good-3.methodsv2.xa
* Child NS:
* ns1.child.parent.good-3.methodsv2.xa
* ns3.parent.good-3.methodsv2.xa
* ns5.good-3.methodsv2.xa (not shared with grandparent zone).
* Glue:
* Address records (A and AAAA) for
* ns1.child.parent.good-3.methodsv2.xa
* ns3.parent.good-3.methodsv2.xa (optional)
### GOOD-4
A "happy path". Everything is fine. Parent zone is also hosted on grandparent
server.
* Zone: child.parent.good-4.methodsv2.xa
* Parent NS:
* ns1.parent.good-4.methodsv2.xa
* ns2.parent.good-4.methodsv2.xa
* ns1.good-4.methodsv2.xa (shared with grandparent zone).
* Glue for parent:
* Address records (A and AAAA) for
* ns1.parent.good-4.methodsv2.xa
* ns2.parent.good-4.methodsv2.xa
* ns1.good-4.methodsv2.xa (optional)
### GOOD-5
A "happy path". Everything is fine. Child zone is hosted also on grandparent
server and parent server.
* Zone: child.parent.good-5.methodsv2.xa
* Child NS:
* ns1.child.parent.good-5.methodsv2.xa
* ns2.child.parent.good-5.methodsv2.xa
* ns1.good-5.methodsv2.xa (shared with grandparent zone).
* ns1.parent.good-5.methodsv2.xa (shared with parent zone).
* Glue:
* Address records (A and AAAA) for
* ns1.child.parent.good-5.methodsv2.xa
* ns2.child.parent.good-5.methodsv2.xa
* ns1.parent.good-5.methodsv2.xa (optional)
### GOOD-6
A "happy path". Everything is fine. Child zone is only hosted on grandparent
servers.
* Zone: child.parent.good-6.methodsv2.xa
* Child NS (both shared with grandparent zone):
* ns1.good-6.methodsv2.xa
* ns2.good-6.methodsv2.xa
* No glue.
### GOOD-7
A "happy path". Everything is fine. Child zone is only hosted on parent
servers.
* Zone: child.parent.good-7.methodsv2.xa
* Child NS (both shared with parent zone):
* ns1.parent.good-7.methodsv2.xa
* ns2.parent.good-7.methodsv2.xa
* Glue:
* Address records (A and AAAA) for
* ns1.parent.good-7.methodsv2.xa (optional)
* ns2.parent.good-7.methodsv2.xa (optional)
### GOOD-UNDEL-1
A "happy path". Everything is fine. Child has both in-bailiwick and
out-of-bailiwick name servers. Child is delegated but is tested
undelegated.
* Zone: child.parent.good-undel-1.methodsv2.xa
* Delegation:
* Child NS:
* ns1-2.child.parent.good-undel-1.methodsv2.xa
* ns3.parent.good-undel-1.methodsv2.xa (not shared with parent zone)
* ns5.good-undel-1.methodsv2.xa (not shared with grandparent zone)
* Glue:
* Adress records (A and AAAA) for
* ns1-2.child.parent.good-undel-1.methodsv2.xa
* ns3.parent.good-undel-1.methodsv2.xa (optional)
* There is an undelegated version of the zone matching undelegated data.
* `ns1-2` have different IP addresses for delegation and delegated zone, on one
hand, and undelegated data and undelegated version of the zone, on the other.
* `ns3.parent.good-undel-1.methodsv2.xa` is shared between delegated zone and
undelegated version of zone, but holding the data of the undelegated version.
* Undelegated data:
* ns1-2.child.parent.good-undel-1.methodsv2.xa/IPv4
* ns1-2.child.parent.good-undel-1.methodsv2.xa/IPv6
* ns3.parent.good-undel-1.methodsv2.xa/IPv4
* ns3.parent.good-undel-1.methodsv2.xa/IPv6
* ns6.good-undel-1.methodsv2.xa
### GOOD-UNDEL-2
A "happy path". Everything is fine. Child has both in-bailiwick and
out-of-bailiwick name servers. Child is not delegated but is tested
undelegated.
* Zone: child.parent.good-undel-2.methodsv2.xa
* No delegation from parent.
* To be tested with undelegated data:
* There is an undelegated version of the zone matching undelegated data.
* Undelegated data:
* ns1.child.parent.good-undel-2.methodsv2.xa/IPv4
* ns1.child.parent.good-undel-2.methodsv2.xa/IPv6
* ns3.parent.good-undel-2.methodsv2.xa/IPv4
* ns3.parent.good-undel-2.methodsv2.xa/IPv6
* ns6.good-undel-2.methodsv2.xa
### DIFF-NS-1
No match in name server names between delegation and zone. Same name server IP.
* Zone: child.parent.diff-ns-1.methodsv2.xa
* Delegation to ns1 and ns2.
* NS in zone ns1-2 and ns2-2.
* ns1-2 and ns2-2 in zone, ns1 and ns2 not in zone.
### DIFF-NS-2
No match in name server names between delegation and zone. Same name server IP on
one server. Different on the other. No zone on servers from delegation except
ns1.
* Zone: child.parent.diff-ns-2.methodsv2.xa
* Delegation to ns1 and ns2.
* NS in zone ns1-2, ns3.
* ns1-2 and ns3 in zone, ns1 and ns2 not in zone.
* No zone on ns2.
* ns1 and ns1-2 have the same IP.
### IB-NOT-IN-ZONE-1
Delegation has in-bailiwick NS, but the names are not defined in the zone.
* Zone: child.parent.ib-not-in-zone-1.methodsv2.xa
* ns1 and ns2 not defined in zone.
### CHILD-NO-ZONE-1
* Zone: child.parent.child-no-zone-1.methodsv2.xa
* No child zone on ns1 and ns2.
* Response SERVFAIL.
### CHILD-NO-ZONE-2
* Zone: child.parent.child-no-zone-2.methodsv2.xa
* No response from ns1 and ns2 of the child.
### GOOD-MIXED-UNDEL-1
The child zone is delegated, but there is also an undelegated version which is
the one tested. One grandparent server, in the delegated tree, also serves
parent zone.
* Zone: child.parent.good-mixed-undel-1.methodsv2.xa
* Grandparent zone `good-mixed-undel-1.methodsv2.xa` is served on `ns1` and
`ns4`.
* Parent zone `parent.good-mixed-undel-1.methodsv2.xa` is served by `ns1`,
`ns2` and `ns4.good-mixed-undel-1.methodsv2.xa`.
* Child zone is delegated, but there is also an undelegated version where
the zone has the same data as the delegation.
* Undelegated data:
* ns3.child.parent.good-mixed-undel-1.methodsv2.xa/IPv4
* ns3.child.parent.good-mixed-undel-1.methodsv2.xa/IPv6
* ns4.child.parent.good-mixed-undel-1.methodsv2.xa/IPv4
* ns4.child.parent.good-mixed-undel-1.methodsv2.xa/IPv6
### GOOD-MIXED-UNDEL-2
The child zone is delegated, but there is also an undelegated version. One parent
server also serves the delegated child zone.
* Zone: child.parent.good-mixed-undel-2.methodsv2.xa
* Parent zone `parent.good-mixed-undel-2.methodsv2.xa` is served by `ns1` and
`ns2`.
* Child zone is served by `ns1`, `ns2` and
`ns2.parent.good-mixed-undel-2.methodsv2.xa`.
* Child zone is delegated, but there is also an undelegated version where the
zone has the same data as the delegation.
* Undelegated data:
* ns3.child.parent.good-mixed-undel-2.methodsv2.xa/IPv4
* ns3.child.parent.good-mixed-undel-2.methodsv2.xa/IPv6
* ns4.child.parent.good-mixed-undel-2.methodsv2.xa/IPv4
* ns4.child.parent.good-mixed-undel-2.methodsv2.xa/IPv6
### NO-DEL-MIXED-UNDEL-1
The child zone is not delegated, but there is an undelegated version that is
tested. One grandparent server also serves the parent zone.
* Zone: child.parent.no-del-mixed-undel-1.methodsv2.xa
* Parent zone `parent.no-del-mixed-undel-1.methodsv2.xa` is served by `ns1`,
`ns2` and on `ns2.no-del-mixed-undel-1.methodsv2.xa`.
* Child zone is not delegated, but there is an undelegated version.
* Undelegated data:
* ns1.child.parent.no-del-mixed-undel-1.methodsv2.xa/IPv4
* ns1.child.parent.no-del-mixed-undel-1.methodsv2.xa/IPv6
* ns2.child.parent.no-del-mixed-undel-1.methodsv2.xa/IPv4
* ns2.child.parent.no-del-mixed-undel-1.methodsv2.xa/IPv6
### NO-CHILD-1
The child zone is not delegated. Parent zone returns NXDOMAIN.
* Zone: child.parent.no-child-1.methodsv2.xa
* Child zone does not exist and is not served by any NS.
### NO-CHILD-2
The child zone is not delegated. Parent zone returns NODATA.
* Zone: child.parent.no-child-2.methodsv2.xa
* Child zone does not exist is not served by any NS.
* The name child.parent.no-child-2.methodsv2.xa exists as a TXT record.
### NO-CHLD-PAR-UNDETER-1
The child zone is not delegated. One grandparent NS lacks delegation of parent
and return NXDOMAIN of child. The parent zone lacks delegation of child.
* Zone: child.parent.no-chld-par-undeter-1.methodsv2.xa
* Child zone does not exist is not served by any NS.
* Grandparent `ns1` lacks delegation of parent.
* Grandparent `ns2` has delegation of parent (to both parent NS).
* Parent zone lacks delegation of child.
### CHLD-FOUND-PAR-UNDET-1
The child zone is delegated from one grandparent NS and from the parent zone.
* Zone: child.parent.chld-found-par-undet-1.methodsv2.xa
* Grandparent `ns1` has delegation of child but lacks delegation of parent.
* Grandparent `ns2` has delegation of parent (to both parent NS).
* Parent zone has delegation of child.
### CHLD-FOUND-INCONSIST-1
The child is delegated from one parent NS. On the other there is an NXDOMAIN
response.
* Zone: child.parent.chld-found-inconsist-1.methodsv2.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child (NXDOMAIN).
### CHLD-FOUND-INCONSIST-2
The child is delegated from one parent NS. On the other there is an CNAME
response.
* Zone: child.parent.chld-found-inconsist-2.methodsv2.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, and has a CNAME on that name,
pointing at `no-child.parent.chld-found-inconsist-2.methodsv2.xa`, which has
two address records (A and AAAA) with the IP addresses of child `ns2`.
### CHLD-FOUND-INCONSIST-3
The child is delegated from one parent NS. On the other there is a CNAME
to another name, and that other name is delegated.
* Zone: child.parent.chld-found-inconsist-3.methodsv2.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, and has a CNAME on the name,
pointing at `sister.parent.chld-found-inconsist-3.methodsv2.xa`, which is
delegated to `ns6-delegated-child.methodsv2.xa` and
`ns7-delegated-child.methodsv2.xa`.
* Zone `sister` does not exist.
### CHLD-FOUND-INCONSIST-4
The child is delegated from one parent NS. On the other there is a DNAME to
another name.
* Zone: child.parent.chld-found-inconsist-4.methodsv2.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` has a DNAME on `child` pointing at
`sister.parent.chld-found-inconsist-4.methodsv2.xa` which is delegated to
`ns6-delegated-child.methodsv2.xa` and `ns7-delegated-child.methodsv2.xa`.
* Zone `sister` does not exist.
### CHLD-FOUND-INCONSIST-5
The child is delegated from one parent NS. On the other there is a NODATA
response.
* Zone: child.parent.chld-found-inconsist-5.methodsv2.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, instead `child` has two address
records (A and AAAA) with the IP addresses of child `ns2`.
### CHLD-FOUND-INCONSIST-6
The child is delegated from one parent NS, which is also NS for the child.
On the other there is an NXDOMAIN response.
* Zone: child.parent.chld-found-inconsist-6.methodsv2.xa
* Parent `ns1` has normal delegation of child to the two child NS.
* Parent `ns2` lacks delegation of child (NXDOMAIN).
* Child shares `ns1.parent.chld-found-inconsist-6.methodsv2.xa` with parent.
* Child also uses child `ns1` and `ns2`.
* Child exists with a zone.
### CHLD-FOUND-INCONSIST-7
The child is delegated from one parent NS, which is also NS for the child. On the
other there is an CNAME response.
* Zone: child.parent.chld-found-inconsist-7.methodsv2.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, and has a CNAME on that name,
pointing at `no-child.parent.chld-found-inconsist-7.methodsv2.xa`, which has
two address records (A and AAAA) with the IP addresses of child `ns2`.
* Child shares `ns1.parent.chld-found-inconsist-7.methodsv2.xa` with parent.
* Child also uses `ns2`.
* Child exists with a zone.
### CHLD-FOUND-INCONSIST-8
The child is delegated from one parent NS, which is also NS for the child. On
the other there is a CNAME to another name, and that other name is delegated.
* Zone: child.parent.chld-found-inconsist-8.methodsv2.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, and has a CNAME on the name,
pointing at `sister.parent.chld-found-inconsist-8.methodsv2.xa`, which is
`ns6-delegated-child.methodsv2.xa` and `ns7-delegated-child.methodsv2.xa`.
* Zone `sister` does not exist.
* Child shares `ns1.parent.chld-found-inconsist-8.methodsv2.xa` with parent.
* Child also uses `ns2`.
* Child exists with a zone.
### CHLD-FOUND-INCONSIST-9
The child is delegated from one parent NS, which is also NS for the child. On
the other there is a DNAME to another name.
* Zone: child.parent.chld-found-inconsist-9.methodsv2.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` has a DNAME on `child` pointing at
`sister.parent.chld-found-inconsist-9.methodsv2.xa` which is delegated to
`ns6-delegated-child.methodsv2.xa` and `ns7-delegated-child.methodsv2.xa`.
* Zone `sister` does not exist.
* Child shares `ns1.parent.chld-found-inconsist-9.methodsv2.xa` with parent.
* Child also uses `ns2`.
* Child exists with a zone.
### CHLD-FOUND-INCONSIST-10
The child is delegated from one parent NS, which is also NS for the child. On the
other there is a NODATA response.
* Zone: child.parent.chld-found-inconsist-10.methodsv2.xa
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
* Parent `ns2` lacks delegation of child, instead `child` has two address
records (A and AAAA) with the IP addresses of child `ns2`.
* Child shares `ns1.parent.chld-found-inconsist-10.methodsv2.xa` with parent.
* Child also uses `ns2`.
* Child exists with a zone.
### NO-DEL-UNDEL-NO-PAR-1
The child is not delegated, but there is undelegated data to test. Both
grandparent NS return SERVFAIL.
* Zone: child.parent.no-del-undel-no-par-1.methodsv2.xa
* Grandparent `ns1` and `ns2` both return SERVFAIL.
* No need of parent zone.
* Child zone is not delegated, but there is an undelegated version.
* Undelegated data:
* ns1.child.parent.no-del-undel-no-par-1.methodsv2.xa/IPv4
* ns1.child.parent.no-del-undel-no-par-1.methodsv2.xa/IPv6
* ns2.child.parent.no-del-undel-no-par-1.methodsv2.xa/IPv4
* ns2.child.parent.no-del-undel-no-par-1.methodsv2.xa/IPv6
### NO-DEL-UNDEL-PAR-UND-1
The child is not delegated, but there is an undelegated data to test. One
grandparent NS lacks delegation of parent and return NXDOMAIN of child. The
parent zone lacks delegation of child.
* Zone: child.parent.no-del-undel-par-und-1.methodsv2.xa
* Child zone does not exist is not served by any NS.
* Grandparent `ns1` has delegation of parent (to both parent NS).
* Grandparent `ns2` lacks delegation of parent.
* Parent zone lacks delegation of child.
* Child zone is not delegated, but there is an undelegated version.
* Undelegated data:
* ns1.child.no-del-undel-par-und-1.methodsv2.xa/IPv4
* ns1.child.no-del-undel-par-und-1.methodsv2.xa/IPv6
* ns2.child.no-del-undel-par-und-1.methodsv2.xa/IPv4
* ns2.child.no-del-undel-par-und-1.methodsv2.xa/IPv6
### NO-CHLD-NO-PAR-1
The child is not delegated. Both grandparent NS return SERVFAIL.
* Zone: child.parent.no-chld-no-par-1.methodsv2.xa
* Grandparent `ns1` and `ns2` both return SERVFAIL.
* No need of parent zone.
* Child zone is not delegated, and there is no undelegated data.
* No need of child zone.
### CHILD-ALIAS-1
The child zone does not exist, instead there is a DNAME in the parent zone.
* Zone: child.parent.child-alias-1.methodsv2.xa
* Parent has a DNAME on `child` pointing at
`sister.parent.child-alias-1.methodsv2.xa` which is delegated to
`ns6-delegated-child.methodsv2.xa` and `ns7-delegated-child.methodsv2.xa`.
* Zone `sister` does not exist.
### ZONE-ERR-GRANDPARENT-1
Grandparent `ns2` responds with AA bit unset on queries for grandparent zone.
* Zone: child.parent.zone-err-grandparent-1.methodsv2.xa
* Normal response on grandparent `ns1`.
* Grandparent `ns2` responds with AA bit unset on queries for the
grandparent zone.
### ZONE-ERR-GRANDPARENT-2
Grandparent `ns2` responds with NODATA on NS query for grandparent zone.
* Zone: child.parent.zone-err-grandparent-2.methodsv2.xa
* Normal response on grandparent `ns1`.
* Grandparent `ns2` responds with NODATA on NS query for the
grandparent zone.
### ZONE-ERR-GRANDPARENT-3
Grandparent `ns2` responds with wrong owner name on NS
on query for grandparent zone NS.
* Zone: child.parent.zone-err-grandparent-3.methodsv2.xa
* Normal response on grandparent `ns1`.
* Grandparent `ns2` responds with other owner name on NS query for
`zone-err-grandparent-3.methodsv2.xa`:
* Owner name `oncle.zone-err-grandparent-3.methodsv2.xa` instead.
### DELEG-OOB-W-ERROR-1
Zone is delegated to two OOB NS, of which one has no IP (NODATA).
* Zone: child.parent.deleg-oob-w-error-1.methodsv2.xa
* Zone is delegated to `ns3.deleg-oob-w-error-1.methodsv2.xa` and
`ns4-nodata.deleg-oob-w-error-1.methodsv2.xa`.
* `ns3` is fully functional with the zone which matches the
delegation.
* `ns4-nodata` cannot be resolved (NODATA).
### DELEG-OOB-W-ERROR-2
Zone is delegated to two OOB NS, of which one has no IP (NXDOMAIN).
* Zone: child.parent.deleg-oob-w-error-2.methodsv2.xa
* Zone is delegated to `ns3.deleg-oob-w-error-2.methodsv2.xa` and
`ns4-nxdomain.deleg-oob-w-error-2.methodsv2.xa`.
* `ns3` is fully functional with the zone which matches the
delegation.
* `ns4-nxdomain` cannot be resolved (NXDOMAIN).
### DELEG-OOB-W-ERROR-3
Zone is delegated to two OOB NS, where both have no IP (NODATA).
* Zone: child.parent.deleg-oob-w-error-3.methodsv2.xa
* Zone is delegated to `ns3-nodata.deleg-oob-w-error-3.methodsv2.xa` and
`ns4-nodata.deleg-oob-w-error-3.methodsv2.xa`.
* `ns3-nodata` and `ns4-nodata` cannot be resolved (NODATA).
* There is no child zone.
### DELEG-OOB-W-ERROR-4
Zone is delegated to two OOB NS, where both have no IP (NXDOMAIN).
* Zone: child.parent.deleg-oob-w-error-4.methodsv2.xa
* Zone is delegated to `ns3-nxdomain.deleg-oob-w-error-4.methodsv2.xa` and
`ns4-nxdomain.deleg-oob-w-error-4.methodsv2.xa`.
* `ns3-nxdomain` and `ns4-nxdomain` cannot be resolved (NXDOMAIN).
* There is no child zone.
### CHILD-NS-CNAME-1
Zone is delegated to two IB NS, where both NS names are aliases (CNAME)
to other names in zone.
* Zone: child.parent.child-ns-cname-1.methodsv2.xa
* Zone is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
`ns1` and `ns2`, respectively.
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
### CHILD-NS-CNAME-2
Zone is delegated to two IB NS, where both NS names are aliases (CNAME)
to other names out of zone.
* Zone: child.parent.child-ns-cname-2.methodsv2.xa
* Zone is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
`child-ns1.child-ns-cname-2.methodsv2.xa` and
`child-ns2.child-ns-cname-2.methodsv2.xa`
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
### CHILD-NS-CNAME-3
Zone is delegated to two OOB NS, where both NS names are aliases (CNAME)
to other names out of zone.
* Zone: child.parent.child-ns-cname-3.methodsv2.xa
* Zone is delegated to `ns3-cname.child-ns-cname-3.methodsv2.xa` and
`ns4-cname.child-ns-cname-3.methodsv2.xa` and both are aliases to `ns3`
and `ns4`, respectively.
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
### CHILD-NS-CNAME-4
Zone is delegated to two IB NS, where both NS names are aliases (CNAME)
to other names in zone.
* Zone: child.parent.child-ns-cname-4.methodsv2.xa
* Zone is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
`ns1` and `ns2`, respectively.
* Both names can be resolved to A via CNAME and give correct IP.
* Neither name can be resolved to AAAA via CNAME.
* The parent zone has glue records for `ns1-cname`, but not for `ns2-cname`.
### PARENT-NS-CNAME-1
Parent is delegated to two IB NS, where both NS names are aliases (CNAME)
to other names in parent zone.
* Zone: child.parent.parent-ns-cname-1.methodsv2.xa
* Parent is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
`ns1` and `ns2`, respectively.
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
### PARENT-NS-CNAME-2
Parent is delegated to two IB NS, where both NS names are aliases (CNAME)
to other names out of zone.
* Zone: child.parent.parent-ns-cname-2.methodsv2.xa
* Parent is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
`parent-ns1.parent-ns-cname-2.methodsv2.xa` and
`parent-ns2.parent-ns-cname-2.methodsv2.xa`
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
### PARENT-NS-SAME-IP-1
Parent is delegated to three IB NS. The delegation lists two name server names
resolving to the same IP.
* Zone: child.parent.parent-ns-same-ip-1.methodsv2.xa
* Parent zone (parent.parent-ns-name-ip-1.methodsv2.xa) is delegated to
`ns1a`, `ns1b` and `ns2`.
* Both `ns1a` and `ns1b` have A and AAAA records pointing to the same IPv4
and IPv6 address respectively.
### PARENT-NS-SAME-IP-2
Parent is delegated to two IB NS. Two of the in-zone NS records resolve to the
same IP. The grandparent zone’s delegation lists name server names that are
different from the in-zone NS record’s, but the sets of IP addresses are equal.
* Zone: child.parent.parent-ns-same-ip-2.methodsv2.xa
* Grandparent zone (parent-ns-name-ip-2.methodsv2.xa) delegates the parent
zone (parent.parent-ns-name-ip-2.methodsv2.xa) to `ns1` and `ns2`.
* Parent zone’s NS records list `ns1a`, `ns1b` and `ns2` instead of `ns1` and
`ns2`.
* Both `ns1a` and `ns1b` have A and AAAA records pointing to the same IPv4
and IPv6 address respectively.
<!-- Links to documents in this repository but outside the public tree must be
absolute -->
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../../README.md
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
[MethodsV2]: ../../tests/MethodsV2.md
[Get parent NS IP addresses]: ../../tests/MethodsV2.md#method-get-parent-ns-ip-addresses
[the implementation of the scenarios]: https://github.com/zonemaster/zonemaster/blob/master/test-zone-data/MethodsV2/README.md

7
zonemaster/docs/public/specifications/test-zones/Nameserver-TP/README.md Normal file
View File

@@ -0,0 +1,7 @@
# Specification of test zones for Nameserver-TP
Test zone specifications are available for:
* [NAMESERVER11](nameserver11.md)
* [NAMESERVER15](nameserver15.md)

118
zonemaster/docs/public/specifications/test-zones/Nameserver-TP/nameserver11.md Normal file
View File

@@ -0,0 +1,118 @@
# Specification of test zones for NAMESERVER11
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
## Background
See the [test zone README file].
## Test Case
This document specifies defined test zones for test case [NAMESERVER11].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [NAMESERVER11] is run on a test zone.
The message tags are defined in the test case ([NAMESERVER11]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test zone README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`nameserver11.xa`) and that subdomain having the same name as the
scenario. The names of those zones are given in section
"[Zone setup for test scenarios]" below.
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:-------------------------|:---------------------------------|:-------------------------------------------
NO-EDNS-ON-UNKNOWN-OC | N11_NO_EDNS | N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
NO-ERROR | (none) | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
NO-RESPONSE-ON-EDNS | (none) | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
NO-RESPONSE-ON-UNKNOWN-OC | N11_NO_RESPONSE | N11_NO_EDNS, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
RETURNS-UNKNOWN-OC | N11_RETURNS_UNKNOWN_OPTION_CODE | N11_NO_EDNS, N11_NO_RESPONSE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
UNEXPECTED-ANSWER-SECTION | N11_UNEXPECTED_ANSWER_SECTION | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_RCODE, N11_UNSET_AA
UNEXPECTED-RCODE-FORMERR | N11_UNEXPECTED_RCODE | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNSET_AA
UNEXPECTED-RCODE-REFUSED | N11_UNEXPECTED_RCODE | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNSET_AA
UNSET-AA | N11_UNSET_AA | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE
## Zone setup for test scenarios
Assumptions for the scenario specifications:
* For each scenario zone there is one name server configured.
* Unless stated otherwise, all name servers respond as follows:
* Responds with a SOA record for the zone on query for SOA.
* All responses are authoritative with [RCODE Name] "NoError".
* EDNS, version 0, is included in all responses on queries with EDNS.
* EDNS is not included in responses on queries without EDNS.
* Unknown EDNS option codes are not included in responses.
### NO-EDNS-ON-UNKNOWN-OC
* Zone: "no-edns-on-unknown-oc.nameserver11.xa."
* The name server will respond without EDNS if the query includes an unknown
EDNS OPTION CODE.
### NO-ERROR
* Zone: "no-error.nameserver11.xa."
* The name server will respond as default (no error).
### NO-RESPONSE-ON-EDNS
* Zone: "no-response-on-edns.nameserver11.xa."
* The name server will not respond to any query with EDNS.
### NO-RESPONSE-ON-UNKNOWN-OC
* Zone: "no-response-on-unknown-oc.nameserver11.xa."
* The name server will not respond if the query includes an unknown EDNS OPTION
CODE.
### RETURNS-UNKNOWN-OC
* Zone: "returns-unknown-oc.nameserver11.xa."
* The name server will respond with an unknown EDNS OPTION CODE if the query
includes an unknown EDNS OPTION CODE.
### UNEXPECTED-ANSWER-SECTION
* Zone: "unexpected-answer-section.nameserver11.xa."
* The name server will respond without the SOA record if the query includes an
unknown EDNS OPTION CODE.
### UNEXPECTED-RCODE-FORMERR
* Zone: "unexpected-rcode-formerr.nameserver11.xa."
* The name server will respond with [RCODE Name] "FormErr" if the query includes an
unknown EDNS OPTION CODE.
### UNEXPECTED-RCODE-REFUSED
* Zone: "unexpected-rcode-refused.nameserver11.xa."
* The name server will respond with [RCODE Name] "Refused" if the query includes an
unknown EDNS OPTION CODE.
### UNSET-AA
* Zone: "unset-aa.nameserver11.xa."
* The name server will respond with AA unset if the query includes an unknown
EDNS OPTION CODE.
[NAMESERVER11]: ../../tests/Nameserver-TP/nameserver11.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../README.md
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

178
zonemaster/docs/public/specifications/test-zones/Nameserver-TP/nameserver15.md Normal file
View File

@@ -0,0 +1,178 @@
# Specification of test zones for NAMESERVER15
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
## Background
See the [test zone README file].
## Test Case
This document specifies defined test zones for test case [NAMESERVER15].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [NAMESERVER15] is run on a test zone.
The message tags are defined in the test case ([NAMESERVER15]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test zone README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`nameserver15.xa`) and that subdomain having the same name as the
scenario. The names of those zones are given in section
"[Zone setup for test scenarios]" below.
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tag | Forbidden message tags
:-------------------------|:--------------------------------------|:-------------------------------------------
NO-VERSION-REVEALED-1 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
NO-VERSION-REVEALED-2 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
NO-VERSION-REVEALED-3 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
NO-VERSION-REVEALED-4 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
NO-VERSION-REVEALED-5 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
NO-VERSION-REVEALED-6 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
ERROR-ON-VERSION-QUERY-1 | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED | N15_SOFTWARE_VERSION, N15_WRONG_CLASS
ERROR-ON-VERSION-QUERY-2 | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED | N15_SOFTWARE_VERSION, N15_WRONG_CLASS
SOFTWARE-VERSION-1 | N15_SOFTWARE_VERSION | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED, N15_WRONG_CLASS
SOFTWARE-VERSION-2 | N15_SOFTWARE_VERSION | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED, N15_WRONG_CLASS
WRONG-CLASS-1 | N15_SOFTWARE_VERSION, N15_WRONG_CLASS | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED
WRONG-CLASS-2 | N15_SOFTWARE_VERSION, N15_WRONG_CLASS | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED
## Zone setup for test scenarios
Assumptions for the scenario specifications:
* For each scenario zone there is one name server configured.
* Unless stated otherwise, all name servers respond as follows:
* Responds with a SOA record for the zone on query for SOA.
* Responds with CH class on queries on CH class.
* Software version query names are "version.bind" and "version.server".
* All responses are [RCODE Name] "NoError".
* EDNS, version 0, is included in all responses on queries with EDNS.
* EDNS is not included in responses on queries without EDNS.
### NO-VERSION-REVEALED-1
This is a happy path
* Zone: "no-version-revealed-1.nameserver15.xa."
* The name server responds with empty answer section on both software version
query names.
### NO-VERSION-REVEALED-2
This is a happy path
* Zone: "no-version-revealed-2.nameserver15.xa."
* The name server responds with empty answer section on both software version
query names.
* The name server responds with [RCODE Name] "NxDomain" on both software
version query names.
### NO-VERSION-REVEALED-3
This is a happy path
* Zone: "no-version-revealed-3.nameserver15.xa."
* The name server responds with empty answer section on both software version
query names.
* The name server responds with [RCODE Name] "Refused" on both software
version query names.
### NO-VERSION-REVEALED-4
This is a happy path
* Zone: "no-version-revealed-4.nameserver15.xa."
* The name server responds with a single CNAME record and no other record in
answer section on both software version query names.
* "version.bind. CNAME version.server." when query name is version.bind.
* "version.server. CNAME version.bind." when query name is version.server.
### NO-VERSION-REVEALED-5
This is a happy path
* Zone: "no-version-revealed-5.nameserver15.xa."
* RDATA of the TXT records for both software version query names is the empty
string.
### NO-VERSION-REVEALED-6
This is a happy path
* Zone: "no-version-revealed-6.nameserver15.xa."
* RDATA of the TXT records for both software version query names only consists
of space characters.
### ERROR-ON-VERSION-QUERY-1
Unexpected response from server
* Zone: "error-on-version-query-1.nameserver15.xa."
* The name server responds with empty answer section on both software version
query names.
* The name server responds with [RCODE Name] "ServFail" on both software
version query names.
### ERROR-ON-VERSION-QUERY-2
Unexpected response from server
* Zone: "error-on-version-query-2.nameserver15.xa."
* The name server does not respond at all to the queries with the software
version query names.
### SOFTWARE-VERSION-1
Normal version string
* Zone: "software-version-1.nameserver15.xa."
* Empty response on software query name "version.bind".
* TXT record with RDATA "v0" in response on software query name
"version.server" in answer section.
### SOFTWARE-VERSION-2
Normal version string
* Zone: "software-version-2.nameserver15.xa."
* Empty response on software query name "version.server".
* TXT record with RDATA "v0" in response on software query name
"version.bind" in answer section.
### WRONG-CLASS-1
Version string returned in wrong class
* Zone: "wrong-class-1.nameserver15.xa."
* Empty response on software query name "version.bind".
* TXT record with RDATA "v0" in response on software query name
"version.server" in answer section.
* TXT record is in IN class, not CH class.
### WRONG-CLASS-2
Version string returned in wrong class
* Zone: "wrong-class-2.nameserver15.xa."
* Empty response on software query name "version.server".
* TXT record with RDATA "v0" in response on software query name
"version.bind" in answer section.
* TXT record is in IN class, not CH class.
[NAMESERVER15]: ../../tests/Nameserver-TP/nameserver15.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../README.md
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios

180
zonemaster/docs/public/specifications/test-zones/README.md Normal file
View File

@@ -0,0 +1,180 @@
# Test scenarios for verification of test case implementation
## Table of contents
* [Objective](#objective)
* [Test scenarios](#test-scenarios)
* [Test environment](#test-environment)
* [Naming conventions](#naming-conventions)
* [Test zone names](#test-zone-names)
* [Data outside the test zones](#data-outside-the-test-zones)
* [Undelegated data](#undelegated-data)
* [Terminology](#terminology)
## Objective
The purpose of the structure found here is to define test zones to be able to
test the correctness of the implementation of the Zonemaster [test cases]. The
main use case is to be the basis for the [unit tests] in the Zonemaster
implementation. The second use case is to verify work in progress, e.g.
implementation of new or updated test cases or updated test case
implementation where the test case has not changed.
There can be other use cases, but only these two use cases are covered here
and in the test zone specifications.
## Test scenarios
The goal of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when a test case is run on test zones. The
message tags are defined in the test case specifications found via "[test cases]"
and the scenarios are defined in the test case specific specifications for test
data found via the [test-zones] directory.
In the test zone specifications the scenarios are defined in two parts:
* What messages from test case that are expected to be outputted and what
messages are expected not to be outputted when a test zone setup according to
the scenario is tested by the test case.
* Specification of the zone setup for the scenario.
One special aspect is the test scenario name. Since the name is to be part
of the test zone name there are some requirements on it:
* Under a specific test case there must not be two scenarios with the same name.
Two closely related scenarios can, in their names, be separated with a
relevant suffix.
* The length of the scenario name must not exceed 32 characters to give room for
additional parts and still make sure it can fit into a DNS label.
* The character set of the name is limited to those of a host name, i.e.
`A-Z0-9-` where `A-Z` will be downcased to `a-z` in the domain name.
* The scenario name must not start or end with `-`.
## Test environment
The tests against the test zones are assumed to be run in a closed environment
with a private DNS tree to achieve full access to any zone. Configuration data
and instructions to set this up are available in the [test-zone-data] directory
in this repository.
## Naming conventions
In this document, domain names are given without trailing dot, except for the root
zone (or node) given as a dot `.`.
The non-existing `.xa` TLD and its tree is used to host the target test
zones, i.e. the zone name that will be given as *Child Zone* to the test case.
All test zones are to be created under `.xa` except for a few cases elaborated
below.
Unless specified in the test zone specification, DNS records that can be stored
within the zone should also be stored there:
* MX records should point at the relative name `mail` and that name should be
added to the zone.
* Name server names (NS record RDATA) should be [in-bailiwick]. "Prefixes" to be
used are `ns1`, `ns2`, `ns3` etc.
### Test zone names
The normal test zone name is built from the following parts:
* `.xa`, the non-existing TLD used here.
* The test case identifier in lower case, e.g. `zone09`.
* The test scenario name in lower case, e.g. `no-response-mx-query`.
In the normal case, the test zone name is `<scenario name>.<test case name>.xa`,
e.g. `no-response-mx-query.zone09.xa`. The normal case should be used as long as
it is possible.
There are some exceptions to the name of the test zone that are identified here:
1. If the test zone is the root, then the name is `.`.
2. If the test zone is a TLD zone, then the name is
`<scenario name>-<test case name>`. Note that hyphen "-" is used between the
parts to create one label. E.g. `no-mx-tld-zone09`. In practice such a TLD
can never be in conflict with real TLDs in the public DNS tree, especially
since TLD names are not permitted to contain neither dash "-" nor digits.
3. If the test zone must be in the ARPA tree, then the name is
`<scenario name>.<test case name>.arpa`, e.g. `no-mx-arpa.zone09.arpa`. In
practice such a name will never be in conflict with names in the public DNS
tree since there no such names under public `.arpa`.
4. If a scenario requires that the parent zone has different settings compared to
other scenarios for the same test case, then the test zone name is
`child.<scenario name>.<test case name>.xa`, e.g.
`child.no-response-mx-query.zone09.xa`, where
`no-response-mx-query.zone09.xa`, instead of `zone09.xa`, is the parent zone
of the test zone.
5. If a scenario requires that the grandparent zone has different settings
compared to other scenarios for the same test case, then the test zone name is
`child.parent.<scenario name>.<test case name>.xa`, e.g.
`child.parent.no-response-mx-query.zone09.xa`, where
`no-response-mx-query.zone09.xa`, instead of `zone09.xa`, is the grandparent
zone of the test zone.
### Data outside the test zones
If a scenario requires that a certain name is outside its own zone, it should be
stored within the `.xb` TLD (also a non-existing TLD) using the same name
structure as under `.xa`, i.e. names for a scenario should be stored under
`<scenario name>.<test case name>.xb`, e.g. `no-mx-arpa.zone09.xb`. If required
test zones can be created in the same way under `.xc` and `.xd`.
What was stated above on data outside its own zone does not apply to reverse data
since that must be stored in the `in-addr.arpa` or `ip6.arpa` tree, and the
owner names of such data must follow the reverse data standards. There is no
requirements for creating separate zones for `in-addr.arpa` or `ip6.arpa` or
below.
### Undelegated data
Some test scenarios require that an [undelegated test] be carried out on it.
In that case, the scenario specification will contain a small
"undelegated data" structure with one line per name server. The format is one of
the following
* NAME-SERVER-NAME
* NAME-SERVER-NAME/IPv4
* NAME-SERVER-NAME/IPv6
where "NAME-SERVER-NAME" is the actual name of the name server, e.g.
`ns1a.del-non-distinct-und.delegation02.xa`, and "IPv4" and "IPv6",
respectively, are literal strings indicating that in the test zone configuration
an IP address of that type should be used. If there is no "/IPv4" or "/IPv6"
then the name server is given without IP address.
In the undelegated structure for a specific scenario the name server name can be
repeated multiple times with different IP addresses. If it appears without
IP address specification it should only appear once.
Here is an example of an undelegated data section from a scenario specification:
```
* Undelegated data:
* ns1a.del-non-distinct-und.delegation02.xa/IPv4
* ns1a.del-non-distinct-und.delegation02.xa/IPv6
* ns1b.del-non-distinct-und.delegation02.xa/IPv4
* ns1b.del-non-distinct-und.delegation02.xa/IPv6
```
## Terminology
* "Glue Record" - The term is used as defined in [RFC 8499], section 7, pages
24-25.
* "In-Bailiwick" - The term is used as defined in [RFC 8499], section 7,
pages 24-25. In this document it is limited to the meaning "in domain" in the
RFC.
* "Out-Of-Bailiwick" - The terms means, in this document, what is not
"In-Bailiwick, in domain". [RFC 8499], section 7, pages 24-25.
[Glue Records]: #terminology
[In-Bailiwick]: #terminology
[Out-Of-Bailiwick]: #terminology
[RFC 8499]: https://datatracker.ietf.org/doc/html/rfc8499#section-7
[Test cases]: ../tests/README.md
[Test-zones]: .
[undelegated test]: ../test-types/undelegated-test.md
[Unit tests]: https://github.com/zonemaster/zonemaster-engine/tree/master/t
[Test-zone-data]: https://github.com/zonemaster/zonemaster/tree/master/test-zone-data

7
zonemaster/docs/public/specifications/test-zones/Zone-TP/README.md Normal file
View File

@@ -0,0 +1,7 @@
# Specification of test zones for Zone-TP
Test zone specifications are available for:
* [Zone09](zone09.md)
* [Zone11](zone11.md)

158
zonemaster/docs/public/specifications/test-zones/Zone-TP/zone09.md Normal file
View File

@@ -0,0 +1,158 @@
# Specification of test zones for ZONE09
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Zone setup for test scenarios]
## Background
See the [test zone README file].
## Test Case
This document specifies defined test zones for test case [Zone09].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [Zone09] is run on a test zone. The
message tags are defined in the test case ([Zone09]) and the scenarios are
defined below.
The test scenarios are structured as stated in the [test zone README file].
## Test zone names
The test zone for each test scenario in this document is a subdomain delegated
from the base name (`zone09.xa`) and that subdomain having the same name as the
scenario except where the test domain must be the root zone, a TLD or a domain
under `.arpa`. The names of those zones are given in section
"[Zone setup for test scenarios]" below.
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
Scenario name | Mandatory message tags | Forbidden message tags
:---------------------|:--------------------------------------------------|:-------------------------------------------
NO-RESPONSE-MX-QUERY | Z09_NO_RESPONSE_MX_QUERY | (none)
UNEXPECTED-RCODE-MX | Z09_UNEXPECTED_RCODE_MX | (none)
NON-AUTH-MX-RESPONSE | Z09_NON_AUTH_MX_RESPONSE | (none)
INCONSISTENT-MX | Z09_INCONSISTENT_MX, Z09_MX_FOUND Z09, NO_MX_FOUND, Z09_MX_DATA | Z09_MISSING_MAIL_TARGET
INCONSISTENT-MX-DATA | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA | Z09_MISSING_MAIL_TARGET, Z09_NULL_MX_NON_ZERO_PREF, Z09_NULL_MX_WITH_OTHER_MX, Z09_ROOT_EMAIL_DOMAIN, Z09_TLD_EMAIL_DOMAIN
NULL-MX-WITH-OTHER-MX | Z09_NULL_MX_WITH_OTHER_MX | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_ROOT_EMAIL_DOMAIN, Z09_TLD_EMAIL_DOMAIN
NULL-MX-NON-ZERO-PREF | Z09_NULL_MX_NON_ZERO_PREF | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_ROOT_EMAIL_DOMAIN, Z09_TLD_EMAIL_DOMAIN
TLD-EMAIL-DOMAIN | Z09_TLD_EMAIL_DOMAIN | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
ROOT-EMAIL-DOMAIN | Z09_ROOT_EMAIL_DOMAIN | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
MX-DATA | Z09_MX_DATA | Z09_INCONSISTENT_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
NULL-MX | (none) | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
NO-MX-SLD | Z09_MISSING_MAIL_TARGET | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
NO-MX-TLD | (none) | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
NO-MX-ARPA | (none) | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
## Zone setup for test scenarios
Assumptions for the zone setup for the test scenarios:
* Only MX records in apex are considered.
* Unless otherwise stated, all name servers respond authoritatively with the
SOA record on SOA queries.
* Unless otherwise stated, all name servers respond authoritatively with (or
without) MX records on MX queries.
* Unless otherwise stated, all responses are authoritative and with [RCODE Name]
"NoError".
### NO-RESPONSE-MX-QUERY
* Zone: "no-response-mx-query.zone09.xa."
* The zone has two name servers.
* Both name servers return an authoritative answer on SOA query.
* One name server does not respond on MX query.
### UNEXPECTED-RCODE-MX
* Zone: "unexpected-rcode-mx.zone09.xa."
* The zone has two name servers.
* Both name servers return an authoritative answer on SOA query.
* One name server returns with any [RCODE Name] except "NoError".
### NON-AUTH-MX-RESPONSE
* Zone: "non-auth-mx-response.zone09.xa."
* The zone has two name servers.
* Both name server return an authoritative answer on SOA query.
* One name server returns with [RCODE Name] "NoError" and non-AA on MX query.
### INCONSISTENT-MX
* Zone: "inconsistent-mx.zone09.xa."
* The zone has two name servers.
* One name server respond with a non-Null MX RRset.
* The other responds without MX RRset (NODATA).
### INCONSISTENT-MX-DATA
* Zone: "inconsistent-mx-data.zone09.xa."
* The zone has two name servers.
* Both name servers respond with an MX RRset.
* The two MX RRsets are not equal.
### NULL-MX-WITH-OTHER-MX
* Zone: "null-mx-with-other-mx.zone09.xa."
* All name servers respond with the same MX RRset.
* The MX RRset is a mix of Null MX and non-Null MX.
### NULL-MX-NON-ZERO-PREF
* Zone: "null-mx-non-zero-pref.zone09.xa."
* All name servers respond with the same MX RRset.
* The MX RRset is a single MX record.
* The MX record is a Null MX with a non-zero preference.
### TLD-EMAIL-DOMAIN
* Zone: "tld-email-domain-zone09." (TLD, dash "-", not dot ".")
* The test zone is a TLD zone.
* All name servers respond with the same MX RRset.
* All MX records are non-Null MX.
### ROOT-EMAIL-DOMAIN
* Zone: "." (root zone)
* The test zone is the root zone.
* All name servers respond with the same MX RRset.
* All MX records are non-Null MX.
### MX-DATA
* Zone: "mx-data.zone09.xa."
* All name servers respond with the same MX RRset.
* All MX records are non-Null MX.
### NULL-MX
* Zone: "null-mx.zone09.xa."
* All name servers respond with the same MX RRset.
* The MX RRset has a single, valid NULL MX.
### NO-MX-SLD
* Zone: "no-mx-sld.zone09.xa."
* The test zone is neither root, TLD or under .ARPA.
* All name servers respond with no MX RRset (NODATA).
### NO-MX-TLD
* Zone: "no-mx-tld-zone09." (TLD, dash "-", not dot ".")
* The test zone is a TLD.
* All name servers respond with no MX RRset (NODATA).
### NO-MX-ARPA
* Zone: "no-mx-arpa.zone09.arpa."
* The test zone is under .ARPA.
* All name servers respond with no MX RRset (NODATA).
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Test zone README file]: ../README.md
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
[Zone09]: ../../tests/Zone-TP/zone09.md

340
zonemaster/docs/public/specifications/test-zones/Zone-TP/zone11.md Normal file
View File

@@ -0,0 +1,340 @@
# Specification of test scenarios for Zone11
## Table of contents
* [Background](#background)
* [Test Case](#test-case)
* [Test scenarios](#test-scenarios)
* [Test zone names](#test-zone-names)
* [All message tags](#all-message-tags)
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
* [Test scenarios and setup of test zones]
## Background
See the [test scenario README file].
## Test Case
This document specifies defined test scenarios for test case [Zone11].
## Test scenarios
The purpose of the test scenarios is to cover all reasonable contexts where
different message tags are outputted when [Zone11] is run on a test zone.
The message tags are defined in the test case ([Zone11]) and the scenarios
are defined below.
The test scenarios are structured as stated in the [test scenario README file].
## Test zone names
Unless specified otherwise, the test zone for each test scenario in this
document is a subdomain delegated from the base name (`zone11.xa`) and that
subdomain having the same name as the scenario. The names of those zones are
given in section "[Test scenarios and setup of test zones]" below.
## All message tags
The test case can output any of these message tags, but not necessarily in any
combination. See [Zone11] for the specification of the tags.
* Z11_DIFFERENT_SPF_POLICIES_FOUND
* Z11_INCONSISTENT_SPF_POLICIES
* Z11_NO_SPF_FOUND
* Z11_NO_SPF_NON_MAIL_DOMAIN
* Z11_NON_NULL_SPF_NON_MAIL_DOMAIN
* Z11_NULL_SPF_NON_MAIL_DOMAIN
* Z11_SPF_MULTIPLE_RECORDS
* Z11_SPF_SYNTAX_ERROR
* Z11_SPF_SYNTAX_OK
* Z11_UNABLE_TO_CHECK_FOR_SPF
## Test scenarios and message tags
If a message tag is not listed for the scenario, its presence or non-presence is
irrelevant to the test scenario and must be ignored.
| Scenario name | Mandatory message tags | Forbidden message tags |
|:-----------------------|:----------------------------------------------------------------|:-----------------------|
| GOOD-SPF-1 | Z11_SPF_SYNTAX_OK | 2) |
| GOOD-SPF-2 | Z11_SPF_SYNTAX_OK | 2) |
| SAME-SPF-DIFFERENT-TXT | Z11_SPF_SYNTAX_OK | 2) |
| NO-TXT | Z11_NO_SPF_FOUND | 2) |
| NO-SPF-TXT | Z11_NO_SPF_FOUND | 2) |
| NO-SPF-ROOT-ZONE | Z11_NO_SPF_NON_MAIL_DOMAIN | 2) |
| NO-SPF-TLD-ZONE | Z11_NO_SPF_NON_MAIL_DOMAIN | 2) |
| NO-SPF-ARPA-ZONE | Z11_NO_SPF_NON_MAIL_DOMAIN | 2) |
| NULL-SPF-ROOT-ZONE | Z11_NULL_SPF_NON_MAIL_DOMAIN | 2) |
| NULL-SPF-TLD-ZONE | Z11_NULL_SPF_NON_MAIL_DOMAIN | 2) |
| NULL-SPF-ARPA-ZONE | Z11_NULL_SPF_NON_MAIL_DOMAIN | 2) |
| NON-NULL-SPF-ROOT-ZONE | Z11_NON_NULL_SPF_NON_MAIL_DOMAIN | 2) |
| NON-NULL-SPF-TLD-ZONE | Z11_NON_NULL_SPF_NON_MAIL_DOMAIN | 2) |
| NON-NULL-SPF-ARPA-ZONE | Z11_NON_NULL_SPF_NON_MAIL_DOMAIN | 2) |
| INVALID-SYNTAX-1 | Z11_SPF_SYNTAX_ERROR | 2) |
| INVALID-SYNTAX-2 | Z11_SPF_SYNTAX_ERROR | 2) |
| INVALID-SYNTAX-3 | Z11_SPF_SYNTAX_ERROR | 2) |
| NON-AUTH-TXT | Z11_UNABLE_TO_CHECK_FOR_SPF | 2) |
| SERVFAIL | Z11_UNABLE_TO_CHECK_FOR_SPF | 2) |
| INCONSISTENT-SPF | Z11_INCONSISTENT_SPF_POLICIES, Z11_DIFFERENT_SPF_POLICIES_FOUND | 2) |
| SPF-MISSING-ON-ONE | Z11_INCONSISTENT_SPF_POLICIES, Z11_DIFFERENT_SPF_POLICIES_FOUND | 2) |
| ALL-DIFFERENT-SPF | Z11_INCONSISTENT_SPF_POLICIES, Z11_DIFFERENT_SPF_POLICIES_FOUND | 2) |
| MULTIPLE-SPF-RECORDS | Z11_SPF_MULTIPLE_RECORDS | 2) |
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
* (2) All tags except for those specified as "Mandatory message tags"
## Test scenarios and setup of test zones
### Default zone configuration
Unless otherwise specified in the specific scenario specification, the test zone
for the scenario will follow the default setup as stated below. The `child zone`
is the zone to be tested for the scenario.
* The child zone is `SCENARIO.zone11.xa`.
* There is a zone file for the child zone.
* It is served by two name servers named ns1 and ns2.child.zone11.xa.
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 address records.
* The parent zone is `zone11.xa`.
* It is served by two in-bailiwick name servers named ns1 and ns2.zone11.xa.
* ns1 and ns2 have the same zone content.
* ns1 and ns2 have both IPv4 and IPv6 glue.
* The records matching glue in the zone are complete.
* All responses will have the AA bit set.
* All responses will have the [RCODE Name] "NoError".
### GOOD-SPF-1
A zone whose SPF record is the shortest legal SPF record possible, namely the
string `v=spf1`. It is valid syntax, albeit not very useful.
* Zone: good-spf-1.zone11.xa
* The TXT RRset at the apex contains one TXT record with the text `v=spf1`.
### GOOD-SPF-2
A zone whose SPF record is well-formed and contains at least one term.
* Zone: good-spf-2.zone11.xa
* The TXT RRset at the apex contains one TXT record starting with the text
`v=spf1`, followed by a space, followed by one or more legal SPF terms.
### SAME-SPF-DIFFERENT-TXT
A zone whose SPF record is identical despite inconsistent TXT RRset records at
the apex.
* Zone: same-spf-different-txt.zone11.xa
* ns1 serves a TXT RRset containing one SPF record and one non-SPF record.
* ns2 serves a different TXT RRset containing one SPF record and one non-SPF
record. The SPF record served by ns2 is identical to the one served
by ns1. The non-SPF record served by ns2 is different from the one served
by ns1.
### NO-TXT
A zone containing no TXT record at the apex.
* Zone: no-txt.zone11.xa
* The TXT RRset at the apex is empty.
### NO-SPF-TXT
A zone containing at least one TXT record, but none of the TXT after
concatenating all strings, gives a string starting with `v=spf1`.
* Zone: no-spf-txt.zone11.xa
* The TXT RRset at the apex is non-empty, but none of the TXT records are
recognized as SPF records.
### NO-SPF-ROOT-ZONE
A root zone without SPF records.
* Zone: "." (root zone)
* It is served by ns1 and ns2.no-spf.root-servers.zone11.xa.
* The TXT RRset at the apex of the root zone is empty.
### NO-SPF-TLD-ZONE
A TLD zone without SPF records.
* Zone: no-spf-zone11
* It is served by ns1 and ns2.zone11.xa.
* The TXT RRset at the apex of the TLD zone is empty.
### NO-SPF-ARPA-ZONE
A zone in .arpa without SPF records.
* Zone: no-spf-arpa-zone.zone11.arpa
* It is served by ns1 and ns2.child.zone11.xa.
* The TXT RRset at the apex of the zone is empty.
### NULL-SPF-ROOT-ZONE
A root zone with a null SPF record.
* Zone: "." (root zone)
* It is served by ns1 and ns2.null-spf.root-servers.zone11.xa.
* The TXT RRset at the apex of the root zone contains one TXT record with the
string `v=spf1 -all`.
### NULL-SPF-TLD-ZONE
A TLD zone with null SPF records.
* Zone: null-spf-zone11
* It is served by ns1 and ns2.zone11.xa.
* The TXT RRset at the apex of the TLD zone contains one TXT record with the
string `v=spf1 -all`.
### NULL-SPF-ARPA-ZONE
A zone in .arpa with a null SPF record.
* Zone: null-spf-arpa-zone.zone11.arpa
* It is served by ns1 and ns2.child.zone11.xa.
* The TXT RRset at the apex of the zone contains one TXT record with the
string `v=spf1 -all`.
### NON-NULL-SPF-ROOT-ZONE
A root zone with a non-null SPF record.
* Zone: "." (root zone)
* It is served by ns1 and ns2.non-null-spf.root-servers.zone11.xa.
* The TXT RRset at the apex of the root zone contains one TXT record with an
SPF record that isn’t null (i.e. permits at least one IP address).
### NON-NULL-SPF-TLD-ZONE
A TLD zone with a non-null SPF record.
* Zone: non-null-spf-zone11
* It is served by ns1 and ns2.zone11.xa.
* The TXT RRset at the apex of the TLD zone contains one TXT record with an
SPF record that isn’t null (i.e. permits at least one IP address).
### NON-NULL-SPF-ARPA-ZONE
A zone in .arpa with a non-null SPF record.
* Zone: non-null-spf-arpa-zone.zone11.arpa
* It is served by ns1 and ns2.child.zone11.xa.
* The TXT RRset at the apex of the zone contains one TXT record with an SPF
record that isn’t null (i.e. permits at least one IP address).
### INVALID-SYNTAX-1
A zone whose SPF record is syntactically invalid.
* Zone: invalid-syntax-1.zone11.xa
* The TXT RRset at the apex contains one SPF record with invalid syntax,
i.e. beginning with `v=spf1` followed by whitespace but not compliant with
the ABNF grammar described in [RFC 7208, Section 4.5][RFC 7208#4.5] and
following sections.
### INVALID-SYNTAX-2
Like INVALID-SYNTAX-1, but two of the name server names in the delegation and in
the zone point to the same IP address. This scenario is there to ensure that
all name servers that serve an ill-formed SPF policy are reported, even if two
of them have the same IP address.
* Zone: invalid-syntax-2.zone11.xa
* It is served by ns1a, ns1b, and ns2.invalid-syntax.zone11.xa.
* ns1a and ns1b resolve to the same IPv4 and IPv6 address as
ns1.child.zone11.xa.
* ns2 resolves to the same IPv4 and IPv6 address as ns2.child.zone11.xa.
* The TXT RRset at the apex contains one SPF record with invalid syntax,
i.e. beginning with `v=spf1` followed by whitespace but not compliant with
the ABNF grammar described in [RFC 7208, Section 4.5][RFC 7208#4.5] and
following sections.
### INVALID-SYNTAX-3
A zone whose SPF record contains a few random bytes, with a few non-ASCII
bytes among those.
* Zone: invalid-syntax-3.zone11.xa
* The TXT RRset at the apex contains one SPF record beginning with `v=spf1`,
followed by some whitespace and containing some random bytes outside the
printable ASCII range, which is not compliant with the ABNF grammar
described in [RFC 7208, Section 4.5][RFC 7208#4.5] and following sections.
### NON-AUTH-TXT
A zone containing one SPF record in its TXT RRset, but served from name
servers that fail to set the AA bit in their responses.
* Zone: non-auth-txt.zone11.xa
* The TXT RRset at the apex contains one SPF record.
* Both name servers serve the aforementioned TXT RRset with the AA bit unset
in the response header.
### SERVFAIL
A zone where responses to queries for the TXT RRset have an RCODE different
from NoError.
* Zone: servfail.zone11.xa
* Responses to queries for the TXT RRset at the zone’s apex have the
[RCODE Name] "ServFail".
### INCONSISTENT-SPF
A zone that serves different SPF records depending on the name server being
queried.
* Zone: inconsistent-spf.zone11.xa
* ns1 serves a TXT RRset at the apex containing one SPF record.
* ns2 serves a different TXT RRset at the apex containing one SPF record
that is also different from the SPF record served by ns1.
### SPF-MISSING-ON-ONE
A zone that serves identical SPF records, except on one of the name servers.
* Zone: spf-missing-on-one.zone11.xa
* The zone is delegated to three name servers named ns1, ns2 and
ns3.child.zone11.xa.
* ns2 and ns3 serve an identical TXT RRset at the apex containing one SPF
record.
* ns1 serves a different TXT RRset at the apex without an SPF record.
### ALL-DIFFERENT-SPF
A zone that serves different SPF records on all of its name servers.
* Zone: all-different-spf.zone11.xa
* The zone is delegated to three name servers named ns1, ns2 and
ns3.child.zone11.xa.
* ns1 serves a TXT RRset at the apex containing one SPF record
* ns2 serves a different TXT RRset at the apex containing one SPF record
that is also different.
* ns3 serves another different TXT RRset at the apex containing one SPF
record that is different from the two previous records.
### MULTIPLE-SPF-RECORDS
A zone whose TXT RRset at the apex contains more than one SPF record.
* Zone: multiple-spf-records.zone11.xa
* The TXT RRset at the apex contains more than one SPF record.
[Zone11]: ../../tests/Zone-TP/zone11.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 7208]: https://www.rfc-editor.org/rfc/rfc7208
[RFC 7208#4.5]: https://www.rfc-editor.org/rfc/rfc7208#section-4.5
[Test scenario README file]: ../README.md
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones

19
zonemaster/docs/public/specifications/tests/Address-TP/README.md Normal file
View File

@@ -0,0 +1,19 @@
# Address Test Plan
These tests focus on the Address specific test cases of the DNS tests.
This document uses the terminology defined in the [Master Test Plan].
[Master Test Plan]: ../MasterTestPlan.md
[Test Case README]: ../README.md
<!-- Content until EOF generated by script updateTestPlanReadme.pl from Zonemaster/Zonemaster utils directory -->
## Test cases list
|Test Case |Test Case Description|
|:---------|:--------------------|
|[ADDRESS01](address01.md)|Name server address must be globally reachable|
|[ADDRESS02](address02.md)|Reverse DNS entry exists for name server IP address|
|[ADDRESS03](address03.md)|Reverse DNS entry matches name server name|

153
zonemaster/docs/public/specifications/tests/Address-TP/address01.md Normal file
View File

@@ -0,0 +1,153 @@
# ADDRESS01: Name server address must be globally reachable
## Test case identifier
**ADDRESS01**
## Table of contents
* [Objective](#Objective)
* [Scope](#Scope)
* [Inputs](#Inputs)
* [Summary](#Summary)
* [Test procedure](#Test-procedure)
* [Outcome(s)](#Outcomes)
* [Intercase dependencies](#Intercase-dependencies)
## Objective
In order for the domain and its resources to be accessible, authoritative
name servers must have addresses in the reachable public addressing space.
IANA is responsible for global coordination of the IP addressing system.
Aside its address allocation activities, it maintains reserved address ranges
for special uses. These ranges can be categorized into two types:
[Special purpose IPv4 addresses] and [Special purpose IPv6 addresses].
This test checks the name server IP addresses, both those derived from delegation and those
derived from the name servers listed in the zone (NS records). Each address is compared against
the IANA databases. If an address is not globally reachable, a message is outputted.
## Scope
This test case does not do any actual connectivity test, which is done by other test cases.
## Inputs
* "Child Zone" -- the domain name to be tested.
* [Special purpose IPv4 addresses]
* [Special purpose IPv6 addresses]
## Summary
| Message Tag | Level | Arguments | Message ID for message tag |
|:--------------------------------|:---------|:----------|:-----------------------------------------------------------------------------------------|
| A01_ADDR_NOT_GLOBALLY_REACHABLE | ERROR | ns_list | IP address(es) not listed as globally reachable: "{ns_list}". |
| A01_DOCUMENTATION_ADDR | ERROR | ns_list | IP address(es) intended for documentation purposes: "{ns_list}". |
| A01_GLOBALLY_REACHABLE_ADDR | INFO | ns_list | Globally reachable IP address(es): "{ns_list}". |
| A01_LOCAL_USE_ADDR | ERROR | ns_list | IP address(es) intended for local use on network or service provider level: "{ns_list}". |
| A01_NO_GLOBALLY_REACHABLE_ADDR | ERROR | | None of the name servers IP addresses are listed as globally reachable. |
| A01_NO_NAME_SERVERS_FOUND | CRITICAL | | No name servers found. |
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [Argument list].
## Test procedure
1. Create the following empty sets:
1. Name server name and IP address ("Name Server IP").
2. Name server name and IP address ("Documentation Address").
3. Name server name and IP address ("Local Use Address").
4. Name server name and IP address ("Not Globally Reachable").
5. Name server name and IP address ("Globally Reachable").
2. Retrieve all name server names and IP addresses for *Child Zone* using
methods [Get-Del-NS-Names-and-IPs] and [Get-Zone-NS-Names-and-IPs],
and add them to the *Name Server IP* set.
3. If the *Name Server IP* set is empty, output *[A01_NO_NAME_SERVERS_FOUND]*
and exit the test.
4. For each name server in *Name Server IP* do:
1. Match the IP address against the IP ranges specified in
[Special purpose IPv4 addresses] and [Special purpose IPv6 addresses]
1. If the IP address falls within any of the address ranges reserved for
*Documentation*, add the name server name and IP address to the
*Documentation Address* set,
2. Else, if it falls within an address range belonging to any of the
following categories, add the name server name and IP address to the
*Local Use Adddress* set:
- *Private-Use (IPv4)*
- *Loopback (IPv4)*
- *Loopback Address (IPv6)*
- *Link Local (IPv4)*
- *Link-Local Unicast* (IPv6)
- *Unique-Local* (IPv6)
- *Shared Address Space* (IPv6)
3. Else, if it falls within any other range that is not registered as
*Globally Reachable*, add the name server name and IP address to
the *Not Globally Reachable* set.
4. Else, add the name server name and IP address to the
*Globally Reachable* set.
2. Go to the next server.
5. If the *Documentation Address* set is non-empty, then output
*[A01_DOCUMENTATION_ADDR]* with a list of name server names and IP addresses
from the set.
6. If the *Local Use Address* set is non-empty, then output
*[A01_LOCAL_USE_ADDR]* with a list of name server names and IP addresses
from the set.
7. If the *Not Globally Reachable* set is non-empty, then output
*[A01_ADDR_NOT_GLOBALLY_REACHABLE]* with a list of name server names and
IP addresses from the set.
8. If the *Globally Reachable* set is non-empty, then output
*[A01_GLOBALLY_REACHABLE_ADDR]* with a list of name server names and
IP addresses from the set.
9. If the *Globally Reachable* set is empty, then output
*[A01_NO_GLOBALLY_REACHABLE_ADDR]*
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*[ERROR]* or *[CRITICAL]*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]* the outcome of this Test Case is "pass".
## Special procedural requirements
The registries [Special purpose IPv4 addresses] and
[Special purpose IPv6 addresses] have to be fetched prior to testing.
## Intercase dependencies
None.
[A01_GLOBALLY_REACHABLE_ADDR]: #summary
[A01_NO_GLOBALLY_REACHABLE_ADDR]: #summary
[A01_ADDR_NOT_GLOBALLY_REACHABLE]: #summary
[A01_DOCUMENTATION_ADDR]: #summary
[A01_LOCAL_USE_ADDR]: #summary
[A01_NO_NAME_SERVERS_FOUND]: #summary
[Argument list]: ../ArgumentsForTestCaseMessages.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[ERROR]: ../SeverityLevelDefinitions.md#error
[Get-Del-NS-Names-and-IPs]: ../MethodsV2.md#method-get-delegation-ns-names-and-ip-addresses
[Get-Zone-NS-Names-and-IPs]: ../MethodsV2.md#method-get-zone-ns-names-and-ip-addresses
[INFO]: ../SeverityLevelDefinitions.md#info
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[Special purpose IPv4 addresses]: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml
[Special purpose IPv6 addresses]: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

46
zonemaster/docs/public/specifications/tests/Address-TP/address02.md Normal file
View File

@@ -0,0 +1,46 @@
## ADDRESS02: Reverse DNS entry exists for name server IP address
### Test case identifier
**ADDRESS02** Reverse DNS entry should exist for name server IP address
### Objective
Some anti-spam techniques use reverse DNS lookup to allow incoming traffic.
In order to prevent name servers to be blocked or blacklisted, DNS
administrators should publish PTR records associated to name server
addresses.
TODO: Technical reference to be found
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Obtain the glue address records of the domain checked
using [Method4](../Methods.md)
2. Obtain the IP addresses of each name server of the domain checked
using [Method5](../Methods.md)
3. For each IP address, a recursive PTR query must be performed.
4. If any answer of the queries performed in step 3 contains an RCODE
other than NOERROR or if the answer does not include a PTR record,
this test case fails.
### Outcome(s)
If the test case succeeds, its result is a list of addresses with corresponding
hostnames which are the result of the PTR queries performed.
The result could be represented as a hash table where the keys are the IP
addresses and the values their corresponding hostnames.
### Special procedural requirements
None.
### Intercase dependencies
The outcomes of this test is used as the input of [ADDRESS03](address03.md) test case.

63
zonemaster/docs/public/specifications/tests/Address-TP/address03.md Normal file
View File

@@ -0,0 +1,63 @@
## ADDRESS03: Reverse DNS entry matches name server name
### Test case identifier
**ADDRESS03** Reverse DNS entry matches name server name
### Objective
Some anti-spam techniques use reverse DNS lookup to allow incoming traffic.
In order to prevent name servers to be blocked or blacklisted, DNS
administrators should publish PTR records associated with the name server
addresses.
Moreover, as mentioned in paragraph 2.1 of [RFC
1912](https://datatracker.ietf.org/doc/html/rfc1912) when a PTR record exists, it must match the host
name.
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Obtain the IP addresses of each name server of the domain from the child
using [Method5](../Methods.md).
These IP addresses can be associated to the name servers through a hash
table where each address is a key and the name server it's unique value.
Let's call this hash table HASH1.
2. Obtain the reverse DNS entries associated to name servers names as described
in test case [ADDRESS02](address02.md). Let's call its outcome HASH2 which
consists of IP addresses as keys and hostnames as values. As multiple PTR
records are allowed, an IP address can have several corresponding hostnames.
3. Compare HASH2 to HASH1.
Parse the address list of HASH1.
For an address (a) of HASH1, take the corresponding hostname (h) in HASH1.
If this hostname (h) is present in the hostnames list associated to this
address (a) in HASH2, then the test succeeds for address (a).
If the hostname (h) does not match any hostnames associated to address (a)
in HASH2, then the test fails for address (a).
If the test fails for one IP address, the whole test case fails.
### Outcome(s)
Multiple addresses and multiple PTR records are allowed. The test
succeeds if every name server address has one or more PTR records
and one of these records matches the server name.
If one address doesn't match, the whole test case fails.
### Special procedural requirements
None.
### Intercase dependencies
Some of the input of this test comes as the result of test case
[ADDRESS02](address02.md). [ADDRESS02](address02.md) must succeed
prior to proceed with this test case [ADDRESS03](address03.md).

160
zonemaster/docs/public/specifications/tests/ArgumentsForTestCaseMessages.md Normal file
View File

@@ -0,0 +1,160 @@
# Arguments for test case messages
## Introduction
This document defines *arguments*. An *argument* is defined with its name, its
type of value and its usage and formatting. The *arguments* are primarily used in
a Zonemaster-Engine message, but can also be used in messages output by
Zonemaster-CLI and Zonemaster-Backend. The messages, in the form of *msgid*
strings, are primarily defined in the Perl modules for the test cases, e.g.
[Basic.pm]. The *arguments* are also used in the translated messages, in the form
of *msgstr* strings, in the PO files, e.g. [fr.po] and [sv.po]. When an
*argument* is used in a message (*msgid* or *msgstr*) it is represented by its
name which is put within curly brackets, e.g. as `{ns}`.
When a message is created or updated only *arguments* defined in this document
should be used. If there is not a defined *argument* that can be used for the
message then a new *argument* must be defined and this document is to be updated.
## Multiple instances of the same argument
In a message the same *argument* can only be used once. In case a message needs
more than one instance of an *argument*, the instances need to be disambiguated.
This is done by adding different suffixes to the argument's name. The suffix is
an underscore ("_") followed by a descriptive string of lower case "a-z0-9". The
suffixed *argument name* is not to be listed in this document, it is just an
instance of the *argument name* without the specific suffix.
### Example of multiple instances
If two arguments of type "List of IP addresses" are to be used in a message, then
both *argument names* should be `ns_ip_list` following the list of defined
arguments below. If the relevant suffixes for those are "nsec" (connected to an
NSEC record type) and "nsec3" (connected to an NSEC3 record type) then two
resulting argument names should be `ns_ip_list_nsec` and `ns_ip_list_nsec3`,
respectively.
The following is a message (*msgid* in this case) where this is in use:
> The zone is inconsistent on NSEC and NSEC3. NSEC is fetched from nameservers
> with IP addresses "{ns_ip_list_nsec}". NSEC3 is fetched from nameservers with
> IP addresses "{ns_ip_list_nsec3}".
## Defined arguments
When a suitable *argument* is found in this list, it should also be used in new
and updated messages (*msgids* and *msgstr*).
| Argument name | Type of value | Description and formatting |
|-----------------|------------------------------------------|------------------------------------------------------------------------------------------------------------------------------|
| algo_descr | Text | The human readable description of a DNSSEC algorithm as in table in [DNSSEC05][DNSSEC05#objective]. |
| algo_mnemo | Text | The mnemonic of a DNSSEC algorithm as in table in [DNSSEC05][DNSSEC05#objective]. |
| algo_num | Non-negative integer | The numeric value for a DNSSEC algorithm as in table in [DNSSEC05][DNSSEC05#objective]. |
| cli_arg | Text | Command line (CLI) argument to an option, valid or invalid |
| domain | Domain name | A domain name. If "nsname", "mailtarget" or "query_name" is also applicable, use that one instead. |
| ds_algo_descr | Text | The human readable description of a [DS Digest algorithm]. |
| ds_algo_mnemo | Text | The mnemonic of a [DS Digest algorithm]. |
| ds_algo_num | Non-negative integer | The numeric value for a [DS Digest algorithm]. |
| int | integer | An integer. If "algo_num", "ds_also_num", "keytag", "soaserial" or some other specific name is applicable, use that instead. |
| ip_prefix | IP prefix | An IP prefix (i.e., an IP address with a network mask in CIDR notation). |
| keytag | Non-negative integer | A keytag for a DNSKEY record or a keytag used in a DS or RRSIG record. |
| label | Domain name label | A single label, i.e. the string between the dots, from a domain name. |
| locale | Locale label | A locale label, user provided or taken from the environment |
| mailtarget | Domain name | The domain name of the mailserver in an MX RDATA. |
| mailtarget_list | List of domain names | A list of name servers, as specified by "mailtarget", separated by ";". |
| module | A Zonemaster test module, or `all` | The name of a Zonemaster test module. |
| module_list | List of Zonemaster test modules | A list of Zonemaster test modules, separated by ":". |
| ns | Domain name and IP address pair | The name and IP address of a name server, separated by "/". |
| ns_ip | IP address | The IP address of a name server. |
| ns_ip_list | List of IP addresses | A list of name servers, as specified by "ns_ip", separated by ";". |
| ns_list | List of domain name and IP address pairs | A list of name servers, as specified by "ns", separated by ";". |
| nsname | Domain name | The domain name of a name server. |
| nsname_list | List of domain names | A list of name servers, as specified by "nsname", separated by ";". |
| query_name | Domain name | A query domain name (QNAME), as defined in [RFC1035, section 4.1.2]. |
| rcode | An RCODE Name | An RCODE Name (not numeric code) from [DNS RCODEs]. |
| rrtype | A Resource Record TYPE Name | A Resource Record TYPE Name (not numeric code) from [DNS RR TYPEs]. |
| soaserial | Non-negative integer | The numeric value for the SERIAL field in an SOA record. Integer in range 0-4,294,967,295 |
| soaserial_list | List of non-negative integers | A list of non-negative integers, as specified by "soaserial", separated by ";". |
| string | Text | The content of the RDATA of a TXT resource record. |
| testcase | A Zonemaster test case, or `all` | A test case identifier. |
| unicode_name | Unicode name of a code point | The name is a string in ASCII only and in upper case, e.g. "LATIN SMALL LETTER A" |
## Preliminary or proposed arguments
The *arguments* in in this table are not fully defined. If used it should follow
the pattern of defined *arguments*, be fully defined and moved to the list of
defined *arguments*.
| Argument name | Type of value | Description and formatting |
|--------------- |------------------------------------|-------------------------------------------------------------|
|| AS number| An Autonomous Space number for an IP address.|
|| Address record type (A or AAAA)| Used to tell the difference between IPv4 and IPv6.|
|| Count of different SOA RNAMEs.| Total number of different SOA RNAME fields seen.|
|| Count of different SOA serial numbers| Total number of different SOA serial numbers seen.|
|| Count of different sets of NS name/IP seen.| Total number of different sets of nameserver information seen.|
|| Count of different time parameter sets seen| Total number of different sets of SOA time parameters seen.|
|| Count of domain names| A count of domain names.|
|| Count of nameservers| A count of nameservers.|
|| DNS packet size| The size in octets of a DNS packets.|
|| DNSKEY key length| The key length for a DNSKEY. The interpretation of this value various quite a bit with the algorithm. Be careful when using it for algorithms that aren't RSA-based.|
|| DNSSEC delegation verification failure reason| A somewhat human-readable reason why the delegation step between the tested zone and its parent is not secure.|
| dlength (?) | Domain name label length| The length of a domain name label.|
|| Duration in seconds| An integer number of seconds.|
| fqdn (?) | FQDN| A fully qualified domain name (with terminating dot).|
| fqdnlength (?) | FQDN length| The length of an FQDN.|
|| IP address| An IPv4 or IPv6 address.|
|| IP address or nothing| An IPv4 or IPv6 address, or no value.|
|| IP range| An IP range.|
|| IP reserved range description| A brief description what an IP range is reserved for.|
|| Largest SOA serial number seen| The numerically largest SOA serial value seen.|
|| List of AS numbers| A list of Autonomous Space numbers.|
|| List of DNSKEY keytags| A list of keytags from DNSKEY records.|
|| List of DS keytags| A list of keytags from DS records.|
|| List of DS/DNSKEY/RRSIG keytags| A list of keytags from DS, DNSKEY or RRSIG records.|
|| List of IP addresses| A list of IP addresses.|
|| List of MX domain names| A list of domain names from MX records.|
|| List of RR types| A list of RR types, typically from an NSEC or NSEC3 record.|
|| List of SOA RNAMEs| A list of RNAME values from SOA records.|
|| List of SOA serial numbers| A list of serial number values from SOA records.|
|| List of domain names| A list of domain names.|
|| NS names from child| A list of nameserver names taken from a zone's child servers.|
|| NS names from parent| A list of nameserver names taken from a zone's parent servers.|
|| NSEC3 iteration count| An iteration count from an NSEC3PARAM record.|
|| Number of DNSKEY RRs in packet| The number of DNSKEY records found in a packet.|
|| Number of RRSIG RRs in packet| The number of RRSIG records found in a packet.|
|| Number of SOA RRs in packet| The number of SOA records found in a packet.|
|| Protocol (UDP or TCP)| The protocol used for a query.|
|| RFC reference| A reference to an RFC.|
| rrtype (?) | RR type| The type of RR the message pertains to.|
|| RRSIG Expiration date| The time when a signature expires.|
|| RRSIG validation error message| The human-readable reason why the cryptographic validation of a signature failed.|
|| SOA MNAME| The MNAME value from a SOA record.|
|| SOA RNAME| The RNAME value from a SOA record.|
|| SOA expire| The expire value from a SOA record.|
|| SOA expire minimum value| The lowest value considered OK for the SOA expire field.|
|| SOA minimum| The minimum value from a SOA record.|
|| SOA minimum maximum value| The highest value considered OK for the SOA minimum field.|
|| SOA minimum minimum value| The lowest value considered OK for the SOA minimum field.|
|| SOA refresh| The refresh value from a SOA record.|
|| SOA refresh minimum value| The lowest value considered OK for the SOA refresh field.|
|| SOA retry| The retry value from a SOA record.|
|| SOA retry minimum value| The lowest value considered OK for the SOA retry field.|
|| SOA serial number| The serial number value from a SOA record.|
|| Smallest SOA serial number seen| The smallest value seen in a SOA serial field in the tested zone.|
|| TLD| The name of a top-level domain.|
|| `time_t` value when RRSIG validation was attempted| The time when an RRSIG validation was attempted, in Unix `time_t` format.|
Message names marked with a question mark should not be considered stable.
[Basic.pm]: https://github.com/zonemaster/zonemaster-engine/blob/master/lib/Zonemaster/Engine/Test/Basic.pm
[DNS RR TYPEs]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
[DNS RCODEs]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[DNSSEC05#objective]: DNSSEC-TP/dnssec05.md#objective
[DS Digest algorithm]: https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
[fr.po]: https://github.com/zonemaster/zonemaster-engine/blob/master/share/fr.po
[RFC1035, section 4.1.2]: https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.2
[sv.po]: https://github.com/zonemaster/zonemaster-engine/blob/master/share/sv.po

22
zonemaster/docs/public/specifications/tests/Basic-TP/README.md Normal file
View File

@@ -0,0 +1,22 @@
# Basic Test Plan
These are tests of a domain's most basic functionality. If these fail,
it will be hard or impossible to perform any other tests at all. The
test code should be constructed so that these tests are always run, even
if a subset of tests is asked for that would not normally include them.
This document uses the terminology defined in the [Master Test Plan].
[Master Test Plan]: ../MasterTestPlan.md
[Test Case README]: ../README.md
<!-- Content until EOF generated by script updateTestPlanReadme.pl from Zonemaster/Zonemaster utils directory -->
## Test cases list
|Test Case |Test Case Description|
|:---------|:--------------------|
|[BASIC01](basic01.md)|Check for the parent zone and the zone itself|
|[BASIC02](basic02.md)|The domain must have at least one working name server|
|[BASIC03](basic03.md)|The _Broken but functional_ test|

385
zonemaster/docs/public/specifications/tests/Basic-TP/basic01.md Normal file
View File

@@ -0,0 +1,385 @@
# BASIC01: Check for the parent zone and the zone itself
## Test case identifier
**BASIC01**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure]
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
In order for a domain (zone) to work, it must be delegated from a
zone higher up in the DNS hierarchy (a parent domain or zone).
This Test Case will determine if parent zone and child zones,
respectively, exist.
If the test is an [undelegated test], however, it can be tested even it is not
delegated. Parent zone for [undelegated test] is disregarded.
If the zone to be tested is the root zone, it has no parent or
delegation and will always pass this Test Case.
If no parent can be determined, there cannot be any delegation.
## Scope
The algorithm in this test case should match the algorithm in method
[Get parent zone].
If the child zone does not exist (is not delegated), the only
test case to be run after this test case is [BASIC03]. However,
if the test type is an [undelegated test], then all other test cases
can be run even if the child zone is not delegated.
## Inputs
Input for this Test Case:
* "Child Zone" - The label of the domain name (zone) to be tested
* "Root Name Servers" - The IANA [List of Root Servers]
* "Test Type" - The test type with values "[undelegated test]" or
"normal test".
## Summary
Message Tag | Level | Arguments | Message ID for message tag
:--------------------------|:------|:-----------------------------------|:--------------------------
B01_CHILD_FOUND |INFO | domain | The zone "{domain}" is found.
B01_CHILD_IS_ALIAS |NOTICE |domain_child, domain_target, ns_list| "{domain_child}" is not a zone. It is an alias for "{domain_target}". Run a test for "{domain_target}" instead. Returned from name servers "{ns_list}".
B01_INCONSISTENT_ALIAS |ERROR | domain | The alias for "{domain}" is inconsistent between name servers.
B01_INCONSISTENT_DELEGATION|ERROR |domain_child, domain_parent, ns_list| The name servers for parent zone "{domain_parent}" give inconsistent delegation of "{domain_child}". Returned from name servers "{ns_list}".
B01_NO_CHILD |ERROR | domain_child, domain_super | "{domain_child}" does not exist as a DNS zone. Try to test "{domain_super}" instead.
B01_PARENT_DISREGARDED |INFO | | This is a test of an undelegated domain so finding the parent zone is disregarded.
B01_PARENT_FOUND |INFO | domain, ns_list | The parent zone is "{domain}" as returned from name servers "{ns_list}".
B01_PARENT_NOT_FOUND |WARNING| | The parent zone cannot be found.
B01_PARENT_UNDETERMINED |WARNING| ns_list | The parent zone cannot be determined on name servers "{ns_list}".
B01_ROOT_HAS_NO_PARENT |INFO | | This is a test of the root zone which has no parent zone.
B01_SERVER_ZONE_ERROR |DEBUG | query_name, rrtype, ns | Unexpected response on query for "{query_name}" with query type "{rrtype}" to "{ns}".
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
The name server names are assumed to be available at the time when the msgid
is created, if the argument name is "ns" or "ns_list" even when in the
"[Test procedure]" below it is only referred to the IP address of the name
servers.
## Test procedure
In this section and unless otherwise specified below, the terms "[DNS Query]"
follow the specification for DNS queries as specified in
[DNS Query and Response Defaults]. The handling of the DNS responses on the
DNS queries follow, unless otherwise specified below, what is specified for
[DNS Response] in the same specification.
1. If the *Child Zone* is the root zone (".") then:
1. Output *[B01_CHILD_FOUND]* with zone name (".").
2. Output *[B01_ROOT_HAS_NO_PARENT]*.
3. Exit the test case.
2. If *Test Type* is "[undelegated test]", then:
1. Output *[B01_CHILD_FOUND]* with zone name equal to *Child Zone*.
2. Output *[B01_PARENT_DISREGARDED]*.
3. Exit the test case.
3. Create [DNS queries][DNS Query]:
1. Query type DNAME and query name *Child Zone* ("DNAME Child Query").
4. Create the following empty sets:
1. Name server IP and zone name ("Remaining Servers").
2. Name server IP and query name ("Handled Servers").
3. Parent name server IP and parent zone name ("Parent Found").
4. Parent name server IP and parent zone name ("Delegation Found").
5. Parent name server IP and parent zone name ("AA NXDomain Found").
6. Parent name server IP and parent zone name ("AA SOA Found").
7. Parent name server IP and parent zone name ("AA CNAME Found").
8. Parent name server IP and parent zone name ("CNAME with Referral Found").
9. Parent name server IP, parent zone name and DNAME target
("AA DNAME Found").
10. Parent name server IP and parent zone name ("AA NODATA Found").
5. Insert all addresses from *Root Name Servers* and the root zone name into the
*Remaining Servers* set.
> In the loop below, the steps tries to capture the name of the parent zone of
> **Child Zone** and the IP addresses of the name servers for that parent zone.
> This is done using a modified version of the "QNAME minimization" technique
> [RFC 9156]. SOA is the query type used for traversing the tree.
6. While the *Remaining Servers* is non-empty pick next name server IP address
and zone name from the set ("Server Address" and "Zone Name") and do:
1. Extract and remove *Server Address* including its *Zone Name* from
*Remaining Servers*.
2. Insert *Server Address* and *Zone Name* into *Handled Servers*.
3. Create [DNS queries][DNS Query]:
1. Query type SOA and query name *Zone Name* ("Zone Name SOA Query").
2. Query type NS and query name *Zone Name* ("Zone Name NS Query").
4. [Send] *Zone Name SOA Query* to *Server Address*.
5. Output [B01_SERVER_ZONE_ERROR] with query name *Zone Name*, [query type]
SOA and name server IP *Server Address* and go to next server in
*Remaining Servers* if one or more of the following matches:
* No DNS response.
* [RCODE Name] different from NoError in response.
* AA bit not set in response.
* Not exactly one SOA record in answer section
* Owner name of SOA record is not *Zone Name*.
6. [Send] *Zone Name NS Query* to *Server Address*.
7. Output [B01_SERVER_ZONE_ERROR] with query name *Zone Name*, [query type]
NS and name server IP *Server Address* and go to next server in
*Remaining Servers* if one or more of the following matches:
* No DNS response.
* [RCODE Name] different from NoError in response.
* AA bit not set in response.
* No NS records in answer section
* Owner name of any of the NS records is not *Zone Name*.
8. Extract the name server names from the NS records and any address records
in the additional section.
9. Do [DNS Lookup] of name server names (A and AAAA) not already listed in the
additional section of the response.
1. For each IP address add the IP address and *Zone Name* to the
*Remaining Servers* set unless the IP address is already listed in
*Handled Servers* together with *Zone Name*.
2. Ignore any failing lookups or lookups resulting in NODATA or NXDOMAIN.
10. Create "Intermediate Query Name" by copying *Zone name* as start value.
11. Run a loop processing *Server Address* (jumps back here from the steps
below).
1. Extend *Intermediate Query Name* by adding one more label to the left
by copying the equivalent label from *Child Zone*. (See "Example 1"
below.)
2. Create a [DNS Query] with query name
*Intermediate Query Name* and [query type] SOA
("Intermediate SOA query").
3. [Send] *Intermediate SOA Query* to *Server Address*. (See "Example 2"
below.)
4. Output [B01_SERVER_ZONE_ERROR] with query name *Intermediate Query Name*
and [query type] SOA and name server IP *Server Address* and go to next
server in *Remaining Servers* if there is no DNS response.
5. If the response has exactly one SOA record with owner name
*Intermediate Query Name* in the answer section, with the AA bit
set and [RCODE Name] NoError then do:
1. If *Intermediate Query Name* is equal to *Child Zone* then
1. Save *Server Address* and *Zone Name* to the *Parent Found* set
and to the *AA SOA Found* set.
2. Go to next server in *Remaining Servers*.
2. Else do:
1. Create a [DNS query][DNS Query] with query name
*Intermediate Query Name* and [query type] NS
("Intermediate NS query").
2. [Send] *Intermediate NS Query* to *Server Address*.
3. Output [B01_SERVER_ZONE_ERROR] with query name
*Intermediate NS Name* and [query type] NS and name server IP
*Server Address* and go to next server in *Remaining Servers* if
one or more of the following matches:
* No DNS response.
* [RCODE Name] different from NoError in response.
* AA bit not set in response.
* No NS records in answer section.
* Owner name of any of the NS records is not *Intermediate Query Name*.
4. Extract the name server names from the NS records and any address
records in the additional section.
5. Do [DNS Lookup] of name server names (A and AAAA) not already
listed in the additional section of the response.
6. For each IP address add the IP address and *Intermediate Query Name*
to the *Remaining Servers* set unless the IP address is already
listed in *Handled Servers* together with *Intermediate Query Name*.
7. Set *Zone Name* to *Intermediate Query Name*.
8. Go back to the start of the loop.
6. Else, if the [RCODE Name] is NXDomain and the AA is set then do:
1. Save *Server Address* and *Zone Name* to the *AA NXDomain Found* set
and the *Parent Found* set.
2. Go to next server in *Remaining Servers*.
7. Else, if the response contains a [Referral] of *Intermediate Query Name*
then do:
1. If *Intermediate Query Name* is equal to *Child Zone* then do:
1. Save *Server Address* and *Zone Name* to the *Parent Found* set
and to the *Delegation Found* set.
2. Else do:
1. Extract the name server names from the NS records and any glue
records.
2. Do [DNS Lookup] of name server names (A and AAAA) not already
listed as glue record or records.
3. For each IP address add *Server Address* and
*Intermediate Query Name* to the *Remaining Servers* set unless
*Server Address* is already listed in *Handled Servers* together
with *Intermediate Query Name*.
3. Go to next server in *Remaining Servers*.
8. Else, if the [RCODE Name] is NoError and the AA is set then do:
1. If *Intermediate Query Name* is not equal to *Child Zone* then
go back to the start of the loop.
2. Else do:
1. If the response has a CNAME record with *Child Zone* as owner
name in the answer section, then do:
1. Save *Server Address* and *Zone Name* to the *Parent Found*
set and to the *AA CNAME Found* set.
2. Go to next server in *Remaining Servers*.
2. Else do:
1. [Send] a *DNAME Child Query* to the name server IP address.
2. If there is a response with the AA flag set, the [RCODE Name]
NoError and a DNAME record with *Child Zone* as owner name in
the answer section, then
1. Save *Server Address* and *Zone Name* to the *Parent Found*
set.
2. Save *Server Address*, *Zone Name* and the DNAME target
(RDATA value) to the *AA DNAME Found* set.
3. Else (no response or some other response than above) save the
*Server Address* and *Zone Name* to the *Parent Found* set
and to the *AA NODATA Found* set.
4. Go to next server in *Remaining Servers*.
9. Else, if the response is a [Referral] with a CNAME record with
*Child Zone* as owner name in the answer section, then
1. Save *Server Address* and *Zone Name* to the *Parent Found* set and
to the *CNAME with Referral Found* set.
2. Go to next server in *Remaining Servers*.
10. Else, output [B01_SERVER_ZONE_ERROR] with query name
*Intermediate NS Name*, [query type] SOA and name server IP
*Server Address* and go to next server in *Remaining Servers*.
7. If the *Parent Found* set is non-empty, then
1. For each parent zone name output *[B01_PARENT_FOUND]*, parent zone name
and the set of name server IP addresses for that name.
2. If not all members of the set have the same parent zone then output
*[B01_PARENT_UNDETERMINED]* and the whole set of name server IP addresses.
8. If the *Parent Found* set is empty, then output *[B01_PARENT_NOT_FOUND]*.
9. If one or both of the *Delegation Found* and the *AA SOA Found* sets are
non-empty, then do:
1. Output *[B01_CHILD_FOUND]* with *Child Zone*.
2. If one or more of the following five sets are also non-empty then output
*[B01_INCONSISTENT_DELEGATION]* with *Child Zone*, parent zone name and
the combined set of name server IP addresses from all five sets.
* *AA NXDomain Found*
* *AA CNAME Found*
* *CNAME with Referral Found*
* *AA DNAME Found*
* *AA NODATA Found*
10. If both of the *Delegation Found* and the *AA SOA Found* sets are empty, then
do:
1. Create "Superdomain" as a copy of *Child Zone* with the first label
removed.
2. Output *[B01_NO_CHILD]* with *Child zone* and *Superdomain*.
11. If the *AA DNAME Found* set is non-empty then do:
1. For each DNAME target in the set output *[B01_CHILD_IS_ALIAS]* with name
server IP list, *Child Zone* and the DNAME target.
2. If not all members of the set have the same DNAME target, output
*[B01_INCONSISTENT_ALIAS]* with *Child Zone*.
> Examples referred to from the steps.
>
> Example 1: If *Child Zone* is "foo.bar.xa" and *Intermediate Query Name* is "."
> (root zone) then *Intermediate Query Name* becomes "xa". If it is "xa", it
> will become "bar.xa" instead.
>
> Example 2: An "bar.xa SOA" query to a name server for "xa".
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message with
the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level *[INFO]* or
*[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, skip [Sending][Send]
queries over that transport protocol. A message will be outputted reporting that
the transport protocol has been skipped.
The *Child Zone* must be a valid name meeting
"[Requirements and normalization of domain names in input]".
## Intercase dependencies
None.
## Terminology
* "Direct Subdomain" - Domain A is considered to be a "direct Subdomain" to
domain B if domain A is just the addition of one label at the least significant
(left) side, e.g. "foo.domain.com" is a direct subdomain to "domain.com".
* "DNS Lookup" - The term is used when a recursive lookup is used, though
any changes to the DNS tree introduced by an [undelegated test] must be
respected. Compare with "[Send]".
* "Non-Referral" - See "[Referral]".
* "Referral" - A DNS response with [RCODE Name] NoError, AA flag unset and NS
records in the authority section. The answer section is empty or with CNAME
record or records. If the query type is CNAME, then the answer section must be
empty (does not apply to this test case). The additional section may contain
address records (A and AAAA) for the name server names from the NS (glue
records).
* "Send" - The term "send" (to an IP address) is used when a DNS query is sent to
a specific name server. Compare with "[DNS Lookup]".
[Argument list]: ../ArgumentsForTestCaseMessages.md
[B01_CHILD_FOUND]: #Summary
[B01_CHILD_IS_ALIAS]: #Summary
[B01_INCONSISTENT_ALIAS]: #Summary
[B01_INCONSISTENT_DELEGATION]: #Summary
[B01_NO_CHILD]: #Summary
[B01_PARENT_DISREGARDED]: #Summary
[B01_PARENT_FOUND]: #Summary
[B01_PARENT_NOT_FOUND]: #Summary
[B01_PARENT_UNDETERMINED]: #Summary
[B01_ROOT_HAS_NO_PARENT]: #Summary
[B01_SERVER_ZONE_ERROR]: #Summary
[Basic03]: basic03.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[Direct Subdomain]: #terminology
[DNS Lookup]: #terminology
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNS Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dns-query
[DNS Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dns-response
[ERROR]: ../SeverityLevelDefinitions.md#error
[Get parent zone]: ../MethodsV2.md#method-get-parent-ns-names-and-ip-addresses
[INFO]: ../SeverityLevelDefinitions.md#info
[List of Root Servers]: https://www.iana.org/domains/root/servers
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[Non-referral]: #terminology
[Query type]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Referral]: #terminology
[Requirements and normalization of domain names in input]: ../RequirementsAndNormalizationOfDomainNames.md
[RFC 9156]: https://www.rfc-editor.org/rfc/rfc9156.html
[Send]: #terminology
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Test procedure]: #test-procedure
[Undelegated test]: ../../test-types/undelegated-test.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

208
zonemaster/docs/public/specifications/tests/Basic-TP/basic02.md Normal file
View File

@@ -0,0 +1,208 @@
# BASIC02: The domain must have at least one working name server
## Test case identifier
**BASIC02**
## Table of contents
* [Objective](#Objective)
* [Scope](#Scope)
* [Inputs](#Inputs)
* [Summary](#Summary)
* [Test procedure](#Test-procedure)
* [Outcome(s)](#Outcomes)
* [Special procedural requirements](#Special-procedural-requirements)
* [Intercase dependencies](#Intercase-dependencies)
* [Terminology](#terminology)
## Objective
In order for the domain to work, it must have at least one name server that can
answer queries about the domain. This test case will verify that.
## Scope
If this test fails, it is not meaningful to continue Zonemaster testing and the
whole testing process, except for the [Basic03] test, is aborted.
## Inputs
* The domain name to be tested ("Child Zone").
* "Test Type" - The test type with values "[undelegated test]" or
"normal test".
* If undelegated test:
* The list of name servers for *the child zone* ("Undelegated NS").
* Any IP addresses of the [in-bailiwick] *undelegated NS*
("Undelegated Glue IP").
* Any IP addresses of the [out-of-bailiwick] *undelegated NS*
("Undelegated Non-Glue IP").
## Summary
Message Tag | Level | Arguments | Message ID for message tag
:--------------------|:---------|:--------------|:--------------------------
B02_AUTH_RESPONSE_SOA| INFO |ns_list, domain| Authoritative answer on SOA query for "{domain}" is returned by name servers "{ns_list}".
B02_NO_DELEGATION | CRITICAL | domain | There is no delegation (name servers) for "{domain}" which means it does not exist as a zone.
B02_NO_WORKING_NS | CRITICAL | domain | There is no working name server for "{domain}" so it is unreachable.
B02_NS_BROKEN | ERROR | ns | Broken response from name server "{ns}" on an SOA query.
B02_NS_NOT_AUTH | ERROR | ns | Name server "{ns}" does not give an authoritative answer on an SOA query.
B02_NS_NO_IP_ADDR | ERROR | nsname | Name server "{nsname}" cannot be resolved into an IP address.
B02_NS_NO_RESPONSE | WARNING | ns | Name server "{ns}" does not respond to an SOA query.
B02_UNEXPECTED_RCODE | ERROR | ns, rcode | Name server "{ns}" responds with an unexpected RCODE name ("{rcode}") on an SOA query.
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
## Test procedure
In this section and unless otherwise specified below, the terms "[DNS Query]"
follow the specification for DNS queries as specified in
[DNS Query and Response Defaults]. The handling of the DNS responses on the DNS
queries follow, unless otherwise specified below, what is specified for
[DNS Response] in the same specification.
1. Create a [DNS Query] with query type SOA and query name *Child Zone*
("SOA Query").
2. Create the following empty sets:
1. Name server name and IP address ("Auth Response on SOA Query").
2. Name server name and IP address ("Broken NS").
3. Name server name and IP address ("NS not auth").
4. Name server name ("NS Cannot Resolve Into IP").
5. Name server name and IP address ("No Response From NS").
6. Name server name, IP address and [RCODE Name] ("Unexpected RCODE").
7. Name server name with IP address set ("Delegation NS").
3. Populate the set *Delegation NS* with name and the set of IP addresses for
each name from the name servers of the delegation of *Child Zone*.
1. If the test is an undelegated test, then:
1. Use *Undelegated NS*, *Undelegated Glue IP* and
*Undelegated Non-Glue IP*.
2. If any [out-of-bailiwick] name server name in the set has no IP address
then do a recursive lookup for address records (both IPv4 and IPv6) for
that name and add resolved addresses, if any, to the set.
2. Else, do:
1. Retrieve the NS records for *Child Zone* using [Method 2] and the IP
addresses ([glue records][glue record]) for any [in-bailiwick] name
servers using [Method 4].
2. Retrieve the IP addresses for any [out-of-bailiwick] name servers
using recursive lookup for address records (both IPv4 and IPv6) for
that name and add resolved addresses, if any, to the set.
4. If the *Delegation NS* set is empty, then do:
1. Output *[B02_NO_DELEGATION]* with *Child Zone* name.
2. Exit these test procedures.
5. Else, for each name server name in the *Delegation NS* set do:
1. If the name server name has no IP address then add the name server name to
the *NS Cannot Resolve Into IP* set.
2. Else, for each IP address for the name server name do:
1. Send *SOA Query* to the name server IP.
2. If there is no [DNS Response], then add the name server name and IP
address to the *No Response From NS* set.
3. Else, if the [RCODE Name] is not "NoError" in the [DNS Response], then
add the name server name, IP address and the [RCODE Name] to the
*Unexpected RCODE* set.
4. Else, if the AA flag is not set in the [DNS Response], then add the name
server name and IP address to the *NS not auth* set.
5. Else do:
1. If the answer section in the [DNS Response] contains an SOA record
with *Child Zone* as owner name, then add the name server name and IP
address to the *Auth Response on SOA Query* set.
2. Else, add the name server name and IP address to the *Broken NS* set.
6. If the *Auth Response on SOA Query* set is non-empty, then:
1. Output *[B02_AUTH_RESPONSE_SOA]* with a list of name server name and IP
address pairs derived from the set and with *Child Zone* name.
2. Exit these test procedures.
7. Else do:
1. Output *[B02_NO_WORKING_NS]* with *Child Zone* name.
2. If the *Broken NS* set is non-empty then for each name server name and IP
address pair from the set output *[B02_NS_BROKEN]* with the pair.
3. If the *NS not auth* set is non-empty then for each name server name and IP
address pair from the set output *[B02_NS_NOT_AUTH]* with the pair.
4. If the *NS Cannot Resolve Into IP* set is non-empty then for each name
server name output *[B02_NS_NO_IP_ADDR]* with the name server name.
5. If the *No Response From NS* set is non-empty then for each name server name
and IP address pair from the set output *[B02_NS_NO_RESPONSE]* with the
pair.
6. If the *Unexpected RCODE* set is non-empty then for each name server name
and IP address pair from the set output *[B02_UNEXPECTED_RCODE]* with the
pair and the [RCODE Name] for that pair in the set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, skip sending queries over that
transport protocol. A message will be outputted reporting that the transport
protocol has been skipped.
The *Child Zone* must be a valid name meeting
"[Requirements and normalization of domain names in input]".
## Terminology
The terms "in-bailiwick", "out-of-bailiwick" and "glue record" are defined in
[RFC 8499], section 7, pages 24-25. In this document, the term "in-bailiwick"
is limited to the meaning "in domain" in [RFC 8499]. The term "out-of-bailiwick"
means what is not "in-bailiwick, in domain", in this document.
## Intercase dependencies
None.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[B02_AUTH_RESPONSE_SOA]: #outcomes
[B02_NO_DELEGATION]: #outcomes
[B02_NO_WORKING_NS]: #outcomes
[B02_NS_BROKEN]: #outcomes
[B02_NS_NOT_AUTH]: #outcomes
[B02_NS_NO_IP_ADDR]: #outcomes
[B02_NS_NO_RESPONSE]: #outcomes
[B02_UNEXPECTED_RCODE]: #outcomes
[Basic03]: basic03.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNS Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dns-query
[DNS Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dns-response
[ERROR]: ../SeverityLevelDefinitions.md#error
[Glue record]: #terminology
[INFO]: ../SeverityLevelDefinitions.md#info
[In-bailiwick]: #terminology
[Method 2]: ../Methods.md#method-2-obtain-glue-name-records-from-parent
[Method 4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[Out-of-bailiwick]: #terminology
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 8499]: https://datatracker.ietf.org/doc/html/rfc8499#section-7
[Requirements and normalization of domain names in input]: ../RequirementsAndNormalizationOfDomainNames.md
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Undelegated test]: ../../test-types/undelegated-test.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

40
zonemaster/docs/public/specifications/tests/Basic-TP/basic03.md Normal file
View File

@@ -0,0 +1,40 @@
## BASIC03: The _Broken but functional_ test
### Test case identifier
**BASIC03** The _Broken but functional_ test
### Objective
The case where the delegation for a domain is too broken to be fully
tested but functional enough for simple web browsing should be detected.
This test should only be performed if the BASIC02 test has failed, in
order to explain why the domain seemingly works but otherwise is
untestable.
### Inputs
The label of the domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve the IP addresses from the parent delegation using [Method 4](
../Methods.md#method-4-obtain-glue-address-records-from-parent). For name
server that are out-of-bailiwick, do separate recursive queries to retrieve
the IP addresses of those names.
2. An A query for the child domain name with the label 'www' prepended is
sent to each address from the input parameters, and the responses
recorded.
3. If no answer from the above queries contain any A record, this test
fails.
### Outcome(s)
If at least one recorded response contains at least one A record for the
requested name, this test succeeds.
### Special procedural requirements
This test should only be performed if the BASIC02 test has failed.
### Intercase dependencies
Only perform this test if BASIC02 fails.

18
zonemaster/docs/public/specifications/tests/Connectivity-TP/README.md Normal file
View File

@@ -0,0 +1,18 @@
# Connectivity Test Plan
This document uses the terminology defined in the [Master Test Plan].
[Master Test Plan]: ../MasterTestPlan.md
[Test Case README]: ../README.md
<!-- Content until EOF generated by script updateTestPlanReadme.pl from Zonemaster/Zonemaster utils directory -->
## Test cases list
|Test Case |Test Case Description|
|:---------|:--------------------|
|[CONNECTIVITY01](connectivity01.md)|UDP connectivity to name servers|
|[CONNECTIVITY02](connectivity02.md)|TCP connectivity to name servers|
|[CONNECTIVITY03](connectivity03.md)|AS Diversity|
|[CONNECTIVITY04](connectivity04.md)|IP Prefix Diversity|

219
zonemaster/docs/public/specifications/tests/Connectivity-TP/connectivity01.md Normal file
View File

@@ -0,0 +1,219 @@
# CONNECTIVITY01: UDP connectivity to name servers
## Test case identifier
**CONNECTIVITY01**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
UDP is the fundamental protocol to reach a general purpose name server hosting
a zone, "DNS servers MUST be able to service UDP \[...]" ([RFC 1123], section
6.1.3.2, page 75), also restated in [RFC 7766][RFC 7766#5], section 5.
This Test Case will verify if the name servers of *Child Zone* are reachable over
UDP. The name servers tested are both those in the delegation of *Child Zone* and
those in the NS records in the *Child Zone* itself.
Most Zonemaster Test Cases will query the name servers in the delegation or the
name servers appointed by the NS records in the zone for the NS or SOA record,
or both. It is crucial that problems are reported, but instead of letting several
Test Cases report the same problems found, most Test Cases assume that this test
case is run. Only this Test Case will report problems found in the following
areas over UDP:
* Name Server not responding to a query without EDNS.
* Name Server not including SOA record of *Child Zone* in the answer section in
the response on a SOA query for *Child Zone*.
* Name Server not including NS record of *Child Zone* in the answer section in
the response on an NS query for *Child Zone*.
* Name Server not setting the AA flag in a response with SOA or NS in answer
section.
* Name Server responding with unexpected [RCODE Name] (any except "NoError") on
query for SOA or NS for *Child Zone*.
In addition, this test case will output a message if transport over IPv4 or IPv6
has been disabled.
## Scope
The only UDP port defined for DNS is port 53 ([RFC 1035][RFC 1035#4.2.1], section
4.2.1), and that is the only port used by this and other Test Cases for DNS
queries to the name servers.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
Message Tag |Level |Arguments | Message ID for message tag
:-----------------------------------|:------|:----------|:------------------------------------------------------------------------------------------
CN01_IPV4_DISABLED | NOTICE| ns_list | IPv4 is disabled. No DNS queries are sent to these name servers: "{ns_list}".
CN01_IPV6_DISABLED | NOTICE| ns_list | IPv6 is disabled. No DNS queries are sent to these name servers: "{ns_list}".
CN01_MISSING_NS_RECORD_UDP |WARNING| ns | Nameserver {ns} responds to a NS query with no NS records in the answer section over UDP.
CN01_MISSING_SOA_RECORD_UDP |WARNING| ns | Nameserver {ns} responds to a SOA query with no SOA records in the answer section over UDP.
CN01_NO_RESPONSE_NS_QUERY_UDP |WARNING| ns | Nameserver {ns} does not respond to NS queries over UDP.
CN01_NO_RESPONSE_SOA_QUERY_UDP |WARNING| ns | Nameserver {ns} does not respond to SOA queries over UDP.
CN01_NO_RESPONSE_UDP |WARNING| ns | Nameserver {ns} does not respond to any queries over UDP.
CN01_NS_RECORD_NOT_AA_UDP |WARNING| ns | Nameserver {ns} does not give an authoritative response on an NS query over UDP.
CN01_SOA_RECORD_NOT_AA_UDP |WARNING| ns | Nameserver {ns} does not give an authoritative response on an SOA query over UDP.
CN01_UNEXPECTED_RCODE_NS_QUERY_UDP |WARNING| ns, rcode | Nameserver {ns} responds with an unexpected RCODE ({rcode}) on an NS query over UDP.
CN01_UNEXPECTED_RCODE_SOA_QUERY_UDP |WARNING| ns, rcode | Nameserver {ns} responds with an unexpected RCODE ({rcode}) on an SOA query over UDP.
CN01_WRONG_NS_RECORD_UDP |WARNING| ns, domain_found, domain_expected | Nameserver {ns} responds with a wrong owner name ({domain_found} instead of {domain_expected}) on NS queries over UDP.
CN01_WRONG_SOA_RECORD_UDP |WARNING| ns, domain_found, domain_expected | Nameserver {ns} responds with a wrong owner name ({domain_found} instead of {domain_expected}) on SOA queries over UDP.
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
## Test procedure
In this section and unless otherwise specified below, the term "[DNS Query]"
follows the specification for DNS queries as specified in
[DNS Query and Response Defaults]. The handling of the DNS responses on the DNS
queries follow, unless otherwise specified below, what is specified for
[DNS Response] in the same specification.
1. Create [DNS Queries][DNS Query]:
1. Query type SOA and query name *Child Zone* ("SOA Query").
1. Query type NS and query name *Child Zone* ("NS Query").
2. Obtain the set of name server IP addresses using [Method4] and [Method5]
("Name Server IP").
3. If IPv4 is disabled then do:
1. Extract all name servers with IPv4 address from *Name Server IP*.
2. If the set of IPv4 name servers is non-empty then output
*[CN01_IPV4_DISABLED]* with the set of IPv4 name servers (names and IP
addresses).
4. If IPv6 is disabled then do:
1. Extract all name servers with IPv6 address from *Name Server IP*.
2. If the set of IPv6 name servers is non-empty then output
*[CN01_IPV6_DISABLED]* with the set of IPv6 name servers (names and IP
addresses).
5. For each name server in *Name Server IP* do:
1. Send *SOA Query* and *NS Query* to the name server and collect
the [DNS Responses][DNS Response].
2. If there is no DNS response on neither query, then:
1. Output *[CN01_NO_RESPONSE_UDP]* with name and IP address of the name
server.
2. Go to next name server.
3. Else:
1. Process the response on *SOA Query*:
1. If there is no [DNS response], then output
*[CN01_NO_RESPONSE_SOA_QUERY_UDP]* with name and IP address of the
name server.
2. Else, if [RCODE Name] is not "NoError" then output
*[CN01_UNEXPECTED_RCODE_SOA_QUERY_UDP]* with [RCODE Name] and name
and IP address of the name server.
3. Else, if there is no SOA record in the answer section, then
output *[CN01_MISSING_SOA_RECORD_UDP]* with name and IP address of
the name server.
4. Else, if the SOA record has owner name other than *Child Zone*
then output *[CN01_WRONG_SOA_RECORD_UDP]* with name and IP address of
the name server, the SOA record owner name and *Child Zone*.
5. Else, if AA flag is unset, then output *[CN01_SOA_RECORD_NOT_AA_UDP]*
with name and IP address of the name server.
2. Process the response on *NS Query*:
1. If there is no [DNS Response], then output
*[CN01_NO_RESPONSE_NS_QUERY_UDP]* with name and IP address of the
name server.
2. Else, if [RCODE Name] is not "NoError" then output
*[CN01_UNEXPECTED_RCODE_NS_QUERY_UDP]* with [RCODE Name] and name and
IP address of the name server.
3. Else, if there is no NS record in the answer section, then
output *[CN01_MISSING_NS_RECORD_UDP]* with name and IP address of the
name server.
4. Else, if the NS record has owner name other than *Child Zone*
then output *[CN01_WRONG_NS_RECORD_UDP]* with name and IP address of
the name server, the NS record owner name and *Child Zone*.
5. Else, if AA flag is unset, then output *[CN01_NS_RECORD_NOT_AA_UDP]*
with name and IP address of the name server.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, skip sending queries over that
transport protocol.
## Intercase dependencies
None.
## Terminology
No special terminology for this test case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[Basic02]: basic02.md
[CN01_IPV4_DISABLED]: #summary
[CN01_IPV6_DISABLED]: #summary
[CN01_MISSING_NS_RECORD_UDP]: #summary
[CN01_MISSING_SOA_RECORD_UDP]: #summary
[CN01_NO_RESPONSE_NS_QUERY_UDP]: #summary
[CN01_NO_RESPONSE_SOA_QUERY_UDP]: #summary
[CN01_NO_RESPONSE_UDP]: #summary
[CN01_NS_RECORD_NOT_AA_UDP]: #summary
[CN01_SOA_RECORD_NOT_AA_UDP]: #summary
[CN01_UNEXPECTED_RCODE_NS_QUERY_UDP]: #summary
[CN01_UNEXPECTED_RCODE_SOA_QUERY_UDP]: #summary
[CN01_WRONG_NS_RECORD_UDP]: #summary
[CN01_WRONG_SOA_RECORD_UDP]: #summary
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DEBUG]: ../SeverityLevelDefinitions.md#notice
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNS Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dns-query
[DNS Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dns-response
[ERROR]: ../SeverityLevelDefinitions.md#error
[INFO]: ../SeverityLevelDefinitions.md#info
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 1035#4.2.1]: https://www.rfc-editor.org/rfc/rfc1035#section-4.2.1
[RFC 1123]: https://www.rfc-editor.org/rfc/rfc1123
[RFC 7766#5]: https://www.rfc-editor.org/rfc/rfc7766#section-5
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

194
zonemaster/docs/public/specifications/tests/Connectivity-TP/connectivity02.md Normal file
View File

@@ -0,0 +1,194 @@
# CONNECTIVITY02: TCP connectivity to name servers
## Test case identifier
**CONNECTIVITY02**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
TCP is a protocol to reach a general purpose name server hosting a zone, "All
general-purpose DNS implementations MUST support \[...] TCP transport"
([RFC 7766][RFC 7766#5], section 5).
This Test Case will verify if the name servers of *Child Zone* are reachable over
TCP. The name servers tested are both those in the delegation of *Child Zone* and
those in the NS records in the *Child Zone* itself.
This Test Case will mimic the tests done by [Connectivity01], but over TCP
instead:
* Name Server responding to a query.
* Name Server including SOA record of *Child Zone* in the answer section in the
response on a SOA query for *Child Zone*.
* Name Server including NS record of *Child Zone* in the answer section in the
response on an NS query for *Child Zone*.
* Name Server setting the AA flag in a response with SOA or NS in answer section.
* Name Server responding with expected [RCODE Name] ("NoError") on query for SOA
or NS for *Child Zone*.
## Scope
The only TCP port defined for DNS is port 53 ([RFC 1035][RFC 1035#4.2.1], section
4.2.1), and that is the only port used by this and other Test Cases for DNS
queries to the name servers.
UDP connectivity is tested by Test Case [Connectivity01].
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
Message Tag |Level |Arguments | Message ID for message tag
:-----------------------------------|:------|:----------|:---------------------------------------------------------------------------------------
CN02_MISSING_NS_RECORD_TCP |WARNING| ns | Nameserver {ns} responds to a NS query with no NS records in the answer section over TCP.
CN02_MISSING_SOA_RECORD_TCP |WARNING| ns | Nameserver {ns} responds to a SOA query with no SOA records in the answer section over TCP.
CN02_NO_RESPONSE_NS_QUERY_TCP |WARNING| ns | Nameserver {ns} does not respond to NS queries over TCP.
CN02_NO_RESPONSE_SOA_QUERY_TCP |WARNING| ns | Nameserver {ns} does not respond to SOA queries over TCP.
CN02_NO_RESPONSE_TCP |WARNING| ns | Nameserver {ns} does not respond to any queries over TCP.
CN02_NS_RECORD_NOT_AA_TCP |WARNING| ns | Nameserver {ns} does not give an authoritative response on an NS query over TCP.
CN02_SOA_RECORD_NOT_AA_TCP |WARNING| ns | Nameserver {ns} does not give an authoritative response on an SOA query over TCP.
CN02_UNEXPECTED_RCODE_NS_QUERY_TCP |WARNING| ns, rcode | Nameserver {ns} responds with an unexpected RCODE ({rcode}) on an NS query over TCP.
CN02_UNEXPECTED_RCODE_SOA_QUERY_TCP |WARNING| ns, rcode | Nameserver {ns} responds with an unexpected RCODE ({rcode}) on an SOA query over TCP.
CN02_WRONG_NS_RECORD_TCP |WARNING| ns, , domain_found, domain_expected | Nameserver {ns} responds with a wrong owner name ({domain_found} instead of {domain_expected}) on NS queries over TCP.
CN02_WRONG_SOA_RECORD_TCP |WARNING| ns, , domain_found, domain_expected | Nameserver {ns} responds with a wrong owner name ({domain_found} instead of {domain_expected}) on SOA queries over TCP.
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
## Test procedure
In this section and unless otherwise specified below, the term "[DNS Query]"
follows the specification for DNS queries as specified in
[DNS Query and Response Defaults]. The handling of the DNS responses on the DNS
queries follow, unless otherwise specified below, what is specified for
[DNS Response] in the same specification.
1. Create [DNS Queries][DNS Query]:
1. Query type SOA and query name *Child Zone* over TCP ("SOA Query TCP").
1. Query type NS and query name *Child Zone* over TCP ("NS Query TCP").
2. Obtain the set of name server IP addresses using [Method4] and [Method5]
("Name Server IP").
3. For each name server in *Name Server IP* do:
1. Send *SOA Query TCP* and *NS Query TCP* to the name server and collect
the [DNS Responses][DNS Response].
2. If there is no DNS response on neither query, then:
1. Output *[CN02_NO_RESPONSE_TCP]* with name and IP address of the name
server.
2. Go to next name server.
3. Else:
1. Process the response on *SOA Query TCP*:
1. If there is no [DNS response], then output
*[CN02_NO_RESPONSE_SOA_QUERY_TCP]* with name and IP address of the
name server.
2. Else, if [RCODE Name] is not "NoError" then output
*[CN02_UNEXPECTED_RCODE_SOA_QUERY_TCP]* with [RCODE Name] and name
and IP address of the name server.
3. Else, if there is no SOA record in the answer section, then
output *[CN02_MISSING_SOA_RECORD_TCP]* with name and IP address of
the name server.
4. Else, if the SOA record has owner name other than *Child Zone*
then output *[CN02_WRONG_SOA_RECORD_TCP]* with name and IP address of
the name server, the SOA record owner name and *Child Zone*.
5. Else, if AA flag is unset, then output *[CN02_SOA_RECORD_NOT_AA_TCP]*
with name and IP address of the name server.
2. Process the response on *NS Query TCP*:
1. If there is no [DNS Response], then output
*[CN02_NO_RESPONSE_NS_QUERY_TCP]* with name and IP address of the
name server.
2. Else, if [RCODE Name] is not "NoError" then output
*[CN02_UNEXPECTED_RCODE_NS_QUERY_TCP]* with [RCODE Name] and name and
IP address of the name server.
3. Else, if there is no NS record in the answer section, then
output *[CN02_MISSING_NS_RECORD_TCP]* with name and IP address of the
name server.
4. Else, if the NS record has owner name other than *Child Zone*
then output *[CN02_WRONG_NS_RECORD_TCP]* with name and IP address of
the name server, the NS record owner name and *Child Zone*.
5. Else, if AA flag is unset, then output *[CN02_NS_RECORD_NOT_AA_TCP]*
with name and IP address of the name server.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, skip sending queries over that
transport protocol.
## Intercase dependencies
None.
## Terminology
No special terminology for this Test Case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[CN02_MISSING_NS_RECORD_TCP]: #summary
[CN02_MISSING_SOA_RECORD_TCP]: #summary
[CN02_NO_RESPONSE_NS_QUERY_TCP]: #summary
[CN02_NO_RESPONSE_SOA_QUERY_TCP]: #summary
[CN02_NO_RESPONSE_TCP]: #summary
[CN02_NS_RECORD_NOT_AA_TCP]: #summary
[CN02_SOA_RECORD_NOT_AA_TCP]: #summary
[CN02_UNEXPECTED_RCODE_NS_QUERY_TCP]: #summary
[CN02_UNEXPECTED_RCODE_SOA_QUERY_TCP]: #summary
[CN02_WRONG_NS_RECORD_TCP]: #summary
[CN02_WRONG_SOA_RECORD_TCP]: #summary
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[Connectivity01]: connectivity01.md
[DEBUG]: ../SeverityLevelDefinitions.md#notice
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNS Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dns-query
[DNS Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dns-response
[ERROR]: ../SeverityLevelDefinitions.md#error
[INFO]: ../SeverityLevelDefinitions.md#info
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 1035#4.2.1]: https://www.rfc-editor.org/rfc/rfc1035#section-4.2.1
[RFC 7766#5]: https://www.rfc-editor.org/rfc/rfc7766#section-5
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

206
zonemaster/docs/public/specifications/tests/Connectivity-TP/connectivity03.md Normal file
View File

@@ -0,0 +1,206 @@
# CONNECTIVITY03: AS Diversity
## Test case identifier
**CONNECTIVITY03**
## Objective
The objective in this test is to verify that all IP addresses of the domain's
authoritative name servers are announced from different ASNs (autonomous system
number). See [RFC 1930] and [Wikipedia] for an explanation of AS (autonomous
system).
This test is done separately on IPv4 and IPv6, and both must match the criterion.
[RFC 2182][RFC 2182#3.1], section 3.1, clearly specifies that distinct authoritative
name servers for a child domain should be placed in different topological and
geographical locations. The objective is to minimise the likelihood of a single
failure disabling all of them.
## Inputs
* "Child Zone" - The domain name to be tested.
* "ASN Database" - The database of ASN data to be used. Possible values
are "RIPE" and "Cymru" (the default value).
* "Cymru Base Name" - If the *ASN Database* is "Cymru", the default value
is "asnlookup.zonemaster.net".
* "Ris Whois Server" - If the *ASN Database* is "RIPE", the default value
is "riswhois.ripe.net".
## Ordered description of steps to be taken to execute the test case
1. Obtain the total set of IP addresses of the name servers for the
*Child Zone* using [Method4] and [Method5] and split those IP addresses
into one set of IPv4 addresses ("NS IPv4") and one set of IPv6 addresses
("NS IPv6"). (One of two sets may be empty.)
2. For each IP address in the set *NS IPv4* and *NS IPv6*, respectively,
determine the ASN set announcing the IP address using either the
*[Cymru database]* or the *[RIPE database]* as described in separate
sections below. Create two sets of ASN data ("NS IPv4 ASN" and
"NS IPv6 ASN", respectively).
3. Analyze the *NS IPv4 ASN* set:
1. If *NS IPv4 ASN* is empty (no IPv4 address) do nothing.
2. Else, if all IPv4 addresses are announced from one and the same ASN, output
*[IPV4_ONE_ASN]*.
3. Else, if all IPv4 addresses are announced from the same set of multiple
ASNs, output *[IPV4_SAME_ASN]*.
4. Else, output *[IPV4_DIFFERENT_ASN]*.
4. Analyze the *NS IPv6 ASN* set:
1. If *NS IPv6 ASN* is empty (no IPv6 address) do nothing.
2. Else, if all IPv6 addresses are announced from one and the same ASN, output
*[IPV6_ONE_ASN]*.
3. Else, if all IPv6 addresses are announced from the same set of multiple
ASNs, output *[IPV6_SAME_ASN]*.
4. Else, output *[IPV6_DIFFERENT_ASN]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one
message with the severity level ERROR or CRITICAL.
The outcome of this Test Case is "warning" if there is at least
one message with the severity level WARNING, but no message with
severity level ERROR or CRITICAL.
In other cases the outcome of this Test Case is "pass".
Message |Default severity level
:------------------|:------------
EMPTY_ASN_SET |NOTICE
ERROR_ASN_DATABASE |NOTICE
IPV4_ONE_ASN |WARNING
IPV4_SAME_ASN |NOTICE
IPV4_DIFFERENT_ASN |INFO
IPV6_ONE_ASN |WARNING
IPV6_SAME_ASN |NOTICE
IPV6_DIFFERENT_ASN |INFO
## Special procedural requirements
This test case is dependent on one of two possible services that can provide
ASN lookup, RIPE or Cymru. The service must be available over the network.
### Cymru ASN lookup
The Cymru lookup method is described on the Team Cymru [IP to ASN Mapping]
using DNS lookup, but the default data comes from [bgp.tools] (Port 179 Ltd
in England and Wales) and is continuously being mapped into
`asnlookup.zonemaster.net` by the Zonemaster project. Data is fetched from
<https://bgp.tools/table.txt>. The Cymru source can also be used, if
requested.
1. Prepend the *Cymru Base Name* with the label "origin" (IPv4) or
"origin6" (IPv6). Example of expanded basenames
("expanded base name"):
```
origin.asnlookup.zonemaster.net
origin6.asnlookup.zonemaster.net
```
2. Reverse the IP address with the same method as is used for
reverse lookup. For description see [RFC 1035][RFC 1035#3.5], section 3.5,
for IPv4 and [RFC 3596][RFC 3596#2.5], section 2.5, for IPv6.
3. Prepend the *expanded base name* with the reversed IP address. For
description see [IP to ASN Mapping].
4. Send a DNS query for the TXT record of the full name created in step 3.
5. If either the DNS response has RCODE "NXDOMAIN" or the DNS response
has RCODE "NOERROR" but empty answer section, output
*[EMPTY_ASN_SET]* and end these steps for Cymru look-up of the specific
IP address.
6. If there is no response (timeout) or the DNS response does not have
the RCODE "NOERROR", output *[ERROR_ASN_DATABASE]* and
end these steps for Cymru look-up of the specific IP address.
8. The expected response is a non-empty string in the TXT record or
records. See [IP to ASN Mapping] for examples.
9. Do the following:
1. Split the string or strings into fields.
2. If there are multiple strings (TXT records), ignore all strings
except for the string with the most specific subnet.
3. Extract the ASN or ASNs.
4. If it was not possible to extract the ASN or ASNs, output
*[ERROR_ASN_DATABASE]* and end these steps for Cymru look-up of
the specific IP address (the response was malformed).
10. Create the ASN set, for the IP address, from the ASN or ASNs from
the steps above and use it for the further processing.
### RIPE ASN lookup
The RIPE ASN lookup is described on the RIPE [RISwhois] page.
1. Construct a query string by prepending the IP address with
" -F -M ". Using "192.0.2.10" as an example, the query string will
be the following (the leading space is intentional)
```
" -F -M 192.0.2.10"
```
2. Send the query string to the *Ris Whois Server* on port
43 with the nicname (whois) protocol. Example of command
line command on unix:
```
whois -h riswhois.ripe.net " -F -M 192.0.2.10"
```
3. Do the following:
1. The non-empty line not prepended with "%" contains the string
with data (no or one such line).
2. Check if there is no string with data (empty reply). If so,
output *[EMPTY_ASN_SET]* and end these steps for RIPE look-up
of the specific IP address.
3. If there is no response from the *Ris Whois Server*, output
*[ERROR_ASN_DATABASE]* and end these steps for RIPE look-up
of the specific IP address.
4. The first field has the ASN or list of ASNs. Split that into ASNs.
5. If it was not possible to extract the ASN or ASNs, output
*[ERROR_ASN_DATABASE]* and end these steps (the response was
malformed).
8. Create the ASN set, for the IP address, from the ASN or ASNs from
the steps above and use it for the further processing.
## Intercase dependencies
None
[Bgp.tools]: https://bgp.tools/
[Cymru database]: #cymru-asn-lookup
[EMPTY_ASN_SET]: #outcomes
[ERROR_ASN_DATABASE]: #outcomes
[IP to ASN Mapping]: https://www.team-cymru.com/ip-asn-mapping
[IPV4_DIFFERENT_ASN]: #outcomes
[IPV4_ONE_ASN]: #outcomes
[IPV4_SAME_ASN]: #outcomes
[IPV6_DIFFERENT_ASN]: #outcomes
[IPV6_ONE_ASN]: #outcomes
[IPV6_SAME_ASN]: #outcomes
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[RFC 1035#3.5]: https://datatracker.ietf.org/doc/html/rfc1035#section-3.5
[RFC 1930]: https://datatracker.ietf.org/doc/html/rfc1930
[RFC 2182#3.1]: https://datatracker.ietf.org/doc/html/rfc2182#section-3.1
[RFC 3596#2.5]: https://datatracker.ietf.org/doc/html/rfc3596#section-2.5
[RIPE database]: #ripe-asn-lookup
[RISwhois]: https://www.ripe.net/analyse/archived-projects/ris-tools-web-interfaces/riswhois
[Wikipedia]: https://en.wikipedia.org/wiki/Autonomous_system_(Internet)

282
zonemaster/docs/public/specifications/tests/Connectivity-TP/connectivity04.md Normal file
View File

@@ -0,0 +1,282 @@
# CONNECTIVITY04: IP Prefix Diversity
## Test case identifier
**CONNECTIVITY04**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Prefix lookup methods](#prefix-lookup-methods)
* [Cymru prefix lookup](#cymru-prefix-lookup)
* [RIPE prefix lookup](#ripe-prefix-lookup)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
The objective in this Test Case is to verify that all IP addresses of the
domain's authoritative name servers are not announced from the same IP prefix.
[RFC 2182, section 3.1][RFC 2182#3.1], clearly specifies that distinct authoritative
name servers for a child domain should be placed in different topological and
geographical locations. The objective is to minimise the likelihood of a single
failure disabling all of them.
## Scope
It is assumed that *Child Zone* is also tested and reported by [Connectivity01].
This Test Case will just ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server.
## Inputs
* "Child Zone" - The domain name to be tested.
* "Prefix Database" - The database of IP Prefix data to be used. Possible values
are "RIPE" and "Cymru" (the default value).
* "Cymru Base Name" - If the *Prefix Database* is "Cymru", the default value
is "asnlookup.zonemaster.net".
* "RIS Whois Server" - If the *Prefix Database* is "RIPE", the default value
is "riswhois.ripe.net".
## Summary
Message Tag | Level | Arguments | Message ID for message tag
:---------------------------|:--------|:----------------------------|:------------------------------------------------------------------------------------------------
CN04_EMPTY_PREFIX_SET | NOTICE | ns_ip | Prefix database returned no information for IP address {ns_ip}.
CN04_ERROR_PREFIX_DATABASE | NOTICE | ns_ip | Prefix database error for IP address {ns_ip}.
CN04_IPV4_DIFFERENT_PREFIX | INFO | ns_list | The following name server(s) are announced in unique IPv4 prefix(es): "{ns_list}"
CN04_IPV4_SAME_PREFIX | NOTICE | ns_list, ip_prefix | The following name server(s) are announced in the same IPv4 prefix ({ip_prefix}): "{ns_list}"
CN04_IPV4_SINGLE_PREFIX | WARNING | | All name server(s) IPv4 address(es) are announced in the same IPv4 prefix.
CN04_IPV6_DIFFERENT_PREFIX | INFO | ns_list | The following name server(s) are announced in unique IPv6 prefix(es): "{ns_list}"
CN04_IPV6_SAME_PREFIX | NOTICE | ns_list, ip_prefix | The following name server(s) are announced in the same IPv6 prefix ({ip_prefix}): "{ns_list}"
CN04_IPV6_SINGLE_PREFIX | WARNING | | All name server(s) IPv6 address(es) are announced in the same IPv6 prefix.
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine Profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [Argument List].
## Test procedure
1. Create the following empty sets:
1. IP prefix, name server name and IP address ("IPv4 Prefix")
2. IP prefix, name server name and IP address ("IPv6 Prefix")
2. Obtain the set of name server names and IP addresses using
[Get-Del-NS-Names-and-IPs] and [Get-Zone-NS-Names-and-IPs] in [MethodsV2] and
split those into IPv4 and IPv6 ("NS IPv4" and "NS IPv6", respectively).
3. For each IP address in *NS IPv4* and *NS IPv6* ("NS IP Address"),
respectively, do:
1. Determine the IP prefix in which *NS IP Address* is announced
using *Prefix Database*. Go to [Prefix Lookup Methods] section below
with the IP address as input.
2. Add found IP prefix, if any, with *NS IP Address* and name server name
to the *IPv4 Prefix* and *IPv6 Prefix* sets, respectively.
4. If the *IPv4 Prefix* set is non-empty, then do:
1. For each IP prefix in the set that has two or more members, output
*[CN04_IPV4_SAME_PREFIX]* with the prefix and list of all members (name
server names and IP addresses) for that prefix.
2. For all IP prefixes in the set that have exactly one member, output
*[CN04_IPV4_DIFFERENT_PREFIX]* with the combined set of their associated
members (name server names and IP addresses).
3. If all members of *NS IPv4* are members of the same IP prefix in
*IPv4 Prefix* then output *[CN04_IPV4_SINGLE_PREFIX]*.
5. If the *IPv6 Prefix* set is non-empty, then do:
1. For each IP prefix in the set that has two or more members, output
*[CN04_IPV6_SAME_PREFIX]* with the prefix and list of all members (name
server names and IP addresses) for that prefix.
2. For all IP prefixes in the set that have exactly one member, output
*[CN04_IPV6_DIFFERENT_PREFIX]* with the combined set of their associated
members (name server names and IP addresses).
3. If all members of *NS IPv6* are members of the same IP prefix in
*IPv6 Prefix* then output *[CN04_IPV6_SINGLE_PREFIX]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
This Test Case is dependent on one of two possible services that can provide
ASN lookup (Cymru or RIPE RIS). The service must be available over the network.
The *Child Zone* must be a valid name meeting
"[Requirements and normalization of domain names in input]".
## Prefix lookup methods
Use the prefix method set in *Prefix Database* and the IP address in the call to
this section. Refer to the appropriate section below with the IP address as
input.
### Cymru prefix lookup
The Cymru prefix lookup is described on the Team Cymru [IP to ASN Mapping]
using DNS lookup, but the default data comes from [bgp.tools] (Port 179 Ltd
in England and Wales) and is continuously being mapped into
`asnlookup.zonemaster.net` by the Zonemaster project. Data is fetched from
<https://bgp.tools/table.txt>. The Cymru source can also be used, if
requested.
1. Input is the IP address in the call to this section ("Input IP").
2. Prepend the *Cymru Base Name* with the label "origin" (IPv4) or
"origin6" (IPv6) ("Expanded Base Name"). Example of expanded basenames :
```
origin.asnlookup.zonemaster.net
origin6.asnlookup.zonemaster.net
```
3. Reverse *Input IP* with the same method as is used for reverse lookup
("Reverse IP"). For description see [RFC 1035][RFC 1035#3.5], section 3.5, for
IPv4 and [RFC 3596][RFC 3596#2.5], section 2.5, for IPv6.
4. Prepend the *Expanded Base Name* with *Reverse IP* ("Query Name").
See [IP to ASN Mapping] for details.
5. Create a [DNS Query] with query type TXT and query name *Query Name*.
("TXT Query").
6. Do [DNS Lookup] of *TXT Query*.
7. If at least one of the following criteria is met, output
*[CN04_EMPTY_PREFIX_SET]* and exit this lookup:
1. The [DNS Response] has the [RCODE Name] NXDomain.
2. The [DNS Response] has the [RCODE Name] NoError and an empty answer section.
8. If at least one of the following criteria is met, output
*[CN04_ERROR_PREFIX_DATABASE]* and exit this lookup:
1. There is no DNS response.
2. The [DNS Response] does not have the [RCODE Name] NoError.
3. The answer section has no TXT record.
9. Extract the TXT record(s) from the answer section (see [IP to ASN Mapping]
for examples). Do for each TXT record:
1. If the TXT record consists of multiple strings in RDATA, then [concatenate]
the strings into one string.
2. Using the format of such string parse the string into its parts and
extract the subnet specification.
1. If it was not possible to parse the string, ignore it and go to next TXT
record.
3. If *Input IP* does not match the extracted subnet, output
*[CN04_ERROR_PREFIX_DATABASE]*, break the processing of TXT records and
exit this loop without returning any prefix.
4. Store the extracted prefix.
10. If more than one IP prefix was stored from the loop above, keep the most
specific and discard the rest.
11. If no IP prefix was stored, output *[CN04_EMPTY_PREFIX_SET]*.
12. Return the IP prefix, or an empty string if no IP prefix was stored.
### RIPE prefix lookup
The RIPE Prefix lookup is described on the RIPE [RISwhois] page.
1. Create a query string by prepending the IP address with
" -F -M " ("WHOIS String"). E.g., using IP address "192.0.2.10":
```
" -F -M 192.0.2.10"
```
2. Create a WHOIS query (port 43 with the nicname ((whois)) protocol)
using the *WHOIS String* ("WHOIS Query"). E.g., on Linux:
```
whois -h riswhois.ripe.net " -F -M 192.0.2.10"
```
3. [Send] *WHOIS Query* to the *RIS Whois Server*.
4. If there is no response, output *[CN04_ERROR_PREFIX_DATABASE]* and exit this lookup.
5. Extract the string (non-empty line not prepended with "%") from the response, and do:
1. If there is no such string, output *[CN04_EMPTY_PREFIX_SET]* and exit this lookup.
2. Extract the IP prefix from the second field of the string.
3. If it was not possible to extract the IP prefix (i.e., malformed response),
output *[CN04_ERROR_PREFIX_DATABASE]* and exit this lookup.
6. Return the IP prefix.
## Intercase dependencies
None
## Terminology
* "Concatenate" - The term is used to refer to the conversion of a TXT
resource record’s data to a single contiguous string, as specified in [RFC
7208, section 3.3][RFC7208#3.3].
* "DNS Lookup" - The term is used when a recursive lookup is used, though
any changes to the DNS tree introduced by an [undelegated test] must be
respected. Compare with "[Send]".
* "Send" - The term "send" (to an IP address) is used when a DNS query is sent to
a specific name server IP address. Compare with "[DNS Lookup]".
[Argument List]: ../ArgumentsForTestCaseMessages.md
[Bgp.tools]: https://bgp.tools/
[CN04_EMPTY_PREFIX_SET]: #outcomes
[CN04_ERROR_PREFIX_DATABASE]: #outcomes
[CN04_IPV4_DIFFERENT_PREFIX]: #outcomes
[CN04_IPV4_SAME_PREFIX]: #outcomes
[CN04_IPV4_SINGLE_PREFIX]: #outcomes
[CN04_IPV6_DIFFERENT_PREFIX]: #outcomes
[CN04_IPV6_SAME_PREFIX]: #outcomes
[CN04_IPV6_SINGLE_PREFIX]: #outcomes
[Concatenate]: #terminology
[Connectivity01]: connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[Cymru Database]: #cymru-prefix-lookup
[DEBUG]: ../SeverityLevelDefinitions.md#notice
[DNS Lookup]: #terminology
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNS Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dns-query
[DNS Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dns-response
[ERROR]: ../SeverityLevelDefinitions.md#error
[Get-Del-NS-Names-and-IPs]: ../MethodsV2.md#method-get-delegation-ns-names-and-ip-addresses
[Get-Zone-NS-Names-and-IPs]: ../MethodsV2.md#method-get-zone-ns-names-and-ip-addresses
[INFO]: ../SeverityLevelDefinitions.md#info
[IP to ASN Mapping]: https://www.team-cymru.com/ip-asn-mapping
[MethodsV2]: ../MethodsV2.md
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[Prefix Lookup Methods]: #prefix-lookup-methods
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[Requirements and normalization of domain names in input]: ../RequirementsAndNormalizationOfDomainNames.md
[RFC 1035#3.5]: https://datatracker.ietf.org/doc/html/rfc1035#section-3.5
[RFC 2182#3.1]: https://datatracker.ietf.org/doc/html/rfc2182#section-3.1
[RFC 3596#2.5]: https://datatracker.ietf.org/doc/html/rfc3596#section-2.5
[RFC7208#3.3]: https://datatracker.ietf.org/doc/html/rfc7208#section-3.3
[RIPE Database]: #ripe-prefix-lookup
[RISwhois]: https://www.ripe.net/analyse/archived-projects/ris-tools-web-interfaces/riswhois
[Send]: #terminology
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Undelegated test]: ../../test-types/undelegated-test.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine Profile]: ../../../configuration/profiles.md

20
zonemaster/docs/public/specifications/tests/Consistency-TP/README.md Normal file
View File

@@ -0,0 +1,20 @@
# Consistency Test Plan
This document uses the terminology defined in the [Master Test Plan].
[Master Test Plan]: ../MasterTestPlan.md
[Test Case README]: ../README.md
<!-- Content until EOF generated by script updateTestPlanReadme.pl from Zonemaster/Zonemaster utils directory -->
## Test cases list
|Test Case |Test Case Description|
|:---------|:--------------------|
|[CONSISTENCY01](consistency01.md)|SOA serial number consistency|
|[CONSISTENCY02](consistency02.md)|SOA RNAME consistency|
|[CONSISTENCY03](consistency03.md)|SOA timers consistency|
|[CONSISTENCY04](consistency04.md)|Name server NS consistency|
|[CONSISTENCY05](consistency05.md)|Consistency between glue and authoritative data|
|[CONSISTENCY06](consistency06.md)|SOA MNAME consistency|

139
zonemaster/docs/public/specifications/tests/Consistency-TP/consistency01.md Normal file
View File

@@ -0,0 +1,139 @@
# CONSISTENCY01: SOA serial number consistency
## Test case identifier
**CONSISTENCY01**
## Objective
For the data served by the authoritative name servers for a designated zone
to be consistent, all authoritative name servers must serve the same SOA
record for the designated zone.
If the serial number (explained in 3.3.13. of [RFC 1035]),
which is part of the SOA record, is not consistent between authoritative servers,
there is a possibility that the data served is inconsistent. The reasons for this
inconsistency may be different - such as misconfiguration, or as a result of slow
propagation to the secondary name servers.
The objective of this test is to verify that the serial number is consistent
between different authoritative name servers.
For reference purposes : [RFC 1982]
explains the serial number arithmetic, and section 4.3.5 of
[RFC 1034] explains the importance of
serial number consistency.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* "Child Zone" - The domain name to be tested
* "Accepted Serial Difference" - Accepted difference between SOA serial
values from SOA records of different name servers for *Child Zone*.
Default value is 0, i.e. no difference.
## Ordered description of steps to be taken to execute the test case
1. Obtain the list of name server IPs for the *Child Zone* from [Method4]
and [Method5] ("Name Server IP").
2. Create an SOA query for *Child Zone* name (the top of the zone).
3. Create an empty set of pair of retrieved SOA serials and name server
name and IP ("SOA Serial Set").
3. For each name server in *Name Server IP* do:
1. Send the SOA query to the name server.
2. If the name server does not respond with a DNS response, then
output *[NO_RESPONSE]*.
3. Or, if the name server returns a DNS response, but no SOA
record is included, then output *[NO_RESPONSE_SOA_QUERY]*.
4. Or, retrieve the SOA SERIAL from the response and add it to
*SOA Serial Set* (unless it is already there) and update the set
with the name server name and IP.
4. If *SOA Serial Set* has exactly one SOA serial value, then output
*[ONE_SOA_SERIAL]*.
5. Or, if *SOA Serial Set* has at least two SOA serials values, then do:
1. Order the serial number values from *SOA Serial Set* from smallest
to largest following the arithmetic for serial number, if possible.
2. If there is not a single, uniquely defined order of the serial
numbers, then output *[SOA_SERIAL_VARIATION]* and
*[MULTIPLE_SOA_SERIALS]*.
3. Or, if the difference between the first and the last serial number
is larger than *Accepted Serial Difference*, using arithmetic
for serial number, then output *[SOA_SERIAL_VARIATION]* and
*[MULTIPLE_SOA_SERIALS]*.
4. Or, if the difference between the first and the last serial number
is not larger than *Accepted Serial Difference*, using arithmetic
for serial number, output *[MULTIPLE_SOA_SERIALS_OK]*.
6. For each SOA serial value in *SOA Serial Set*, output *[SOA_SERIAL]*
with the serial number and a semicolon separated list of name server
names and IP address pairs (name/IP).
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level (if message is emitted)
:-----------------------------|:-----------------------------------
NO_RESPONSE | DEBUG
NO_RESPONSE_SOA_QUERY | DEBUG
ONE_SOA_SERIAL | INFO
MULTIPLE_SOA_SERIALS | WARNING
MULTIPLE_SOA_SERIALS_OK | NOTICE
SOA_SERIAL | INFO
SOA_SERIAL_VARIATION | NOTICE
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
A manual inspection of the SOA serial may be needed to determine if the zone
updates work properly or not, and if the serial values are within a
reasonable range, then the test is OK.
When comparing SOA serial it must be done using the arithmetic defined in
[RFC 1982].
## Intercase dependencies
None
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[MULTIPLE_SOA_SERIALS]: #outcomes
[MULTIPLE_SOA_SERIALS_OK]: #outcomes
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NO_RESPONSE]: #outcomes
[NO_RESPONSE_SOA_QUERY]: #outcomes
[ONE_SOA_SERIAL]: #outcomes
[RFC 1034]: https://datatracker.ietf.org/doc/html/rfc1035
[RFC 1035]: https://datatracker.ietf.org/doc/html/rfc1035
[RFC 1982]: https://datatracker.ietf.org/doc/html/rfc1982
[SOA_SERIAL]: #outcomes
[SOA_SERIAL_VARIATION]: #outcomes

82
zonemaster/docs/public/specifications/tests/Consistency-TP/consistency02.md Normal file
View File

@@ -0,0 +1,82 @@
# CONSISTENCY02: SOA RNAME consistency
## Test case identifier
**CONSISTENCY02**
## Objective
All authoritative name servers must serve the same SOA record for the
tested domain (section 4.2.1 of [RFC 1034]). As per section 3.3.13 of [RFC 1035],
the RNAME field in the SOA RDATA refers to the administrative contact. An inconsistency in
the administrative contact for the domain might result in operational
failures being reported to different persons.
The objective of this test is to verify that the administrative contact is
consistent between different authoritative name servers.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* The domain name to be tested ("Child Zone")
## Ordered description of steps to be taken to execute the test case
1. Obtain the list of name server IPs for the *Child Zone* from [Method4]
and [Method5].
2. Create an SOA query for *Child Zone* apex and send it to all name
server IPs.
3. Retrieve the SOA RR from the responses from all name server IPs.
4. If a name server does not respond, emit *[NO_RESPONSE]*.
5. If a name server responds but does not include a SOA record
in the response, emit *[NO_RESPONSE_SOA_QUERY]*.
6. If at least one SOA record has been retrieved and RNAME is
identical in all SOA records, emit *[ONE_SOA_RNAME]*.
7. If RNAME is not identical in all SOA records, emit
*[MULTIPLE_SOA_RNAMES]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level (if message is emitted)
:-----------------------------|:-----------------------------------
NO_RESPONSE | DEBUG
NO_RESPONSE_SOA_QUERY | DEBUG
ONE_SOA_RNAME | INFO
MULTIPLE_SOA_RNAMES | NOTICE
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
## Intercase dependencies
None
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[MULTIPLE_SOA_RNAMES]: #outcomes
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NO_RESPONSE]: #outcomes
[NO_RESPONSE_SOA_QUERY]: #outcomes
[ONE_SOA_RNAME]: #outcomes
[RFC 1034]: https://datatracker.ietf.org/doc/html/rfc1034
[RFC 1035]: https://datatracker.ietf.org/doc/html/rfc1035
[RFC 1982]: https://datatracker.ietf.org/doc/html/rfc1982

95
zonemaster/docs/public/specifications/tests/Consistency-TP/consistency03.md Normal file
View File

@@ -0,0 +1,95 @@
# CONSISTENCY03: SOA timers consistency
## Test case identifier
**CONSISTENCY03**
## Objective
All SOA record timer fields must be consistent across all authoritative
name servers. An inconsistency in these fields might result in operational
inconsistencies for the designated zone.
There are other test cases that provide consistency tests for the other
SOA fields:
* [CONSISTENCY01] (SOA Serial)
* [CONSISTENCY02] (RNAME)
* [CONSISTENCY06] (MNAME)
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* The domain name to be tested ("Child Zone").
## Ordered description of steps to be taken to execute the test case
1. Create an SOA query for *Child Zone* apex.
2. Obtain the list of name server IPs for the *Child Zone* from [Method4]
and [Method5].
3. Send the SOA query to all name server IPs.
4. If a name server does not respond, emit *[NO_RESPONSE]*.
5. If a name server responds but no SOA record is included in the
response, emit *[NO_RESPONSE_SOA_QUERY]*.
6. Retrieve the SOA RR from the responses from all name server IPs.
7. Emit *[ONE_SOA_TIME_PARAMETER_SET]* if at least one SOA record has
been retrieved and all SOA records have:
1. the same REFRESH value,
2. the same RETRY value,
3. the same EXPIRE value, and
4. the same MINIMUM value.
8. Emit *[MULTIPLE_SOA_TIME_PARAMETER_SET]* if any two SOA
records had different values in previous step.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level (if message is emitted)
:--------------------------------|:-----------------------------------
NO_RESPONSE | DEBUG
NO_RESPONSE_SOA_QUERY | DEBUG
ONE_SOA_TIME_PARAMETER_SET | INFO
MULTIPLE_SOA_TIME_PARAMETER_SET | NOTICE
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
## Intercase dependencies
None.
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CONSISTENCY01]: consistency01.md
[CONSISTENCY02]: consistency02.md
[CONSISTENCY06]: consistency06.md
[MULTIPLE_SOA_TIME_PARAMETER_SET]: #outcomes
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NO_RESPONSE]: #outcomes
[NO_RESPONSE_SOA_QUERY]: #outcomes
[ONE_SOA_TIME_PARAMETER_SET]: #outcomes

90
zonemaster/docs/public/specifications/tests/Consistency-TP/consistency04.md Normal file
View File

@@ -0,0 +1,90 @@
# CONSISTENCY04: Name server NS consistency
## Test case identifier
**CONSISTENCY04**
## Objective
All authoritative name servers must serve the same NS record set
for the tested domain, child zone ([RFC 1034], section 4.2.2).
Any inconsistencies in NS records described in [RFC 1035],
section 3.3.11, might result in operational failures.
The objective of this test is to verify that the NS records are
consistent between all authoritative name servers of the child zone.
Two NS RR sets are considered to be equal if both sets have the
same number of NS records, and for each NS record in one of the
sets there is exactly one NS record with identical owner name,
class, TTL and RDATA in the other NS set.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* The domain name to be tested ("Child Zone").
## Ordered description of steps to be taken to execute the test case
1. Obtain the set of name server IPs for the *Child Zone* using
[Method4] and [Method5].
2. Create an NS query for the apex of the *Child Zone*.
3. Send the NS query to each of the retrieved name server IPs.
4. If a name server IP does not respond, emit *[NO_RESPONSE]*.
5. If the response from a name server IP does not include an
NS RR set for the *Child Zone* with the AA flag set, emit
*[NO_RESPONSE_NS_QUERY]*.
6. If all retrieved NS RR sets are equal, emit *[ONE_NS_SET]*. Otherwise,
emit *[MULTIPLE_NS_SET]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level (if message is emitted)
:-----------------------------|:-----------------------------------
NO_RESPONSE | DEBUG
NO_RESPONSE_NS_QUERY | DEBUG
ONE_NS_SET | INFO
MULTIPLE_NS_SET | NOTICE
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
## Intercase dependencies
None
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[MULTIPLE_NS_SET]: #outcomes
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NO_RESPONSE]: #outcomes
[NO_RESPONSE_NS_QUERY]: #outcomes
[ONE_NS_SET]: #outcomes
[RFC 1034]: https://datatracker.ietf.org/doc/html/rfc1034
[RFC 1035]: https://datatracker.ietf.org/doc/html/rfc1035

205
zonemaster/docs/public/specifications/tests/Consistency-TP/consistency05.md Normal file
View File

@@ -0,0 +1,205 @@
# CONSISTENCY05: Consistency between glue and authoritative data
## Test case identifier
**CONSISTENCY05**
## Objective
For name servers that have IP addresses listed as glue, the IP addresses must
match the authoritative A and AAAA records for that host. This is an IANA
[name server requirement].
The objective of this test is to verify that the [glue records][terminology]
in the delegation are consistent with authoritative data.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* "Child Zone" - The domain name to be tested.
## Ordered description of steps to be taken to execute the test case
1. Obtain the set of name server names from the NS records in the
delegation of *Child Zone* using [Method2] and any glue IP addresses
from the same delegation using [Method4].
1. Extract the [in-bailiwick][terminology] name server names and create the set
"Delegation Strict Glue", where each name server name
is matched with its IP address or addresses, if available. (The
set may be empty.)
2. Extract the [out-of-bailiwick][terminology] name server names and create the
set "Delegation Extended Glue", where each name server name
is matched with its IP address or addresses, if available. (The
set may be empty.)
2. Obtain the set of name server names for the *Child Zone* using
[Method2] and [Method3] and extract the [in-bailiwick][terminology] name
server names, "IB NS Name Set". (The set may be empty.)
3. Create an empty set of name server name with associated IP address
or addresses, "Address Records From Child".
4. If *IB NS Name Set* is non-empty, obtain the set of name server IP
addresses, "NS IP", for *Child Zone* using [Method4] and [Method5].
5. If *IB NS Name Set* is non-empty, then for each name server name in
that set do:
1. Create one A query and one AAAA query with the RD flag unset
and name server name as owner name.
2. For each name server in *NS IP* and for each record
types (A, AAAA):
1. Send the address query to the name server.
2. If there is no DNS response from the server, then
output *[NO_RESPONSE]*.
3. Or, if the response is a delegation (referral) to a
sub-zone of *Child Zone*, then:
1. Copy the address query (A, AAAA) that gave the referral
response.
2. Set the RD flag in the copied query (from unset to set).
3. Do a [DNS Lookup][terminology] of the query.
4. If the lookup returns the relevant address record or records,
A for A record query and AAAA for AAAA record query, and
with the same owner name as in the query (i.e. CNAME should
not be followed), then extract those and add to
*Address Records From Child* with name and IP
address or addresses.
4. Or, if the response has the AA flag unset, then
output *[CHILD_NS_FAILED]*.
5. Or, if the RCODE of the response is neither NOERROR nor
NXDOMAIN, then output *[CHILD_NS_FAILED]*.
6. Or, if the RCODE is NOERROR (with the AA flag set), then
extract any address records (A, AAAA) from the answer
section whose owner name matches the owner name
of the query (i.e. CNAME should not be followed) and add
that or those to *Address Records From Child* with name and IP.
7. Else, there is nothing to do (i.e. RCODE is NXDOMAIN).
3. If all servers outputted *[NO_RESPONSE]* or *[CHILD_NS_FAILED]*,
then output *[CHILD_ZONE_LAME]* and completely stop processing
this test case.
6. Compare the IP address for the name servers from
*Delegation Strict Glue* with *Address Records From Child*
(i.e. [in-bailiwick][terminology] only).
1. If an IP from *Delegation Strict Glue* is not listed in
*Address Records From Child* with that same name server name,
then output *[IN_BAILIWICK_ADDR_MISMATCH]*.
2. If an IP from *Address Records From Child* is not listed in
*Delegation Strict Glue* with that same name server name, then
output *[EXTRA_ADDRESS_CHILD]*.
7. For each name server name in *Delegation Extended Glue*
(i.e. [out-of-bailiwick][terminology] only) ("DEG Name Server Name") do:
1. Do two [DNS Lookups][terminology], one record type A and one record type
AAAA, for *DEG Name Server Name* on public DNS and create a
set of the IP addresses from the A and AAAA records, respectively,
from the answer sections of the responses and that matches
the owner name of the query (i.e. CNAME should not be followed).
(The set will be empty if there are no relevant records in the
answer sections or if there is no response, e.g. SERVFAIL.)
2. For each IP address for *DEG Name Server Name* in
*Delegation Extended Glue* do:
1. If the address is not member of the IP address set created
in the previous DNS lookups, output
*[OUT_OF_BAILIWICK_ADDR_MISMATCH]*.
8. If none of *[IN_BAILIWICK_ADDR_MISMATCH]*, *[EXTRA_ADDRESS_CHILD]*
or *[OUT_OF_BAILIWICK_ADDR_MISMATCH]* has been outputted, output
*[ADDRESSES_MATCH]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
The outcome of this Test case is "pass" in all other cases.
Message | Default severity level (when message is outputted)
:---------------------------------|:-----------------------------------
CHILD_NS_FAILED | DEBUG
NO_RESPONSE | DEBUG
CHILD_ZONE_LAME | ERROR
IN_BAILIWICK_ADDR_MISMATCH | ERROR
OUT_OF_BAILIWICK_ADDR_MISMATCH | ERROR
EXTRA_ADDRESS_CHILD | NOTICE
ADDRESSES_MATCH | INFO
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol and log a message reporting
the ignored result.
If the test is an [undelegated test] then [Method2] and [Method4] will
include the provided input data instead of data from any real delegation
and authoritative data.
For an [undelegated test] it is possible to intentionally insert data
for [out-of-bailiwick][terminology] name servers that do not match what is found in
public DNS. This Test Case will then report this as an ERROR which
may not match the users expectation.
It is assumed that the name servers of the parent zone behave the same way
for the parent zone as when [BASIC01] was run.
## Intercase dependencies
None
## Terminology
The terms "in-bailiwick" and "out-of-bailiwick" are used as defined
in [RFC 7719], section 6, page 15.
The term "glue records" is defined in [RFC 7719], section 6, page 15.
Here we use "glue" in the wider sense.
When the term "using Method" is used, names and IP addresses are fetched
using the defined [Methods].
The term "send" (to an IP address) is used when a DNS query is sent to
a specific name server.
The term "DNS Lookup" is used when a recursive lookup is used, though
any changes to the DNS tree introduced by an [undelegated test] must be
respected.
[ADDRESSES_MATCH]: #outcomes
[BASIC01]: ../Basic-TP/basic01.md
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CHILD_NS_FAILED]: #outcomes
[CHILD_ZONE_LAME]: #outcomes
[DELEGATION05]: ../Delegation-TP/delegation05.md
[EXTRA_ADDRESS_CHILD]: #outcomes
[IN_BAILIWICK_ADDR_MISMATCH]: #outcomes
[Method2]: ../Methods.md#method-2-obtain-glue-name-records-from-parent
[Method3]: ../Methods.md#method-3-obtain-name-servers-from-child
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[Methods]: ../Methods.md
[NO_RESPONSE]: #outcomes
[OUT_OF_BAILIWICK_ADDR_MISMATCH]: #outcomes
[RFC 7719]: https://datatracker.ietf.org/doc/html/rfc7719
[UNDEL_OOB_ADDR_MISMATCH]: #outcomes
[name server requirement]: https://www.iana.org/help/nameserver-requirements
[terminology]: #terminology
[undelegated test]: ../../test-types/undelegated-test.md

91
zonemaster/docs/public/specifications/tests/Consistency-TP/consistency06.md Normal file
View File

@@ -0,0 +1,91 @@
# CONSISTENCY06: SOA MNAME consistency
## Test case identifier
**CONSISTENCY06**
## Objective
All authoritative name servers must serve the same SOA record (section
4.2.1) of [RFC 1034] for the tested domain. As per section 3.3.13 of
[RFC 1035] the MNAME field in the SOA RDATA refers to the name of
"the name server that was the original or primary source of data
for this zone". Inconsistency in MNAME of the domain might result in
operational failures for applications that uses MNAME.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* "Child Zone" - The domain name to be tested.
## Ordered description of steps to be taken to execute the test case
1. Obtain the set of name server IPs for the *Child Zone* from [Method4]
and [Method5] ("Name Server IP").
2. Create an SOA query for *Child Zone* apex.
3. For each name server in *Name Server IP* do:
1. Send the query to name server.
2. If the name server does not respond with a DNS response,
emit *[NO_RESPONSE]* for that name server and go to next server.
3. If the DNS response does not include a SOA record in the answer
section then emit *[NO_RESPONSE_SOA_QUERY]* for that server and go
to next server.
4. Retrieve the MNAME field from the SOA RR from the DNS response
and save that to compare it with the MNAME from the other name
servers.
4. Compare the MNAME fields retrieved from all name servers.
5. If at least one name server has responded with a SOA record and the
MNAME is identical in all SOA records retrieved, emit *[ONE_SOA_MNAME]*.
6. If MNAME is not identical in all SOA records retrieved, emit
*[MULTIPLE_SOA_MNAMES]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level (if message is emitted)
:-----------------------------|:-----------------------------------
NO_RESPONSE | DEBUG
NO_RESPONSE_SOA_QUERY | DEBUG
ONE_SOA_MNAME | INFO
MULTIPLE_SOA_MNAMES | NOTICE
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
## Intercase dependencies
None
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[MULTIPLE_SOA_MNAMES]: #outcomes
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NO_RESPONSE]: #outcomes
[NO_RESPONSE_SOA_QUERY]: #outcomes
[ONE_SOA_MNAME]: #outcomes
[RFC 1034]: https://datatracker.ietf.org/doc/html/rfc1035
[RFC 1035]: https://datatracker.ietf.org/doc/html/rfc1035

204
zonemaster/docs/public/specifications/tests/DNSQueryAndResponseDefaults.md Normal file
View File

@@ -0,0 +1,204 @@
# DNS Query and Response Defaults
**Table of contents**
* [Overview](#overview)
* [Application of this specification](#application-of-this-specification)
* [Default setting in *DNS Query*](#default-setting-in-dns-query)
* [Default setting in *EDNS Query*](#default-setting-in-edns-query)
* [Default setting in *DNSSEC Query*](#default-setting-in-dnssec-query)
* [Default handling of a *DNS Response*](#default-handling-of-a-dns-response)
* [Default handling of an *EDNS Response*](#default-handling-of-an-edns-response)
* [Default handling of a *DNSSEC response*](#default-handling-of-a-dnssec-response)
* [Appendix A: UDP Message size setting in EDNS][Appendix A]
## Overview
Almost all [test cases] emit DNS queries and react to the responses. This
document defines the default "setting" of a DNS query and the default handling
of "setting" in the DNS response. The meaning of "setting" here will be clear
from the specification below.
## Application of this specification
This specification applies to all [test case specifications][Test Cases] that has
an explicit reference to this document.
## Default setting in *DNS Query*
A *DNS Query* has the following default setting. A test case specification can
refer to a *DNS Query* with one or several changes to the *Parameters*
overriding the default values. If a *Parameter* is specified as "fixed" (with an
"X" in that column) then the default value cannot be overidden.
|Parameter |Default value |Fixed |Comment |
|:------------|:-------------|:-----|:-----------------------------|
|Protocol | UDP | | |
|OpCode | "query" | X | |
|QR flag | unset | X | |
|AA flag | unset | X | |
|TC flag | unset | X | |
|RD flag | unset | | |
|RA flag | unset | X | |
|AD flag | unset | | |
|CD flag | unset | | |
|RCODE | "NoError" | X | |
|Query Name | - | | Must be defined in test case |
|Query Type | - | | Must be defined in test case |
|Query Class | "IN" | | |
|EDNS | no | | No OPT record is included |
## Default setting in *EDNS Query*
An *EDNS Query* inherit the default setting from a *DNS Query* except for the
parameters specified below. If a *Parameter* is specified as "fixed" (with an
"X" in that column) then the default value cannot be overidden.
A test case specification can refer to an *EDNS Query* with one or several
changes to the *Parameters*.
| Parameter | Default value | Fixed | Comment |
|:----------------------|:--------------------|:------|:-----------------|
| EDNS | OPT record included | X | |
| EDNS UDP Message size | 512 | | See [Appendix A] |
| EDNS Extended RCODE | no | | |
| EDNS Version | 0 | | |
| EDNS DO flag | unset | | |
| EDNS Z flag | unset | | |
| EDNS0 Option | none | | |
## Default setting in *DNSSEC Query*
A *DNSSEC Query* inherits the default setting from an *EDNS Query* except for the
parameter specified below. If a *Parameter* is specified as "fixed" (with an
"X" in that column) then the default value cannot be overidden.
A test case specification can refer to a *DNSSEC Query* with one or several
changes to the Parameters.
| Parameter | Default value | Fixed | Comment |
|:----------------------|:--------------|:------|:-----------------|
| EDNS DO flag | set | X | |
| EDNS UDP Message size | 1232 | | See [Appendix A] |
| | | | |
## Default handling of a *DNS Response*
A *DNS Response* is a response to a *DNS Query*. Unless specified in the test
case specification, the items in the response are handled as listed in the table
below.
### Validation of DNS message
If a *Response Item* is specified as "fixed" (with an "X" in that column) then
the requirement, as specified under "Default handling", must be met for the
response to be considered to be a DNS response.
|Response Item |Default handling | Fixed | Comment |
|:-------------|:-----------------------------------------|:------|:---------------------|
|OpCode | Require value to be "response" | X | |
|QR flag | Require flag to be set | X | |
|AA flag | - | | Defined in test case |
|TC flag | Re-query over TCP if set | | |
|RD flag | ignore | | |
|RA flag | ignore | | |
|AD flag | ignore | | |
|CD flag | ignore | | |
|RCODE | - | | Defined in test case |
|Query Name | ignore | | |
|Query Type | ignore | | |
|Query Class | Require value to be same as in the query | | Normally "IN" |
|EDNS | ignore | | |
### Extraction of DNS records
* Owner name and record type of a DNS record are compared, by default, against
*Query Name* and *Query Type* in the question section in the query, not in the
response.
* When fetching records from the answer section, these are the default criteria:
* Only records matching *Query Name* and *Query Type* are fetched. Any
RRSIG records meeting the next criterion are also fetched.
* RRSIG records matching *Query Name* and covering *Query Type* are
fetched.
* CNAME records are ignored unless *Query Type* is CNAME.
* When the test case specification states that a CNAME chain is to be followed,
the default handling is to only follow a CNAME chain, and fetch the records, if
the CNAME chain is valid.
* The chain is, by default, considered to be valid if the following criteria
are met:
* It must be possible to arrange all CNAME records from the answer section
into a contiguous logical chain with a possible addition of a non-CNAME
record whose owner name matches the RDATA of the last CNAME record.
* The owner name of the first CNAME record in the chain must match
*Query Name*.
* The last record in the chain must either be a CNAME or a record matching
*Query Type*.
* For each owner name of the CNAME records in the chain there must not be any
additional records in the answer section with the same owner name besides
RRSIG and NSEC records (that may exist).
* CNAME records not part of a valid CNAME chain are by default ignored.
* Authority and additional sections are by default ignored.
The test case specification may prescribe that CNAME records are handled in a
different way than the default above.
## Default handling of an *EDNS Response*
An *EDNS response* is a response to an *EDNS Query*. An *EDNS Response* inherits
the default handling from a *DNS Response* except for the response items
specified below. Unless specified in the test case specification, the items in
the response are handled using the default handling.
|Response Item |Default handling | Comment |
|:-------------|:----------------------------|:---------------------------------------------------------------|
|EDNS | Take note if OPT is missing | Further actions to be specified in the test case specification |
## Default handling of a *DNSSEC response*
A *DNSSEC response* is a response to a *DNSSEC Query*. A *DNSSEC Response*
inherits the default handling from a *EDNS Response* except for the response
items specified below. Unless specified in the test case specification, the items
in the response are handled using the default handling.
|Response Item |Default handling | Comment |
|:-------------|:------------------------------- |:---------------------------------------------------------------|
| EDNS DO flag | Take note if DO flag is missing | Further actions to be specified in the test case specification |
## Appendix A: UDP Message size setting in EDNS
In non-DNSSEC messages the Zonemaster choice is to set the EDNS UDP Message size
to 512 to prevent any firewalls from blocking a response. This guarantees
that the response is never larger than the non-EDNS limit, assuming that
the remote server respects the setting.
In DNSSEC messages the Zonemaster choice is to set the EDNS UDP Message size to
a value that makes fragmentation unlikely, even though fragmentation of UDP
messages is supported. 1280 is the smallest MTU supported by IPv6. When 48 bytes
for IPv6 and UDP headers are removed the value is 1232 bytes, which is the
Zonemaster choice and also the recommendation in [DNS flag day 2020].
At the time of writing there is an active IETF draft, not yet an RFC, that
recommends 1400 bytes as the EDNS UDP Message size. See
[IP Fragmentation Avoidance in DNS over UDP].
Choosing a small value is permitted. It might result in more truncated responses
and requerying over TCP.
[Appendix A]: #appendix-a-udp-message-size-setting-in-edns
[DNS flag day 2020]: https://www.dnsflagday.net/2020/
[IP Fragmentation Avoidance in DNS over UDP]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/
[Test Cases]: README.md#list-of-defined-test-cases

59
zonemaster/docs/public/specifications/tests/DNSSEC-TP/README.md Normal file
View File

@@ -0,0 +1,59 @@
# DNSSEC Test Plan
These are the DNSSEC tests for a domain.
This document uses the terminology defined in the [Master Test Plan].
## Default DNS query flags for all DNSSEC tests
* Transport: UDP
* Bufsize: EDNS0 buffer size (512)
* Flags -- query flags
* do -- DNSSEC ok (1)
* cd -- Checking Disabled (1)
* rd -- Recursion Desired (0)
* ad -- Authenticated Data (0)
See section 3.2 of [RFC 4035]
for a description of the flags used by a recursive name server.
## Key, hash and signature algorithms
There are many algorithms defined for doing DNSSEC, not all of them are
mandatory to implement. This test case should strive not only to implement
all mandatory algorithms, but also most of those that are in use on the
internet today as well.
If any algorithm in a DNSSEC record type is not recognized by the test
system, the test system should emit a notice about this.
[Master Test Plan]: ../MasterTestPlan.md
[RFC 4035]: https://datatracker.ietf.org/doc/html/rfc4035#section-3.2
[Test Case README]: ../README.md
<!-- Content until EOF generated by script updateTestPlanReadme.pl from Zonemaster/Zonemaster utils directory -->
## Test cases list
|Test Case |Test Case Description|
|:---------|:--------------------|
|[DNSSEC01](dnssec01.md)|Legal values for the DS hash digest algorithm|
|[DNSSEC02](dnssec02.md)|DS must match a valid DNSKEY in the child zone|
|[DNSSEC03](dnssec03.md)|Verify NSEC3 parameters|
|[DNSSEC04](dnssec04.md)|Check for too short or too long RRSIG lifetimes|
|[DNSSEC05](dnssec05.md)|Check for invalid DNSKEY algorithms|
|[DNSSEC06](dnssec06.md)|Verify DNSSEC additional processing|
|[DNSSEC07](dnssec07.md)|DNSSEC signed zone and DS in parent for signed zone|
|[DNSSEC08](dnssec08.md)|Valid RRSIG for DNSKEY|
|[DNSSEC09](dnssec09.md)|RRSIG(SOA) must be valid and created by a valid DNSKEY|
|[DNSSEC10](dnssec10.md)|Zone contains NSEC or NSEC3 records|
|[DNSSEC11](dnssec11.md)|DS in delegation requires signed zone|
|[DNSSEC12](dnssec12.md)|Test for DNSSEC Algorithm Completeness|
|[DNSSEC13](dnssec13.md)|All DNSKEY algorithms used to sign the zone|
|[DNSSEC14](dnssec14.md)|Check for valid RSA DNSKEY key size|
|[DNSSEC15](dnssec15.md)|Existence of CDS and CDNSKEY|
|[DNSSEC16](dnssec16.md)|Validate CDS|
|[DNSSEC17](dnssec17.md)|Validate CDNSKEY|
|[DNSSEC18](dnssec18.md)|Validate trust from DS to CDS and CDNSKEY|

314
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec01.md Normal file
View File

@@ -0,0 +1,314 @@
# DNSSEC01: Legal values for the DS hash digest algorithm
## Test case identifier
**DNSSEC01**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Classification of algorithms]
* [Inputs](#inputs)
* [Summary]
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
A parent zone should only use digest algorithms for DS records that are
specified by specified by [RFC 8624][RFC 8624#3.3], section 3.3 (including the
update in [RFC 9157][RFC 9157#upd-8624]), and is published in the [IANA
registry][IANA registry on DS Digest Algorithm] of *DS RR Type Digest
Algorithms*. No DS Digest Algorithm values, other than those specified in the
RFC and allocated by IANA, should be used in public DNS.
A DS record for a public domain name (zone) should not use private digestet
algorithms.
Both [RFC 8624][RFC 8624#3.3] and [IANA registry][IANA registry on DS Digest
Algorithm] recommends digest algorithm 2 (SHA-256) to be used, and if there is a
DS record for a DNSKEY, but no DS record based on that digest algorithm, a
message is outputted as a NOTICE.
## Scope
This test case will query the name servers of the parent zone, and will just
ignore non-responsive name servers or name servers not giving a correct DNS
response for an authoritative name server, unless all such names servers fail in
which case a message is outputted.
The RDATA of a DS record consists of four fields. The third field specifies the
digest algorithm number of the data in the fourth field. This test case will
only check what the algorithm is used by checking the third field. It will not
verify that the key is matching the algorithm.
This test case does not report if the parent servers give inconsistent
responses.
If the *Child Zone* is the root zone, then it has no parent zone, and no DS
records can be fetch, but DS can be provided as *Undelegated DS*.
If *Undelegated DS* or *Undelegated NS* has been submitted, parent zone is not
queried for DS. *Undelegated DS*, if any, is used instead.
## Classification of algorithms
In the table below, the first two columns are copied from the [IANA
registry][IANA registry on DS Digest Algorithm], where the complete IANA table
can be found. The third column is for Zonemaster classification and it holds the
the relevant message tags listed in the "[Summary]" section below.
The "Zonemaster classification" is based on the "Use for DNSSEC delegation" in
the [IANA registry][IANA registry on DS Digest Algorithm] of *DS Digest
Algorithms*.
| Algorithm number | Algorithm (or description) | Zonemaster classification |
|:-----------------|:---------------------------|:--------------------------|
| 0 | Reserved | DS01_DS_ALGO_NOT_DS |
| 1 | SHA-1 | DS01_DS_ALGO_DEPRECATED |
| 2 | SHA-256 | DS01_DS_ALGO_OK |
| 3 | GOST R 34.11-94 | DS01_DS_ALGO_DEPRECATED |
| 4 | SHA-384 | DS01_DS_ALGO_OK |
| 5 | GOST R 34.11-2012 | DS01_DS_ALGO_OK |
| 6 | SM3 | DS01_DS_ALGO_OK |
| 7-127 | Unassigned | DS01_DS_ALGO_UNASSIGNED |
| 128-252 | Reserved | DS01_DS_ALGO_RESERVED |
| 253-254 | Reserved for Private Use | DS01_DS_ALGO_PRIVATE |
| 255 | Unassigned | DS01_DS_ALGO_UNASSIGNED |
## Inputs
* "Child Zone" - The domain name to be tested.
* The table in section "[Classification of algorithms]" above.
* "Undelegated DS" - The DS record or records submitted. Empty unless submitted.
* "Undelegated Test" - TRUE if undelegated NS has been provided for the test.
## Summary
| Message Tag | Level | Arguments | Message ID for message tag |
|:-------------------------|:--------|:--------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| DS01_DS_ALGO_2_MISSING | NOTICE | ns_list, keytag | There is a DS record with keytag {keytag}. A DS record using digest algorithm 2 (SHA-256) is missing. Fetched from parent name servers "{ns_list}". |
| DS01_DS_ALGO_DEPRECATED | ERROR | ns_list, keytag, ds_algo_num, ds_algo_descr | The DS record with keytag {keytag} uses a deprecated digest algorithm {ds_algo_num} ({ds_algo_descr}). Fetched from parent name servers "{ns_list}". |
| DS01_DS_ALGO_NOT_DS | ERROR | ns_list, keytag, ds_algo_num, ds_algo_descr | The DS record with keytag {keytag} uses a digest algorithm {ds_algo_num} ({ds_algo_descr}) not meant for DS records. Fetched from parent name servers "{ns_list}". |
| DS01_DS_ALGO_OK | INFO | ns_list, keytag, ds_algo_num, ds_algo_descr | The DS record with keytag {keytag} uses digest algorithm {ds_algo_num} ({ds_algo_descr}), which is OK. Fetch from parent name servers "{ns_list}". |
| DS01_DS_ALGO_PRIVATE | ERROR | ns_list, keytag, ds_algo_num | The DS record with keytag {keytag} uses a digest algorithm {ds_algo_num} for private use. Fetched from parent name servers "{ns_list}". |
| DS01_DS_ALGO_RESERVED | ERROR | ns_list, keytag, ds_algo_num | The DS record with keytag {keytag} uses a reserved digest algorithm {ds_algo_num} on name servers "{ns_list}". |
| DS01_DS_ALGO_UNASSIGNED | ERROR | ns_list, keytag, ds_algo_num | The DS record with keytag {keytag} uses an unassigned digest algorithm {ds_algo_num} on parent name servers "{ns_list}". |
| DS01_NO_RESPONSE | WARNING | ns_list | No response or error in response from all parent name servers on the DS query. Name servers are "{ns_list}". |
| DS01_PARENT_SERVER_NO_DS | ERROR | ns_list | The following name servers do not provide DS record or have not been properly configured. Fetched from parent name servers "{ns_list}". |
| DS01_PARENT_ZONE_NO_DS | NOTICE | ns_list | The parent zone provides no DS records for the child zone. Fetched from parent name servers "{ns_list}". |
| DS01_ROOT_N_NO_UNDEL_DS | INFO | | Tested zone is the root zone, but no undelegated DS has been provided. DS is not tested. |
| DS01_UNDEL_N_NO_UNDEL_DS | INFO | | Tested zone is undelegated, but no undelegated DS has been provided. DS is not tested. |
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
## Test procedure
In this section and unless otherwise specified below, the term "[DNSSEC Query]"
follows the specification for DNS queries as specified in
[DNS Query and Response Defaults]. The handling of the DNS responses on the DNS
queries follow, unless otherwise specified below, what is specified for
[DNSSEC Response] in the same specification.
1. Create a [DNSSEC Query] with query type DS and query name *Child Zone*
("DS Query").
2. Retrieve all name server names and IP addresses for the parent zone of
*Child Zone* using method [Get-Parent-NS-Names-and-IPs]
("Parent Name and IP"). If the method returns an empty list, then create
*Parent Name and IP* as an empty set.
3. The name server names are assumed to be available at the time when a `msgid`
listed above in [Summary] is created. If the argument name is "ns" or
"ns_list" the name server name is extracted from *Parent Name and IP* even
though it is only referred to the IP address of the name servers in the steps
below. Furthermore, if there are more than one name server names for the same
IP address, one entry is created for each name.
4. If the IP address below is represented as "-" it means that there is no IP
address for that instance, and when a `msgid` listed above in [Summary] is
created with an argument name "ns" or "ns_list" then that name server is
entried as just "-".
5. Create the following empty sets:
1. Name server IP address ("Ignored Parent NS IP")
2. Name server IP address ("Responds Without Valid DS")
3. Name server IP address ("Responds With DS")
4. Name server IP address and key tag ("Non-Algo 2 DS")
5. Name server IP address and key tag ("Algo 2 DS")
6. Name server IP address, key tag and digest algorithm code ("DS01_DS_ALGO_DEPRECATED")
7. Name server IP address, key tag and digest algorithm code ("DS01_DS_ALGO_RESERVED")
8. Name server IP address, key tag and digest algorithm code ("DS01_DS_ALGO_UNASSIGNED")
9. Name server IP address, key tag and digest algorithm code ("DS01_DS_ALGO_PRIVATE")
10. Name server IP address, key tag and digest algorithm code ("DS01_DS_ALGO_NOT_DS")
11. Name server IP address, key tag and digest algorithm code ("DS01_DS_ALGO_OK")
6. If *Undelegated DS* is non-empty then do:
1. For each DS record in *Undelegated DS* do:
1. Extract the digest algorithm code and key tag from the DS record.
2. From section "[Classification of algorithms]" retrieve the table and
extract the row matching the algorithm number.
3. From the row extract the message tag from column "Zonemaster
classification"
4. Add name server IP as "-", key tag and the algorithm code to the set
with the same name as the extracted message tag.
5. If the digest algorithm code is 2 add IP address as "-" and the key tag
to the *Algo 2 DS* set, else add IP address as "-" and the key tag to
the *Non-Algo 2 DS* set.
2. Add name server IP as "-" to the *Responds With DS* set.
3. Make *Parent Name and IP* an empty set.
> Note: The *Parent Name and IP* set will be empty if *Undelegated test* is
> TRUE, if *Undelegated DS* is non-empty or if *Child Zone* is ".", i.e. root
> zone.
7. For each unique name server IP in the *Parent Name and IP* set do:
1. Send *DS Query* to the name server IP.
2. If at least one of the following criteria is met, then add name server IP
to *Ignored Parent NS IP* and go to next parent name server:
1. There is no [DNSSEC Response].
2. The RCODE in the [DNSSEC Response] is not "NoError"
([IANA RCODE List]).
3. The OPT record is absent in the [DNSSEC Response].
4. The DO flag is unset in the [DNSSEC Response].
5. The AA flag is not set in the [DNSSEC Response].
3. If there is no valid DS record with matching owner name in the answer
section of the [DNSSEC Response], then do:
1. Add name server IP to *Responds Without Valid DS*.
2. Go to next parent name server.
4. Add name server IP to the *Responds With DS* set.
5. For each DS record in the answer section of the [DNSSEC Response] do:
1. Extract the digest algorithm code and key tag from the DS record.
2. From section "[Classification of algorithms]" retrieve the table and
extract the row matching the algorithm number.
3. From the row extract the message tag from column "Zonemaster
classification"
4. Add name server IP, key tag and the algorithm code to the set
with the same name as the extracted message tag.
5. If the digest algorithm code is 2 add IP address and the key tag to
the *Algo 2 DS* set.
6. Else, add IP address and the key tag to the *Non-Algo 2 DS* set.
8. For each of the sets matching each of the following message tags do if the set
is non-empty:
* For each combination of key tag and digest algorithm code do:
* Output the message tag matching the set name with the list of name
servers IP from the subset (key tag and code) plus the key tag, the
algorithm number and algorithm description from the table in section
"[Classification of algorithms]". Exclude the algorithm description if
not listed for the tag in [Summary].
* Sets:
* *[DS01_DS_ALGO_DEPRECATED]*
* *[DS01_DS_ALGO_RESERVED]*
* *[DS01_DS_ALGO_UNASSIGNED]*
* *[DS01_DS_ALGO_PRIVATE]*
* *[DS01_DS_ALGO_NOT_DS]*
* *[DS01_DS_ALGO_OK]*
9. If the *Non-Algo 2 DS* set is non-empty do:
1. For each pair of IP address and key tag in the *Algo 2 DS* set remove the
same pair from the *Non-Algo 2 DS* set.
2. For each key tag from the *Non-Algo 2 DS* set extract all IP addresses for
the key tag and output [DS01_DS_ALGO_2_MISSING] with key tag and the
extracted list of IP addresses.
10. If the *Responds Without Valid DS* is empty, the *Responds With DS* set is
empty and the *Ignored Parent NS IP* set is non-empty, then output
*[DS01_NO_RESPONSE]* with the name server IP from the *Ignored Parent NS IP*
set.
11. If *Child Zone* is "." (i.e. root zone) and *Undelegated DS* is empty then
output *[DS01_ROOT_N_NO_UNDEL_DS]*.
12. If *Child Zone* is not ".", *Undelegated Test* is TRUE and *Undelegated DS*
is empty then output *[DS01_UNDEL_N_NO_UNDEL_DS]*.
13. If the *Responds Without Valid DS* is non-empty then do:
1. If the *Responds With DS* set is empty then output
*[DS01_PARENT_ZONE_NO_DS]* with name server IP from the *Responds Without
Valid DS* set.
2. Else, output *[DS01_PARENT_SERVER_NO_DS]* with name server IP from the
*Responds Without Valid DS* set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
See the [DNSSEC README] document about DNSSEC algorithms.
## Intercase dependencies
None.
## Terminology
No special terminology for this test case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[Classification of algorithms]: #classification-of-algorithms
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNSSEC Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dnssec-query
[DNSSEC README]: README.md
[DNSSEC Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dnssec-response
[DS01_DS_ALGO_2_MISSING]: #summary
[DS01_DS_ALGO_DEPRECATED]: #summary
[DS01_DS_ALGO_NOT_DS]: #summary
[DS01_DS_ALGO_OK]: #summary
[DS01_DS_ALGO_PRIVATE]: #summary
[DS01_DS_ALGO_RESERVED]: #summary
[DS01_DS_ALGO_UNASSIGNED]: #summary
[DS01_NO_RESPONSE]: #summary
[DS01_PARENT_SERVER_NO_DS]: #summary
[DS01_PARENT_ZONE_NO_DS]: #summary
[DS01_ROOT_N_NO_UNDEL_DS]: #summary
[DS01_UNDEL_N_NO_UNDEL_DS]: #summary
[ERROR]: ../SeverityLevelDefinitions.md#error
[Get-Parent-NS-Names-and-IPs]: ../MethodsV2.md#method-get-parent-ns-names-and-ip-addresses
[IANA RCODE List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[IANA registry on DS Digest Algorithm]: https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xml
[INFO]: ../SeverityLevelDefinitions.md#info
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 8624#3.3]: https://datatracker.ietf.org/doc/html/rfc8624#section-3.3
[RFC 9157#upd-8624]: https://www.rfc-editor.org/rfc/rfc9157#name-update-to-rfc-8624
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Summary]: #summary
[Undelegated]: ../../test-types/undelegated-test.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

309
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec02.md Normal file
View File

@@ -0,0 +1,309 @@
# DNSSEC02: DS must match a valid DNSKEY in the child zone
## Test case identifier
**DNSSEC02**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
DNS delegations from a parent to a child are secured with DNSSEC by
publishing one or several Delegation Signer (DS) records in the parent
zone, along with the NS records for the delegation.
For the secure delegation to work, at least one DS record must match a
DNSKEY record in the child zone ([RFC 4035][RFC 4035#section-5], section 5).
Each DS record should match a DNSKEY record in the child zone. More
than one DS may match the same DNSKEY. The DNSKEY that the DS record
refer to must be used to sign the DNSKEY RRset in the child zone
([RFC 4035][RFC 4035#section-5], section 5).
The DNSKEY record that the DS record refer to must have bit 7
("Zone Key flag") set in the DNSKEY RR Flags ([RFC 4034][RFC 4034#section-5.2],
section 5.2).
Bit 15 ("Secure Entry Point flag") on a DNSKEY record signals that it
is meant to be a KSK and pointed out by a DS record. It is noted if
the DNSKEY record that the DS points at does not have that flag set
([RFC 4034][RFC 4034#section-2.1.1], section 2.1.1).
## Scope
This test case will just ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server (handled by
[Connectivity01]).
If no DS record is found in the parent zone or no DNSKEY record is found in the
*Child Zone* then this test case will be terminated (also see [DNSSEC11]).
This test case does not report if the parent servers are unresponsive or
inconsistent.
## Inputs
* "Child Zone" - The domain name to be tested.
* "Test Type" - The test type with value "undelegated" or "normal".
* "Undelegated DS" - The DS record or records submitted
(only if *Test Type* is [undelegated]).
## Summary
* Both DS record and DNSKEY record must be found, or else no further
investigation will be done and no messages will be outputted.
* No messages will be outputted due to errors in the responses from the parent
name servers.
Message Tag outputted | Level | Arguments | Description of when message tag is outputted
:----------------------------------|:--------|:---------------------------------------|:-----------------------------------------------------------------------
DS02_ALGO_NOT_SUPPORTED_BY_ZM | NOTICE |ns_ip_list, algo_mnemo, algo_num, keytag| DNSKEY with tag {keytag} uses unsupported algorithm {algo_num} ({algo_mnemo}) by this installation of Zonemaster. Fetched from the nameservers with IP addresses "{ns_ip_list}".
DS02_DNSKEY_NOT_FOR_ZONE_SIGNING | ERROR | ns_ip_list, keytag | Flags field of DNSKEY record with tag {keytag} does not have ZONE bit set although DS with same tag is present in parent. Fetched from the nameservers with IP addresses "{ns_ip_list}".
DS02_DNSKEY_NOT_SEP | NOTICE | ns_ip_list, keytag | Flags field of DNSKEY record with tag {keytag} does not have SEP bit set although DS with same tag is present in parent. Fetched from the nameservers with IP addresses "{ns_ip_list}".
DS02_DNSKEY_NOT_SIGNED_BY_ANY_DS | ERROR | ns_ip_list | The DNSKEY RRset has not been signed by any DNSKEY matched by a DS record. Fetched from the nameservers with IP addresses "{ns_ip_list}".
DS02_NO_DNSKEY_FOR_DS | WARNING | ns_ip_list, keytag | The DNSKEY record with tag {keytag} that the DS refers to does not exist in the DNSKEY RRset. Fetched from the nameservers with IP "{ns_ip_list}".
DS02_NO_MATCHING_DNSKEY_RRSIG | WARNING | ns_ip_list, keytag | The DNSKEY RRset is not signed by the DNSKEY with tag {keytag} that the DS record refers to. Fetched from the nameservers with IP "{ns_ip_list}".
DS02_NO_MATCH_DS_DNSKEY | ERROR | ns_ip_list, keytag | The DS record does not match the DNSKEY with tag {keytag} by algorithm or digest. Fetched from the nameservers with IP "{ns_ip_list}".
DS02_NO_VALID_DNSKEY_FOR_ANY_DS | ERROR | ns_ip_list | There is no valid DNSKEY matched by any of the DS records. Fetched from the nameservers with IP addresses "{ns_ip_list}".
DS02_RRSIG_NOT_VALID_BY_DNSKEY | ERROR | ns_ip_list, keytag | The DNSKEY RRset is signed with an RRSIG with tag {keytag} which cannot be validated by the matching DNSKEY. Fetched from the nameservers with IP addresses "{ns_ip_list}".
The value in the Level column is the default severity level of the message. The
severity level can be overridden in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
## Test procedure
In this section and unless otherwise specified below, the term "[DNSSEC Query]"
follows the specification for DNS queries as specified in
[DNS Query and Response Defaults]. The handling of the DNS responses on the DNS
queries follow, unless otherwise specified below, what is specified for
[DNSSEC Response] in the same specification.
1. Create the following empty sets:
1. DS record RDATA ("DS Record").
2. Name server IP and key tag from DS record ("No DNSKEY for DS").
3. Name server IP and key tag from DS record ("No Match DS DNSKEY").
4. Name server IP and DNSKEY record key tag ("DNSKEY Not for Zone Signing").
5. Name server IP and DNSKEY record key tag ("DNSKEY not SEP").
6. Name server IP and DNSKEY record key tag ("No Matching DNSKEY RRSIG").
7. Name server IP address, DNSKEY record key tag and DNSKEY algorithm code
("Algo Not Supported By ZM").
8. Name server IP and key tag from RRSIG record ("RRSIG Not Valid by DNSKEY").
9. Name server IP ("Responding Child Name Servers").
10. DNSKEY record and key tag ("DNSKEY Matching DS").
11. Name server IP ("Has DNSKEY Match DS").
12. Name server IP ("Has DNSKEY RRSIG Match DS").
2. If the *Test Type* is "[undelegated]" do:
1. If *Undelegated DS* is empty then do terminate this test case.
2. Else add *Undelegated DS* as DS records to the *DS Record* set.
3. If *Test Type* is "normal", then:
1. Create a [DNSSEC Query] with query type DS and query name *Child Zone*
("DS Query").
2. Retrieve all name server IP addresses for the parent zone of
*Child Zone* using [Method1] (store as "Parent NS IP").
3. For each parent name server in *Parent NS IP* do:
1. Send *DS Query* to the name server IP.
2. If at least one of the following criteria is met, then go to next
parent name server:
1. There is no [DNSSEC Response].
2. The RCODE in the [DNSSEC Response] is not "NoError"
([IANA RCODE List]).
3. The OPT record is absent in the [DNSSEC Response].
4. The DO flag is unset in the [DNSSEC Response].
5. The AA flag is not set in the [DNSSEC Response].
6. There is no DS record with matching owner name in the answer
section of the [DNSSEC Response].
3. Retrieve the DS records from the [DNSSEC Response] and add them to the
*DS Record* set.
4. If the *DS Record* set is empty exit this test case.
4. Create a [DNSSEC Query] with query type DNSKEY and query name *Child Zone*
("DNSKEY Query").
5. Obtain the set of child name server IP addresses using [Method4] and
[Method5] (store as "Child NS IP").
6. For each child name server in *Child NS IP* do:
1. Send *DNSKEY Query* to the name server IP and collect the response.
2. If at least one of the following criteria is met, then go to next
child name server:
1. There is no [DNSSEC Response].
2. The RCODE in the [DNSSEC Response] is not "NoError"
([IANA RCODE List]).
3. The OPT record is absent in the [DNSSEC Response].
4. The DO flag is unset in the [DNSSEC Response].
5. The AA flag is not set in the [DNSSEC Response].
6. There is no DNSKEY record with matching owner name in the answer
section of the [DNSSEC Response].
3. Add the name server IP address to the *Responding Child Name Servers* set.
4. Retrieve the DNSKEY RRset (store as "DNSKEY RRs") from the
[DNSSEC Response].
5. Retrieve the RRSIG records covering the DNSKEY RRset, possibly
none (store as "DNSKEY RRSIG") from the [DNSSEC Response].
6. Empty the *DNSKEY Matching DS* set.
7. For each DS in *DS Records*, do:
1. Find the equivalent DNSKEY in *DNSKEY RRs* by key ID (key tag). If
there is more than one such DNSKEY, select the correct one.
2. If matching DNSKEY is not found add DS key tag and name server IP to
the *No DNSKEY for DS* set and go to next DS.
3. Verify if the Zonemaster installation has support for the digest
algorithm that created the DS:
1. If no support, then ignore the following test if the DS matches
the DNSKEY.
2. Else, if the DS values (algorithm and digest) do not match the
DNSKEY record then add DS key tag and name server IP to the
*No Match DS DNSKEY* set.
4. If bit 7 of the DNSKEY flags field is unset (value 0), then do:
1. Add DS key tag and name server IP to the
*DNSKEY Not for Zone Signing* set.
2. Go to next DS.
5. If bit 15 of the DNSKEY flags field is unset (value 0), then add the
DNSKEY record key tag and name server IP to the *DNSKEY not SEP*
set.
6. Add the DNSKEY record and key tag to the *DNSKEY Matching DS*
set.
7. Add the name server IP to the *Has DNSKEY Match DS*
set.
8. For each DNSKEY in the *DNSKEY Matching DS* set, do:
1. Look for an RRSIG record created by the DNSKEY in *DNSKEY RRSIG*.
* Use key ID (key tag) to identify the corresponding RRSIG record.
* If there is more than one such RRSIG record, select the correct one
by verifying the signature against the DNSKEY.
2. If a matching RRSIG is not found, add DNSKEY record key tag and name
server IP to the *No Matching DNSKEY RRSIG* set.
3. Else, if the Zonemaster installation does not have support for the
DNSKEY algorithm that created the RRSIG, then add name server IP,
DNSKEY algorithm and DNSKEY key tag to the *Algo Not Supported By ZM*
set.
4. Else, if the RRSIG values (algorithm and signature) do not match
the DNSKEY then add the key tag from the RRSIG record and name server
IP to the *RRSIG Not Valid by DNSKEY* set.
5. Else add the name server IP address to the *Has DNSKEY RRSIG Match DS*
set.
7. If the *No DNSKEY for DS* set is non-empty, then for each key tag from the DS
record from the set output *[DS02_NO_DNSKEY_FOR_DS]* with the key tag and the
name servers IP addresses from the set.
8. If the *No Match DS DNSKEY* set is non-empty, then for each key tag from the
DS record from the set output *[DS02_NO_MATCH_DS_DNSKEY]* with the key tag
and the name servers IP addresses from the set.
9. If the *DNSKEY Not for Zone Signing* set is non-empty, then for each DNSKEY
key tag from the set output *[DS02_DNSKEY_NOT_FOR_ZONE_SIGNING]* with the key
tag and the name servers IP addresses from the set.
10. If the *DNSKEY not SEP* set is non-empty, then for each DNSKEY key tag from
the set output *[DS02_DNSKEY_NOT_SEP]* with the key tag and the name servers
IP addresses from the set.
11. If the *No Matching DNSKEY RRSIG* set is non-empty, then for each DNSKEY key
tag from the set output *[DS02_NO_MATCHING_DNSKEY_RRSIG]* with the key tag
and the name servers IP addresses from the set.
12. If the *Algo Not Supported By ZM* set is non-empty, then output
*[DS02_ALGO_NOT_SUPPORTED_BY_ZM]* for each DNSKEY key tag with the name
server IP addresses, the key tag and the algorithm code from the set.
13. If the *RRSIG Not Valid by DNSKEY* set is non-empty, then for each key tag
from the RRSIG record from the set output *[DS02_RRSIG_NOT_VALID_BY_DNSKEY]*
with the key tag and the name servers IP addresses from the set.
14. Extract the name server IP addresses that are members of
*Responding Child Name Servers* but are not members of *Has DNSKEY Match DS*
set.
15. If the subset from previous step is non-empty, then output
*[DS02_NO_VALID_DNSKEY_FOR_ANY_DS]* with the subset of name server IP
addresses.
16. Else do:
1. Extract the name server IP addresses that are members of
*Responding Child Name Servers* but are not members of
*Has DNSKEY RRSIG Match DS* set.
2. If that subset is non-empty, then output
*[DS02_DNSKEY_NOT_SIGNED_BY_ANY_DS]* with the subset of name server IP
addresses.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, skip sending queries over that
transport protocol. Output a message reporting that the transport protocol has
been disabled.
See the [DNSSEC README] document about DNSSEC algorithms.
## Intercase dependencies
None.
## Terminology
No special terminology for this test case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNSSEC Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dnssec-query
[DNSSEC README]: README.md
[DNSSEC Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dnssec-response
[DNSSEC11]: dnssec11.md
[DS02_ALGO_NOT_SUPPORTED_BY_ZM]: #summary
[DS02_DNSKEY_NOT_FOR_ZONE_SIGNING]: #summary
[DS02_DNSKEY_NOT_SEP]: #summary
[DS02_DNSKEY_NOT_SIGNED_BY_ANY_DS]: #summary
[DS02_NO_DNSKEY_FOR_DS]: #summary
[DS02_NO_MATCHING_DNSKEY_RRSIG]: #summary
[DS02_NO_MATCH_DS_DNSKEY]: #summary
[DS02_NO_VALID_DNSKEY_FOR_ANY_DS]: #summary
[DS02_RRSIG_NOT_VALID_BY_DNSKEY]: #summary
[ERROR]: ../SeverityLevelDefinitions.md#error
[IANA RCODE List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[INFO]: ../SeverityLevelDefinitions.md#info
[Method1]: ../Methods.md#method-1-obtain-the-parent-domain
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 4034#section-2.1.1]: https://datatracker.ietf.org/doc/html/rfc4034#section-2.1.1
[RFC 4034#section-5.2]: https://datatracker.ietf.org/doc/html/rfc4034#section-5.2
[RFC 4035#section-5]: https://datatracker.ietf.org/doc/html/rfc4035#section-5
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Undelegated]: ../../test-types/undelegated-test.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

337
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec03.md Normal file
View File

@@ -0,0 +1,337 @@
## DNSSEC03: Verify NSEC3 parameters
### Test case identifier
**DNSSEC03**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure]
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
The NSEC3 record type and its parameters are defined in [RFC 5155]. The
recommended values of the parameters have been updated by [RFC 9276].
For NSEC3 there are four fields that determine how the NSEC3 record are created
and interpreted ([RFC 5155][RFC 5155#section-3], section 3):
* Hash algorithm
* Flags
* Iterations
* Salt
**Hash algorithm:** The only legal value of the hash algorithm is value 1
(SHA-1). See ([RFC 5155][RFC 5155#section-11], section 11 and
[IANA NSEC3 Parameters registry]).
**Flags:** The only defined flags in the flag field is bit 7 (the least
significant bit), "opt-out". It may only be set in the NSEC record, not in the
NSEC3PARAM record ([RFC 5155][RFC 5155#section-11], section 11 and
[IANA NSEC3 Parameters registry]). "For small zones, the use of opt-out-based
NSEC3 records is NOT RECOMMENDED. For very large and sparsely signed zones, where
the majority of the records are insecure delegations, opt-out MAY be used"
([RFC 9276][RFC 9276#section-3.1], section 3.1). This means that unless the zone
is a TLD or a TLD like domain found in the [Public Suffix List] it should
not have the opt-out bit set.
**Iterations:** For a name server an increased number of NSEC3 iterations have a
negative impact on performance. The recommendation is to have 0 iterations. "If
NSEC3 must be used, then an iterations count of 0 MUST be used to alleviate
computational burdens" ([RFC 9276][RFC 9276#section-3.1], section 3.1).
**Salt:** The salt parameter has been seen as a security feature but
[RFC 9276][RFC 9276#section-3.1], section 3.1, states that zones "SHOULD NOT use
a salt by indicating a zero-length salt value instead". The justification for
the recommendation is found in [RFC 9276][RFC 9276#section-2.4], section 2.4.
## Scope
This test case will just ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server (covered by
[Connectivity01]).
This test case is only relevant if the zone has been DNSSEC signed.
## Inputs
* "Child Zone" - The domain name to be tested.
* "Public Suffix List Data" - The list or a copy of the list found at
[Public Suffix List data].
## Summary
* If no DNSKEY records are found, no further investigation will be done.
Message Tag outputted | Level |Arguments| Message ID for message tag
:----------------------------------|:--------|:--------|:--------------------------------------------
DS03_ERROR_RESPONSE_NSEC_QUERY | ERROR | ns_list | The following servers give erroneous response to NSEC query. Fetched from name servers "{ns_list}".
DS03_ERR_MULT_NSEC3 | ERROR | ns_list | Multiple NSEC3 records when one is expected. Fetched from name servers "{ns_list}".
DS03_ILLEGAL_HASH_ALGO | ERROR | ns_list, algo_num | The following servers respond with an illegal hash algorithm for NSEC3 ({algo_num}). Fetched from name servers "{ns_list}".
DS03_ILLEGAL_ITERATION_VALUE | WARNING | ns_list, int | The following servers respond with the NSEC3 iteration value {int}. The recommended practice is to set this value to 0. Fetched from name servers "{ns_list}".
DS03_ILLEGAL_SALT_LENGTH | WARNING | ns_list, int | The following servers respond with a non-empty salt in NSEC3 ({int} octets). The recommended practice is to use an empty salt. Fetched from name servers "{ns_list}".
DS03_INCONSISTENT_HASH_ALGO | ERROR | | Inconsistent hash algorithm in NSEC3 in responses for the child zone from different name servers.
DS03_INCONSISTENT_ITERATION | ERROR | | Inconsistent NSEC3 iteration value in responses for the child zone from different name servers.
DS03_INCONSISTENT_NSEC3_FLAGS | ERROR | | Inconsistent NSEC3 flag list in responses for the child zone from different name servers.
DS03_INCONSISTENT_SALT_LENGTH | ERROR | | Inconsistent salt length in NSEC3 in responses for the child zone from different name servers.
DS03_LEGAL_EMPTY_SALT | INFO | ns_list | The following servers respond with a legal empty salt in NSEC3. Fetched from name servers "{ns_list}".
DS03_LEGAL_HASH_ALGO | INFO | ns_list | The following servers respond with a legal hash algorithm in NSEC3. Fetched from name servers "{ns_list}".
DS03_LEGAL_ITERATION_VALUE | INFO | ns_list | The following servers respond with NSEC3 iteration value set to zero (as recommended). Fetched from name servers "{ns_list}".
DS03_NO_DNSSEC_SUPPORT | NOTICE | ns_list | The zone is not DNSSEC signed or not properly DNSSEC signed. Testing for NSEC3 has been skipped. Fetched from name servers "{ns_list}".
DS03_NO_NSEC3 | INFO | ns_list | The zone does not use NSEC3. Testing for NSEC3 has been skipped. Fetched from name servers "{ns_list}".
DS03_NO_RESPONSE_NSEC_QUERY | ERROR | ns_list | The following servers do not respond to NSEC query. Fetched from name servers "{ns_list}".
DS03_NSEC3_OPT_OUT_DISABLED | INFO | ns_list | The following servers respond with NSEC3 opt-out disabled (as recommended). Fetched from name servers "{ns_list}".
DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD | NOTICE | ns_list | The following servers respond with NSEC3 opt-out enabled. The recommended practice is to disable opt-out. Fetched from name servers "{ns_list}".
DS03_NSEC3_OPT_OUT_ENABLED_TLD | INFO | ns_list | The following servers respond with NSEC3 opt-out enabled. Fetched from name servers "{ns_list}".
DS03_SERVER_NO_DNSSEC_SUPPORT | ERROR | ns_list | The following name servers do not support DNSSEC or have not been properly configured. Testing for NSEC3 has been skipped on those servers. Fetched from name servers "{ns_list}".
DS03_SERVER_NO_NSEC3 | ERROR | ns_list | The following name servers do not use NSEC3, but others do. Testing for NSEC3 has been skipped on the following servers. Fetched from name servers "{ns_list}".
DS03_UNASSIGNED_FLAG_USED | ERROR | ns_list, int | The following servers respond with an NSEC3 record where an unassigned flag is used (bit {int}). Fetched from name servers "{ns_list}".
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
The name server names are assumed to be available at the time when the msgid
is created, if the argument name is "ns" or "ns_list" even when in the
"[Test procedure]" below it is only referred to the IP address of the name
servers.
## Test procedure
In this section and unless otherwise specified below, the term "[DNSSEC Query]"
follows the specification for DNS queries as specified in
[DNS Query and Response Defaults]. The handling of the DNS responses on the DNS
queries follow, unless otherwise specified below, what is specified for
[DNSSEC Response] in the same specification.
A complete list of all DNS Resource Record types can be found in the
[IANA RR Type List].
1. Create a [DNSSEC Query] with query type DNSKEY and query name *Child Zone*
("DNSKEY Query").
2. Create a [DNSSEC Query] with query type NSEC and query name *Child Zone*
("NSEC Query").
3. Retrieve all name server names and IP addresses for the
*Child Zone* using [Method4] and [Method5] ("NS IP").
3. Create the following empty sets:
1. Name server IP address ("Responds Without DNSKEY").
2. Name server IP address ("Responds With DNSKEY").
3. Name server IP address ("Responds Without NSEC3").
4. Name server IP address ("Responds With NSEC3").
5. Name server IP address ("Multiple NSEC3").
6. Name server IP address and NSEC3 hash algorithm ("Hash Algorithm").
7. Name server IP address and NSEC3 flags ("NSEC3 Flags").
8. Name server IP address and NSEC3 iterations value ("NSEC3 Iterations").
9. Name server IP address and NSEC3 salt length ("NSEC3 Salt Length").
10. Name server IP address ("No Response NSEC Query")
11. Name server IP address ("Error Response NSEC Query")
6. For each name server IP address in *NS IP* do:
1. Send *DNSKEY Query* to the name server IP.
2. If at least one of the following criteria is met, then go to next name
server IP:
1. There is no DNS response.
2. The [RCODE Name] in the response is not "NoError".
3. The AA flag is not set in the response.
3. If the response does not contain any DNSKEY record with owner name
matching *Child Zone* in the answer section, add name server IP to the
*Responds Without DNSKEY* set and go to next name server.
4. Add name server IP to the *Responds With DNSKEY* set.
5. Send *NSEC Query* to the name server IP.
6. If there is no DNS response do:
1. Add name server IP to the *No Response NSEC Query* set.
2. Go to next name server IP.
7. If the [RCODE Name] in the response is not "NoError" or if the AA flag is
not set in the response (or both) then do:
1. Add name server IP to the *Error Response NSEC Query* set.
2. Go to next name server IP.
8. If the authority section contains no NSEC3 record then add the name server
IP to the *Responds Without NSEC3* set and go to next name server.
9. Else do:
1. If there are more than one NSEC3 record in the authority section then
add name server IP to the *Multiple NSEC3* set and use the first one
for the following steps.
2. Add name server IP to the *Responds With NSEC3* set.
3. Extract the NSEC3 hash algorithm and add it and the name server IP to
the *Hash Algorithm* set.
4. Extract the NSEC3 flags and add them and the name server IP to the
*NSEC3 flags* set.
5. Extract the NSEC3 hash iterations value and add it and the name server
IP to the *NSEC3 Iterations* set.
6. Extract the NSEC3 salt length and add it and the name server IP to the
*NSEC3 Salt Length* set.
7. If the *Responds With DNSKEY* set is empty and the *Responds Without DNSKEY*
is non-empty then output *[DS03_NO_DNSSEC_SUPPORT]* with the name server IP
addresses from the *Responds Without DNSKEY* set.
8. If both the *Responds With DNSKEY* set and the *Responds Without DNSKEY* set
are non-empty then output *[DS03_SERVER_NO_DNSSEC_SUPPORT]* with the name
server IP addresses from the *Responds Without DNSKEY* set.
9. If the *Responds With NSEC3* set is empty and the *Responds Without NSEC3*
is non-empty then output *[DS03_NO_NSEC3]* with the name server IP
addresses from the *Responds Without NSEC3* set.
10. If both the *Responds With NSEC3* set and the *Responds Without NSEC3*
are non-empty then output *[DS03_SERVER_NO_NSEC3]* with the name server IP
addresses from the *Responds Without NSEC3* set.
11. If the *Multiple NSEC3* set is non-empty then output *[DS03_ERR_MULT_NSEC3]*
with the name server IP addresses from the set.
12. If the *Hash Algorithm* set is non-empty then do:
1. If the set has more than one hash algorithm value then output
*[DS03_INCONSISTENT_HASH_ALGO]*.
2. For each algorithm value do:
1. If the value is 1 output *[DS03_LEGAL_HASH_ALGO]* with the name servers
IP addresses from the set with that value.
2. Else, output *[DS03_ILLEGAL_HASH_ALGO]* with the hash algorithm value
and the name servers IP addresses from the set with that value.
13. If the *NSEC3 Flags* set is non-empty then do:
1. If the set has more than one flag list value then output
*[DS03_INCONSISTENT_NSEC3_FLAGS]*.
2. For each flag list value do:
1. If any flag 0-6 (bits 0-6) is set then for each such flag output
*[DS03_UNASSIGNED_FLAG_USED]* with the flag (bit) number and the name
server IP addresses from the flag list value where the bit is set.
2. If flag 7 (bit 7) is set, then do:
1. If *Child Zone* is the root zone, a TLD zone or a zone matching
*Public Suffix List Data* then output
*[DS03_NSEC3_OPT_OUT_ENABLED_TLD]* with the name servers IP
addresses from the set with that flag list value.
2. Else, output *[DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD]* with the name
servers IP addresses from the set with that flag list value.
3. If flag 7 (bit 7) is unset, then output
*[DS03_NSEC3_OPT_OUT_DISABLED]* with the name servers IP addresses from
the set with that flag list value.
14. If the *NSEC3 Iterations* set is non-empty then do:
1. If the set has more than one iteration value then output
*[DS03_INCONSISTENT_ITERATION]*.
2. For each iteration value do:
1. If the value is 0 output *[DS03_LEGAL_ITERATION_VALUE]* with the name
servers IP addresses from the set with that iteration value.
2. Else, output *[DS03_ILLEGAL_ITERATION_VALUE]* with the value and the
name servers IP addresses from the set with that iteration value.
15. If the *NSEC3 Salt Length* set is non-empty then do:
1. If the set has more than one salt length then output
*[DS03_INCONSISTENT_SALT_LENGTH]*.
2. For each iteration value do:
1. If the length is 0 output *[DS03_LEGAL_EMPTY_SALT]* with the name
servers IP addresses from the set with that salt length.
2. Else, output *[DS03_ILLEGAL_SALT_LENGTH]* with the length and the
name servers IP addresses from the set with that salt length.
16. If the *No Response NSEC Query* set is non-empty then output
*[DS03_NO_RESPONSE_NSEC_QUERY]* with the name server IP addresses from the
set.
17. If the *Error Response NSEC Query* set is non-empty then output
*[DS03_ERROR_RESPONSE_NSEC_QUERY]* with the name server IP addresses from the
set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, skip sending queries over that
transport protocol. A message will be outputted reporting that the transport
protocol has been skipped.
See the [DNSSEC README] document about DNSSEC algorithms.
## Intercase dependencies
None.
## Terminology
No special terminology for this Test Case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNSSEC Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dnssec-query
[DNSSEC README]: README.md
[DNSSEC Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dnssec-response
[DS03_ERROR_RESPONSE_NSEC_QUERY]: #summary
[DS03_ERR_MULT_NSEC3]: #summary
[DS03_ILLEGAL_HASH_ALGO]: #summary
[DS03_ILLEGAL_ITERATION_VALUE]: #summary
[DS03_ILLEGAL_SALT_LENGTH]: #summary
[DS03_INCONSISTENT_HASH_ALGO]: #summary
[DS03_INCONSISTENT_ITERATION]: #summary
[DS03_INCONSISTENT_NSEC3_FLAGS]: #summary
[DS03_INCONSISTENT_SALT_LENGTH]: #summary
[DS03_LEGAL_EMPTY_SALT]: #summary
[DS03_LEGAL_HASH_ALGO]: #summary
[DS03_LEGAL_ITERATION_VALUE]: #summary
[DS03_NO_DNSSEC_SUPPORT]: #summary
[DS03_NO_NSEC3]: #summary
[DS03_NO_RESPONSE_NSEC_QUERY]: #summary
[DS03_NSEC3_OPT_OUT_DISABLED]: #summary
[DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD]: #summary
[DS03_NSEC3_OPT_OUT_ENABLED_TLD]: #summary
[DS03_SERVER_NO_DNSSEC_SUPPORT]: #summary
[DS03_SERVER_NO_NSEC3]: #summary
[DS03_UNASSIGNED_FLAG_USED]: #summary
[ERROR]: ../SeverityLevelDefinitions.md#error
[IANA NSEC3 Parameters registry]: https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml
[IANA RR Type List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
[INFO]: ../SeverityLevelDefinitions.md#info
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[Public Suffix List data]: https://publicsuffix.org/list/public_suffix_list.dat
[Public Suffix List]: https://publicsuffix.org/list/
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 5155#section-11]: https://www.rfc-editor.org/rfc/rfc5155.html#section-11
[RFC 5155#section-3]: https://www.rfc-editor.org/rfc/rfc5155.html#section-3
[RFC 5155]: https://www.rfc-editor.org/rfc/rfc5155.html
[RFC 9276#section-2.4]: https://www.rfc-editor.org/rfc/rfc9276.html#section-2.4
[RFC 9276#section-3.1]: https://www.rfc-editor.org/rfc/rfc9276.html#section-3.1
[RFC 9276]: https://www.rfc-editor.org/rfc/rfc9276.html
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Test procedure]: #test-procedure
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

57
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec04.md Normal file
View File

@@ -0,0 +1,57 @@
## DNSSEC04: Check for too short or too long RRSIG lifetimes
### Test case identifier
**DNSSEC04** Check for too short or too long RRSIG lifetimes
### Objective
Having RRSIG signature lifetimes last for too long opens up for DNS replay
attacks. Having too short RRSIG signature lifetimes is likely to have
a major operational impact if the master name server is down for that long.
There is no clear recommendation of the exact validity periods to use with
DNSSEC. Shorter validity than 12 hours until expiration will give a serious
operational problem just in case of temporary network problems, and longer
than 180 days will create wide open holes for replay attacks.
The considerations are described in [RFC6781](
https://datatracker.ietf.org/doc/html/rfc6781).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Obtain a set of name server IP addresses using [Method4] and [Method5].
2. Create a DNSKEY query with DO flag set for the apex of the child zone.
3. Create a SOA query with DO flag set for the apex of the child zone.
4. Send the DNSKEY query over UDP to each name server IP address until
a response is received or until the set is exhausted.
5. Send the SOA query over UDP to each name server IP address until
a response is received or until the set is exhausted.
6. If any RRSIG validity is found where the expiration time already has
passed, this test case fails.
7. If any RRSIG validity time is shorter than 12 hours (from "now"),
this test case fails.
8. If any RRSIG validity time is longer than 180 days (from "now"), this
test fails.
9. If any RRSIG validity from inception to expiration is longer than 180
days, this test case fails.
### Outcome(s)
If any of the signature expirations time is either shorter than 12 hours or
longer than 180 days, this test case fails.
### Special procedural requirements
Test case is only performed if RRSIG RRs are found in the answers.
### Intercase dependencies
None.
-------
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child

275
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec05.md Normal file
View File

@@ -0,0 +1,275 @@
# DNSSEC05: Check for invalid DNSKEY algorithms
## Test case identifier
**DNSSEC05**
## Table of contents
* [Objective](#Objective)
* [Scope](#Scope)
* [Classification of algorithms]
* [Inputs](#Inputs)
* [Summary]
* [Test procedure]
* [Outcome(s)](#Outcomes)
* [Special procedural requirements](#Special-procedural-requirements)
* [Intercase dependencies](#Intercase-dependencies)
* [Terminology](#terminology)
## Objective
A domain name (zone) should only use DNSKEY algorithms that are specified by
[RFC 8624][RFC 8624#3.1], section 3.1 (including the update in
[RFC 9157][RFC 9157#upd-8624]) and the [IANA registry][IANA DNSSEC algo num] of
*DNSSEC Algorithm Numbers* to be used for DNSSEC signing. A public domain name
(zone) should not use private algorithms.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will just ignore non-responsive name servers or name servers not giving a
correct DNS response for an authoritative name server unless all such name
servers fail, in which case a message is outputted.
The RDATA of a DNSKEY record consists of four fields. The third field specifies
the algorithm number of the public key in the fourth field. This test case will only
check which algorithm is used by checking the third field. It will not verify
that the key is matching the algorithm.
## Classification of algorithms
In the table below, the first three columns are copied from the
[IANA registry][IANA DNSSEC algo num]. The fourth column is for Zonemaster
classification and it holds the relevant message tags listed in the
"[Summary]" section below. In the table below "mnemonic" is defined by Zonemaster
when undefined in the IANA table, which is available at
[IANA registry][IANA DNSSEC algo num].
The "Zonemaster classification" is based on the "Use for DNSSEC signing" in the
[IANA registry][IANA DNSSEC algo num] of *DNSSEC Algorithm Numbers*.
| Algorithm no | Algorithm (or description) | Mnemonic | Zonemaster classification | Note |
|:-------------|:---------------------------------|:-------------------|:--------------------------|:-----|
| 0 | Delete DS | DELETE | DS05_ALGO_NOT_ZONE_SIGN | |
| 1 | RSA/MD5 | RSAMD5 | DS05_ALGO_DEPRECATED | |
| 2 | Diffie-Hellman | DH | DS05_ALGO_NOT_ZONE_SIGN | |
| 3 | DSA/SHA1 | DSA | DS05_ALGO_DEPRECATED | |
| 4 | Reserved | RESERVED | DS05_ALGO_RESERVED | (1) |
| 5 | RSA/SHA-1 | RSASHA1 | DS05_ALGO_DEPRECATED | |
| 6 | DSA-NSEC3-SHA1 | DSA-NSEC3-SHA1 | DS05_ALGO_DEPRECATED | |
| 7 | RSASHA1-NSEC3-SHA1 | RSASHA1-NSEC3-SHA1 | DS05_ALGO_DEPRECATED | |
| 8 | RSA/SHA-256 | RSASHA256 | DS05_ALGO_OK | |
| 9 | Reserved | RESERVED | DS05_ALGO_RESERVED | (1) |
| 10 | RSA/SHA-512 | RSASHA512 | DS05_ALGO_NOT_RECOMMENDED | |
| 11 | Reserved | RESERVED | DS05_ALGO_RESERVED | (1) |
| 12 | GOST R 34.10-2001 | ECC-GOST | DS05_ALGO_DEPRECATED | |
| 13 | ECDSA Curve P-256 with SHA-256 | ECDSAP256SHA256 | DS05_ALGO_OK | |
| 14 | ECDSA Curve P-384 with SHA-384 | ECDSAP384SHA384 | DS05_ALGO_OK | |
| 15 | Ed25519 | ED25519 | DS05_ALGO_OK | |
| 16 | Ed448 | ED448 | DS05_ALGO_OK | |
| 17 | SM2 signing algo w SM3 hash algo | SM2SM3 | DS05_ALGO_OK | |
| 18-22 | Unassigned | UNASSIGNED | DS05_ALGO_UNASSIGNED | (1) |
| 23 | GOST R 34.10-2012 | ECC-GOST12 | DS05_ALGO_OK | |
| 24-122 | Unassigned | UNASSIGNED | DS05_ALGO_UNASSIGNED | (1) |
| 123-251 | Reserved | RESERVED | DS05_ALGO_RESERVED | (1) |
| 252 | Reserved for Indirect Keys | INDIRECT | DS05_ALGO_NOT_ZONE_SIGN | |
| 253 | private algorithm | PRIVATEDNS | DS05_ALGO_PRIVATE | |
| 254 | private algorithm OID | PRIVATEOID | DS05_ALGO_PRIVATE | |
| 255 | Reserved | RESERVED | DS05_ALGO_RESERVED | (1) |
(1) Mnemonic defined for Zonemaster usage when undefined in the IANA table.
## Inputs
* The domain name to be tested ("Child Zone").
* The table in section "[Classification of algorithms]" above.
## Summary
| Message Tag | Level | Arguments | Message ID for message tag |
|:--------------------------|:--------|:--------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| DS05_ALGO_DEPRECATED | ERROR | ns_list, keytag, algo_num, algo_descr, algo_mnemo | The DNSKEY with tag {keytag} uses deprecated algorithm number {algo_num} ("{algo_descr}", {algo_mnemo}). Fetched from name servers "{ns_list}". |
| DS05_ALGO_NOT_RECOMMENDED | WARNING | ns_list, keytag, algo_num, algo_descr, algo_mnemo | The DNSKEY with tag {keytag} uses unrecommended algorithm number {algo_num} ("{algo_descr}", {algo_mnemo}). Fetched from name servers "{ns_list}". |
| DS05_ALGO_NOT_ZONE_SIGN | ERROR | ns_list, keytag, algo_num, algo_descr, algo_mnemo | The DNSKEY with tag {keytag} uses algorithm number {algo_num} ("{algo_descr}", {algo_mnemo}) which is not meant for zone signing. Fetched from name servers "{ns_list}". |
| DS05_ALGO_OK | INFO | ns_list, keytag, algo_num, algo_descr, algo_mnemo | The DNSKEY with tag {keytag} uses algorithm number {algo_num} ("{algo_descr}", {algo_mnemo}). Fetched from name servers "{ns_list}". |
| DS05_ALGO_PRIVATE | ERROR | ns_list, keytag, algo_num | The DNSKEY with tag {keytag} uses algorithm number {algo_num} which is reserved for private use. Fetched from name servers "{ns_list}". |
| DS05_ALGO_RESERVED | ERROR | ns_list, keytag, algo_num | The DNSKEY with tag {keytag} uses reserved algorithm number {algo_num}. Fetched from name servers "{ns_list}". |
| DS05_ALGO_UNASSIGNED | ERROR | ns_list, keytag, algo_num | The DNSKEY with tag {keytag} uses unassigned algorithm number {algo_num}. Fetched from name servers "{ns_list}". |
| DS05_NO_RESPONSE | WARNING | ns_list | No response or error in response from all name servers on the DNSKEY query. Failing name servers: "{ns_list}". |
| DS05_SERVER_NO_DNSSEC | ERROR | ns_list | Some name servers do not support DNSSEC or have not been properly configured. DNSKEY cannot be tested on those servers. Fetched from name servers "{ns_list}". |
| DS05_ZONE_NO_DNSSEC | NOTICE | ns_list | The zone is not DNSSEC signed or not properly DNSSEC signed. DNSKEY cannot be tested. Fetched from name servers "{ns_list}". |
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
The name server names are assumed to be available at the time when the msgid
is created, if the argument name is "ns" or "ns_list" even when in the
"[Test procedure]" below it is only referred to the IP address of the name
servers.
## Test procedure
In this section and unless otherwise specified below, the term "[DNSSEC Query]"
follows the specification for DNS queries as specified in
[DNS Query and Response Defaults]. The handling of the DNS responses on the DNS
queries follow, unless otherwise specified below, what is specified for
[DNSSEC Response] in the same specification.
A complete list of all DNS Resource Record types can be found in the
[IANA RR Type List].
1. Create a [DNSSEC Query] with query type DNSKEY and query name *Child Zone*
("DNSKEY Query").
2. Retrieve all name server names and IP addresses for *Child Zone* using
methods [Get-Del-NS-Names-and-IPs] and [Get-Zone-NS-Names-and-IPs]
("NS Name and IP").
3. The name server names are assumed to be available at the time when a `msgid`
listed above in [Summary] is created. If the argument name is "ns" or
"ns_list" the name server name is extracted from *NS Name and IP* even
though it is only referred to the IP address of the name servers in the steps
below. Furthermore, if there are more than one name server names for the same
IP address, one entry is created for each name.
4. Create the following empty sets:
1. Name server IP address ("Ignored NS IP")
2. Name server IP address ("Responds without valid DNSKEY")
3. Name server IP address ("Responds with DNSKEY")
4. Name server IP address, key tag and DNSKEY algorithm code ("DS05_ALGO_DEPRECATED")
5. Name server IP address, key tag and DNSKEY algorithm code ("DS05_ALGO_RESERVED")
6. Name server IP address, key tag and DNSKEY algorithm code ("DS05_ALGO_UNASSIGNED")
7. Name server IP address, key tag and DNSKEY algorithm code ("DS05_ALGO_NOT_RECOMMENDED")
8. Name server IP address, key tag and DNSKEY algorithm code ("DS05_ALGO_PRIVATE")
9. Name server IP address, key tag and DNSKEY algorithm code ("DS05_ALGO_NOT_ZONE_SIGN")
10. Name server IP address, key tag and DNSKEY algorithm code ("DS05_ALGO_OK")
5. For each unique name server IP address in *NS Name and IP* do:
1. Send *DNSKEY Query* to the name server IP.
2. Add the name server IP to the *Ignored NS IP* set and go to next name
server IP if at least one of the following criteria is met:
1. There is no DNS response.
2. The [RCODE Name] in the response is not "NoError".
3. The AA flag is not set in the response.
3. If the response does not contain any valid DNSKEY record with owner name
matching *Child Zone* in the answer section, add name server IP to the
*Responds without valid DNSKEY* set and go to next server.
4. Else, add name server IP to the *Responds with DNSKEY* set and retrieve
valid DNSKEY records from the answer section.
5. For each DNSKEY record retrieved do:
1. Extract algorithm number from the third field of RDATA of the DNSKEY
record.
2. Calculate the key tag for the DNSKEY record.
3. From section "[Classification of algorithms]" retrieve the table and
extract the row matching the algorithm number.
4. From the row extract the message tag from column "Zonemaster
classification".
5. Add name server IP, key tag and the algorithm code to the set with the
same name as the extracted message tag.
6. For each of the sets matching each of the following message tags do if the set
is non-empty:
* For each combination of key tag and algorithm code do:
* Output the message tag matching the set name with the list of name server
IP from the subset (key tag and code) plus the key tag, the algorithm
number, algorithm description and algorithm mnemonic from the table in
section "[Classification of algorithms]". Exclude algorithm description
and algorithm mnemonic if not listed for the tag in [Summary].
* Sets:
* *[DS05_ALGO_DEPRECATED]*
* *[DS05_ALGO_RESERVED]*
* *[DS05_ALGO_UNASSIGNED]*
* *[DS05_ALGO_NOT_RECOMMENDED]*
* *[DS05_ALGO_PRIVATE]*
* *[DS05_ALGO_NOT_ZONE_SIGN]*
* *[DS05_ALGO_OK]*
7. If the *Responds without valid DNSKEY* and *Responds with DNSKEY* sets are empty
then output *[DS05_NO_RESPONSE]* with the list of name server IP addresses from
the *Ignored NS IP* set.
8. If the *Responds without valid DNSKEY* is non-empty then do:
1. If *Responds with DNSKEY* sets is empty then output *[DS05_ZONE_NO_DNSSEC]*
with name server IP from the *Responds without valid DNSKEY* set.
2. Else, output *[DS05_SERVER_NO_DNSSEC]* with name server IP from the
*Responds without valid DNSKEY* set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message with
the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message with
the severity level *[WARNING]*, but no message with severity level *ERROR* or
*CRITICAL*.
In other cases, no message or only messages with severity level *[INFO]* or
*[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, skip sending queries over that
transport protocol. A message will be outputted reporting that the transport
protocol has been skipped.
See the [DNSSEC README] document about DNSSEC algorithms.
## Intercase dependencies
None.
## Terminology
No special terminology for this Test Case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[Classification of algorithms]: #classification-of-algorithms
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNSSEC Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dnssec-query
[DNSSEC README]: ./README.md
[DNSSEC Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dnssec-response
[DS05_ALGO_DEPRECATED]: #outcomes
[DS05_ALGO_NOT_RECOMMENDED]: #outcomes
[DS05_ALGO_NOT_ZONE_SIGN]: #outcomes
[DS05_ALGO_OK]: #outcomes
[DS05_ALGO_PRIVATE]: #outcomes
[DS05_ALGO_RESERVED]: #outcomes
[DS05_ALGO_UNASSIGNED]: #outcomes
[DS05_NO_RESPONSE]: #outcomes
[DS05_SERVER_NO_DNSSEC]: #outcomes
[DS05_ZONE_NO_DNSSEC]: #outcomes
[Get-Del-NS-Names-and-IPs]: ../MethodsV2.md#method-get-delegation-ns-names-and-ip-addresses
[Get-Zone-NS-Names-and-IPs]: ../MethodsV2.md#method-get-zone-ns-names-and-ip-addresses
[IANA DNSSEC algo num]: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml
[IANA RR Type List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 8624#3.1]: https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1
[RFC 9157#upd-8624]: https://www.rfc-editor.org/rfc/rfc9157#name-update-to-rfc-8624
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Summary]: #Summary
[Test procedure]: #Test-procedure
[Zonemaster-Engine profile]: ../../../configuration/profiles.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[ERROR]: ../SeverityLevelDefinitions.md#error
[INFO]: ../SeverityLevelDefinitions.md#info
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[WARNING]: ../SeverityLevelDefinitions.md#warning

38
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec06.md Normal file
View File

@@ -0,0 +1,38 @@
## DNSSEC06: Verify DNSSEC additional processing
### Test case identifier
**DNSSEC06** Verify DNSSEC additional processing
### Objective
In order for an authoritative name server to be DNSSEC compliant,
it must serve DNSSEC signatures (RRSIG) as additional data in a DNS answer.
This additional processing is described in section 3.1 of [RFC 4035](
https://datatracker.ietf.org/doc/html/rfc4035#section-3.1).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. For each name server configured for the domain:
2. Retrieve the DNSKEY RR set from the child zone.
3. If the answer from the query does contain a DNSKEY _and_ RRSIG, this
test case passes.
4. If there is no DNSKEY RR or RRSIG RR in the answer and the RCODE is
NOERROR, this test case fails.
### Outcome(s)
If any of the name servers configured for the domains fail to answer with
DNSSEC data, this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
This test should only run if [DNSSEC07](dnssec07.md) has been successful
in finding a DNSKEY for the domain.

340
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec07.md Normal file
View File

@@ -0,0 +1,340 @@
# DNSSEC07: DNSSEC signed zone and DS in parent for signed zone
## Test case identifier
**DNSSEC07**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Restrictions on combinations of the message tags](#restrictions-on-combinations-of-the-message-tags)
* [Test procedure]
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
DNSSEC is the security upgrade of DNS, just as TLS is the security upgrade of
HTTP (but done in very different ways). If a zone is upgraded to DNSSEC it means
that it is signed by DNSSEC keys. This test case will verify if the zone has been
DNSSEC signed, and if so, also verify that there is at least one DS record in the
parent zone for the tested zone.
The public half of the DNSSEC keys are stored in the zone. For a zone to be
correctly signed it is not enough to have DNSKEY records, but this test case
assumes that the existence of at least one DNSKEY record with at least one RRSIG
record [covering] the DNSKEY RRset means that the zone is signed.
It is not enough to have a signed zone. The parent zone must have a DS record to
create a chain of trust from root. If the zone is signed (i.e. has at least one
DNSKEY record) this test case will check if the parent zone has any DS records
for the zone.
The method for authentication a DNS response is described in section 5 of
[RFC 4035][RFC 4035#section-5]. The DNSKEY record is defined in section 2 of
[RFC 4034][RFC 4034#section-2], and the DS record is defined in section 5 of
[RFC 4034][RFC 4034#section-5].
While DNSSEC is an optional feature of the DNS protocol, not signing a zone
with DNSSEC is deemed to be a deviation from best practices that should
trigger an alert. A WARNING is therefore raised if the zone is not signed, or
if DS records are absent for a signed zone.
## Inputs
* "Child Zone" - The domain name to be tested.
* "Undelegated DS" - The DS record or records submitted. Empty unless submitted.
* "Undelegated Test" - TRUE if undelegated NS has been provided for the test.
## Summary
* If no DNSKEY records are found, then further investigation will not be done
and no messages will be outputted.
| Message Tag outputted | Level | Arguments | Message ID for message tag |
|:------------------------------|:--------|:---------------|:--------------------------------------------------------------------------------------------------------------------------------------------------|
| DS07_DS_FOR_SIGNED_ZONE | INFO | | The parent zone has DS record or records for the signed child zone. |
| DS07_DS_ON_PARENT_SERVER | INFO | ns_list | The following parent name servers respond with DS record or records for the child zone. Name servers: "{ns_list}". |
| DS07_INCONSISTENT_DS | ERROR | | Inconsistent responses from parent name servers. Some include DS, others do not. |
| DS07_INCONSISTENT_SIGNED | ERROR | | Inconsistent responses from name servers. Some include signed responses, others do not. |
| DS07_NON_AUTH_RESPONSE_DNSKEY | WARNING | ns_list | The following name servers give a non authoritative response on DNSKEY query with DO bit set. Name servers: "{ns_list}". |
| DS07_NOT_SIGNED | WARNING | | The zone is not signed. |
| DS07_NOT_SIGNED_ON_SERVER | WARNING | ns_list | The following name servers respond with no DNSKEY (unsigned child zone). Name servers: "{ns_list}". |
| DS07_NO_DS_ON_PARENT_SERVER | WARNING | ns_list | The following parent name servers respond without DS record for the child zone. Name servers: "{ns_list}". |
| DS07_NO_DS_FOR_SIGNED_ZONE | WARNING | | The parent zone has no DS record for the signed child zone. |
| DS07_NO_RESPONSE_DNSKEY | WARNING | ns_list | The following name servers do not respond on DNSKEY query with DO bit set. Name servers: "{ns_list}". |
| DS07_SIGNED | INFO | | The zone is signed. |
| DS07_SIGNED_ON_SERVER | INFO | ns_list | The following name servers respond with DNSKEY (signed child zone). Name servers: "{ns_list}". |
| DS07_UNEXP_RCODE_RESP_DNSKEY | WARNING | ns_list, rcode | The following name servers respond with RCODE "{rcode}" instead of expected "NOERROR" on DNSKEY query with DO bit set. Name servers: "{ns_list}". |
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
The name server names are assumed to be available at the time when the msgid
is created, if the argument name is "ns" or "ns_list" even when in the
"[Test procedure]" below it is only referred to the IP address of the name
servers.
### Restrictions on combinations of the message tags
Below are some restrictions on how some of the message tags, defined above, can
be combined.
* For each test exactly one of either *DS07_INCONSISTENT_SIGNED*, *DS07_SIGNED* and
*DS07_NOT_SIGNED* is outputted.
* For each test only one of *DS07_INCONSISTENT_DS*, *DS07_DS_FOR_SIGNED_ZONE* and
*DS07_NO_DS_FOR_SIGNED_ZONE* can be outputted.
* If *DS07_NOT_SIGNED* is outputted, then none of *DS07_INCONSISTENT_DS*,
*DS07_DS_FOR_SIGNED_ZONE* and *DS07_NO_DS_FOR_SIGNED_ZONE* is outputted.
## Test procedure
In this section and unless otherwise specified below, the terms "[DNS Query]"
and "[DNSSEC Query]", respectively, follow the specification for DNS queries as
specified in [DNS Query and Response Defaults]. The handling of the DNS responses
on the DNS queries follow, unless otherwise specified below, what is specified
for [DNS Response] and [DNSSEC Response], respectively, in the same
specification.
A complete list of all DNS Resource Record types can be found in the
[IANA RR Type List].
1. Create a [DNS Query] with query type SOA and query name *Child Zone*
("SOA Query").
2. Create a [DNSSEC Query] with query type DNSKEY and query name *Child Zone*
("DNSKEY Query").
3. Create a [DNSSEC Query] with query type DS and query name *Child Zone*
("DS Query") (for the parent name servers).
4. Retrieve all name server names and IP addresses for *Child Zone* using methods
[Get-Del-NS-Names-and-IPs] and [Get-Zone-NS-Names-and-IPs] ("Child NS IP").
5. Create the following empty sets:
1. Name server IP address ("Ignored Child NS").
2. Name server IP address ("No Response DNSKEY Query").
3. Name server IP address ("No Auth DNSKEY Response").
4. Name server IP address and [RCODE Name] ("Error RCODE DNSKEY Response").
5. Name server IP address ("No DNSKEY").
6. Name server IP address ("Signed Response").
7. Name server IP address ("Ignored Parent NS IP").
8. Name server IP address ("No DS").
9. Name server IP address ("DS in Response").
6. For each name server IP address in *Child NS IP* do:
1. Send *SOA Query* to the name server IP.
2. Add the name server IP to the *Ignored Child NS* set and go to next name
server IP if at least one of the following criteria is met:
1. There is no DNS response.
2. The [RCODE Name] in the response is not "NoError".
3. The AA flag is not set in the response.
4. The SOA record is missing in the answer section.
3. Send *DNSKEY Query* to the name server IP.
4. Add the name server IP to the *No Response DNSKEY Query* set and go to
next name server IP if there is no DNS response to the query.
5. Add the name server IP to the *No Auth DNSKEY Response* set and go to
next name server IP if the AA bit is not set in the response.
6. Add the name server IP and the [RCODE Name] to the
*Error RCODE DNSKEY Response* set and go to next name server IP if the
[RCODE Name] is not NOERROR.
7. Add the name server IP to the *Signed Response* set and go to next name
server IP if the answer section contains the following DNS records:
* At least one DNSKEY record.
* At least one RRSIG record [covering] the DNSKEY RRset.
8. Else add the name server IP to the *No DNSKEY* set and go to
next name server IP.
7. Retrieve all name server names and IP addresses for the parent zone of
*Child Zone* using method [Get-Parent-NS-Names-and-IPs]
("Parent NS Names and IPs").
8. If *Undelegated DS* is non-empty then do:
1. Add name server IP as "-" to the *DS in Response* set.
2. Make *Parent NS Names and IPs* an empty set.
9. If the *Signed Response* set is empty, make *Parent NS Names and IPs* and
*DS in Response* empty sets.
> Note: *Parent NS Names and IPs* will be empty if any of the following is true:
> * *Undelegated test* is TRUE.
> * *Undelegated DS* is non-empty.
> * *Child Zone* is ".", i.e. root zone.
> * The *Signed Response* set is empty.
10. For each unique parent name server IP in *Parent NS Names and IPs* do:
1. Send *DS Query* to the name server IP.
2. If at least one of the following criteria is met, then add name server IP
to the "Ignored Parent NS IP" set and go to next parent name server:
1. There is no [DNSSEC Response].
2. The [RCODE Name] in the [DNSSEC Response] is not "NoError".
3. The OPT record is absent in the [DNSSEC Response].
4. The DO flag is unset in the [DNSSEC Response].
5. The AA flag is not set in the [DNSSEC Response].
3. Add the parent name server IP to the *DS in Response* set and go to the
next parent name server IP if the answer section contains the following
DNS records:
* At least one DS record with *Child Zone* as owner name.
* At least one RRSIG [covering] the DS RRset.
4. Else add the parent name server IP to the *No DS* set and go
to next parent name server IP.
11. The name server names are assumed to be available at the time when the msgid
is created, if the argument name is "ns" or "ns_list" even when below it is
only referred to the IP address of the name servers. For child zone name
servers refer to the *Child NS IP* set, and for the parent name servers refer
to the *Parent NS Names and IPs* set. In both sets more than one name server
name may be connected to the same IP address. In such a case, multiple "ns"
or multiple entries in the "ns_list" should be created.
12. If the following sets combined (i.e. the union of the sets) is identical to
the *Child NS IP* set, output *[DS07_NOT_SIGNED]*.
* *Ignored Child NS*
* *No Response DNSKEY Query*
* *No Auth DNSKEY Response*
* *Error RCODE DNSKEY Response*
13. If the *No Response DNSKEY Query* set is non-empty then output
*[DS07_NO_RESPONSE_DNSKEY]* with the list of name servers from the
*No Response DNSKEY Query* set.
14. If the *No Auth DNSKEY Response* set is non-empty then output
*[DS07_NON_AUTH_RESPONSE_DNSKEY]* with the list of name servers from the
*No Auth DNSKEY Response* set.
15. If the *Error RCODE DNSKEY Response* set is non-empty then for each
[RCODE Name] in the set output *[DS07_UNEXP_RCODE_RESP_DNSKEY]* with the
[RCODE Name] and list of name servers from the *Error RCODE DNSKEY Response*
set.
16. If the *Signed Response* set is non-empty then output
*[DS07_SIGNED_ON_SERVER]* with the list of name servers from the
*Signed Response* set.
17. If the *No DNSKEY* set is non-empty then output *[DS07_NOT_SIGNED_ON_SERVER]*
with the list of name servers from the *No DNSKEY* set.
18. If both the *Signed Response* and *No DNSKEY* sets are non-empty then output
*[DS07_INCONSISTENT_SIGNED]*.
19. If the *Signed Response* is non-empty and the *No DNSKEY* set is empty then
output *[DS07_SIGNED]*.
20. If the *Signed Response* is empty and the *No DNSKEY* set is non-empty then
output *[DS07_NOT_SIGNED]*.
21. If the *No DS* sets is non-empty, then output *[DS07_NO_DS_ON_PARENT_SERVER]*
with the list of name servers from the *No DS* set.
22. If the *DS in Response* sets non-empty, then output
*[DS07_DS_ON_PARENT_SERVER]* with the list of name servers from the
*DS in Response* set.
22. If both the *No DS* and the *DS in Response* sets are non-empty, then output
*[DS07_INCONSISTENT_DS]*.
24. If the *No DNSKEY* set is empty and the *Signed Response* set is non-empty,
then do:
1. If the *No DS* is non-empty and the *DS in Response* set is empty, then
output *[DS07_NO_DS_FOR_SIGNED_ZONE]*.
2. If the *No DS* is empty and the *DS in Response* set is non-empty, then
output *[DS07_DS_FOR_SIGNED_ZONE]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
This test case should always be the first test case to be run in the DNSSEC
Module. The second test case to be run is [DNSSEC11]. If this test case outputs
*[DS07_NOT_SIGNED]* for a test, then no other
[test case of the DNSSEC module][DNSSEC#test-case-list] besides [DNSSEC11]
should be run.
## Intercase dependencies
None.
## Terminology
"Covering" -- the term is used in this test case to describe the relation of an
RRSIG to the signed RRset as described in the first four bullets in section 5.3.1
in [RFC 4035][RFC 4035#section-5.3.1]. The verification described in the
following four bullets and the actual verification against the DNSKEY is not
included for this test case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[Covering]: #terminology
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNS Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dns-query
[DNS Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dns-response
[DNSSEC Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dnssec-query
[DNSSEC README]: README.md
[DNSSEC#test-case-list]: README.md#test-case-list
[DNSSEC Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dnssec-response
[DNSSEC11]: dnssec11.md
[DS07_DS_FOR_SIGNED_ZONE]: #summary
[DS07_DS_ON_PARENT_SERVER]: #summary
[DS07_INCONSISTENT_DS]: #summary
[DS07_INCONSISTENT_SIGNED]: #summary
[DS07_NON_AUTH_RESPONSE_DNSKEY]: #summary
[DS07_NOT_SIGNED]: #summary
[DS07_NOT_SIGNED_ON_SERVER]: #summary
[DS07_NO_DS_ON_PARENT_SERVER]: #summary
[DS07_NO_DS_FOR_SIGNED_ZONE]: #summary
[DS07_NO_RESPONSE_DNSKEY]: #summary
[DS07_SIGNED]: #summary
[DS07_SIGNED_ON_SERVER]: #summary
[DS07_UNEXP_RCODE_RESP_DNSKEY]: #summary
[ERROR]: ../SeverityLevelDefinitions.md#error
[Get-Del-NS-Names-and-IPs]: ../MethodsV2.md#method-get-delegation-ns-names-and-ip-addresses
[Get-Parent-NS-Names-and-IPs]: ../MethodsV2.md#method-get-parent-ns-names-and-ip-addresses
[Get-Zone-NS-Names-and-IPs]: ../MethodsV2.md#method-get-zone-ns-names-and-ip-addresses
[IANA RR Type List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
[INFO]: ../SeverityLevelDefinitions.md#info
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 4034#section-2]: https://datatracker.ietf.org/doc/html/rfc4034#section-2
[RFC 4034#section-5]: https://datatracker.ietf.org/doc/html/rfc4034#section-5
[RFC 4035#section-5.3.1]: https://datatracker.ietf.org/doc/html/rfc4035#section-5.3.1
[RFC 4035#section-5]: https://datatracker.ietf.org/doc/html/rfc4035#section-5
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Test procedure]: #test-procedure
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

192
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec08.md Normal file
View File

@@ -0,0 +1,192 @@
# DNSSEC08: Valid RRSIG for DNSKEY
## Test case identifier
**DNSSEC08**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
A DNSSEC signed zone should have a DNSKEY RRset in the zone apex
([RFC 4035][RFC 4035#section-2.1], section 2.1) and that RRset
should be signed by a key that matches one of the records in the
DNSKEY RRset ([RFC 4035][RFC 4035#section-2.2], section 2.2).
This test case will verify if the *Child Zone* meets that
requirement.
## Scope
It is assumed that *Child Zone* is tested and reported by [Connectivity01]. This test
case will just ignore non-responsive name servers or name servers not giving a
correct DNS response for an authoritative name server.
This test case is only relevant if the zone has been DNSSEC signed.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
* If no DNSKEY records are found, then further investigation will not be done
and no messages will be outputted.
Message Tag outputted | Level | Arguments | Description of when message tag is outputted
:----------------------------------|:--------|:-------------------|:--------------------------------------------
DS08_ALGO_NOT_SUPPORTED_BY_ZM | NOTICE | ns_ip_list, algo_mnemo, algo_num, keytag | This installation of Zonemaster does not support the DNSKEY algorithm.
DS08_DNSKEY_RRSIG_EXPIRED | ERROR | ns_ip_list, keytag | DNSKEY RRset is signed with an RRSIG that has expired.
DS08_DNSKEY_RRSIG_NOT_YET_VALID | ERROR | ns_ip_list, keytag | DNSKEY RRset is signed with a not yet valid RRSIG.
DS08_MISSING_RRSIG_IN_RESPONSE | ERROR | ns_ip_list | DNSKEY is unsigned which is against expectation.
DS08_NO_MATCHING_DNSKEY | ERROR | ns_ip_list, keytag | DNSKEY RRset is signed with an RRSIG that does not match any DNSKEY.
DS08_RRSIG_NOT_VALID_BY_DNSKEY | ERROR | ns_ip_list, keytag | DNSKEY RRset is signed with an RRSIG that cannot be validated by the matching DNSKEY.
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
## Test procedure
1. Create a DNSKEY query with DO flag set for *Child Zone* ("DNSKEY Query").
2. Retrieve all name server IP addresses for the
*Child Zone* using [Method4] and [Method5] ("NS IP").
3. Create the following empty sets:
1. Name server IP address ("DNSKEY without RRSIG").
2. Name server IP address and RRSIG key tag ("DNSKEY RRSIG not yet valid").
3. Name server IP address and RRSIG key tag ("DNSKEY RRSIG expired").
4. Name server IP address and RRSIG key tag ("No matching DNSKEY").
5. Name server IP address and RRSIG key tag ("RRSIG not valid by DNSKEY").
6. Name server IP address, DNSKEY record key tag and DNSKEY algorithm code
("Algo Not Supported By ZM").
4. For each name server IP address in *NS IP* do:
1. Send *DNSKEY Query* to the name server IP.
2. If at least one of the following criteria is met, then go to next name
server IP:
1. There is no DNS response.
2. The RCODE of response is not "NoError" ([IANA RCODE List]).
3. The AA flag is not set in the response.
4. There is no DNSKEY record with matching owner name in the answer
section.
3. Retrieve the DNSKEY records and its RRSIG records from the answer section.
4. If there is no RRSIG for the DNSKEY record, then add the name server IP
address to the *DNSKEY without RRSIG* set and go to next name server IP.
8. Else, for each DNSKEY RRSIG record do:
1. If the RRSIG record start of validity is after the time of the
test, then add name server IP and RRSIG key tag to the
*DNSKEY RRSIG not yet valid* set.
2. Else, if the RRSIG record end of validity is before the time of the
test, then add name server IP and RRSIG key tag to the
*DNSKEY RRSIG expired* set.
3. Else, if the Zonemaster installation does not have support for the
DNSKEY algorithm that created the RRSIG, then add name server IP,
DNSKEY algorithm and DNSKEY key tag to the *Algo Not Supported By ZM*
set.
4. Else, if the RRSIG does not match any DNSKEY, then add the name server
IP and the RRSIG key tag to the *No matching DNSKEY* set.
5. Else, if the RRSIG cannot be validated by the matching DNSKEY record,
then add the name server
IP and the RRSIG key tag to the *RRSIG not valid by DNSKEY* set.
6. If the *DNSKEY without RRSIG* set is non-empty, then output
*[DS08_MISSING_RRSIG_IN_RESPONSE]* with the name servers IP addresses from
the set.
7. If the *DNSKEY RRSIG not yet valid* set is non-empty, then for each RRSIG key tag
from the set output *[DS08_DNSKEY_RRSIG_NOT_YET_VALID]* with the key tag and the
name servers IP addresses from the set.
8. If the *DNSKEY RRSIG expired* set is non-empty, then for each RRSIG key tag
from the set output *[DS08_DNSKEY_RRSIG_EXPIRED]* with the key tag and the
name servers IP addresses from the set.
9. If the *No matching DNSKEY* set is non-empty, then for each RRSIG key tag
from the set output *[DS08_NO_MATCHING_DNSKEY]* with the key tag and the
name servers IP addresses from the set.
10. If the *RRSIG not valid by DNSKEY* set is non-empty, then for each RRSIG key
ID from the set output *[DS08_RRSIG_NOT_VALID_BY_DNSKEY]* with the key tag and
the name servers IP addresses from the set.
11. If the *Algo Not Supported By ZM* set is non-empty, then output
*[DS08_ALGO_NOT_SUPPORTED_BY_ZM]* for each DNSKEY key tag with the name
server IP addresses, the key tag and the algorithm name and code from the set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
See the [DNSSEC README] document about DNSSEC algorithms.
## Intercase dependencies
None.
## Terminology
No special terminology for this test case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DNSSEC README]: ./README.md
[DNSSEC README]: README.md
[DS08_ALGO_NOT_SUPPORTED_BY_ZM]: #summary
[DS08_DNSKEY_RRSIG_EXPIRED]: #summary
[DS08_DNSKEY_RRSIG_NOT_YET_VALID]: #summary
[DS08_MISSING_RRSIG_IN_RESPONSE]: #summary
[DS08_NO_MATCHING_DNSKEY]: #summary
[DS08_RRSIG_NOT_VALID_BY_DNSKEY]: #summary
[ERROR]: ../SeverityLevelDefinitions.md#error
[IANA RCODE List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[INFO]: ../SeverityLevelDefinitions.md#info
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 4035#section-2.1]: https://datatracker.ietf.org/doc/html/rfc4035#section-2.1
[RFC 4035#section-2.2]: https://datatracker.ietf.org/doc/html/rfc4035#section-2.2
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

212
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec09.md Normal file
View File

@@ -0,0 +1,212 @@
# DNSSEC09: RRSIG(SOA) must be valid and created by a valid DNSKEY
## Test case identifier
**DNSSEC09**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
If the zone is signed, the SOA RR should be signed with a valid RRSIG
using a DNSKEY from the DNSKEY RR set. This is described
in [RFC 4035][RFC 4035#section-2.2], section 2.2.
This test case will verify if the *Child Zone* meets that
requirement.
## Scope
It is assumed that *Child Zone* is tested and reported by [Connectivity01]. This test
case will just ignore non-responsive name servers or name servers not giving a
correct DNS response for an authoritative name server.
Inconsistencies in the SOA record are expected to be caught by [Consistency01],
[Consistency02], [Consistency03] and [Consistency06].
Inconsistencies in the DNSKEY RRset are expected to be caught by [DNSSEC08].
This test case is only relevant if the zone has been DNSSEC signed.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
* If no DNSKEY records are found, then further investigation will not be done
and no messages will be outputted.
Message Tag outputted | Level | Arguments | Description of when message tag is outputted
:----------------------------------|:--------|:-------------------|:--------------------------------------------
DS09_ALGO_NOT_SUPPORTED_BY_ZM | NOTICE | ns_ip_list, algo_mnemo, algo_num, keytag | This installation of Zonemaster does not support the DNSKEY algorithm.
DS09_MISSING_RRSIG_IN_RESPONSE | ERROR | ns_ip_list | SOA is unsigned which is against expectation
DS09_NO_MATCHING_DNSKEY | ERROR | ns_ip_list, keytag | SOA is signed with an RRSIG that does not match any DNSKEY
DS09_RRSIG_NOT_VALID_BY_DNSKEY | ERROR | ns_ip_list, keytag | SOA is signed with an RRSIG that cannot be validated by the matching DNSKEY
DS09_SOA_RRSIG_EXPIRED | ERROR | ns_ip_list, keytag | SOA is signed with an RRSIG that has expired
DS09_SOA_RRSIG_NOT_YET_VALID | ERROR | ns_ip_list, keytag | SOA is signed with a not yet valid RRSIG
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
## Test procedure
1. Create a DNSKEY query with DO flag set for *Child Zone* ("DNSKEY Query").
2. Create an SOA query with DO flag set for *Child Zone* ("SOA Query").
3. Retrieve all name server IP addresses for the
*Child Zone* using [Method4] and [Method5] ("NS IP").
4. Create the following empty sets:
1. Name server IP address ("SOA without RRSIG").
2. Name server IP address and RRSIG key tag ("SOA RRSIG not yet valid").
3. Name server IP address and RRSIG key tag ("SOA RRSIG expired").
4. Name server IP address and RRSIG key tag ("No matching DNSKEY").
5. Name server IP address and RRSIG key tag ("RRSIG not valid by DNSKEY").
6. Name server IP address, DNSKEY record key tag and DNSKEY algorithm code
("Algo Not Supported By ZM").
5. For each name server IP address in *NS IP* do:
1. Send *DNSKEY Query* to the name server IP.
2. If at least one of the following criteria is met, then go to next name
server IP:
1. There is no DNS response.
2. The RCODE of response is not "NoError" ([IANA RCODE List]).
3. The AA flag is not set in the response.
4. There is no DNSKEY record with matching owner name in the answer
section.
3. Retrieve the DNSKEY records with matching owner name from the answer
section (any DNSKEY records with non-matching owner name are ignored).
4. Send *SOA Query* over UDP to the name server IP.
5. If at least one of the following criteria is met, then go to next name
server IP:
1. There is no DNS response.
2. The RCODE of response is not "NoError" ([IANA RCODE List]).
3. The AA flag is not set in the response.
4. There is no SOA record with matching owner name in the answer
section.
6. Retrieve the SOA record with matching owner name and its RRSIG record.
* Retrieve only one SOA record if there are multiple records. Any SOA
records with non-matching owner name are ignored.
7. If there is no RRSIG for the SOA record, then add the name server IP
address to the *SOA without RRSIG* set and go to next name server IP.
8. Else, for each SOA RRSIG record do:
1. If the RRSIG record start of validity is after the time of the
test, then add name server IP and RRSIG key tag to the
*SOA RRSIG not yet valid* set.
2. Else, if the RRSIG record end of validity is before the time of the
test, then add name server IP and RRSIG key tag to the
*SOA RRSIG expired* set.
3. Else, if the Zonemaster installation does not have support for the
DNSKEY algorithm that created the RRSIG, then add name server IP,
DNSKEY algorithm and DNSKEY key tag to the *Algo Not Supported By ZM*
set.
4. Else, if the RRSIG does not match any DNSKEY, then add the name server
IP and the RRSIG key tag to the *No matching DNSKEY* set.
5. Else, if the RRSIG cannot be validated by the matching DNSKEY record,
then add the name server
IP and the RRSIG key tag to the *RRSIG not valid by DNSKEY* set.
6. If the *SOA without RRSIG* set is non-empty, then output
*[DS09_MISSING_RRSIG_IN_RESPONSE]* with the name servers IP addresses from
the set.
7. If the *SOA RRSIG not yet valid* set is non-empty, then for each RRSIG key tag
from the set output *[DS09_SOA_RRSIG_NOT_YET_VALID]* with the key tag and the
name servers IP addresses from the set.
8. If the *SOA RRSIG expired* set is non-empty, then for each RRSIG key tag
from the set output *[DS09_SOA_RRSIG_EXPIRED]* with the key tag and the
name servers IP addresses from the set.
9. If the *No matching DNSKEY* set is non-empty, then for each RRSIG key tag
from the set output *[DS09_NO_MATCHING_DNSKEY]* with the key tag and the
name servers IP addresses from the set.
10. If the *RRSIG not valid by DNSKEY* set is non-empty, then for each RRSIG key
ID from the set output *[DS09_RRSIG_NOT_VALID_BY_DNSKEY]* with the key tag and
the name servers IP addresses from the set.
11. If the *Algo Not Supported By ZM* set is non-empty, then output
*[DS09_ALGO_NOT_SUPPORTED_BY_ZM]* for each DNSKEY key tag with the name
server IP addresses, the key tag and the algorithm name and code from the set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
See the [DNSSEC README] document about DNSSEC algorithms.
## Intercase dependencies
None.
## Terminology
No special terminology for this test case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[Consistency01]: ../Consistency-TP/consistency01.md
[Consistency02]: ../Consistency-TP/consistency02.md
[Consistency03]: ../Consistency-TP/consistency03.md
[Consistency06]: ../Consistency-TP/consistency06.md
[DNSSEC README]: ./README.md
[DNSSEC08]: ../DNSSEC-TP/dnssec08.md
[DS09_ALGO_NOT_SUPPORTED_BY_ZM]: #summary
[DS09_MISSING_RRSIG_IN_RESPONSE]: #summary
[DS09_NO_MATCHING_DNSKEY]: #summary
[DS09_RRSIG_NOT_VALID_BY_DNSKEY]: #summary
[DS09_SOA_RRSIG_EXPIRED]: #summary
[DS09_SOA_RRSIG_NOT_YET_VALID]: #summary
[ERROR]: ../SeverityLevelDefinitions.md#error
[IANA RCODE List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[INFO]: ../SeverityLevelDefinitions.md#info
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 4035#section-2.2]: https://datatracker.ietf.org/doc/html/rfc4035#section-2.2
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

617
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec10.md Normal file
View File

@@ -0,0 +1,617 @@
# DNSSEC10: Zone contains NSEC or NSEC3 records
## Test case identifier
**DNSSEC10**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Comments on mixing of NSEC and NSEC3](#comments-on-mixing-of-nsec-and-nsec3)
* [Test procedure]
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
When DNSSEC is enabled, NSEC or NSEC3 records provide a secure denial of
existence for records not present in the zone. This Test Case verifies that
correct NSEC or NSEC3 records with valid signatures are returned for a query for
an RR type that does not exist for that specific name (node in the DNS tree).
The existing RR types are listed in the [IANA RR Type List].
Furthermore, it is verified that the name servers for the zone are consistent
about NSEC and NSEC3, i.e. either all servers should use NSEC or all servers
should use NSEC3. It is never permitted to serve both NSEC and NSEC3 for the
same zone.
The NSEC3PARAM RR that must exist in the zone (in apex, and apex only) if NSEC3
is used, but must not exist in a zone using NSEC.
The use of the NSEC RR type is described in [RFC 4035][RFC 4035#section-3.1.3],
section 3.1.3, and the description of the NSEC RR itself is in
[RFC 4034][RFC 4034#section-4], section 4.
The description of the NSEC3 and NSEC3PARAM RRs are found in
[RFC 5155][RFC 5155#section-3], section 3, and [RFC 5155][RFC 5155#section-4],
section 4, respectively. The use of NSEC3 in the DNS response is described in
[RFC 5155][RFC 5155#section-7.2], section 7.2.
## Scope
This test case will just ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server (covered by
[Connectivity01]).
This test case is only relevant if the zone has been DNSSEC signed.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
* If no DNSKEY records are found, then further investigation will not be done
and no messages will be outputted.
Message Tag outputted | Level | Arguments | Message ID for message tag
:----------------------------------|:--------|:-----------|:--------------------------------------------
DS10_ALGO_NOT_SUPPORTED_BY_ZM | NOTICE | ns_list, algo_mnemo, algo_num, keytag | DNSKEY with tag {keytag} uses unsupported algorithm {algo_num} ({algo_mnemo}) by this installation of Zonemaster. Fetched from name servers "{ns_list}".
DS10_ERR_MULT_NSEC | ERROR | ns_list | Multiple NSEC records when one is expected. Fetched from name servers "{ns_list}".
DS10_ERR_MULT_NSEC3 | ERROR | ns_list | Multiple NSEC3 records when one is expected. Fetched from name servers "{ns_list}".
DS10_ERR_MULT_NSEC3PARAM | ERROR | ns_list | Multiple NSEC3PARAM records when one is expected. Fetched from name servers "{ns_list}".
DS10_EXPECTED_NSEC_NSEC3_MISSING | ERROR | ns_list | The server responded with DNSKEY but not with expected NSEC or NSEC3. Fetched from name servers "{ns_list}".
DS10_HAS_NSEC | INFO | ns_list | The zone has NSEC records. Fetched from name servers "{ns_list}".
DS10_HAS_NSEC3 | INFO | ns_list | The zone has NSEC3 records. Fetched from name servers "{ns_list}".
DS10_INCONSISTENT_NSEC | ERROR | ns_list | Inconsistent responses from zone with NSEC. Fetched from name servers "{ns_list}".
DS10_INCONSISTENT_NSEC3 | ERROR | ns_list | Inconsistent responses from zone with NSEC3. Fetched from name servers "{ns_list}".
DS10_INCONSISTENT_NSEC_NSEC3 | ERROR |ns_list_nsec, ns_list_nsec3| The zone is inconsistent on NSEC and NSEC3. NSEC is fetched from name servers "{ns_list_nsec}". NSEC3 is fetched from name servers "{ns_list_nsec3}".
DS10_MIXED_NSEC_NSEC3 | ERROR | ns_list | The zone responds with both NSEC and NSEC3, where only one of them is expected. Fetched from name servers "{ns_list}".
DS10_NSEC3PARAM_GIVES_ERR_ANSWER | ERROR | ns_list | Unexpected DNS record in the answer section on an NSEC3PARAM query. Fetched from name servers "{ns_list}".
DS10_NSEC3PARAM_MISMATCHES_APEX | ERROR | ns_list | The returned NSEC3PARAM record has an unexpected non-apex owner name. Fetched from name servers "{ns_list}".
DS10_NSEC3PARAM_QUERY_RESPONSE_ERR | ERROR | ns_list | No response or error in response on query for NSEC3PARAM. Fetched from name servers "{ns_list}".
DS10_NSEC3_ERR_TYPE_LIST | ERROR | ns_list | NSEC3 record for the zone apex with incorrect type list. Fetched from name servers "{ns_list}".
DS10_NSEC3_MISMATCHES_APEX | ERROR | ns_list | The returned NSEC3 record unexpectedly does not match the zone name. Fetched from name servers "{ns_list}".
DS10_NSEC3_MISSING_SIGNATURE | ERROR | ns_list | Missing RRSIG (signature) for the NSEC3 record or records. Fetched from name servers "{ns_list}".
DS10_NSEC3_NODATA_MISSING_SOA | ERROR | ns_list | Missing SOA record in NODATA response with NSEC3. Fetched from name servers "{ns_list}".
DS10_NSEC3_NODATA_WRONG_SOA | ERROR | ns_list, domain | Wrong owner name ("{domain}") on SOA record in NODATA response with NSEC3. Fetched from name servers "{ns_list}".
DS10_NSEC3_NO_VERIFIED_SIGNATURE | ERROR | ns_list | The RRSIG (signature) for the NSEC3 record cannot be verified. Fetched from name servers "{ns_list}".
DS10_NSEC3_RRSIG_EXPIRED | ERROR | ns_list, keytag | The RRSIG (signature) with tag {keytag} for the NSEC3 record has expired. Fetched from name servers "{ns_list}".
DS10_NSEC3_RRSIG_NOT_YET_VALID | ERROR | ns_list, keytag | The RRSIG (signature) with tag {keytag} for the NSEC3 record it not yet valid. Fetched from name servers "{ns_list}".
DS10_NSEC3_RRSIG_NO_DNSKEY | WARNING | ns_list, keytag | There is no DNSKEY record matching the RRSIG (signature) with tag {keytag} for the NSEC3 record. Fetched from name servers "{ns_list}".
DS10_NSEC3_RRSIG_VERIFY_ERROR | ERROR | ns_list, keytag | The RRSIG (signature) with tag {keytag} for the NSEC3 record cannot be verified. Fetched from name servers "{ns_list}".
DS10_NSEC_ERR_TYPE_LIST | ERROR | ns_list | NSEC record for the zone apex with incorrect type list. Fetched from name servers "{ns_list}".
DS10_NSEC_GIVES_ERR_ANSWER | ERROR | ns_list | Unexpected DNS record in the answer section on an NSEC query. Fetched from name servers "{ns_list}".
DS10_NSEC_MISMATCHES_APEX | ERROR | ns_list | The returned NSEC record has an unexpected non-apex owner name. Fetched from name servers "{ns_list}".
DS10_NSEC_MISSING_SIGNATURE | ERROR | ns_list | Missing RRSIG (signature) for the NSEC record or records. Fetched from name servers "{ns_list}".
DS10_NSEC_NODATA_MISSING_SOA | ERROR | ns_list | Missing SOA record in NODATA response with NSEC. Fetched from name servers "{ns_list}".
DS10_NSEC_NODATA_WRONG_SOA | ERROR | ns_list, domain | Wrong owner name ("{domain}") on SOA record in NODATA response with NSEC. Fetched from name servers "{ns_list}".
DS10_NSEC_NO_VERIFIED_SIGNATURE | ERROR | ns_list | There is no RRSIG (signature) for the NSEC record that can be verified. Fetched from name servers "{ns_list}".
DS10_NSEC_QUERY_RESPONSE_ERR | ERROR | ns_list | No response or error in response on query for NSEC. Fetched from name servers "{ns_list}".
DS10_NSEC_RRSIG_EXPIRED | ERROR | ns_list, keytag | The RRSIG (signature) with tag {keytag} for the NSEC record has expired. Fetched from name servers "{ns_list}".
DS10_NSEC_RRSIG_NOT_YET_VALID | ERROR | ns_list, keytag | The RRSIG (signature) with tag {keytag} for the NSEC record it not yet valid. Fetched from name servers "{ns_list}".
DS10_NSEC_RRSIG_NO_DNSKEY | WARNING | ns_list, keytag | There is no DNSKEY record matching the RRSIG (signature) with tag {keytag} for the NSEC record. Fetched from name servers "{ns_list}".
DS10_NSEC_RRSIG_VERIFY_ERROR | ERROR | ns_list, keytag | The RRSIG (signature) with tag {keytag} for the NSEC record cannot be verified. Fetched from name servers "{ns_list}".
DS10_SERVER_NO_DNSSEC | ERROR | ns_list | The following name servers do not support DNSSEC or have not been properly configured. Testing for NSEC and NSEC3 has been skipped on these servers. Fetched from name servers "{ns_list}".
DS10_ZONE_NO_DNSSEC | NOTICE | ns_list | The zone is not DNSSEC signed or not properly DNSSEC signed. Testing for NSEC and NSEC3 has been skipped. Fetched from name servers "{ns_list}".
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
The name server names are assumed to be available at the time when the msgid
is created, if the argument name is "ns" or "ns_list" even when in the
"[Test procedure]" below it is only referred to the IP address of the name
servers.
For the Zonemaster definition of the mnemonics for DNSKEY algorithms, see the
algorithm table in the "Objective" section in [DNSSEC05][DNSSEC05#objective].
### Comments on mixing of NSEC and NSEC3
In section "[Test procedure]" below, if the server returns an NSEC record (either
in the answer section when querying for NSEC or on the authority section when
querying for NSEC3PARAM) it is considered to be "NSEC type" for the zone.
If the server returns an NSEC3PARAM record in the answer section when querying for
it or an NSEC3 record in the authority section when querying for NSEC, it is
considered to be "NSEC3 type" for the zone.
*[DS10_MIXED_NSEC_NSEC3]* means that one or several name servers have been
identified as both "NSEC type" and "NSEC3 type".
*[DS10_INCONSISTENT_NSEC_NSEC3]* means that some name servers are non-mixed
"NSEC type" and others are non-mixed "NSEC3 type" for the same zone.
## Test procedure
In this section and unless otherwise specified below, the term "[DNSSEC Query]"
follow the specification for DNS queries as specified in
[DNS Query and Response Defaults]. The handling of the DNS responses on the DNS
queries follow, unless otherwise specified below, what is specified for
[DNSSEC Response] in the same specification.
A complete list of all DNS Resource Record types can be found in the
[IANA RR Type List].
1. Create a [DNSSEC Query] with query type DNSKEY and query name *Child Zone*
("DNSKEY Query").
2. Create a [DNSSEC Query] with query type NSEC and query name *Child Zone*
("NSEC Query").
3. Create a [DNSSEC Query] with query type NSEC3PARAM and query name *Child Zone*
("NSEC3PARAM Query").
4. Retrieve all name server names and IP addresses for *Child Zone* using
methods [Get-Del-NS-Names-and-IPs] and [Get-Zone-NS-Names-and-IPs] ("NS IP").
5. Create the following empty sets:
1. Name server IP address, DNSKEY record key tag and DNSKEY algorithm code
("Algo Not Supported By ZM").
2. Name server IP address ("Erroneous Multiple NSEC").
3. Name server IP address ("Erroneous Multiple NSEC3").
4. Name server IP address ("Erroneous Multiple NSEC3PARAM").
5. Name server IP address ("Ignored NS IP").
6. Name server IP address ("NSEC In Answer").
7. Name server IP address ("NSEC Incorrect Type List").
8. Name server IP address ("NSEC Mismatches Apex").
9. Name server IP address ("NSEC Missing Signature").
10. Name server IP address and owner name (domain name data)
("NSEC NODATA Wrong SOA").
11. Name server IP address ("NSEC NODATA Missing SOA").
12. Name server IP address ("NSEC Query Gives Erroneous Answer").
13. Name server IP address ("NSEC Query Gives NSEC3 NODATA").
14. Name server IP address and key tag ("NSEC RRSIG Verify Error").
15. Name server IP address and key tag ("NSEC RRSIG Expired").
16. Name server IP address and key tag ("NSEC RRSIG Not Yet Valid").
17. Name server IP address and key tag ("NSEC RRSIG No DNSKEY").
18. Name server IP address ("NSEC RRSIG Verified").
19. Name server IP address ("NSEC Query Response Error").
20. Name server IP address ("NSEC3 Incorrect Type List").
21. Name server IP address ("NSEC3 Mismatches Apex").
22. Name server IP address ("NSEC3 Missing Signature").
23. Name server IP address and owner name (domain name data)
("NSEC3 NODATA Wrong SOA").
24. Name server IP address ("NSEC3 NODATA Missing SOA").
25. Name server IP address and key tag ("NSEC3 RRSIG Verify Error").
26. Name server IP address and key tag ("NSEC3 RRSIG Expired").
27. Name server IP address and key tag ("NSEC3 RRSIG Not Yet Valid").
28. Name server IP address and key tag ("NSEC3 RRSIG No DNSKEY").
29. Name server IP address ("NSEC3 RRSIG Verified").
30. Name server IP address ("NSEC3PARAM In Answer").
31. Name server IP address ("NSEC3PARAM Mismatches Apex").
32. Name server IP address ("NSEC3PARAM Query Gives Erroneous Answer").
33. Name server IP address ("NSEC3PARAM Query Gives NSEC NODATA").
34. Name server IP address ("NSEC3PARAM Query Response Error").
35. Name server IP address ("Responds without DNSKEY").
36. Name server IP address ("Responds with DNSKEY").
6. For each name server IP address in *NS IP* do:
1. Send *DNSKEY Query* to the name server IP.
2. Add the name server IP to the *Ignored NS IP* set and go to next name
server IP if at least one of the following criteria is met:
1. There is no DNS response.
2. The [RCODE Name] in the response is not "NoError".
3. The AA flag is not set in the response.
3. If the response does not contain any DNSKEY record with owner name
matching *Child Zone* in the answer section, add name server name and IP
to the *Responds without DNSKEY* set and go to next server.
4. Else, add name server IP to the *Responds with DNSKEY* set and retrieve
the DNSKEY records from the answer section to be used in validation below.
5. Send *NSEC Query* to the name server IP and do:
1. If at least one of the following criteria is met, then add the name
server IP to the *NSEC Query Response Error* set:
1. There is no DNS response.
2. The [RCODE Name] in the response is not "NoError".
3. The AA flag is not set in the response.
2. Else if the answer section is non-empty, then do:
1. If the answer section has at least one NSEC RR then do:
1. Add the name server IP to the *NSEC In Answer* set.
2. If the number of NSEC records is greater than one then add name
server IP to the *Erroneous Multiple NSEC* set.
3. Else, if the owner name of the NSEC record is not *Child Zone*
then add name server IP to the *NSEC Mismatches Apex* set.
2. Else add the name server IP to the
*NSEC Query Gives Erroneous Answer* set.
3. Else if the answer section is empty and the authority section contains
an NSEC3 record then do:
1. Add the name server IP to the *NSEC Query Gives NSEC3 NODATA*
set.
2. If the SOA record is missing from the authority section then add name
server IP to the *NSEC3 NODATA Missing SOA* set.
3. Else if the owner name of SOA record is not *Child Zone* then
add name server IP and owner name to the *NSEC3 NODATA Wrong SOA*
set.
4. If the authority section contains more than one NSEC3 record then
add name server IP to the *Erroneous Multiple NSEC3* set.
5. Else do:
1. If the hash owner name of the NSEC3 record does not match apex
of *Child Zone* then add name server IP to the
*NSEC3 Mismatches Apex* set.
2. Else if the type list in the NSEC3 record matches at least one
of the following criteria then add name server IP to the
*NSEC3 Incorrect Type List* set:
1. At least one of SOA, NS, DNSKEY, NSEC3PARAM or RRSIG is
missing.
2. At least one of NSEC or NSEC3 is included.
3. Retrieve the NSEC3 record from the response.
4. Retrieve the RRSIG records for the retrieved NSEC3 record.
5. If the NSEC3 record do not have a matching RRSIG
record, then add the name server IP to the
*NSEC3 Missing Signature* set.
6. Else do:
1. Use the DNSKEY records retrieved above.
2. For each NSEC3 RRSIG do:
1. Verify the RRSIG record by the DNSKEY records.
2. If there is no DNSKEY that matches RRSIG by key tag,
then add the name server IP and RRSIG key ID to the
*NSEC3 RRSIG No DNSKEY* set.
3. Else, if the RRSIG record has a validity period that ends
before the time of test execution, then add the name
server IP and RRSIG key ID to the
*NSEC3 RRSIG Expired* set.
4. Else, if the RRSIG record has a validity period that starts
after the time of test execution, then add the name
server IP and RRSIG key ID to the
*NSEC3 RRSIG Not Yet Valid* set.
5. Else, if the Zonemaster installation does not have support
for the DNSKEY algorithm that created the RRSIG, then add
name server IP, DNSKEY algorithm and DNSKEY key tag to
the *Algo Not Supported By ZM* set.
6. Else, if the RRSIG cannot be validated by the DNSKEY record
appointed, then add name server IP and DNSKEY key tag
to the *NSEC3 RRSIG Verify Error* set.
7. Else, add the name server IP to the
*NSEC3 RRSIG Verified* set.
6. Send *NSEC3PARAM Query* to the name server IP and do:
1. If at least one of the following criteria is met, then add the name
server IP to the *NSEC3PARAM Query Response Errors* set:
1. There is no DNS response.
2. The [RCODE Name] in the response is not "NoError".
3. The AA flag is not set in the response.
2. Else if the answer section is non-empty, then do:
1. If the answer section has at least one NSEC3PARAM RR then do:
1. Add the name server IP to the *NSEC3PARAM In Answer* set.
2. If the number of NSEC3PARAM records is greater than one then add
name server IP to the *Erroneous Multiple NSEC3PARAM* set.
3. Else, if the owner name of the NSEC3PARAM record is not
*Child Zone* then add name server IP to the
*NSEC3PARAM Mismatches Apex* set.
2. Else add the name server IP to the
*NSEC3PARAM Query Gives Erroneous Answer* set.
3. Else if the answer section is empty and the authority section contains
an NSEC record then do:
1. Add the name server IP to the *NSEC3PARAM Query Gives NSEC NODATA* set.
2. If the SOA record is missing the authority section then add the
name server IP to the *NSEC NODATA Missing SOA* set.
3. Else if the owner name of the SOA record is not *Child Zone* then
add name server IP and the owner name to the
*NSEC NODATA Wrong SOA* set.
4. If the authority section contains more than one NSEC record then
add name server IP to the *Erroneous Multiple NSEC* set.
5. Else do:
1. If the owner name of the NSEC record is not *Child Zone* then
add name server IP to the *NSEC Mismatches Apex* set.
2. Else if the type list in the NSEC record matches at least one
of the following criteria then add name server IP to the
*NSEC Incorrect Type List* set:
1. At least one of SOA, NS, DNSKEY, NSEC or RRSIG is missing.
2. At least one of NSEC3PARAM or NSEC3 is included.
3. Retrieve the NSEC record from the response.
4. Retrieve the RRSIG records for the retrieved NSEC record.
5. If the NSEC record does not have a matching RRSIG
record, then add the name server IP to the
*NSEC Missing Signature* set.
6. Else do:
1. Use the DNSKEY records retrieved above.
2. For each NSEC RRSIG do:
1. Verify the RRSIG record by the DNSKEY records.
2. If there is no DNSKEY that matches RRSIG by key tag,
then add the name server IP and RRSIG key ID to the
*NSEC RRSIG No DNSKEY* set.
3. Else, if the RRSIG record has a validity period that ends
before the time of test execution, then add the name
server IP and RRSIG key ID to the
*NSEC RRSIG Expired* set.
4. Else, if the RRSIG record has a validity period that starts
after the time of test execution, then add the name
server IP and RRSIG key ID to the
*NSEC RRSIG Not Yet Valid* set.
5. Else, if the Zonemaster installation does not have support
for the DNSKEY algorithm that created the RRSIG, then add
name server IP, DNSKEY algorithm and DNSKEY key tag to
the *Algo Not Supported By ZM* set.
6. Else, if the RRSIG cannot be validated by the DNSKEY record
appointed, then add name server IP and DNSKEY key tag
to the *NSEC RRSIG Verify Error* set.
7. Else, add the name server IP to the
*NSEC RRSIG Verified* set (unless it is already a member
of the set).
7. If the *Erroneous Multiple NSEC* set is non-empty then output
*[DS10_ERR_MULT_NSEC]* with the name server IP addresses from the
set.
8. If the *Erroneous Multiple NSEC3* set is non-empty then output
*[DS10_ERR_MULT_NSEC3]* with the name server IP addresses from the
set.
9. If the *Erroneous Multiple NSEC3PARAM* set is non-empty then output
*[DS10_ERR_MULT_NSEC3PARAM]* with the name server IP addresses from the
set.
10. Create a list of those name server IP included in the *NSEC In Answer* set
but not in the *NSEC3PARAM Query Gives NSEC NODATA* set, or the other way
around. From that list remove any name server IP included in the
*NSEC3PARAM In Answer* set or in the *NSEC Query Gives NSEC3 NODATA* set.
Output *[DS10_INCONSISTENT_NSEC]* with the resulting list of name server
IP addresses.
11. Create a list of those name server IP included in the *NSEC3PARAM In Answer*
set but not in the *NSEC Query Gives NSEC3 NODATA* set, or the other way
around. From that list remove any name server IP included in the
*NSEC In Answer* set or the *NSEC3PARAM Query Gives NSEC NODATA* set.
Output *[DS10_INCONSISTENT_NSEC3]* with the resulting list of name server
IP addresses.
12. Create a list of those name server IP included in the *NSEC3PARAM In Answer*
set or in the *NSEC Query Gives NSEC3 NODATA* set, and also included in the
*NSEC In Answer* set or the *NSEC3PARAM Query Gives NSEC NODATA* set. Output
*[DS10_MIXED_NSEC_NSEC3]* with the resulting list of name server IP
addresses.
13. If the *NSEC In Answer* set or the *NSEC3PARAM Query Gives NSEC NODATA* set
(or both) is non-empty and both the *NSEC3PARAM In Answer* set and the
*NSEC Query Gives NSEC3 NODATA* set are empty, then output *[DS10_HAS_NSEC]*
with the name server IP addresses from the sets.
14. If the *NSEC3PARAM In Answer* set or the *NSEC Query Gives NSEC3 NODATA* set
(or both) is non-empty and both the *NSEC In Answer* set and the
*NSEC3PARAM Query Gives NSEC NODATA* set are empty, then output
*[DS10_HAS_NSEC3]* with the name server IP addresses from the sets.
15. Create a list of the name server IP in the *NSEC3PARAM In Answer* set or in
the *NSEC Query Gives NSEC3 NODATA* set (or both), but neither in
the *NSEC In Answer* set or the *NSEC3PARAM Query Gives NSEC NODATA* set.
Create a second list of the name server IP in the *NSEC In Answer* set or in
the *NSEC3PARAM Query Gives NSEC NODATA* set (or both), but neither in the
*NSEC3PARAM In Answer* set or the *NSEC Query Gives NSEC3 NODATA* set.
If both lists are non-empty then output *[DS10_INCONSISTENT_NSEC_NSEC3]* with
both the lists.
16. If the *NSEC Incorrect Type List* set is non-empty, then output
*[DS10_NSEC_ERR_TYPE_LIST] with the list of name server IP in the set.
17. If the *NSEC Mismatches Apex* set is non-empty, then output
*[DS10_NSEC_MISMATCHES_APEX] with the list of name server IP in the set.
18. If the *NSEC NODATA Wrong SOA* set is non-empty, then for each owner name
in the set output *[DS10_NSEC_NODATA_WRONG_SOA]* with the owner name and the
list of name server IP in the set for that owner name.
19. If the *NSEC NODATA Missing SOA* set is non-empty, then output
*[DS10_NSEC_NODATA_MISSING_SOA]* with the list of name server IP in the set.
20. If the *NSEC Query Gives Erroneous Answer* set is non-empty, then output
*[DS10_NSEC_GIVES_ERR_ANSWER]* with the list of name server IP in the
set.
21. If the *NSEC Query Response Error* set is non-empty, then output
*[DS10_NSEC_QUERY_RESPONSE_ERR]* with the list of name server IP in the set.
22. If the *NSEC3 Incorrect Type List* set is non-empty, then output
*[DS10_NSEC3_ERR_TYPE_LIST]* with the list of name server IP in the set.
23. If the *NSEC3 Mismatches Apex* set is non-empty, then output
*[DS10_NSEC3_MISMATCHES_APEX]* with the list of name server IP in the set.
24. If the *NSEC3 NODATA Wrong SOA* set is non-empty, then for each owner name
in the set output *[DS10_NSEC3_NODATA_WRONG_SOA]* with the owner name and the
list of name server IP in the set for that owner name.
25. If the *NSEC3 NODATA Missing SOA* set is non-empty, then output
*[DS10_NSEC3_NODATA_MISSING_SOA]* with the list of name server IP in the set.
26. If the *NSEC3PARAM Query Gives Erroneous Answer* set is non-empty, then
output *[DS10_NSEC3PARAM_GIVES_ERR_ANSWER]* with the list of name server IP
in the set.
27. If the *NSEC3PARAM Mismatches Apex* set is non-empty, then output
*[DS10_NSEC3PARAM_MISMATCHES_APEX]* with the list of name server IP in the set.
28. If the *NSEC3PARAM Query Response Error* set is non-empty, then output
*[DS10_NSEC3PARAM_QUERY_RESPONSE_ERR]* with the list of name server IP in the
set.
29. If the *NSEC Missing Signature* set is non-empty then output
*[DS10_NSEC_MISSING_SIGNATURE]* with the name server IP addresses from the
set.
30. If the *NSEC3 Missing Signature* set is non-empty then output
*[DS10_NSEC3_MISSING_SIGNATURE]* with the name server IP addresses from the
set.
31. If the *NSEC RRSIG No DNSKEY* set is non-empty, then for each key ID
output *[DS10_NSEC_RRSIG_NO_DNSKEY]* with the key ID and the name server
IP addresses from the set for the key ID.
32. If the *NSEC RRSIG Expired* set is non-empty, then for each key ID
output *[DS10_NSEC_RRSIG_EXPIRED]* with the key ID and the name server
IP addresses from the set for the key ID.
33. If the *NSEC RRSIG Not Yet Valid* set is non-empty, then for each key ID
output *[DS10_NSEC_RRSIG_NOT_YET_VALID]* with the key ID and the name server
IP addresses from the set for the key ID.
34. If the *NSEC RRSIG Verify Error* set is non-empty, then for each key ID
output *[DS10_NSEC_RRSIG_VERIFY_ERROR]* with the key ID and the name server
IP addresses from the set for the key ID.
35. If the combined set of the unique name server IP addresses of the
*NSEC RRSIG No DNSKEY*, *NSEC RRSIG Expired*, *NSEC RRSIG Not Yet Valid* and
*NSEC RRSIG Verify Error* sets is non-empty, then do:
1. For each name server IP address in the combined set store the IP address
in a temporary set for the next step if the IP address is not a member of
the *NSEC RRSIG Verified* set.
2. If the temporary set is non-empty then output
*[DS10_NSEC_NO_VERIFIED_SIGNATURE]* with the name server IP addresses from
the set.
36. If the *NSEC3 RRSIG No DNSKEY* set is non-empty, then for each key ID
output *[DS10_NSEC3_RRSIG_NO_DNSKEY]* with the key ID and the name server
IP addresses from the set for the key ID.
37. If the *NSEC3 RRSIG Expired* set is non-empty, then for each key ID
output *[DS10_NSEC3_RRSIG_EXPIRED]* with the key ID and the name server
IP addresses from the set for the key ID.
38. If the *NSEC3 RRSIG Not Yet Valid* set is non-empty, then for each key ID
output *[DS10_NSEC3_RRSIG_NOT_YET_VALID]* with the key ID and the name server
IP addresses from the set for the key ID.
39. If the *NSEC3 RRSIG Verify Error* set is non-empty, then for each key ID
output *[DS10_NSEC3_RRSIG_VERIFY_ERROR]* with the key ID and the name server
IP addresses from the set for the key ID.
40. If the combined set of the *NSEC3 RRSIG No DNSKEY*, *NSEC3 RRSIG Expired*,
*NSEC3 RRSIG Not Yet Valid* and *NSEC3 RRSIG Verify Error* sets is non-empty,
then do:
1. Extract all unique name server IP address in the combined set that are
not members the *NSEC3 RRSIG Verified* set.
2. If the extracted name server IP addresses is a non-empty set then output
*[DS10_NSEC3_NO_VERIFIED_SIGNATURE]* with the extracted name server IP
addresses.
41. If the *Algo Not Supported By ZM* set is non-empty, then output
*[DS10_ALGO_NOT_SUPPORTED_BY_ZM]* for each DNSKEY key tag with the name
server IP addresses, the key tag and the algorithm name and code from the
set.
42. If the *Responds with DNSKEY* set is empty and the *Responds without DNSKEY*
is non-empty then output *[DS10_ZONE_NO_DNSSEC]* with the name server IP
addresses from the *Responds without DNSKEY* set.
43. If both the *Responds with DNSKEY* set and the *Responds without DNSKEY* set
are non-empty then output *[DS10_SERVER_NO_DNSSEC]* with the name server IP
addresses from the *Responds without DNSKEY* set.
44. Extract all members of the *NS IP* set that is not also a member of
the *Ignored NS IP* set, the *Responds without DNSKEY* set, the
*NSEC In Answer* set, the *NSEC3PARAM Query Gives NSEC NODATA* set, the
*NSEC3PARAM In Answer* set or the *NSEC Query Gives NSEC3 NODATA* set. If the
extracted set is non-empty, then output *[DS10_EXPECTED_NSEC_NSEC3_MISSING]*
with the extracted list of name server IP addresses.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, skip sending queries over that
transport protocol. A message will be outputted reporting that the transport
protocol has been skipped.
See the [DNSSEC README] document about DNSSEC algorithms.
## Intercase dependencies
None.
## Terminology
No special terminology for this Test Case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
[DNSSEC Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dnssec-query
[DNSSEC README]: README.md
[DNSSEC Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dnssec-response
[DNSSEC05#objective]: ../DNSSEC-TP/dnssec05.md#objective
[DS10_ALGO_NOT_SUPPORTED_BY_ZM]: #summary
[DS10_ERR_MULT_NSEC3PARAM]: #summary
[DS10_ERR_MULT_NSEC3]: #summary
[DS10_ERR_MULT_NSEC]: #summary
[DS10_EXPECTED_NSEC_NSEC3_MISSING]: #summary
[DS10_HAS_NSEC3]: #summary
[DS10_HAS_NSEC]: #summary
[DS10_INCONSISTENT_NSEC3]: #summary
[DS10_INCONSISTENT_NSEC]: #summary
[DS10_INCONSISTENT_NSEC_NSEC3]: #summary
[DS10_MIXED_NSEC_NSEC3]: #summary
[DS10_NSEC3PARAM_GIVES_ERR_ANSWER]: #summary
[DS10_NSEC3PARAM_MISMATCHES_APEX]: #summary
[DS10_NSEC3PARAM_QUERY_RESPONSE_ERR]: #summary
[DS10_NSEC3_ERR_TYPE_LIST]: #summary
[DS10_NSEC3_MISMATCHES_APEX]: #summary
[DS10_NSEC3_MISSING_SIGNATURE]: #summary
[DS10_NSEC3_NODATA_MISSING_SOA]: #summary
[DS10_NSEC3_NODATA_WRONG_SOA]: #summary
[DS10_NSEC3_NO_VERIFIED_SIGNATURE]: #summary
[DS10_NSEC3_RRSIG_EXPIRED]: #summary
[DS10_NSEC3_RRSIG_NOT_YET_VALID]: #summary
[DS10_NSEC3_RRSIG_NO_DNSKEY]: #summary
[DS10_NSEC3_RRSIG_VERIFY_ERROR]: #summary
[DS10_NSEC_ERR_TYPE_LIST]: #summary
[DS10_NSEC_GIVES_ERR_ANSWER]: #summary
[DS10_NSEC_MISMATCHES_APEX]: #summary
[DS10_NSEC_MISSING_SIGNATURE]: #summary
[DS10_NSEC_NODATA_MISSING_SOA]: #summary
[DS10_NSEC_NODATA_WRONG_SOA]: #summary
[DS10_NSEC_NO_VERIFIED_SIGNATURE]: #summary
[DS10_NSEC_QUERY_RESPONSE_ERR]: #summary
[DS10_NSEC_RRSIG_EXPIRED]: #summary
[DS10_NSEC_RRSIG_NOT_YET_VALID]: #summary
[DS10_NSEC_RRSIG_NO_DNSKEY]: #summary
[DS10_NSEC_RRSIG_VERIFY_ERROR]: #summary
[DS10_SERVER_NO_DNSSEC]: #summary
[DS10_ZONE_NO_DNSSEC]: #summary
[ERROR]: ../SeverityLevelDefinitions.md#error
[Get-Del-NS-Names-and-IPs]: ../MethodsV2.md#method-get-delegation-ns-names-and-ip-addresses
[Get-Zone-NS-Names-and-IPs]: ../MethodsV2.md#method-get-zone-ns-names-and-ip-addresses
[IANA RR Type List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
[INFO]: ../SeverityLevelDefinitions.md#info
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 4034#section-4]: https://datatracker.ietf.org/doc/html/rfc4034#section-4
[RFC 4035#section-3.1.3]: https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.3
[RFC 5155#section-3]: https://datatracker.ietf.org/doc/html/rfc5155#section-3
[RFC 5155#section-4]: https://datatracker.ietf.org/doc/html/rfc5155#section-4
[RFC 5155#section-7.2]: https://datatracker.ietf.org/doc/html/rfc5155#section-7.2
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Test procedure]: #test-procedure
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

245
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec11.md Normal file
View File

@@ -0,0 +1,245 @@
# DNSSEC11: DS in delegation requires signed zone
## Test case identifier
**DNSSEC11**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
If the delegation of the zone contains DS records, i.e. if the parent
zone has DS records with the same owner name as the apex of the zone,
then the zone must be signed. If not, a DNSSEC aware resolver should
consider the zone to be "bogus" (see [RFC 4033][RFC 4033#section-5], section 5),
and the zone will be unavailable.
This test case will verify that a zone with DS in delegation from
parent is also signed. Here we just verify that it has DNSKEY in apex.
## Scope
It is assumed that *Child Zone* is tested and reported by other test cases:
* This test case will ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server (covered
by [Connectivity01]).
* This test case will ignore any irregularities in fetching the DS record from
parent zone (covered by [DNSSEC02]).
* This test case will ignore if the DNSKEY and SOA RRsets are not signed
(covered by [DNSSEC08] and [DNSSEC09], respectively).
## Inputs
* "Child Zone" - The domain name to be tested.
* "Test Type" - The test type with value "[undelegated]" or "normal".
* "Undelegated DS" - The DS record or records submitted
(only if *Test Type* is [undelegated]).
## Summary
* If there are no DS records in the parent zone, this test case will terminate
without outputting any message.
Message Tag outputted | Level | Arguments | Description of when message tag is outputted
:-----------------------------|:--------|:-----------|:--------------------------------------------
DS11_INCONSISTENT_DS | WARNING | | Parent name servers are inconsistent on the existence of DS.
DS11_INCONSISTENT_SIGNED_ZONE | ERROR | | Name servers for the child zone are inconsistent on whether the zone is signed or not.
DS11_UNDETERMINED_DS | ERROR | | It cannot be determined if the parent zone has DS for the child zone or not.
DS11_UNDETERMINED_SIGNED_ZONE | ERROR | | It cannot be determined if the child zone is signed or not.
DS11_PARENT_WITHOUT_DS | NOTICE | ns_ip_list | List of parent name servers without DS for the child zone.
DS11_PARENT_WITH_DS | NOTICE | ns_ip_list | List of parent name servers with DS for the child zone.
DS11_NS_WITH_SIGNED_ZONE | NOTICE | ns_ip_list | List of child name servers with signed child zone.
DS11_NS_WITH_UNSIGNED_ZONE | WARNING | ns_ip_list | List of child name servers with unsigned child zone.
DS11_DS_BUT_UNSIGNED_ZONE | ERROR | | The child zone is unsigned, but the parent zone has DS record.
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
## Test procedure
1. Create the following empty sets:
1. Parent name server IP address ("Undetermined DS").
2. Parent name server IP address ("No DS Record").
3. Parent name server IP address ("Has DS Record").
4. Child name server IP address ("Undetermined DNSKEY")
5. Child name server IP address ("No DNSKEY Record").
6. Child name server IP address ("Has DNSKEY Record").
2. If the *Test Type* is "[undelegated]" and if *Undelegated DS* is empty,
then do exit this test case.
3. If *Test Type* is "normal", then:
1. Create a DS query with the DO flag set for the name of the *Child Zone*
("DS Query").
2. Retrieve all name server IP addresses for the parent zone of
*Child Zone* using [Method1] ("Parent NS IP").
3. For each name server IP in *Parent NS IP* do:
1. Send *DS Query* to the name server IP.
2. If the response has the TC flag set, re-query over TCP and use that
response instead.
3. Add the name server (IP) to the *Undetermined DS* set if at least one
of the following criteria matches:
1. There is no DNS response.
2. The RCODE of response is not "NoError" ([IANA RCODE List]).
3. The AA flag is not set in the response.
4. If there is no DS record with matching owner name in the
answer section, then add the name server (IP) to the
*No DS Record* set.
5. Else add the name server (IP) to the *Has DS Record* set.
4. If the *Undetermined DS* set is non-empty and both the
*No DS Record* and *Has DS Record* sets are empty then do:
1. Output *[DS11_UNDETERMINED_DS]*.
2. Exit this test case.
5. If the *No DS Record* set is non-empty and the *Has DS Record* set is
empty then exit this test case.
6. If both the *No DS Record* and *Has DS Record* sets are non-empty,
then do:
1. Output *[DS11_INCONSISTENT_DS]*.
2. Output *[DS11_PARENT_WITHOUT_DS]* and list parent name servers in
*No DS Record*.
3. Output *[DS11_PARENT_WITH_DS]* and list parent name servers in
*Has DS Record*.
4. Create DNS queries for the child zone:
1. SOA query for the *Child Zone* without any OPT record (no EDNS)
("SOA Query").
2. DNSKEY query for the *Child Zone* with the DO flag set ("DNSKEY Query").
5. Obtain the set of child name server IP addresses using [Method4] and
[Method5] ("Child NS IP").
7. For each name server IP in *Child NS IP* do:
1. Send *SOA Query* over UDP to the name server IP and collect the response.
2. Go to next name server if
1. there is no DNS response on the SOA query, or
2. the RCODE of the response is not "NoError" ([IANA RCODE List]), or
3. the AA flag is not set in the response, or
4. there is no SOA record with owner name matching the query in the
answer section.
3. Send *DNSKEY Query* over UDP to the name server IP and collect the
response.
4. If the response has the TC flag set, re-query over TCP and use that
response instead.
5. Add the name server (IP) to the *Undetermined DNSKEY* set if at least one
of the following criteria matches:
1. There is no DNS response.
2. The RCODE of response is not "NoError" ([IANA RCODE List]).
3. The AA flag is not set in the response.
6. If there is no DNSKEY record with matching owner name in the answer
section, then add the name server (IP) to the *No DNSKEY Record* set.
7. Else add the name server (IP) to the *Has DNSKEY Record* set.
8. If the *Undetermined DNSKEY* set is non-empty and both the
*No DNSKEY Record* and *Has DNSKEY Record* sets are empty then output
*[DS11_UNDETERMINED_SIGNED_ZONE]*.
9. Else, if the *No DNSKEY Record* set is non-empty and the
*Has DNSKEY Record* set is empty then output
*[DS11_DS_BUT_UNSIGNED_ZONE]*.
10. Else, if both the *No DNSKEY Record* and *Has DNSKEY Record* sets
are non-empty, then do:
1. Output *[DS11_INCONSISTENT_SIGNED_ZONE]*.
2. Output *[DS11_NS_WITH_UNSIGNED_ZONE]* and list name servers in
*No DNSKEY Record*.
3. Output *[DS11_NS_WITH_SIGNED_ZONE]* and list name servers in
*Has DNSKEY Record*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
See the [DNSSEC README] document about DNSSEC algorithms.
This test case is always performed.
## Intercase dependencies
None.
## Terminology
No special terminology for this test case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DNSSEC README]: README.md
[DNSSEC02]: dnssec02.md
[DNSSEC08]: dnssec08.md
[DNSSEC09]: dnssec09.md
[DS11_DS_BUT_UNSIGNED_ZONE]: #summary
[DS11_INCONSISTENT_DS]: #summary
[DS11_INCONSISTENT_SIGNED_ZONE]: #summary
[DS11_UNDETERMINED_DS]: #summary
[DS11_UNDETERMINED_SIGNED_ZONE]: #summary
[DS11_NS_WITH_SIGNED_ZONE]: #summary
[DS11_NS_WITH_UNSIGNED_ZONE]: #summary
[DS11_PARENT_WITHOUT_DS]: #summary
[DS11_PARENT_WITH_DS]: #summary
[ERROR]: ../SeverityLevelDefinitions.md#error
[IANA RCODE List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[INFO]: ../SeverityLevelDefinitions.md#info
[Method1]: ../Methods.md#method-1-obtain-the-parent-domain
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 4033#section-5]: https://datatracker.ietf.org/doc/html/rfc4033#section-5
[RFC 8499#section-11]: https://datatracker.ietf.org/doc/html/rfc8499#section-11
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Severity Level]: ../SeverityLevelDefinitions.md
[Terminology]: #terminology
[Undelegated]: ../../test-types/undelegated-test.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

40
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec12.md Normal file
View File

@@ -0,0 +1,40 @@
## DNSSEC12: Test for DNSSEC Algorithm Completeness
### Test case identifier
**DNSSEC12** Test for DNSSEC Algorithm Completeness
### Objective
The objectives for this Test Case has yet to be defined. This is a
placeholder for a complete definition of the Test Case. The Test Case
is not yet implemented.
Test for DNSSEC Algorithm Completeness (DS->DNSKEY->RRSIG)
See issues [#588], [#528], [#529] and [#231].
[#588]: https://github.com/zonemaster/zonemaster/issues/588
[#528]: https://github.com/zonemaster/zonemaster/issues/528
[#529]: https://github.com/zonemaster/zonemaster/issues/529
[#231]: https://github.com/zonemaster/zonemaster/issues/231
### Inputs
TBD.
### Ordered description of steps to be taken to execute the test case
TBD.
### Outcome(s)
TBD.
### Special procedural requirements
TBD.
### Intercase dependencies
TBD.

210
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec13.md Normal file
View File

@@ -0,0 +1,210 @@
# DNSSEC13: All DNSKEY algorithms used to sign the zone
## Test case identifier
**DNSSEC13**
## Table of contents
* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)
## Objective
From [RFC 6840][RFC 6840#section-5.11], section 5.11:
> The DS RRset and DNSKEY RRset are used to signal which algorithms are used to
> sign a zone. \[...] The zone MUST also be signed with each algorithm (though
> not each key) present in the DNSKEY RRset. \[...]
To verify that the whole zone is signed with all algorithms require access to the
complete zone, which is generally not possible for public zones. This test case
is limited to three RRsets that must be present in a signed zone, the SOA RRset,
the NS RRset and the DNSKEY RRset.
This test case will verify that for each DNSKEY algorithm, there is a RRSIG of
that algorithm for the three selected RRsets.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01], [DNSSEC08] and
[DNSSEC09]. Issues covered by [Connectivity01] (basic name server issues), [DNSSEC08]
(signing of DNSKEY RRset) and [DNSSEC09] (signing of SOA RRset) will not result
in messages from this test case.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
* If the name server reports no DNSKEY RRset, then this test case will not test
or report anything.
* This test case will not report anything unless there is an issue to report.
Message Tag outputted | Level | Arguments | Description of when message tag is outputted
:-----------------------------|:--------|:---------------------------------|:--------------------------------------------
DS13_ALGO_NOT_SIGNED_DNSKEY | WARNING | ns_ip_list, algo_mnemo, algo_num | The DNSKEY RRset is not signed with an algorithm present in the DNSKEY RRset
DS13_ALGO_NOT_SIGNED_NS | WARNING | ns_ip_list, algo_mnemo, algo_num | The NS RRset is not signed with an algorithm present in the DNSKEY RRset
DS13_ALGO_NOT_SIGNED_SOA | WARNING | ns_ip_list, algo_mnemo, algo_num | The SOA RRset is not signed with an algorithm present in the DNSKEY RRset
The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.
The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].
## Test procedure
1. Create a DNSKEY query with DO flag set for the apex of the
*Child Zone* ("DNSKEY Query").
2. Create a SOA query with DO flag set for the apex of the
*Child Zone* ("SOA Query").
3. Create a NS query with DO flag set for the apex of the
*Child Zone* ("NS Query").
4. Retrieve all name server IP addresses for the
*Child Zone* using [Method4] and [Method5] ("NS IP").
5. Create the following empty sets:
1. Name server IP address and associated DNSKEY algorithm
("Algo not signed DNSKEY").
2. Name server IP address and associated DNSKEY algorithm
("Algo not signed SOA").
3. Name server IP address and associated DNSKEY algorithm
("Algo not signed NS").
6. For each name server IP in the *NS IP* set do:
1. Create an empty set of DNSKEY algorithms ("DNSKEY Algorithm").
2. Send *DNSKEY Query* over UDP and do:
1. Go to next name server IP if any of the following criteria is met:
1. No DNS response is returned.
2. The RCODE value of the DNS response is not "NoError"
([IANA RCODE List]).
3. The AA flag of the response is unset.
4. The DNS response contains no DNSKEY record in the answer section.
5. The DNS response contains no RRSIG for the DNSKEY RRset.
2. Extract all DNSKEY records from the answer section.
3. Extract the algorithm numbers from each DNSKEY record and add them to
the *DNSKEY Algorithm* set.
4. Extract all RRSIG records for the DNSKEY RRset from the response.
5. For each algorithm in *DNSKEY Algorithm* do:
* If there is no RRSIG for the DNSKEY RRset created by the algorithm
then add name server IP and DNSKEY algorithm to the
*Algo not signed DNSKEY* set.
3. Send *SOA Query* over UDP and do:
1. Go to next name server IP if any of the following criteria is met:
1. No DNS response is returned.
2. The RCODE value of the DNS response is not "NoError"
([IANA RCODE List]).
3. The AA flag of the response is unset.
4. The DNS response contains no SOA record in the answer section.
5. The DNS response contains no RRSIG for the SOA RRset.
2. Extract the SOA record from the answer section (ignore additional SOA
records, if any).
3. Extract all RRSIG records for the SOA RRset from the response.
4. For each algorithm in *DNSKEY Algorithm* do:
* If there is no RRSIG for the SOA RRset created by the algorithm then
add name server IP and DNSKEY algorithm to the
*Algo not signed SOA* set.
4. Send *NS Query* over UDP.
1. Go to next name server IP if any of the following criteria is met:
1. No DNS response is returned.
2. The RCODE value of the DNS response is not "NoError"
([IANA RCODE List]).
3. The AA flag of the response is unset.
4. The DNS response contains no NS record in the answer section.
5. The DNS response contains no RRSIG for the NS RRset.
2. Extract all NS records from the answer section.
3. Extract all RRSIG records for the NS RRset from the response.
4. For each algorithm in *DNSKEY Algorithm* do:
* If there is no RRSIG for the NS RRset created by the algorithm then
add name server IP and DNSKEY algorithm to the
*Algo not signed NS* set.
7. If the *Algo not signed DNSKEY* set is non-empty, then for each DNSKEY
algorithm in the set output *[DS13_ALGO_NOT_SIGNED_DNSKEY]* with the name
server IP addresses from the set and the DNSKEY algorithm.
8. If the *Algo not signed SOA* set is non-empty, then for each DNSKEY
algorithm in the set output *[DS13_ALGO_NOT_SIGNED_SOA]* with the name
server IP addresses from the set and the SOA algorithm.
9. If the *Algo not signed NS* set is non-empty, then for each DNSKEY
algorithm in the set output *[DS13_ALGO_NOT_SIGNED_NS]* with the name
server IP addresses from the set and the NS algorithm.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
See the [DNSSEC README] document about DNSSEC algorithms.
Test case is only performed if DNSKEY records are found.
## Intercase dependencies
None.
## Terminology
No special terminology for this test case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DNSSEC README]: README.md
[DNSSEC08]: dnssec08.md
[DNSSEC09]: dnssec09.md
[DS13_ALGO_NOT_SIGNED_DNSKEY]: #summary
[DS13_ALGO_NOT_SIGNED_NS]: #summary
[DS13_ALGO_NOT_SIGNED_SOA]: #summary
[ERROR]: ../SeverityLevelDefinitions.md#error
[IANA RCODE List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[INFO]: ../SeverityLevelDefinitions.md#info
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 6840#section-5.11]: https://datatracker.ietf.org/doc/html/rfc6840#section-5.11
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

135
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec14.md Normal file
View File

@@ -0,0 +1,135 @@
# DNSSEC14: Check for valid RSA DNSKEY key size
## Test case identifier
**DNSSEC14**
## Objective
The DNSKEYs based on RSA have different minimum and maximum key sizes,
which must be followed. This test case will validate the keys size of
such keys. RSA based algorithms that are deprecated or else not suitable
for DNSKEY ([RFC 8624] and [IANA registry]) are just ignored. See test
case [DNSSEC05] for test of algorithm.
The table 1 below specify the maximum and minimum key size,
respectively. Algorithm number can be found in [IANA registry].
Table 1: Minimum and maximum RSA key sizes in bits
Algorithm | Min size | Max size | Reference
:---------|:----------|:---------|:----------------
5 | 512 | 4096 | [RFC 3110]
7 | 512 | 4096 | [RFC 5155]
8 | 512 | 4096 | [RFC 5702]
10 | 1024 | 4096 | [RFC 5702]
It is also recommended that an RSA based algorithm has a key length
of at least 2048 bit as stated in [NIST SP 800-57 Part 1 Rev. 4],
table 2 on page 53 in section 5.6.1 and table 4 on page 55 in
section 5.6.2.
This test case verifies that RSA DNSKEYs follows the stated key lengths
from the RFCs and also the NIST recommended shortest key length.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* "Child Zone" - The domain name to be tested.
* "Key Size Table" - The table above.
## Ordered description of steps to be taken to execute the test case
1. Create a DNSKEY query with DO flag set for the apex of the
*Child Zone*.
2. Retrieve all name server IP addresses for the
*Child Zone* using [Method4] and [Method5] ("NS IP").
3. Create an empty set "DNSKEY RRs".
4. For each name server IP address in *NS IP* do:
1. Send the DNSKEY query over UDP.
2. If no DNS response is returned, then output *[NO_RESPONSE]*.
3. Else, if the DNS response does not contain an DNSKEY RRset,
then output *[NO_RESPONSE_DNSKEY]*.
4. Else, retrieve the DNSKEY RRs and add them to *DNSKEY RRs*.
5. For each DNSKEY from the *DNSKEY RRs* do:
1. If the algorithm of the DNSKEY is not listed in *Key Size
Table*, go to next DNSKEY.
2. Else, if the algorithm is listed in *Key Size Table* and the
key size is smaller than specified, then output
*[DNSKEY_TOO_SMALL_FOR_ALGO]*.
3. Else, if the algorithm is listed in *Key Size Table* and the
key size is smaller than 2048 bits, then output
*[DNSKEY_SMALLER_THAN_REC]*.
3. Else, if the algorithm is listed in *Key Size Table* and the
key size is larger than specified, then output
*[DNSKEY_TOO_LARGE_FOR_ALGO]*.
6. If *DNSKEY RRs* is non-empty and no messages, except for any
*[NO_RESPONSE]*, has been outputted, then output
*[KEY_SIZE_OK]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level
:-----------------------------|:-----------------------------------
NO_RESPONSE | DEBUG
NO_RESPONSE_DNSKEY | WARNING
DNSKEY_SMALLER_THAN_REC | WARNING
DNSKEY_TOO_SMALL_FOR_ALGO | ERROR
DNSKEY_TOO_LARGE_FOR_ALGO | ERROR
KEY_SIZE_OK | INFO
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
See the [DNSSEC README] document about DNSSEC algorithms.
The test case is only performed if some DNSKEY record is found in the
*Child Zone*.
## Intercase dependencies
None.
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[DNSKEY_SMALLER_THAN_REC]: #outcomes
[DNSKEY_TOO_LARGE_FOR_ALGO]: #outcomes
[DNSKEY_TOO_SMALL_FOR_ALGO]: #outcomes
[DNSSEC README]: ./README.md
[DNSSEC05]: ./dnssec05.md
[IANA registry]: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml
[KEY_SIZE_OK]: #outcomes
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NIST SP 800-57 Part 1 Rev. 4]: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-4/archive/2016-01-28
[NO_RESPONSE]: #outcomes
[NO_RESPONSE_DNSKEY]: #outcomes
[RFC 3110]: https://datatracker.ietf.org/doc/html/rfc3110
[RFC 5155]: https://datatracker.ietf.org/doc/html/rfc5155
[RFC 5702]: https://datatracker.ietf.org/doc/html/rfc5702#section-2
[RFC 8624]: https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1
[Recommendation for key Management, part 1, revision 4]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

194
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec15.md Normal file
View File

@@ -0,0 +1,194 @@
# DNSSEC15: Existence of CDS and CDNSKEY
## Test case identifier
**DNSSEC15**
## Objective
CDS and CDNSKEY record types are defined in [RFC 7344] and [RFC 8078].
Both record types are optional in a zone. The objective of this test
case is to verify that they are correctly set-up, if included in the
zone.
If a CDS record is included in the zone, the corresponding CDNSKEY
record should also be included ([RFC 7344][RFC 7344#4], section 4).
The CDS and CDNSKEY RRsets should be consistent between all name
servers for the zone in question.
If there are both CDS RRs and CDNSKEY RRs in the zone they must match in
content ([RFC 7344][RFC 7344#4], section 4). It means that both
must be derived from the same DNSKEY or both being "delete" CDS and
CDNSKEY.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will just ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
Message Tag outputted | [Default level] | Description of when message tag is outputted
:-------------------------|:----------------|:-----------------------------------------
DS15_HAS_CDNSKEY_NO_CDS | NOTICE | CDNSKEY RRset is found, but no CDS RRset.
DS15_HAS_CDS_AND_CDNSKEY | INFO | CDNSKEY and CDS RRsets are found.
DS15_HAS_CDS_NO_CDNSKEY | NOTICE | CDS RRset is found, but no CDNSKEY RRset.
DS15_INCONSISTENT_CDNSKEY | ERROR | All servers do not have the same CDNSKEY RRset.
DS15_INCONSISTENT_CDS | ERROR | All servers do not have the same CDS RRset.
DS15_MISMATCH_CDS_CDNSKEY | ERROR | Both CDS and CDNSKEY RRsets are found but they do not match.
DS15_NO_CDS_CDNSKEY | INFO | No CDS or CDNSKEY RRsets are found on any name server.
## Ordered description of steps to be taken to execute the test case
1. Create the following empty sets:
1. Name server IP address and associated CDS RRset ("CDS RRsets"). A
name server IP can hold an empty RRset.
2. Name server IP address and associated CDNSKEY RRset ("CDNSKEY RRsets").
A name server IP can hold an empty RRset.
3. Name server IP address set ("Mismatch CDS/CDNSKEY").
4. Name server IP address set ("Has CDS No CDNSKEY").
5. Name server IP address set ("Has CDNSKEY No CDS").
6. Name server IP address set ("Has CDS And CDNSKEY").
2. Retrieve all name server IP addresses for the *Child Zone* using
[Method4] and [Method5] ("NS IP").
3. Create a CDS query with EDNS enabled with the DO bit set for the
apex of the *Child Zone*.
4. Create a CDNSKEY query with EDNS enabled with the DO bit set for
the apex of the *Child Zone*.
5. For each name server IP in the *NS IP* set do:
1. Send the CDS query over UDP to the name server IP address.
1. If no DNS response is returned, then go to next name server IP.
2. Else, if AA bit is not set in the DNS response, then go to next
name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then go to
next name server IP.
4. Else, if the DNS response contains no CDS record in the
answer section, then add the name server IP and an empty RRset to
the *CDS RRsets* set.
5. Else, add the name server IP and the CDS RRset from the answer
section to the *CDS RRsets* set.
2. Send the CDNSKEY query over UDP to the name server IP address.
1. If no DNS response is returned, then go to next name server IP.
2. Else, if AA bit is not set in the DNS response, then go to next
name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then go to
next name server IP.
4. Else, if the DNS response contains no CDNSKEY record in the
answer section, then add the name server IP and an empty RRset to
the *CDNSKEY RRsets* set.
5. Else, add the name server IP and the CDNSKEY RRset from the answer
section to the *CDNSKEY RRsets* set.
3. Go to next name server IP.
6. If the *CDS RRsets* set and the *CDNSKEY RRsets* set are empty
then output *[DS15_NO_CDS_CDNSKEY]* and terminate this
test case.
7. For each name server IP in the *CDS RRsets* set do:
1. If the name server IP is not listed in *CDNSKEY RRsets*, go to next name
server IP.
2. If the name server IP address has a non-empty RRset in the
*CDS RRsets* set, but an empty RRset in the *CDNSKEY RRsets*
set, then add the name server IP address to *Has CDS No CDNSKEY*.
3. If the name server IP address has a non-empty RRset in the
*CDNSKEY RRsets* set, but an empty RRset in the *CDS RRsets*
set, then add the name server IP address to *Has CDNSKEY No CDS*.
4. If the name server IP address has a non-empty RRset in both
sets, *CDNSKEY RRsets* and *CDS RRsets*, then add the name
server IP address to *Has CDS And CDNSKEY*.
5. Go to next name server IP.
8. For each name server IP in the *CDS RRsets* set do:
1. If the name server IP is not listed in *CDNSKEY RRsets*, go to next name
server IP.
2. Extract the CDS RRset (possibly empty) for the IP in the *CDS RRsets* set.
3. Extract the CDNSKEY RRset (possibly empty) for the same IP from
the *CDNSKEY RRsets* set.
4. If both RRsets are non-empty then do:
1. For each CDS RR verify that there is a matching CDNSKEY (derived
from the same DNSKEY or both being "delete").
2. For each CDNSKEY RR verify that there is a matching CDS (derived
from the same DNSKEY or both being "delete").
3. If one or both of the verifications fail then add the name server
IP to the *Mismatch CDS/CDNSKEY* set.
4. Go to next name sever IP.
9. If the *Has CDS No CDNSKEY* set is non-empty then output
*[DS15_HAS_CDS_NO_CDNSKEY]* with the name server IP addresses from
the set.
10. If the *Has CDNSKEY No CDS* set is non-empty then output
*[DS15_HAS_CDNSKEY_NO_CDS]* with the name server IP addresses from
the set.
11. If the *Has CDS And CDNSKEY* set is non-empty then output
*[DS15_HAS_CDS_AND_CDNSKEY]* with the name server IP addresses from
the set.
12. If not all CDS RRsets in the *CDS RRsets* set are identical, where
a non-empty RRset is considered to be different from an empty
RRset, then output *[DS15_INCONSISTENT_CDS]*.
13. If not all CDNSKEY RRsets in the *CDNSKEY RRsets* set are identical,
where a non-empty RRset is considered to be different from an
empty RRset, then output *[DS15_INCONSISTENT_CDNSKEY]*.
14. If the *Mismatch CDS/CDNSKEY* set is non-empty, then output
*[DS15_MISMATCH_CDS_CDNSKEY]* and list the name server IPs from
the set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
the ignored protocol.
## Intercase dependencies
None.
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DS15_HAS_CDNSKEY_NO_CDS]: #summary
[DS15_HAS_CDS_AND_CDNSKEY]: #summary
[DS15_HAS_CDS_NO_CDNSKEY]: #summary
[DS15_INCONSISTENT_CDNSKEY]: #summary
[DS15_INCONSISTENT_CDS]: #summary
[DS15_MISMATCH_CDS_CDNSKEY]: #summary
[DS15_NO_CDS_CDNSKEY]: #summary
[Default level]: ../SeverityLevelDefinitions.md
[ERROR]: ../SeverityLevelDefinitions.md#error
[INFO]: ../SeverityLevelDefinitions.md#info
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 7344#4]: https://datatracker.ietf.org/doc/html/rfc7344#section-4
[RFC 7344]: https://datatracker.ietf.org/doc/html/rfc7344
[RFC 8078]: https://datatracker.ietf.org/doc/html/rfc8078
[WARNING]: ../SeverityLevelDefinitions.md#warning

264
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec16.md Normal file
View File

@@ -0,0 +1,264 @@
# DNSSEC16: Validate CDS
## Test case identifier
**DNSSEC16**
## Objective
CDS and CDNSKEY record types are defined in [RFC 7344] and [RFC 8078].
Both record types are optional in a zone. The objective of this test
case is to verify that the CDS RRset is valid. This test case is
only relevant if the zone has at least one CDS record. For tests of the
CDNSKEY, see test case [DNSSEC17].
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will just ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server.
It is assumed that *Child Zone* has been tested or will be tested by
[DNSSEC15] and [DNSSEC17] and that the servers give the same responses.
Running this test case without running [DNSSEC15] and [DNSSEC17] can
give an incomplete report of the CDS and CDNSKEY status of
*Child Zone*.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
* If no CDS record is found, the test case will terminate early
with no message tag outputted.
* If a CDS record is of "delete" type, then it can by definition not
match or point at any DNSKEY record.
Message Tag outputted | [Default level] | Description of when message tag is outputted
:------------------------------------|:--------|:-----------------------------------------
DS16_CDS_INVALID_RRSIG | ERROR | CDS RRset is signed with an invalid RRSIG.
DS16_CDS_MATCHES_NON_SEP_DNSKEY | NOTICE | CDS record matches a DNSKEY with SEP bit (bit 15) unset.
DS16_CDS_MATCHES_NON_ZONE_DNSKEY | ERROR | CDS record matches a DNSKEY with zone bit (bit 7) unset.
DS16_CDS_MATCHES_NO_DNSKEY | WARNING | CDS record does not match any DNSKEY in DNSKEY RRset.
DS16_CDS_NOT_SIGNED_BY_CDS | NOTICE | CDS RRset is not signed by the key that the CDS record points to.
DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY | ERROR | CDS RRset is signed by a key not in DNSKEY RRset.
DS16_CDS_UNSIGNED | ERROR | CDS RRset is unsigned.
DS16_CDS_WITHOUT_DNSKEY | ERROR | CDS RRset exists, but there is no DNSKEY RRset.
DS16_DELETE_CDS | INFO | CDS RRset has a "delete" CDS record as a single record.
DS16_DNSKEY_NOT_SIGNED_BY_CDS | WARNING | DNSKEY RRset is not signed by the key or keys that the CDS records point to.
DS16_MIXED_DELETE_CDS | ERROR | "Delete" CDS record is mixed with normal CDS record.
## Ordered description of steps to be taken to execute the test case
1. Create the following empty sets:
1. Name server IP address and associated CDS RRset and its RRSIG
records ("CDS RRsets"). The set of RRSIG records may be empty.
2. Name server IP address and associated DNSKEY RRset and its
RRSIG records ("DNSKEY RRsets"). The set of RRSIG records may be empty.
3. Name server IP address ("No DNSKEY RRset").
4. Name server IP address ("Mixed Delete CDS").
5. Name server IP address ("Delete CDS").
6. Name server IP address and associated CDS key tag
("No Match CDS With DNSKEY").
7. Name server IP address and associated CDS key tag
("CDS points to non-zone DNSKEY").
8. Name server IP address and associated CDS key tag
("CDS points to non-SEP DNSKEY").
9. Name server IP address and associated CDS key tag
("DNSKEY Not Signed By CDS").
10. Name server IP address and associated CDS key tag
("CDS Not Signed By CDS").
11. Name server IP address ("CDS Not Signed").
12. Name server IP address and key tag
("CDS Signed By Unknown DNSKEY").
13. Name server IP address and key tag ("CDS Invalid RRSIG").
2. Create a CDS query with EDNS enabled and the DO bit set for the
apex of the *Child Zone*.
3. Create a DNSKEY query with EDNS enabled and the DO bit set for
the apex of the *Child Zone*.
4. Retrieve all name server IP addresses for the *Child Zone* using
[Method4] and [Method5] ("NS IP").
5. Repeat the following steps for each name server IP address in
*NS IP*:
1. Send the CDS query over UDP to the name server IP address.
1. If no DNS response is returned, then go to next name server
IP.
2. Else, if AA bit is not set in the DNS response, then go to
next name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then
go to next name server IP.
4. Else, if the answer section has no CDS records, go to next
name server IP.
5. Add the name server IP and the CDS RRset from the answer
section to the *CDS RRsets* set. Also include any associated
RRSIG records in the answer section.
2. Send the DNSKEY query over UDP to the name server IP address.
1. If no DNS response is returned, then go to next name server
IP.
2. Else, if AA bit is not set in the DNS response, then go to
next name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then
go to next name server IP.
4. Else, if the DNS response contains at least one DNSKEY
record in the answer section, then add the name server IP and
the DNSKEY RRset from the answer section to the
*DNSKEY RRsets* set. Also include any associated RRSIG
records in the answer section.
3. Go to next name server IP.
6. If the *CDS RRsets* set is empty then terminate this test case.
7. For each name server IP in the *CDS RRsets* set do:
1. If the CDS RRset is empty go to next name server IP address.
2. Get the CDS RRset and the associated RRSIG records, if any, from the
*CDS RRsets* set for the name server IP.
3. If any CDS record is a "delete" CDS, then do:
1. If there is more than a single CDS record then add the name
server IP to the *Mixed Delete CDS* set.
2. Else, add the name server IP address to the *Delete CDS*
set.
4. Get the DNSKEY RRset and the associated RRSIG records, if any, from the
*DNSKEY RRsets* for the same name server IP.
5. If there are no DNSKEY records, then do:
1. Add name server IP address to the *No DNSKEY RRset* set.
2. Go to next name server IP.
6. Repeat the following steps for each CDS record unless it is a "delete"
CDS record:
1. Compare the key tag from the CDS record with the
[calculated key tags][Key Tag Calculation] for the DNSKEY records.
2. If the CDS record does not match any DNSKEY record then add
the name server IP address and CDS record key tag to the
*No Match CDS With DNSKEY* set.
3. Else, if bit 7 of the flags field of the DNSKEY that the DS record
points to is unset (value 0) then add the name server IP address and
CDS record key tag to the *CDS points to non-zone DNSKEY* set.
4. Else, do:
1. If the DNSKEY RRset has not been signed by the DNSKEY record that
the CDS record points at then add the name server IP address and
key tag of CDS record to the *DNSKEY Not Signed By CDS* set.
2. If the CDS RRset has not been signed by the DNSKEY record that
the CDS record points at then add the name server IP address and
key tag of CDS record to the *CDS Not Signed By CDS* set.
3. If bit 15 of the flags field of the DNSKEY that the CDS record
points at is unset (value 0) then add the name server IP address
and the key tag of the CDS record to the
*CDS points to non-SEP DNSKEY* set.
7. If CDS RRset is not signed, then add the name server IP address to the
*CDS Not Signed* set.
8. Else, for each RRSIG for the CDS RRset do:
1. If the key tag of the RRSIG does not match any DNSKEY record in the
DNSKEY RRset then add the name server IP address and key tag to the
*CDS Signed By Unknown DNSKEY* set.
2. Else, if the RRSIG cannot be validated by the DNSKEY it
refers to by key tag, then add the name server IP and RRSIG
key tag to the *CDS Invalid RRSIG* set.
9. Go to next name server IP address.
8. If the *No DNSKEY RRset* set is non-empty, then output
*[DS16_CDS_WITHOUT_DNSKEY]* with all name server IP addresses
in the set.
9. If the *Mixed Delete CDS* set is
non-empty, then output *[DS16_MIXED_DELETE_CDS]* with all
name server IP addresses in the set.
10. If the *Delete CDS* set is non-empty, then output
*[DS16_DELETE_CDS]* with all name server IP addresses.
11. If the *No Match CDS With DNSKEY* set is non-empty then do:
* For each CDS key tag in the set do:
* Output *[DS16_CDS_MATCHES_NO_DNSKEY]* with the CDS key tag
and the name server IP addresses in the set for that key
tag.
12. If the *CDS points to non-zone DNSKEY* set is non-empty then do:
* For each CDS key tag in the set do:
* Output *[DS16_CDS_MATCHES_NON_ZONE_DNSKEY]* with the CDS key tag
and the name server IP addresses in the set for that key
tag.
13. If the *CDS points to non-SEP DNSKEY* set is non-empty then do:
* For each CDS key tag in the set do:
* Output *[DS16_CDS_MATCHES_NON_SEP_DNSKEY]* with the CDS key tag
and the name server IP addresses in the set for that key
tag.
14. If the *DNSKEY Not Signed By CDS* set is non-empty then do:
* For each CDS key tag in the set do:
* Output *[DS16_DNSKEY_NOT_SIGNED_BY_CDS]* with the CDS key
tag and the name server IP addresses in the set for that
key tag.
15. If the *CDS Not Signed By CDS* set is non-empty then do:
* For each CDS key tag in the set do:
* Output *[DS16_CDS_NOT_SIGNED_BY_CDS]* with the CDS key
tag and the name server IP addresses in the set for that
key tag.
16. If the *CDS Invalid RRSIG* set is non-empty then do:
* For each RRSIG key tag in the set do:
* Output *[DS16_CDS_INVALID_RRSIG]* with the RRSIG key tag and
the name server IP addresses in the set for that key tag.
17. If the *CDS Not Signed* set is non-empty then output
*[DS16_CDS_UNSIGNED]* with all name server IP addresses in the set.
18. If the *CDS Signed By Unknown DNSKEY* set is non-empty then output
*[DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY]* with the name server IP
addresses in the set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
the ignored protocol.
## Intercase dependencies
None.
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DNSSEC15]: dnssec15.md
[DNSSEC17]: dnssec17.md
[DS16_CDS_INVALID_RRSIG]: #summary
[DS16_CDS_MATCHES_NON_SEP_DNSKEY]: #summary
[DS16_CDS_MATCHES_NON_ZONE_DNSKEY]: #summary
[DS16_CDS_MATCHES_NO_DNSKEY]: #summary
[DS16_CDS_NOT_SIGNED_BY_CDS]: #summary
[DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY]: #summary
[DS16_CDS_UNSIGNED]: #summary
[DS16_CDS_WITHOUT_DNSKEY]: #summary
[DS16_DELETE_CDS]: #summary
[DS16_DNSKEY_NOT_SIGNED_BY_CDS]: #summary
[DS16_MIXED_DELETE_CDS]: #summary
[Default level]: ../SeverityLevelDefinitions.md
[ERROR]: ../SeverityLevelDefinitions.md#error
[INFO]: ../SeverityLevelDefinitions.md#info
[Key Tag Calculation]: https://datatracker.ietf.org/doc/html/rfc4034#appendix-B
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 7344, section 4]: https://datatracker.ietf.org/doc/html/rfc7344#section-4
[RFC 7344]: https://datatracker.ietf.org/doc/html/rfc7344
[RFC 8078]: https://datatracker.ietf.org/doc/html/rfc8078
[WARNING]: ../SeverityLevelDefinitions.md#warning

269
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec17.md Normal file
View File

@@ -0,0 +1,269 @@
# DNSSEC17: Validate CDNSKEY
## Test case identifier
**DNSSEC17**
## Objective
CDS and CDNSKEY record types are defined in [RFC 7344] and [RFC 8078].
Both record types are optional in a zone. The objective of this test
case is to verify that the CDNSKEY RRset is valid. This test case is
only relevant if the zone has at least one CDNSKEY record. For tests of the
CDS, see test case [DNSSEC16].
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will just ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server.
It is assumed that *Child Zone* has been tested or will be tested by
[DNSSEC15] and [DNSSEC16] and that the servers give the same responses.
Running this test case without running [DNSSEC15] and [DNSSEC16] can
give an incomplete report of the CDS and CDNSKEY status of
*Child Zone*.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
* If no CDNSKEY record is found, the test case will terminate early
with no message tag outputted.
* If a CDNSKEY record is of "delete" type, then it can by
definition not match or point at any DNSKEY record.
Message Tag outputted | [Default level] | Description of when message tag is outputted
:------------------------------------|:--------|:-----------------------------------------
DS17_CDNSKEY_INVALID_RRSIG | ERROR | CDNSKEY RRset signed with an invalid RRSIG.
DS17_CDNSKEY_IS_NON_SEP | NOTICE | CDNSKEY record has the SEP bit (bit 15) unset.
DS17_CDNSKEY_IS_NON_ZONE | ERROR | CDNSKEY record has the zone bit (bit 7) unset.
DS17_CDNSKEY_MATCHES_NO_DNSKEY | WARNING | CDNSKEY record does not match any DNSKEY in DNSKEY RRset.
DS17_CDNSKEY_NOT_SIGNED_BY_CDNSKEY | NOTICE | CDNSKEY RRset is not signed by the key that the CDNSKEY record points to.
DS17_CDNSKEY_SIGNED_BY_UNKNOWN_DNSKEY| ERROR | CDNSKEY RRset is signed by a key not in DNSKEY RRset.
DS17_CDNSKEY_UNSIGNED | ERROR | CDNSKEY RRset is unsigned.
DS17_CDNSKEY_WITHOUT_DNSKEY | ERROR | CDNSKEY RRset exists, but there is no DNSKEY RRset.
DS17_DELETE_CDNSKEY | INFO | CDNSKEY RRset has a "delete" CDNSKEY record as a single record.
DS17_DNSKEY_NOT_SIGNED_BY_CDNSKEY | WARNING | DNSKEY RRset is not signed by the key or keys that the CDNSKEY records point to.
DS17_MIXED_DELETE_CDNSKEY | ERROR | "Delete" CDNSKEY record is mixed with normal CDNSKEY record.
## Ordered description of steps to be taken to execute the test case
1. Create the following empty sets:
1. Name server IP address and associated CDNSKEY RRset and its
RRSIG records ("CDNSKEY RRsets"). The set of RRSIG records may be empty
2. Name server IP address and associated DNSKEY RRset and its
RRSIG records ("DNSKEY RRsets"). The set of RRSIG records may be empty.
3. Name server IP address ("No DNSKEY RRset").
4. Name server IP address ("Mixed Delete CDNSKEY").
5. Name server IP address ("Delete CDNSKEY").
6. Name server IP address and associated CDNSKEY key tag
("No Match CDNSKEY With DNSKEY").
7. Name server IP address and associated CDNSKEY key tag
("CDNSKEY is non-zone key").
8. Name server IP address and associated CDNSKEY key tag
("CDNSKEY is non-SEP key").
9. Name server IP address and key tag
("DNSKEY Not Signed By CDNSKEY").
10. Name server IP address and key tag
("CDNSKEY Not Signed By CDNSKEY").
11. Name server IP address ("CDNSKEY Not Signed").
12. Name server IP address and key tag
("CDNSKEY Signed By Unknown DNSKEY").
13. Name server IP address and key tag ("CDNSKEY Invalid RRSIG").
2. Create a CDNSKEY query with EDNS enabled and the DO bit set for
the apex of the *Child Zone*.
3. Create a DNSKEY query with EDNS enabled and the DO bit set for
the apex of the *Child Zone*.
4. Retrieve all name server IP addresses for the *Child Zone* using
[Method4] and [Method5] ("NS IP").
5. Repeat the following steps for each name server IP address in
*NS IP*:
1. Send the CDNSKEY query over UDP to the name server IP address.
1. If no DNS response is returned, then go to next name server
IP.
2. Else, if AA bit is not set in the DNS response, then go to
next name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then
go to next name server IP.
4. Else, if the answer section has no CDNSKEY records, go to
next name server IP.
5. Add the name server IP and the CDNSKEY RRset from the answer
section to the *CDNSKEY RRsets* set. Also include any
associated RRSIG records in the answer section.
2. Send the DNSKEY query over UDP to the name server IP address.
1. If no DNS response is returned, then go to next name server
IP.
2. Else, if AA bit is not set in the DNS response, then go to
next name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then
go to next name server IP.
4. Else, if the DNS response contains at least one DNSKEY
record in the answer section, then add the name server IP and
the DNSKEY RRset from the answer section to the
*DNSKEY RRsets* set. Also include any associated RRSIG records
in the answer section.
3. Go to next name server IP.
6. If the *CDNSKEY RRsets* set is empty then terminate this test case.
7. For each name server IP in the *CDNSKEY RRsets* set do:
1. If the CDNSKEY RRset is empty go to next name server IP address.
2. Get the CDNSKEY RRset and the associated RRSIG records, if any, from the
*CDNSKEY RRsets* set for the name server IP.
3. If any CDNSKEY record is a "delete" CDNSKEY, then do:
1. If there is more than a single CDNSKEY record then add the
name server IP to the *Mixed Delete CDNSKEY* set.
2. Else, add the name server IP address to the *Delete CDNSKEY*
set.
4. Get the DNSKEY RRset and the associated RRSIG records, if any, from the
*DNSKEY RRsets* for the same name server IP.
5. If there are no DNSKEY records, then do:
1. Add name server IP address to the *No DNSKEY RRset* set
(duplicates not possible).
2. Go to next name server IP.
6. Repeat the following steps for each CDNSKEY record unless it is a "delete"
CDNSKEY record:
1. If bit 7 of the flags field of the CDNSKEY record is unset (value 0)
then add the name server IP address and the
[key tag calculated][Key Tag Calculation] from the CDNSKEY record to
the *CDNSKEY is non-zone key* set.
2. Else, do:
1. If bit 15 of the flags field of the CDNSKEY is unset (value 0) then
add the name server IP address and the
[key tag calculated][Key Tag Calculation] from the CDNSKEY to the
*CDNSKEY is non-SEP key* set.
2. Compare the CDNSKEY record with the DNSKEY records.
3. If the CDNSKEY record does not match any DNSKEY record then
add the name server IP address and the
[key tag calculated][Key Tag Calculation] from the CDNSKEY record
to the *No Match CDNSKEY With DNSKEY* set.
4. Else, do:
1. If the DNSKEY RRset is not signed by the DNSKEY record that
corresponds to the CDNSKEY record then add the name server IP
address and [key tag calculated][Key Tag Calculation] from
CDNSKEY record to the *DNSKEY Not Signed By CDNSKEY* set.
2. If the CDNSKEY RRset is not signed by the DNSKEY record that
corresponds to the CDNSKEY record then add the name server IP
address and [key tag calculated][Key Tag Calculation] from
CDNSKEY record to the *CDNSKEY Not Signed By CDNSKEY* set.
7. If the CDNSKEY RRset is not signed, then add the name server IP address to
the *CDNSKEY Not Signed* set.
8. Else, for each RRSIG for the CDNSKEY RRset do:
1. If the key tag of the RRSIG does not match any DNSKEY record in the
DNSKEY RRset then add the name server IP address and key tag to the
*CDNSKEY Signed By Unknown DNSKEY* set.
2. Else, if the RRSIG cannot be validated by the DNSKEY it
refers to by key tag, then add the name server IP and RRSIG
key tag to the *CDNSKEY Invalid RRSIG* set.
9. Go to next name server IP address.
8. If the *No DNSKEY RRset* set is non-empty, then output
*[DS17_CDNSKEY_WITHOUT_DNSKEY]* with all name server IP addresses
in the set.
9. If the *Mixed Delete CDNSKEY* set is
non-empty, then output *[DS17_MIXED_DELETE_CDNSKEY]* with all
name server IP addresses in the set.
10. If the *Delete CDNSKEY* set is non-empty then output
*[DS17_DELETE_CDNSKEY]* with all name server IP addresses.
11. If the *No Match CDNSKEY With DNSKEY* set is non-empty then do:
* For each CDNSKEY key tag in the set do:
* Output *[DS17_CDNSKEY_MATCHES_NO_DNSKEY]* with the CDNSKEY
key tag and the name server IP addresses in the set for that
key tag.
12. If the *CDNSKEY is non-zone key* set is non-empty then do:
* For each CDNSKEY key tag in the set do:
* Output *[DS17_CDNSKEY_IS_NON_ZONE]* with the CDNSKEY key tag
and the name server IP addresses in the set for that key tag.
13. If the *CDNSKEY is non-SEP key* set is non-empty then do:
* For each CDNSKEY key tag in the set do:
* Output *[DS17_CDNSKEY_IS_NON_SEP]* with the CDNSKEY key tag
and the name server IP addresses in the set for that key tag.
14. If the *DNSKEY Not Signed By CDNSKEY* set is non-empty then do:
* For each CDNSKEY key tag in the set do:
* Output *[DS17_DNSKEY_NOT_SIGNED_BY_CDNSKEY]* with the CDNSKEY
key tag and the name server IP addresses in the set for that
key tag.
15. If the *CDNSKEY Not Signed By CDNSKEY* set is non-empty then do:
* For each CDNSKEY key tag in the set do:
* Output *[DS17_CDNSKEY_NOT_SIGNED_BY_CDNSKEY]* with the CDNSKEY key tag
and the name server IP addresses in the set for that key tag.
16. If the *CDNSKEY Invalid RRSIG* set is non-empty then do:
* For each RRSIG key tag in the set do:
* Output *[DS17_CDNSKEY_INVALID_RRSIG]* with the RRSIG key tag
and the name server IP addresses in the set for that key tag.
17. If the *CDNSKEY Not Signed* set is
non-empty then output *[DS17_CDNSKEY_UNSIGNED]* with all
name server IP addresses in the set.
18. If the *CDNSKEY Signed By Unknown DNSKEY* set is non-empty then
output *[DS17_CDNSKEY_SIGNED_BY_UNKNOWN_DNSKEY]* with the name server
IP addresses in the set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
the ignored protocol.
## Intercase dependencies
None.
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DNSSEC15]: dnssec15.md
[DNSSEC16]: dnssec16.md
[DS17_CDNSKEY_INVALID_RRSIG]: #summary
[DS17_CDNSKEY_IS_NON_SEP]: #summary
[DS17_CDNSKEY_IS_NON_ZONE]: #summary
[DS17_CDNSKEY_MATCHES_NO_DNSKEY]: #summary
[DS17_CDNSKEY_NOT_SIGNED_BY_CDNSKEY]: #summary
[DS17_CDNSKEY_SIGNED_BY_UNKNOWN_DNSKEY]: #summary
[DS17_CDNSKEY_UNSIGNED]: #summary
[DS17_CDNSKEY_WITHOUT_DNSKEY]: #summary
[DS17_DELETE_CDNSKEY]: #summary
[DS17_DNSKEY_NOT_SIGNED_BY_CDNSKEY]: #summary
[DS17_MIXED_DELETE_CDNSKEY]: #summary
[Default level]: ../SeverityLevelDefinitions.md
[ERROR]: ../SeverityLevelDefinitions.md#error
[INFO]: ../SeverityLevelDefinitions.md#info
[Key Tag Calculation]: https://datatracker.ietf.org/doc/html/rfc4034#appendix-B
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 7344, section 4]: https://datatracker.ietf.org/doc/html/rfc7344#section-4
[RFC 7344]: https://datatracker.ietf.org/doc/html/rfc7344
[RFC 8078]: https://datatracker.ietf.org/doc/html/rfc8078
[WARNING]: ../SeverityLevelDefinitions.md#warning

229
zonemaster/docs/public/specifications/tests/DNSSEC-TP/dnssec18.md Normal file
View File

@@ -0,0 +1,229 @@
# DNSSEC18: Validate trust from DS to CDS and CDNSKEY
## Test case identifier
**DNSSEC18**
## Objective
CDS and CDNSKEY record types are defined in [RFC 7344] and [RFC 8078]. Both
record types are optional in a zone. The objective of this test case is to verify
that there is a correct chain of trust from DS, in the parent zone to the CDS and
CDNSKEY RRsets ([RFC 7344][RFC 7344#4.1], section 4.1).
As stated in [RFC 4035][RFC 4035#2.4], section 2.4:
> A DS RR SHOULD point to a DNSKEY RR that is present in the child's
> apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be
> signed by the corresponding private key.
This Test case is only relevant if
* The *Child Zone* has either CDS or CDNSKEY record or both, and
* The parent zone has a DS RRset for the *Child Zone*.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will just ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server.
It is assumed that *Child Zone* has been tested or will be tested by
[DNSSEC15], [DNSSEC16] and [DNSSEC17] and that the servers give the
same responses. Running this test case without running [DNSSEC15],
[DNSSEC16] and [DNSSEC17] can give an incomplete report of the CDS and
CDNSKEY status of *Child Zone*.
## Summary
* If no CDS or CDNSKEY records are found, this test case is not run
and no message will be outputted.
* If no DS records are found at parent, this test case is not run
and no message will be outputted.
Message Tag outputted | [Default level] | Description of when message tag is outputted
:------------------------------|:------|:-----------------------------------------
DS18_NO_MATCH_CDS_RRSIG_DS | ERROR | The CDS RRset is not signed with a DNSKEY record that a DS record points to.
DS18_NO_MATCH_CDNSKEY_RRSIG_DS | ERROR | CDNSKEY RRset is not signed with a DNSKEY record that a DS record points to.
## Inputs
* "Child Zone" - The domain name to be tested.
* "Test Type" - The test type with value "undelegated" or "normal".
* "Undelegated DS" - The DS record or records submitted (only if
Test Type is undelegated).
## Ordered description of steps to be taken to execute the test case
1. Create a CDS query with EDNS enabled and the DO bit set for the
apex of the *Child Zone*.
2. Create a CDNSKEY query with EDNS enabled and the DO bit set for
the apex of the *Child Zone*.
3. Create a DNSKEY query with EDNS enabled and the DO bit set for
the apex of the *Child Zone*.
4. Create a DS query with EDNS enabled and DO flag set for the name of
the *Child Zone*.
5. Create the following empty sets:
1. Name server IP address and associated CDS RRset and its RRSIG
records ("CDS RRsets"). A name server IP can hold an empty
RRset or no RRSIG records.
2. Name server IP address and associated CDNSKEY RRset and its
RRSIG records ("CDNSKEY RRsets"). A name server IP can hold an
empty RRset or no RRSIG records.
3. Name server IP address and associated DNSKEY RRset
("DNSKEY RRsets"). A name server IP can hold an empty RRset.
4. DS record set ("DS Records").
5. Name server IP ("DS No Match CDS RRSIG").
6. Name server IP ("DS No Match CDNSKEY RRSIG").
6. If the *Test Type* is "undelegated", then:
1. Add *Undelegated DS* set to *DS Records*.
7. Else, do (*Test Type* is "normal"):
1. Retrieve all name server IP addresses for the parent zone of
*Child Zone* using [Get-Parent-NS-IPs] ("Parent NS IP").
2. For each IP address in *Parent NS IP* do:
1. Send the DS query over UDP to the name server IP.
2. If no DNS response is returned, then go to next name server
IP.
3. Else, if AA bit is not set in the DNS response, then go to
next name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then
go to next name server IP.
4. Else, if the DNS response contains at least one DS record
add all DS records to *DS Records*.
8. If *DS Records* is empty, terminate this test case.
9. Retrieve all name server IP addresses for the *Child Zone* using
[Method4] and [Method5] ("NS IP").
10. Repeat the following steps for each name server IP address in
*NS IP*:
1. Send the CDS query over UDP to the name server IP address.
1. If no DNS response is returned, then go to next name server
IP.
2. Else, if AA bit is not set in the DNS response, then go to
next name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then
go to next name server IP.
4. Else, if the DNS response contains at least one CDS record
in the answer section, then add the name server IP and the
CDS RRset to the *CDS RRsets* set. Also include any associated
RRSIG records.
2. Send the CDNSKEY query over UDP to the name server IP address.
1. If no DNS response is returned, then go to next name server
IP.
2. Else, if AA bit is not set in the DNS response, then go to
next name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then
go to next name server IP.
4. Else, if the DNS response contains at least one CDNSKEY
record in the answer section, then add the name server IP and
the CDNSKEY RRset from the answer section to the
*CDNSKEY RRsets* set. Also include any associated RRSIG records.
3. Send the DNSKEY query over UDP to the name server IP address.
1. If no DNS response is returned, then go to next name server
IP.
2. Else, if AA bit is not set in the DNS response, then go to
next name server IP.
3. Else, if the RCODE in the DNS response is not *NOERROR*, then
go to next name server IP.
4. Else, if the DNS response contains at least one DNSKEY
record in the answer section, then add the name server IP and
the DNSKEY RRset from the answer section to the
*DNSKEY RRsets* set.
4. Go to next name server IP.
11. If both the *CDS RRsets* and *CDNSKEY RRsets* sets are empty, then
terminate this test case.
12. If the *DNSKEY RRsets* is empty, then terminate this test case.
13. For each name server IP in the *CDS RRsets* set do:
1. Extract the RRSIG records for the CDS RRset.
2. Extract the DNSKEY from the *DNSKEY RRsets* for the same name
server IP.
3. For each DS record in *DS Records* do:
1. If the DS record does not point to a DNSKEY record then go
to next DS record.
2. Else, if the DNSKEY that the DS record points to matches
an RRSIG for CDS RRset then go to next name server IP
address.
3. Go to next DS records.
4. Add name server IP to the *DS No Match CDS RRSIG* (i.e. there was no match
between any DS record and an RRSIG record for the CDS RRset in the DS
record loop above).
5. Go to next name server IP address.
14. For each name server IP in the *CDNSKEY RRsets* set do:
1. Extract the RRSIG records for the CDNSKEY RRset.
2. Extract the DNSKEY from the *DNSKEY RRsets* for the same name
server IP.
3. For each DS record in *DS Records* do:
1. If the DS record does not point to a DNSKEY record then go
to next DS record.
2. Else, if the DNSKEY that the DS record points to matches
an RRSIG for CDNSKEY RRset then go to next name server IP
address.
3. Go to next DS records.
4. Add name server IP to the *DS No Match CDNSKEY RRSIG* (i.e. there was no match
between any DS record and an RRSIG record for the CDNSKEY RRset in the DS
record loop above).
5. Go to next name server IP address.
15. If the *DS No Match CDS RRSIG* set is non-empty then output
*[DS18_NO_MATCH_CDS_RRSIG_DS]* with the name server IP addresses in
the set.
16. If the *DS No Match CDNSKEY RRSIG* set is non-empty then output
*[DS18_NO_MATCH_CDNSKEY_RRSIG_DS]* with the name server IP
addresses in the set.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *[ERROR]* or *[CRITICAL]*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *[WARNING]*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
the ignored protocol.
## Intercase dependencies
None.
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[DNSSEC15]: dnssec15.md
[DNSSEC16]: dnssec16.md
[DNSSEC17]: dnssec16.md
[DS18_NO_MATCH_CDNSKEY_RRSIG_DS]: #summary
[DS18_NO_MATCH_CDS_RRSIG_DS]: #summary
[Default level]: ../SeverityLevelDefinitions.md
[ERROR]: ../SeverityLevelDefinitions.md#error
[Get-Parent-NS-IPs]: ../MethodsV2.md#method-get-parent-ns-ip-addresses
[INFO]: ../SeverityLevelDefinitions.md#info
[Method1]: ../Methods.md#method-1-obtain-the-parent-domain
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RFC 4035#2.4]: https://datatracker.ietf.org/doc/html/rfc4035#section-2.4
[RFC 7344#4.1]: https://datatracker.ietf.org/doc/html/rfc7344#section-4.1
[RFC 7344]: https://datatracker.ietf.org/doc/html/rfc7344
[RFC 8078]: https://datatracker.ietf.org/doc/html/rfc8078
[WARNING]: ../SeverityLevelDefinitions.md#warning

21
zonemaster/docs/public/specifications/tests/Delegation-TP/README.md Normal file
View File

@@ -0,0 +1,21 @@
# Delegation Test Plan
This document uses the terminology defined in the [Master Test Plan].
[Master Test Plan]: ../MasterTestPlan.md
[Test Case README]: ../README.md
<!-- Content until EOF generated by script updateTestPlanReadme.pl from Zonemaster/Zonemaster utils directory -->
## Test cases list
|Test Case |Test Case Description|
|:---------|:--------------------|
|[DELEGATION01](delegation01.md)|Minimum number of name servers |
|[DELEGATION02](delegation02.md)|Name servers must have distinct IP addresses|
|[DELEGATION03](delegation03.md)|No truncation of referrals|
|[DELEGATION04](delegation04.md)|Name server is authoritative|
|[DELEGATION05](delegation05.md)|Name server must not point at CNAME alias|
|[DELEGATION06](delegation06.md)|Existence of SOA|
|[DELEGATION07](delegation07.md)|Parent glue name records present in child|

135
zonemaster/docs/public/specifications/tests/Delegation-TP/delegation01.md Normal file
View File

@@ -0,0 +1,135 @@
# DELEGATION01: Minimum number of name servers
## Test case identifier
**DELEGATION01**
## Objective
Section 4.1 of [RFC 1034] specifies that there must be a minimum of two name servers
for a domain. This test is done to verify this condition.
The RFC ([RFC 1034]) predates IPv6. Since IPv4 and IPv6 work as separate networks, this
test case has been extended to test for two name servers that resolve into IPv4 addresses
and IPv6 addresses respectively.
Both [RFC 3901] (section 3) and [RFC 4472] (section 1.3) states that a domain
(zone) should be available over IPv4 for the time being. Therefore, it is by the
default level in this test case considered to be more problematic not being available
over IPv4 than not being available over IPv6.
## Inputs
"Child Zone" - The domain name to be tested
## Ordered description of steps to be taken to execute the test case
1. Using [Method2], obtain the complete set of names of the name servers
from the delegation of the *Child Zone*.
2. Count the name server names:
1. If zero or one, emit *[NOT_ENOUGH_NS_DEL]*.
2. If two or more, emit *[ENOUGH_NS_DEL]*.
3. Using [Method4], obtain the IP addresses for the name servers of the
delegation of the *Child Zone*.
4. Count the number of name server names that resolve into at least one IPv4
address:
1. If zero, emit *[NO_IPV4_NS_DEL]*.
2. If one, emit *[NOT_ENOUGH_IPV4_NS_DEL]*.
3. If two or more, emit *[ENOUGH_IPV4_NS_DEL]*.
5. Count the number of name server names that resolve into at least one IPv6
address:
1. If zero, emit *[NO_IPV6_NS_DEL]*.
2. If one, emit *[NOT_ENOUGH_IPV6_NS_DEL]*.
3. If two or more, emit *[ENOUGH_IPV6_NS_DEL]*.
6. Using [Method3], obtain the complete set of names of the name servers
from the *Child Zone* for the *Child Zone*.
7. Count the name server names:
1. If zero or one, emit *[NOT_ENOUGH_NS_CHILD]*.
2. If two or more, emit *[ENOUGH_NS_CHILD]*.
8. Using [Method5], obtain the IP addresses for the name servers from
the *Child Zone* for the *Child Zone*.
9. Count the number of name server names that resolve into at least one IPv4
address:
1. If zero, emit *[NO_IPV4_NS_CHILD]*.
2. If one, emit *[NOT_ENOUGH_IPV4_NS_CHILD]*.
3. If two or more, emit *[ENOUGH_IPV4_NS_CHILD]*.
10. Count the number of name server names that resolve into at least one IPv6
address:
1. If zero, emit *[NO_IPV6_NS_CHILD]*.
2. If one, emit *[NOT_ENOUGH_IPV6_NS_CHILD]*.
3. If two or more, emit *[ENOUGH_IPV6_NS_CHILD]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
Else the outcome of this Test Case is "pass".
Message | Default severity level
:-----------------------------|:-----------------------------------
ENOUGH_IPV4_NS_CHILD | INFO
ENOUGH_IPV4_NS_DEL | INFO
ENOUGH_IPV6_NS_CHILD | INFO
ENOUGH_IPV6_NS_DEL | INFO
ENOUGH_NS_CHILD | INFO
ENOUGH_NS_DEL | INFO
NOT_ENOUGH_IPV4_NS_CHILD | ERROR
NOT_ENOUGH_IPV4_NS_DEL | ERROR
NOT_ENOUGH_IPV6_NS_CHILD | ERROR
NOT_ENOUGH_IPV6_NS_DEL | ERROR
NOT_ENOUGH_NS_CHILD | ERROR
NOT_ENOUGH_NS_DEL | ERROR
NO_IPV4_NS_CHILD | WARNING
NO_IPV4_NS_DEL | WARNING
NO_IPV6_NS_CHILD | NOTICE
NO_IPV6_NS_DEL | NOTICE
## Special procedural requirements
None
## Intercase dependencies
None
[RFC 1034]: https://datatracker.ietf.org/doc/html/rfc1034
[RFC 3901]: https://datatracker.ietf.org/doc/html/rfc3901
[RFC 4472]: https://datatracker.ietf.org/doc/html/rfc4472
[Method2]: ../Methods.md#method-2-obtain-glue-name-records-from-parent
[Method3]: ../Methods.md#method-3-obtain-name-servers-from-child
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[ENOUGH_IPV4_NS_CHILD]: #outcomes
[ENOUGH_IPV4_NS_DEL]: #outcomes
[ENOUGH_IPV6_NS_CHILD]: #outcomes
[ENOUGH_IPV6_NS_DEL]: #outcomes
[ENOUGH_NS_CHILD]: #outcomes
[ENOUGH_NS_DEL]: #outcomes
[NOT_ENOUGH_IPV4_NS_CHILD]: #outcomes
[NOT_ENOUGH_IPV4_NS_DEL]: #outcomes
[NOT_ENOUGH_IPV6_NS_CHILD]: #outcomes
[NOT_ENOUGH_IPV6_NS_DEL]: #outcomes
[NOT_ENOUGH_NS_CHILD]: #outcomes
[NOT_ENOUGH_NS_DEL]: #outcomes
[NO_IPV4_NS_CHILD]: #outcomes
[NO_IPV4_NS_DEL]: #outcomes
[NO_IPV6_NS_CHILD]: #outcomes
[NO_IPV6_NS_DEL]: #outcomes

81
zonemaster/docs/public/specifications/tests/Delegation-TP/delegation02.md Normal file
View File

@@ -0,0 +1,81 @@
# DELEGATION02: Name servers must have distinct IP addresses
## Test case identifier
**DELEGATION02:** Name servers must have distinct IP addresses
## Objective
If the domain's name servers use several different names, they can all
be using the same IP address. This may be due to a configuration error, or
a workaround for a certain policy restriction. This test case checks that
the name servers used do not reuse the same IP addresses.
Section 4.1 of [RFC 1034] says at least two name servers must be used
for a delegation.
## Inputs
"Child Zone" - The domain name to be tested.
## Ordered description of steps to be taken to execute the test case
1. Obtain the complete set of name server names in the delegation of
the *Child Zone* using [Method2] and the IP addresses for each name
using [Method4].
2. If the same IP address is found for two or more name server names,
emit *[DEL_NS_SAME_IP]* for each repeated address, else emit
*[DEL_DISTINCT_NS_IP]*.
3. Obtain the complete set of name server names from the *Child Zone*
using [Method3] and the IP addresses for each name using [Method5].
4. If the same IP address is found for two or more name server names,
emit *[CHILD_NS_SAME_IP]* for each repeated address, else emit
*[CHILD_DISTINCT_NS_IP]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level (if message is emitted)
:---------------------|:-----------------------------------
DEL_NS_SAME_IP | ERROR
CHILD_NS_SAME_IP | ERROR
DEL_DISTINCT_NS_IP | INFO
CHILD_DISTINCT_NS_IP | INFO
## Special procedural requirements
None
## Intercase dependencies
None
[RFC 1034]: https://datatracker.ietf.org/doc/html/rfc1034
[Method2]: ../Methods.md#method-2-obtain-glue-name-records-from-parent
[Method3]: ../Methods.md#method-3-obtain-name-servers-from-child
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[DEL_NS_SAME_IP]: #outcomes
[CHILD_NS_SAME_IP]: #outcomes
[DEL_DISTINCT_NS_IP]: #outcomes
[CHILD_DISTINCT_NS_IP]: #outcomes

137
zonemaster/docs/public/specifications/tests/Delegation-TP/delegation03.md Normal file
View File

@@ -0,0 +1,137 @@
# DELEGATION03: No truncation of referrals
## Test case identifier
**DELEGATION03**
## Objective
The Domain Name System defaults to using UDP for queries and answers with a
DNS payload limit of 512 octets (bytes). Larger replies cause an initial
truncation indication leading to a subsequent handling via TCP with
substantially higher overhead. EDNS0 is used to allow for larger UDP
responses thus reducing the need for use of TCP.
But [IANA] still maintains that referrals from the parent zone name servers
must fit into a non-EDNS0 UDP DNS packet.
## Inputs
* "Child Zone" - The domain name to be tested.
## Ordered description of steps to be taken to execute the test case
1. Create a DNS packet with a maximally long subdomain
under the *Child Zone* apex (that is, 255 octets including label
separators) in the Query section.
2. Obtain the set of name server names from the delegation of
the *Child Zone* from the parent using [Method2].
3. For each name server name obtained in the previous step:
1. Create an NS record with the *Child Zone* apex as owner name
and the name server name as RDATA.
2. Add the NS record to the Authority section of the DNS packet
created above using the message compression schema defined
in section 4.1.4 of [RFC 1035] where applicable.
4. Using [Method1], get the parent zone of *Child Zone*.
5. Obtain the name server IP addresses per name server name for
the delegation using [Method4].
6. Make a set of the name server names that resolve into at least one
IPv4 address ("IPv4 Name Server Set").
7. If the *IPv4 Name Server Set* is not empty and all name server
names in it are [In-Bailiwick of Parent] then:
1. Create an A record using one of the name server names and any
IPv4 address.
2. Add the A record to the Additional section of the DNS packet
created above using the message compression schema defined in
section 4.1.4 of [RFC 1035].
8. Make a set of the name server names that resolve into at least one
IPv6 address ("IPv6 Name Server Set").
9. If the *IPv6 Name Server Set* is not empty and all name server
names in it are [In-Bailiwick of Parent] then:
1. Create a AAAA record using one of the name server names and any
IPv6 address.
2. Add the AAAA record to the Additional section of the DNS packet
created above using the message compression schema defined in
section 4.1.4 of [RFC 1035].
10. If the size of the DNS packet after encoding exceeds 512 octets
then output *[REFERRAL_SIZE_TOO_LARGE]* else output
*[REFERRAL_SIZE_OK]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level of message
:---------------------------------|:-----------------------------------
REFERRAL_SIZE_TOO_LARGE | WARNING
REFERRAL_SIZE_OK | INFO
## Special procedural requirements
None
## Intercase dependencies
None
## Terminology
The terms "in-bailiwick" and "out-of-bailiwick" are used as defined
in [RFC 7719], section 6, page 15.
## In-Bailiwick of Parent
A name server name is *In-Bailiwick of Parent* if the name is a or
below the zone cut of the parent zone. If "example.com" is the parent
zone of "foofoo.example.com" then name server "ns1.barbar.example.com"
is *In-Bailiwick of Parent* for "foofoo.example.com".
All name servers of a TLD are *In-Bailiwick of Parent* since all
names are below the root apex '.'.
[RFC 7719]: https://datatracker.ietf.org/doc/html/rfc7719
[RFC 1035]: https://datatracker.ietf.org/doc/html/rfc1035
[IANA]: https://www.iana.org/help/nameserver-requirements
[in-bailiwick]: #terminology
[In-Bailiwick of Parent]: #in-bailiwick-of-parent
[Method1]: ../Methods.md#method-1-obtain-the-parent-domain
[Method2]: ../Methods.md#method-2-obtain-glue-name-records-from-parent
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[REFERRAL_SIZE_TOO_LARGE]: #outcomes
[REFERRAL_SIZE_OK]: #outcomes

43
zonemaster/docs/public/specifications/tests/Delegation-TP/delegation04.md Normal file
View File

@@ -0,0 +1,43 @@
## DELEGATION04: Name server is authoritative
### Test case identifier
**DELEGATION04:** Name server is authoritative
### Objective
Subsection 6.1 of [RFC 2181](https://datatracker.ietf.org/doc/html/rfc2181) specifies
that the nameservers must answer authoritatively for the domain. Answers
to queries to the name servers for the designated zone must have the "AA"
bit set.
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Obtain the complete set of name server address records from the parent using
[Method4](../Methods.md) and the child using [Method5](../Methods.md).
2. All the uniquely obtained address records are queried for the SOA record
over TCP and UDP on port 53.
3. For each query in step 2, check whether DNS answer (bogus response are not
checked here) is obtained. If any of the query fails to respond with an
answer, then do not proceed to step 4 for that query. Exit from the test
without any exceptions.
4. If any name server fail to give an authoritative answer ("AA-bit" is set
in the answer), the test fails.
### Outcome(s)
If all the name servers answer with the AA-bit set, then the test succeeds.
### Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
### Intercase dependencies
None

129
zonemaster/docs/public/specifications/tests/Delegation-TP/delegation05.md Normal file
View File

@@ -0,0 +1,129 @@
# DELEGATION05: Name server must not point at CNAME alias
## Test case identifier
**DELEGATION05**
## Objective
Name servers for a zone are defined in NS records. An NS record points
at a name, i.e. the RDATA for an NS record is a domain name. That
name is the name of the name server. [RFC 2181][RFC 2181#10.3], section
10.3, states that the name of the name server must not itself point at
a CNAME.
The objective of this test is to verify that name servers of the tested
domain (zone) do not point at CNAME records.
## Inputs
"Child Zone" - The domain name to be tested.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Ordered description of steps to be taken to execute the test case
1. Obtain the set of name server names using [Method2] and [Method3]
("NS Name").
2. Obtain the set of name server IP addresses using [Method4] and
[Method5] ("NS IP").
3. For each name server name in *NS Name* do:
1. Create a query for A record (A query) with the name server
name as owner name.
2. If the name server name is [in-domain] (sub-type of
[in-bailiwick]) then for each name server IP in
*NS IP* do:
1. Send the A query to the name server IP with the RD flag unset.
2. If the name server does not respond with a DNS response, then
output *[NO_RESPONSE]*.
3. Else, if the RCODE is not NOERROR, then output
*[UNEXPECTED_RCODE]*.
4. Else, if the answer section of the response includes a CNAME
record then output *[NS_IS_CNAME]*.
5. Else, if the response is a delegation (referral) to a
sub-zone of *Child Zone*, then:
1. Do a [DNS Lookup] of the A query with the RD
flag set.
2. If the answer section of the response includes a CNAME
record then output *[NS_IS_CNAME]*.
3. Else (the name server name is either [sibling domain]
or [out-of-bailiwick]) then do:
1. Do a [DNS Lookup] of the A query with the RD
flag set.
2. If the answer section of the response includes a CNAME
record then output *[NS_IS_CNAME]*.
4. If no *[NS_IS_CNAME]* was outputted, then output *[NO_NS_CNAME]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level
:---------------------|:-----------------------------------
NO_RESPONSE | DEBUG
UNEXPECTED_RCODE | WARNING
NS_IS_CNAME | ERROR
NO_NS_CNAME | INFO
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
## Intercase dependencies
None
## Terminology
The terms "in-domain", "sibling domain", "in-bailiwick" and
"out-of-bailiwick" are used as defined in [RFC 8499][RFC 8499#7], section 7
(p 25), where "in-domain" and "sibling domain" are defined as a sub-types
of "in-bailiwick".
The term "DNS Lookup" is used when a recursive lookup is used, though
any changes to the DNS tree introduced by an [undelegated test] must be
respected.
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[DNS Lookup]: #terminology
[Method2]: ../Methods.md#method-2-obtain-glue-name-records-from-parent
[Method3]: ../Methods.md#method-3-obtain-name-servers-from-child
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NO_NS_CNAME]: #outcomes
[NO_RESPONSE]: #outcomes
[NS_IS_CNAME]: #outcomes
[RFC 2181#10.3]: https://datatracker.ietf.org/doc/html/rfc2181#section-10.3
[RFC 8499#7]: https://datatracker.ietf.org/doc/html/rfc8499#section-7
[UNEXPECTED_RCODE]: #outcomes
[in-bailiwick]: #terminology
[in-domain]: #terminology
[out-of-bailiwick]: #terminology
[sibling domain]: #terminology
[terminology]: #terminology
[undelegated test]: ../../test-types/undelegated-test.md

39
zonemaster/docs/public/specifications/tests/Delegation-TP/delegation06.md Normal file
View File

@@ -0,0 +1,39 @@
## DELEGATION06: Existence of SOA
### Test case identifier
**DELEGATION06:** Existence of SOA
### Objective
Section 6.1 of the [RFC 2181](https://datatracker.ietf.org/doc/html/rfc2181) specifies
that the SOA record is mandatory for every zone.
This test is intended to verify the presence of a SOA record for the
domain.
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Obtain the complete set of name server address records from the parent using
[Method4](../Methods.md) and the child using [Method5](../Methods.md).
2. All the uniquely obtained address records are queried for the SOA record.
3. If there is an answer with NOERROR and there is no content in the
answer section, this test case fails.
### Outcome(s)
If there is a SOA record present for the domain this test case succeeds.
### Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
### Intercase dependencies
None

35
zonemaster/docs/public/specifications/tests/Delegation-TP/delegation07.md Normal file
View File

@@ -0,0 +1,35 @@
## DELEGATION07: Parent glue name records present in child
### Test case identifier
**DELEGATION07:** Parent glue name records present in child
### Objective
If the list of name servers for a domain obtained from its parent are not
found in its child zone, then it leads to an inconsistency (section 2.3
of [RIPE-114](https://www.ripe.net/publications/docs/ripe-114))
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Obtain the complete set of name servers from the parent using
[Method2](../Methods.md) and the child using [Method3](../Methods.md).
3. If the set of NS names obtained from [Method2](../Methods.md) are
not found in [Method3](../Methods.md), then the test fails.
### Outcome(s)
If the set of glue name records obtained are found in the list of name
servers obtained from the child also, then the test succeeds
### Special procedural requirements
None
### Intercase dependencies
None

87
zonemaster/docs/public/specifications/tests/ImplementedTestCases.md Normal file
View File

@@ -0,0 +1,87 @@
<!-- File generated by generateImplementedTestCases.pl, script in zonemaster/zonemaster util directory.
Use that script to generate a new file for each release of Zonemaster when
Zonemaster-Engine also has been updated.-->
# Implemented Test Cases
Index of Text Case specifications is also found in [README](README.md).
[Zonemaster-Engine] is the repository of the implementation of the Test Cases (the methods).
|Test level (linked to Perl code at CPAN)|Method name in Perl code|Test Case Identifier (linked to specification)|
|:---------------------------------------|:-----------------------|----------------------------------------------|
| [Address](https://metacpan.org/pod/Zonemaster::Engine::Test::Address) | address01 | [ADDRESS01](Address-TP/address01.md) |
| [Address](https://metacpan.org/pod/Zonemaster::Engine::Test::Address) | address02 | [ADDRESS02](Address-TP/address02.md) |
| [Address](https://metacpan.org/pod/Zonemaster::Engine::Test::Address) | address03 | [ADDRESS03](Address-TP/address03.md) |
| [Basic](https://metacpan.org/pod/Zonemaster::Engine::Test::Basic) | basic01 | [BASIC01](Basic-TP/basic01.md) |
| [Basic](https://metacpan.org/pod/Zonemaster::Engine::Test::Basic) | basic02 | [BASIC02](Basic-TP/basic02.md) |
| [Basic](https://metacpan.org/pod/Zonemaster::Engine::Test::Basic) | basic03 | [BASIC03](Basic-TP/basic03.md) |
| [Connectivity](https://metacpan.org/pod/Zonemaster::Engine::Test::Connectivity) | connectivity01 | [CONNECTIVITY01](Connectivity-TP/connectivity01.md) |
| [Connectivity](https://metacpan.org/pod/Zonemaster::Engine::Test::Connectivity) | connectivity02 | [CONNECTIVITY02](Connectivity-TP/connectivity02.md) |
| [Connectivity](https://metacpan.org/pod/Zonemaster::Engine::Test::Connectivity) | connectivity03 | [CONNECTIVITY03](Connectivity-TP/connectivity03.md) |
| [Connectivity](https://metacpan.org/pod/Zonemaster::Engine::Test::Connectivity) | connectivity04 | [CONNECTIVITY04](Connectivity-TP/connectivity04.md) |
| [Consistency](https://metacpan.org/pod/Zonemaster::Engine::Test::Consistency) | consistency01 | [CONSISTENCY01](Consistency-TP/consistency01.md) |
| [Consistency](https://metacpan.org/pod/Zonemaster::Engine::Test::Consistency) | consistency02 | [CONSISTENCY02](Consistency-TP/consistency02.md) |
| [Consistency](https://metacpan.org/pod/Zonemaster::Engine::Test::Consistency) | consistency03 | [CONSISTENCY03](Consistency-TP/consistency03.md) |
| [Consistency](https://metacpan.org/pod/Zonemaster::Engine::Test::Consistency) | consistency04 | [CONSISTENCY04](Consistency-TP/consistency04.md) |
| [Consistency](https://metacpan.org/pod/Zonemaster::Engine::Test::Consistency) | consistency05 | [CONSISTENCY05](Consistency-TP/consistency05.md) |
| [Consistency](https://metacpan.org/pod/Zonemaster::Engine::Test::Consistency) | consistency06 | [CONSISTENCY06](Consistency-TP/consistency06.md) |
| [Delegation](https://metacpan.org/pod/Zonemaster::Engine::Test::Delegation) | delegation01 | [DELEGATION01](Delegation-TP/delegation01.md) |
| [Delegation](https://metacpan.org/pod/Zonemaster::Engine::Test::Delegation) | delegation02 | [DELEGATION02](Delegation-TP/delegation02.md) |
| [Delegation](https://metacpan.org/pod/Zonemaster::Engine::Test::Delegation) | delegation03 | [DELEGATION03](Delegation-TP/delegation03.md) |
| [Delegation](https://metacpan.org/pod/Zonemaster::Engine::Test::Delegation) | delegation04 | [DELEGATION04](Delegation-TP/delegation04.md) |
| [Delegation](https://metacpan.org/pod/Zonemaster::Engine::Test::Delegation) | delegation05 | [DELEGATION05](Delegation-TP/delegation05.md) |
| [Delegation](https://metacpan.org/pod/Zonemaster::Engine::Test::Delegation) | delegation06 | [DELEGATION06](Delegation-TP/delegation06.md) |
| [Delegation](https://metacpan.org/pod/Zonemaster::Engine::Test::Delegation) | delegation07 | [DELEGATION07](Delegation-TP/delegation07.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec01 | [DNSSEC01](DNSSEC-TP/dnssec01.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec02 | [DNSSEC02](DNSSEC-TP/dnssec02.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec03 | [DNSSEC03](DNSSEC-TP/dnssec03.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec04 | [DNSSEC04](DNSSEC-TP/dnssec04.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec05 | [DNSSEC05](DNSSEC-TP/dnssec05.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec06 | [DNSSEC06](DNSSEC-TP/dnssec06.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec07 | [DNSSEC07](DNSSEC-TP/dnssec07.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec08 | [DNSSEC08](DNSSEC-TP/dnssec08.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec09 | [DNSSEC09](DNSSEC-TP/dnssec09.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec10 | [DNSSEC10](DNSSEC-TP/dnssec10.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec11 | [DNSSEC11](DNSSEC-TP/dnssec11.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec13 | [DNSSEC13](DNSSEC-TP/dnssec13.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec14 | [DNSSEC14](DNSSEC-TP/dnssec14.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec15 | [DNSSEC15](DNSSEC-TP/dnssec15.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec16 | [DNSSEC16](DNSSEC-TP/dnssec16.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec17 | [DNSSEC17](DNSSEC-TP/dnssec17.md) |
| [DNSSEC](https://metacpan.org/pod/Zonemaster::Engine::Test::DNSSEC) | dnssec18 | [DNSSEC18](DNSSEC-TP/dnssec18.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver01 | [NAMESERVER01](Nameserver-TP/nameserver01.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver02 | [NAMESERVER02](Nameserver-TP/nameserver02.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver03 | [NAMESERVER03](Nameserver-TP/nameserver03.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver04 | [NAMESERVER04](Nameserver-TP/nameserver04.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver05 | [NAMESERVER05](Nameserver-TP/nameserver05.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver06 | [NAMESERVER06](Nameserver-TP/nameserver06.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver07 | [NAMESERVER07](Nameserver-TP/nameserver07.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver08 | [NAMESERVER08](Nameserver-TP/nameserver08.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver09 | [NAMESERVER09](Nameserver-TP/nameserver09.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver10 | [NAMESERVER10](Nameserver-TP/nameserver10.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver11 | [NAMESERVER11](Nameserver-TP/nameserver11.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver12 | [NAMESERVER12](Nameserver-TP/nameserver12.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver13 | [NAMESERVER13](Nameserver-TP/nameserver13.md) |
| [Nameserver](https://metacpan.org/pod/Zonemaster::Engine::Test::Nameserver) | nameserver15 | [NAMESERVER15](Nameserver-TP/nameserver15.md) |
| [Syntax](https://metacpan.org/pod/Zonemaster::Engine::Test::Syntax) | syntax01 | [SYNTAX01](Syntax-TP/syntax01.md) |
| [Syntax](https://metacpan.org/pod/Zonemaster::Engine::Test::Syntax) | syntax02 | [SYNTAX02](Syntax-TP/syntax02.md) |
| [Syntax](https://metacpan.org/pod/Zonemaster::Engine::Test::Syntax) | syntax03 | [SYNTAX03](Syntax-TP/syntax03.md) |
| [Syntax](https://metacpan.org/pod/Zonemaster::Engine::Test::Syntax) | syntax04 | [SYNTAX04](Syntax-TP/syntax04.md) |
| [Syntax](https://metacpan.org/pod/Zonemaster::Engine::Test::Syntax) | syntax05 | [SYNTAX05](Syntax-TP/syntax05.md) |
| [Syntax](https://metacpan.org/pod/Zonemaster::Engine::Test::Syntax) | syntax06 | [SYNTAX06](Syntax-TP/syntax06.md) |
| [Syntax](https://metacpan.org/pod/Zonemaster::Engine::Test::Syntax) | syntax07 | [SYNTAX07](Syntax-TP/syntax07.md) |
| [Syntax](https://metacpan.org/pod/Zonemaster::Engine::Test::Syntax) | syntax08 | [SYNTAX08](Syntax-TP/syntax08.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone01 | [ZONE01](Zone-TP/zone01.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone02 | [ZONE02](Zone-TP/zone02.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone03 | [ZONE03](Zone-TP/zone03.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone04 | [ZONE04](Zone-TP/zone04.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone05 | [ZONE05](Zone-TP/zone05.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone06 | [ZONE06](Zone-TP/zone06.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone07 | [ZONE07](Zone-TP/zone07.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone08 | [ZONE08](Zone-TP/zone08.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone09 | [ZONE09](Zone-TP/zone09.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone10 | [ZONE10](Zone-TP/zone10.md) |
| [Zone](https://metacpan.org/pod/Zonemaster::Engine::Test::Zone) | zone11 | [ZONE11](Zone-TP/zone11.md) |
[Zonemaster-Engine]: https://github.com/zonemaster/zonemaster-engine

375
zonemaster/docs/public/specifications/tests/MasterTestPlan.md Normal file
View File

@@ -0,0 +1,375 @@
Zonemaster Master Test Plan
===========================
Introduction
------------
This section gives a brief introduction to Zonemaster.
### Background
DNSCheck from IIS and Zonecheck from AFNIC were two different software
packages that do DNS validation of the quality of a DNS
delegation. The Zonemaster implementation is a major
rewrite of these software packages, and implement the best parts of
both.
### Purpose
The purpose of Zonemaster is to test the quality of a DNS
delegation. The core of the software is all the implemented
tests. There is a command line tool to run a complete set of
tests, and a web interface tailored for use by both basic and advanced
users.
### Goals
The goal of this document is to give an overview of the requirements
and the test levels. Each of the requirements will be broken down into
a set of test procedures. The process of doing this will be done in
accordance with the standard IEEE 829-2008.
The test requirements are all documented in the
[Test Requirements] document.
### Scope
The [Test Requirements] document is the base directive on what
test specifications implement.
### References
#### External
References to external documents are found in the [Test Requirements]
document.
#### Internal
No internal requirements.
#### Document hierarchy
* Master Test Plan
* [Basic] Test Plan
* Test Case x
* [Delegation] Test Plan
* Test Case x
* [Consistency] Test Plan
* Test Case x
* [DNSSEC] Test Plan
* Test Case x
* [Address] Test Plan
* Test Case x
* [Name Server] Test Plan
* Test Case x
* [Connectivity] Test Plan
* Test Case x
* [Zone] Test Plan
* Test Case x
* [Syntax] Test Plan
* Test Case x
### System overview and key features
A domain will be tested for the quality of the delegation in the DNS
hierarchy. Some of the high level properties that will be tested
include:
* **[Basic]** (initial tests)
* **[Delegation]** properties (parent and child name servers)
* **[Consistency]** (all names have consistent answers)
* **[DNSSEC]** properties (algorithms, secure delegation)
* **[Address]** properties (IP addresses)
* **[Name server]** properties
* Name server **[Connectivity]**
* **[Zone]** properties (are data controlling the zone sane)
* **[Syntax]** (illegal hostnames and characters)
A domain can be given to the testing system and all DNS information
will be retrieved from the public global DNS hierarchy, or a set of
pre-delegation data can be given to test a domain not yet published in
the global DNS hierarchy. A complete set of DNS queries and answers
can also be given as the input to the system for repeat testing.
### Test overview
The test organization, test schedule, integrity level scheme, test
resources, responsibilities, tools, techniques, and methods are
necessary to perform the testing.
#### Organization
A test is run on any machine where the Zonemaster software is
available. The tests ordinarily needs access to a complete DNS
hierarchy to be performed.
#### Master test schedule
A test is run as soon as the software is scheduled to run, often
immediately upon execution.
The first tests that are supposed to run are those from the Basic test
plan. If those tests succeeds, the rest of the test plans are run in
no specific order.
#### Integrity level schema
An integrity level schema is used for illustrating relative importance
of a software component. The effect of a failing component can range
from negligible to catastrophic. A component with a high integrity
level needs to be tested more thoroughly than a component with a lower
level. There is, however, no guidance in the requirements that
indicate the relative importance of different areas. Each area is thus
considered equally important. However, one of the main objectives is
to ensure the stability of DNS.
#### Resources summary
TODO: Briefly describe the necessary resources to run a test.
#### Responsibilities
#### Tools, techniques, methods, and metrics
TODO: Briefly described the necessary input and any metrics in the
output.
Details of the Master Test Plan
-------------------------------
The utilization of the IEEE 829-2008 is described in this
chapter. There is also a mapping between the test areas and the
requirements.
### Test processes
The goal of these documents is to describe the test cases and how the
DNS is tested. This is a part of a larger project where the goal is to
test the quality of the Internet. Processes for Management,
Acquisition, Supply, Development, Operation, and Maintenance are not
part of this subproject to define.
### Definition of test levels
There can be different types of tests, e.g. unit, system, and
acceptance tests. This test environment will only focus on compliance
testing for DNS, thus only one test level. Multiple areas have however
been identified within the system requirements:
* Basic
* Delegation
* Consistency
* DNSSEC
* Address
* Name server
* Connectivity
* Zone
* Syntax
The separation of test levels does not necessarily mean that
the levels are fully separated in the Zonemaster implementation.
At this level, the separation is done to make a better overview
of all the test cases specified.
### Test documentation requirements
The following documents can be created according to the standard:
* Level Test Plan (LTP)
* Level Test Design (LTD)
* Level Test Case (LTC)
* Level Test Procedure (LTPr)
However, the LTD has been incorporated in the LTP and in the LTC. LTPr
has been incorporated in the LTC.
#### Level Test Plan
The system will undergo acceptance testing against the
requirements. Each area is documented in a separate test plan. The
purpose is to map the requirements into test cases and also to
describe the approach for testing this level.
In the title of the plan, the word “Level” is replaced by the name for
the particular level being documented by the plan. E.g. [Delegation]
Test Plan and [DNSSEC] Test Plan.
#### Level Test Case
The purpose of the LTC is to define the information needed as it
pertains to inputs to and outputs from the software or software-based
system being tested. The test cases may be documented in a single or
multiple LTC depending on the extent of the area. Any procedures are
included in the documentation.
In the title of the test case, the word “Level” is replaced by the
name for the particular level being documented by the test case. The
documents have sub-titles since there can be more than one document
within one level. E.g. DNSSEC Test Cases or Connectivity Test Cases.
### Test administration requirements
These activities are needed to administer the tests during execution.
#### Anomaly Resolution
The tests are executed with the input given by the user. The input
data is validated to be correct. Depending on the input data and what
is available in the public DNS, some test cases might not be executed.
The output from Zonemaster should clearly indicate what test cases have
been executed, and which have not.
#### Reporting Processes
The output from all the tests are collected by the system and reported
back to the user depending on the choice of the user. There might be
several different methods used, for example as a brief or verbose log
file, or as XML or JSON output, or directly into a database.
### Test reporting requirements
The following documents can be created according to the standard:
* Level Test Log (LTL)
* Anomaly Report (AR)
* Level Interim Test Status Report (LITSR)
* Level Test Report (LTR)
* Master Test Report (MTR)
Only an MTR will be generated by the system.
#### Level Test Log
All logs from each test level are aggregated into the Master Test
Report.
#### Anomaly Report
An Anomaly Report is created if the result from the test is not
conclusive due to internal or external anomalies. All anomalies are in
the Master Test Report. However, the software implementation will also
report any anomalies with a different return code, so any calling
software can determine if the test cases were executed as planned, or
if any anomaly stopped the execution prematurely.
#### Master Test Report
The Master Test Report is generated continually during the execution
of the test plan. It will indicate the result of all the test cases,
and depending on any selected verbosity also down to the level where
you can see all the DNS queries and replies in a preferred data
format.
TODO: make a better description of the log files here?
### System requirements
The requirements are found in [Test Requirements] document.
#### RFCs
Where it is possible, the test cases refer to any RFCs describing what
the current IETF standards advise on the implementation of the DNS
protocol.
General
-------
This section contains the glossary and document change procedures for
all of the test plans and test cases.
### Glossary
| Word / Acronym | Explanation |
|:---------------|:-----------------------------------------|
| DNS | Domain Name System |
| DNSSEC | DNS Security Extensions |
| RFC | Request for Comments, IETF document |
| MTP | Master Test Plan |
| MTR | Master Test Report |
| LTC | Level Test Case |
| LTL | Level Test Log |
| LTP | Level Test Plan |
| LTR | Level Test Report |
| AR | Anomaly Report |
### Definitions of Terms
Since there are some terms relating to DNS that are commonly used with
unclear or multiple meanings, we will define here exactly what we mean
when we use them in the context of these specifications and these
tests. Any uncommon or special terms we use will also be defined here.
_Child Domain_ or _Child Zone_ is the domain or zone being tested.
_Parent Domain_ is the domain or zone that delegates directly to the domain
being tested. Differently put, it is the domain whose nameservers
delivers the glue records for the child domain.
_Glue Name Records_ are defined as all NS records
pertaining to the child domain that are delivered by the nameservers
for the parent domain.
_Glue Address Records_ are all A or AAAA records
pertaining to the child domain that are delivered by the nameservers
for the parent domain
_In bailiwick_ means that nameservers for a domain is in
the same domain (within the domain). i.e for 'domain.com', nameserver
is ns.domain.com and not ns.domain.net nor ns.otherdomain.org
_Out of bailiwick_ The term out-of-bailiwick means that nameservers for
a domain is not in the same domain. ie for 'domain.com' nameserver is
ns.domain.net or ns.otherdomain.org etc.
### Document change procedures
The overall change procedures are defined by the project and the
change management. However, there are some steps to take into
consideration when changing the test documents.
#### Identifying
A change to the documents may be initiated because of several reasons:
* New internal or external requirements
* Problems with the test cases
* Text that needs to be clarified
* Etc.
#### Implementing
The document versioning is managed by a version control system
(Git). Each change must contain a specific commit message detailing
the change. The major revisions section of this document should also
be updated if there is a new release of the document.
It is important that the outcome of the test cases stays the same;
unless the change was based on new or updated requirements.
#### Recording changes
An overall description must be stated in the document control chapter,
including a new revision number. A more detailed description of the
changes is part of the specific commit in the version control system.
#### Approving
The technical review team must approve any changes made to the test
cases.
[Test requirements]: https://github.com/zonemaster/zonemaster/blob/master/docs/internal/test-requirements/TestRequirements.md
[Basic]: Basic-TP/README.md
[Delegation]: Delegation-TP/README.md
[Consistency]: Consistency-TP/README.md
[DNSSEC]: DNSSEC-TP/README.md
[Address]: Address-TP/README.md
[Name Server]: Nameserver-TP/README.md
[Connectivity]: Connectivity-TP/README.md
[Zone]: Zone-TP/README.md
[Syntax]: Syntax-TP/README.md

74
zonemaster/docs/public/specifications/tests/Methods.md Normal file
View File

@@ -0,0 +1,74 @@
# Methods common to Test Case Specifications (version 1)
This is a list of generic Methods used in many Test Case specifications. The
Test Cases that makes use of any of these Methods should link directly to
this text.
This document holds version 1 of the set of Methods. Version 2 is defined in
[MethodsV2]. Methods from version 1 will be replaced by Methods from version 2 in
all Test Case specifications.
Before the transition all Test Cases specifications use version 1 (this
document). During the transition it will be stated in each specification
if the Test Case uses Methods from version 1 (this document) or Methods from
version 2 ([MethodsV2]). When the transition is completed, this document will be
removed.
### Method 1: Obtain the parent domain
This Method tries to obtain the parent domain from the domain used as input
to this Method.
1. A recursive SOA-record lookup for the child domain name starting at the
root domain should be done, and the steps of the process recorded.
2. If the recursion reaches a name server that responds with a redirect
directly to the requested domain, including functional glue, the test
succeeds. The domain through which the name server was found is
considered the parent domain.
3. If the recursion reaches a name server that authoritatively responds
with NXDOMAIN for the child domain, the test succeeds. The domain through
which the name server was found is considered the parent domain.
### Method 2: Obtain "glue Name records" from parent
This Method tries to obtain the authoritative name servers from the
delegation of the parent domain.
1. Obtain the parent domain as input from Method 1.
2. Send a query to the parent domain asking for the list of name servers
authoritative for the domain that is being tested
3. Record the list of name servers obtained from the authority section
### Method 3: Obtain name servers from child
Just as in Method 2, this Method tries to obtain the name servers configured
for the child zone from the child domain itself.
1. A NS query for the domain is made to all listed name servers obtained
from Method 2.
2. Record all the unique name servers from the answers received from the query in
step 1.
### Method 4: Obtain "glue address records" from parent
This Method tries to obtain any glue address records from the delegation
in the parent zone.
1. Query the servers in Method 2 for A and AAAA addresses.
2. Record the unique IP addresses from the answers (both A and AAAA) in
the additional section, which are the glue address records for the
domain.
### Method 5: Obtain the name server address records from child
This Method tries to obtain the IP addresses for the name servers used in
the child zone.
1. Send an A query to all name servers obtained in Method 3.
2. Record the list of unique IPv4 addresses in the answer section.
3. Send an AAAA query to all name servers obtained in Method 3.
4. Record the list of unique IPv6 addresses in the answer section.
[MethodsV2]: MethodsV2.md

1099
zonemaster/docs/public/specifications/tests/MethodsV2.md Normal file
View File

File diff suppressed because it is too large Load Diff

30
zonemaster/docs/public/specifications/tests/Nameserver-TP/README.md Normal file
View File

@@ -0,0 +1,30 @@
# Name Server Test Plan
These are tests of the properties of a name server.
This document uses the terminology defined in the [Master Test Plan].
[Master Test Plan]: ../MasterTestPlan.md
[Test Case README]: ../README.md
<!-- Content until EOF generated by script updateTestPlanReadme.pl from Zonemaster/Zonemaster utils directory -->
## Test cases list
|Test Case |Test Case Description|
|:---------|:--------------------|
|[NAMESERVER01](nameserver01.md)|A name server should not be a recursor|
|[NAMESERVER02](nameserver02.md)|Test of EDNS0 support|
|[NAMESERVER03](nameserver03.md)|Test availability of zone transfer (AXFR)|
|[NAMESERVER04](nameserver04.md)|Same source address|
|[NAMESERVER05](nameserver05.md)|Behaviour against AAAA query|
|[NAMESERVER06](nameserver06.md)|NS can be resolved|
|[NAMESERVER07](nameserver07.md)|To check whether authoritative name servers return an upward referral|
|[NAMESERVER08](nameserver08.md)|Testing QNAME case insensitivity |
|[NAMESERVER09](nameserver09.md)|Testing QNAME case sensitivity|
|[NAMESERVER10](nameserver10.md)|Test for undefined EDNS version|
|[NAMESERVER11](nameserver11.md)|Test for unknown EDNS OPTION-CODE|
|[NAMESERVER12](nameserver12.md)|Test for unknown EDNS flags|
|[NAMESERVER13](nameserver13.md)|Test for truncated response on EDNS query|
|[NAMESERVER15](nameserver15.md)|Checking for revealed software version|

99
zonemaster/docs/public/specifications/tests/Nameserver-TP/nameserver01.md Normal file
View File

@@ -0,0 +1,99 @@
# NAMESERVER01: A name server should not be a recursor
## Test case identifier
**NAMESERVER01**
## Objective
To ensure consistency in DNS, an authoritative name server should not be
configured to do recursive lookups. Also, open recursive resolvers are
considered bad internet practice due to their capability of assisting in
large scale DDoS attacks. The introduction to [RFC 5358] elaborates on
mixing recursor and authoritative functionality, and the issue is further
elaborated by [D.J. Bernstein].
Section 2.5 of [RFC 2870] have very specific requirement on disabling
recursion functionality on root name servers.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* The domain name to be tested ("Child Zone").
## Ordered description of steps to be taken to execute the test case
1. Create A queries for the following domain names:
1. xn--nameservertest.iis.se
2. xn--nameservertest.icann.org
3. xn--nameservertest.ripe.net
2. Retrieve all name server IPs for the *Child Zone* using
[Method4] and [Method5].
3. Repeat the following steps for each name server IP.
1. Send the three A queries over UDP.
2. For each query do the following steps:
1. If the name server does not respond with a DNS
response, then emit *[NO_RESPONSE]*.
2. If the DNS response comes with the RA flag set, then
emit *[IS_A_RECURSOR]*.
3. If the RCODE is NXDOMAIN in the responses for all three
queries then emit *[IS_A_RECURSOR]*.
4. If neither *[NO_RESPONSE]* nor *[IS_A_RECURSOR]* has been emitted
for that server, then emit *[NO_RECURSOR]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level (if message is emitted)
:-----------------------------|:-----------------------------------
NO_RESPONSE | DEBUG
IS_A_RECURSOR | ERROR
NO_RECURSOR | INFO
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
The domain names used in the queries are selected to be almost certainly
nonexistent name since the names are chosen to violate the
[IDNA 2008 specification] under SLDs (second-level domains) expected to
respect that specification. The SLDs are selected so that the chance that
they are all hosted on the same servers is low.
## Intercase dependencies
None.
## Terminology
Valid domain names according to the "IDNA 2008 specification" is found in
[RFC 5890], section 2.3.1, page 7.
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[D.J. Bernstein]: https://cr.yp.to/djbdns/separation.html
[IDNA 2008 specification]: #terminology
[IS_A_RECURSOR]: #outcomes
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NO_RECURSOR]: #outcomes
[NO_RESPONSE]: #outcomes
[RFC 2870]: https://datatracker.ietf.org/doc/html/rfc2870
[RFC 5358]: https://datatracker.ietf.org/doc/html/rfc5358
[RFC 5890]: https://datatracker.ietf.org/doc/html/rfc5890

128
zonemaster/docs/public/specifications/tests/Nameserver-TP/nameserver02.md Normal file
View File

@@ -0,0 +1,128 @@
# NAMESERVER02: Test of EDNS0 support
## Test case identifier
**NAMESERVER02**
## Objective
EDNS(0) is a mechanism to announce capabilities of a DNS implementation,
and is now basically required by any new functionality in DNS such as
DNSSEC. EDNS(0) is standardized in [RFC 6891].
This test case checks that all name servers has the capability to do
EDNS(0) or if not, correctly replies to queries containing EDNS
(OPT record).
Servers not supporting EDNS(0) must return FORMERR
([RFC 6891, section 7]):
> Responders that choose not to implement the protocol extensions
> defined in this document MUST respond with a return code (RCODE) of
> FORMERR to messages containing an OPT record in the additional
> section and MUST NOT include an OPT record in the response.
Servers supporting EDNS(0) must reply with EDNS(0)
([RFC 6891, section 6.1.1]):
> If an OPT record is present in a received request, compliant
> responders MUST include an OPT record in their respective responses.
To eliminating the risk of falsely classifying the server as not supporting
EDNS due e.g. firewall issues, the UDP buffer size is set to 512 bytes
(octets).
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* "Child Zone" - The domain name to be tested.
## Ordered description of steps to be taken to execute the test case
1. Created an SOA query for the *Child Zone* with an OPT record with
EDNS version set to "0" and with EDNS(0) option of payload size ("bufsize")
set to 512 and "DO" bit unset.
2. Create a second SOA query for the *Child Zone* without any OPT record.
3. Obtain the set of name server IP addresses using [Method4] and [Method5]
("Name Server IP").
4. For each name server in *Name Server IP* do:
1. Send the SOA query **with** OPT record to the name server and collect
the response.
2. If there is no DNS response, then:
1. Send the SOA query **without** OPT record to the name server and
collect the response.
2. If there is no DNS response, then output *[NO_RESPONSE]* and
go to next server.
3. Else (there is a DNS response), then output
*[BREAKS_ON_EDNS]* and go to next server.
3. Else, if the DNS response meet the following two criteria,
then output *[NO_EDNS_SUPPORT]*:
1. It has the RCODE "FORMERR"
2. It has no OPT record.
4. Else, if the DNS response meet the following criteria (compliant
server), then go to the next name server:
1. It has the RCODE "NOERROR".
2. The answer section contains the SOA record for *Child Zone*.
3. It has OPT record with EDNS version 0.
5. Else, if the DNS response meet the following criteria,
then output *[EDNS_RESPONSE_WITHOUT_EDNS]* and go to next server.
1. It has the RCODE "NOERROR".
2. It has no OPT record.
6. Else, if the DNS response meet the following criteria,
then output *[EDNS_VERSION_ERROR]* and go to next server.
1. It has the RCODE "NOERROR".
2. It has OPT record with EDNS version other than 0.
7. Else output *[NS_ERROR]* (i.e. other erroneous or unexpected
response).
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
The outcome of this Test case is "pass" in all other cases.
Message | Default severity level (when message is outputted)
:---------------------------------|:-----------------------------------
NO_RESPONSE | DEBUG
NO_EDNS_SUPPORT | WARNING
BREAKS_ON_EDNS | ERROR
EDNS_RESPONSE_WITHOUT_EDNS | ERROR
EDNS_VERSION_ERROR | ERROR
NS_ERROR | WARNING
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol and log a message reporting
the ignored result.
## Intercase dependencies
None
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[BREAKS_ON_EDNS]: #outcomes
[EDNS_RESPONSE_WITHOUT_EDNS]: #outcomes
[EDNS_VERSION_ERROR]: #outcomes
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NO_EDNS_SUPPORT]: #outcomes
[NO_RESPONSE]: #outcomes
[NS_ERROR]: #outcomes
[RFC 6891, section 6.1.1]: https://datatracker.ietf.org/doc/html/rfc6891#section-6.1.1
[RFC 6891, section 7]: https://datatracker.ietf.org/doc/html/rfc6891#section-7
[RFC 6891]: https://datatracker.ietf.org/doc/html/rfc6891

39
zonemaster/docs/public/specifications/tests/Nameserver-TP/nameserver03.md Normal file
View File

@@ -0,0 +1,39 @@
## NAMESERVER03: Test availability of zone transfer (AXFR)
### Test case identifier
**NAMESERVER03** Test availability of zone transfer (AXFR)
### Objective
AXFR is a mechanism to transfer the whole content of a zone from a name
server. Some people prefer to not disclose the whole content of a zone
for various reasons, and thus wants the public name server infrastructure
not do disclose the whole zone content to the public. This test case
checks the availability of the AXFR mechanism.
AXFR is defined in its latest revision in
[RFC 5936](https://datatracker.ietf.org/doc/html/rfc5936).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve all address records for all the name servers using [Method
4](../Methods.md) and [Method 5](../Methods.md).
2. Send an AXFR query to each name server IP address found in step 1.
3. If any answer to the AXFR query is starting with the SOA record
for the domain, this test case fails.
### Outcome(s)
If any name server for the domain allows a zone transfer using AXFR,
this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

38
zonemaster/docs/public/specifications/tests/Nameserver-TP/nameserver04.md Normal file
View File

@@ -0,0 +1,38 @@
## NAMESERVER04: Same source address
### Test case identifier
**NAMESERVER04** Same source address
### Objective
Responses from the authoritative name servers must contain same source IP
address as the destination IP address of the initial query. This has been
clarified in section 4 of
[RFC 2181](https://datatracker.ietf.org/doc/html/rfc2181#section-4).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve all address records for all the name servers using [Method
4](../Methods.md) and [Method 5](../Methods.md).
2. A SOA query for the domain name sent to the each name server IP address
found in step 1.
3. Any answer received from the SOA query must come from the same source IP address
as the query was sent to. If there is a mismatch, this test case fails.
### Outcome(s)
If any response comes from another IP address than the query was sent to,
this test case fails.
### Special procedural requirements
If there are many authoritative DNS nodes behind the IP address the query
is sent to, there could be multiple answers with possibly different source
addresses for the query. This special case is currently ignored.
### Intercase dependencies
None.

103
zonemaster/docs/public/specifications/tests/Nameserver-TP/nameserver05.md Normal file
View File

@@ -0,0 +1,103 @@
# NAMESERVER05: Behaviour against AAAA query
## Test case identifier
**NAMESERVER05**
## Objective
Older implementations of authoritative name servers have shown different
misbehaviours trying to answer queries for AAAA records, as described in
[RFC 4074]. This test case is intended to find out if the name server
authoritative for the domain shows any of these behaviours.
## Scope
It is assumed that *Child Zone* is also tested by [Connectivity01]. This test
case will set DEBUG level on messages for non-responsive name servers.
## Inputs
* "Child Zone" - The domain name to be tested.
## Ordered description of steps to be taken to execute the test case
1. Create an A query for the apex of the *Child Zone*.
2. Create a AAAA query for the apex of the *Child Zone*.
3. Create an empty set "AAAA OK".
4. Retrieve all name server IP addresses for the
*Child Zone* using [Method4] and [Method5] ("NS IP").
5. For each name server IP address in *NS IP* do:
1. Send the A query over UDP to the name server IP.
2. If no DNS response is returned, then output *[NO_RESPONSE]*.
3. Else, if DNS response does not have RCODE NOERROR, then output
*[A_UNEXPECTED_RCODE]*.
4. Else, do:
1. Send the AAAA query over UDP to the name server IP.
2. If no DNS response is returned, then output *[AAAA_QUERY_DROPPED]*.
3. Else, if the RCODE of the response is not NOERROR, then output
*[AAAA_UNEXPECTED_RCODE]*.
4. Else, if the answer section contains an AAAA record with incorrect
RDATA length (e.g. 4 instead of 16 octets), then output
*[AAAA_BAD_RDATA]*.
5. Else, add the name server IP to *AAAA OK*.
6. If *AAAA OK* is non-empty and no messages *[AAAA_QUERY_DROPPED]*,
*[AAAA_UNEXPECTED_RCODE]* or *[AAAA_BAD_RDATA]* have been outputted for any
name server IP, then output *[AAAA_WELL_PROCESSED]*.
## Outcome(s)
The outcome of this Test Case is "fail" if there is at least one message
with the severity level *ERROR* or *CRITICAL*.
The outcome of this Test Case is "warning" if there is at least one message
with the severity level *WARNING*, but no message with severity level
*ERROR* or *CRITICAL*.
In other cases the outcome of this Test Case is "pass".
Message | Default severity level
:-----------------------------|:-----------------------------------
AAAA_BAD_RDATA | ERROR
AAAA_QUERY_DROPPED | ERROR
AAAA_UNEXPECTED_RCODE | ERROR
AAAA_WELL_PROCESSED | INFO
A_UNEXPECTED_RCODE | WARNING
NO_RESPONSE | DEBUG
## Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of the
result of any test using this transport protocol. Log a message reporting
on the ignored result.
## Intercase dependencies
None.
[AAAA_BAD_RDATA]: #outcomes
[AAAA_QUERY_DROPPED]: #outcomes
[AAAA_UNEXPECTED_RCODE]: #outcomes
[AAAA_WELL_PROCESSED]: #outcomes
[A_UNEXPECTED_RCODE]: #outcomes
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[Method4]: ../Methods.md#method-4-obtain-glue-address-records-from-parent
[Method5]: ../Methods.md#method-5-obtain-the-name-server-address-records-from-child
[NO_RESPONSE]: #outcomes
[RFC 4074]: https://datatracker.ietf.org/doc/html/rfc4074

47
zonemaster/docs/public/specifications/tests/Nameserver-TP/nameserver06.md Normal file
View File

@@ -0,0 +1,47 @@
## NAMESERVER06: NS can be resolved
### Test case identifier
**NAMESERVER06** NS can be resolved
### Objective
All name servers names listed for a delegation must be resolvable in DNS.
If they are not resolvable using DNS this is a sign of misconfiguration,
and raises the risk of unreachability for the domain. It could also lower
the performance for any resolver trying to resolve the name.
The objective of this test is to resolve the domain using all the listed
name servers used in the delegation. More information about resolver
behavior is in section 7 of [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Obtain the list of name servers for the domain using [Method 2](
../Methods.md#method-2-obtain-glue-name-records-from-parent) and [Method 3](
../Methods.md#method-3-obtain-name-servers-from-child).
2. Use [Method 4](
../Methods.md#method-4-obtain-glue-address-records-from-parent) and
[Method 5](
../Methods.md#method-5-obtain-the-name-server-address-records-from-child)
to resolve all the name server names obtained in step 1.
3. If any name does not resolve to either an A RR or AAAA RR, this test
case fails.
### Outcome(s)
If any of the name server names fails to resolve to an IP address, this
test case fails.
### Special procedural requirements
If either IPv4 or IPv6 transport is disabled, ignore the evaluation of
the result of any test using this transport protocol. Log a message
reporting on the ignored result.
### Intercase dependencies
None.

34
zonemaster/docs/public/specifications/tests/Nameserver-TP/nameserver07.md Normal file
View File

@@ -0,0 +1,34 @@
## NAMESERVER07: To check whether authoritative name servers return an upward referral
### Test case identifier
NAMESERVER07 To check whether authoritative name servers return an upward
referral
### Objective
The configuration and/or implementation of some authoritative name servers
causes them to return an upward referral to the root zone. There are proofs that
such a [behaviour could be used for DDoS attacks](
https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful)
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. If the input domain to be tested is the root, exit from the test.
2. Retrieve all address records for all the name servers using [Method
4](../Methods.md) and [Method 5](../Methods.md).
3. An NS query is sent to each name server IP address found in step 2,
with the root “.” as the destination
4. If any of the query returns with one or more responses in the
authority section, then this test case fails.
### Outcome(s)
The test case is Ok only if there are no responses in the authority section
### Special procedural requirements
None.
### Intercase dependencies
None.

44
zonemaster/docs/public/specifications/tests/Nameserver-TP/nameserver08.md Normal file
View File

@@ -0,0 +1,44 @@
## NAMESERVER08: Testing QNAME case insensitivity
### Test case identifier
NAMESERVER08 Verify whether the authoritative nameserver response match the
case of every letter in the query name
### Objective
The DNS standards require that nameservers treat names with case insensitivity.
That is, the names example.com and EXAMPLE.COM should resolve to the same IP
address. However, in the response, most nameservers echo back the name as it
appeared in the request, preserving the original case.
Therefore, another way to add entropy to requests is to randomly vary the case
of letters in domain names queried. This technique, also known as "0x20" because
bit 0x20 is used to set the case of of US-ASCII letters, was first proposed in
the [IETF internet draft](https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00) Use of Bit 0x20 in DNS Labels to Improve Transaction
Identity. With this technique, the nameserver response must match not only the
query name, but the case of every letter in the name string; for example,
wWw.eXaMpLe.CoM or WwW.ExamPLe.COm. This may add little or no entropy to queries
for the top-level and root domains, but it's effective for most hostnames.
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve all address records for all the name servers using [Method
4](../Methods.md) and [Method 5](../Methods.md).
2. A random query with mixed case (e.G Www.iETf.Org) is sent to each unique name
server IP address found in step 1.
3. Remember the case of the QNAME in the query sent.
4. Compare the QNAME in the question section of the response with the string in step3.
5. If the string in step3 and step4 are not equal with respect to case in
sensitivity, the test fails.
### Outcome(s)
The test case is Ok only if there are no responses in the authority section
### Special procedural requirements
None.
### Intercase dependencies
None.

39
zonemaster/docs/public/specifications/tests/Nameserver-TP/nameserver09.md Normal file
View File

@@ -0,0 +1,39 @@
## NAMESERVER09: Testing QNAME case sensitivity
### Test case identifier
NAMESERVER09 Verify whether the authoritative nameserver returns same results
for equivalent names with different cases in the request.
### Objective
There has been cases where the nameservers respond with complete
case-sensitivity (in violation of the DNS standards): that is, they match the
exact case of the name in the response; but return different results for
equivalent names with different cases in the request (typically NXDOMAIN).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve all address records for all the name servers using [Method
4](../Methods.md) and [Method 5](../Methods.md).
2. Send a query with the input string in a mixed case (e.g. wWW.iETF.oRG) to
each of the name server IP address found in step 1.
3. If the "answer" flag is greater than 0, remember the "answer" section, else
remember the status flag.
4. Send another query with an alternative mixed case (e.g. Www.Ietf.Org) to each
of the name server found in step 1.
5. If the "answer" flag is greater than 0, remember the "answer" section, else
remember the status flag.
6. Compare the results remembered in step3 and step5.
7. If the results in step 6 are not equal, the test case fails.
### Outcome(s)
The test case passes only if the results of all queries are exactly the same.
### Special procedural requirements
None.
### Intercase dependencies
None.

Some files were not shown because too many files have changed in this diff Show More