feat: add full Zonemaster stack with Docker and Spanish UI

- 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:
2026-04-21 08:19:24 +02:00
commit 8d4eaa1489
1567 changed files with 204155 additions and 0 deletions

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|

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

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.

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).

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

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|

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

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

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.

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|

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

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

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)

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 records 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

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|

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

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

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

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

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

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

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

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|

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

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

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

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

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

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.

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

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

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

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

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

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.

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

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

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

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

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

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

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|

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

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

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

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

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

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

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

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

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

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

File diff suppressed because it is too large Load Diff

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|

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

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

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.

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.

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

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.

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.

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.

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.

View File

@@ -0,0 +1,164 @@
# NAMESERVER10: Test for undefined EDNS version
## Test case identifier
**NAMESERVER10**
## 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
EDNS ([RFC 6891]) is a mechanism to announce capabilities of a DNS
implementation, and is required by new functionality in DNS such as DNSSEC
([RFC 4033][RFC 4033#section-3], section 3).
[RFC 6891][RFC 6891#section-6.1.3], section 6.1.3, states that if a nameserver
has implemented EDNS but has not implemented the version level of the request,
then it MUST respond with RCODE "BADVERS". Only version "0" has been defined for
EDNS.
Note that RCODE "BADVERS" is an extended RCODE which is calculated from the
combination of the normal RCODE field in the DNS package header
([RFC 1035][RFC 1035#section-4.1.1], section 4.1.1) and the OPT record
EXTENDED-RCODE field ([RFC 6891][RFC 6891#section-6.1.3], section 6.1.3). Also
see [IANA RCODE Registry].
## Scope
Issues covered by [Connectivity01] (basic name server issues) or [Nameserver02] (basic
EDNS issues) will not result in messages from this test case.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
* Only relevant for a zone whose name servers correctly support EDNS, version 0.
Message Tag outputted | Level | Arguments | Description of when message tag is outputted
:-----------------------------|:--------|:------------------|:--------------------------------------------
N10_NO_RESPONSE_EDNS1_QUERY | WARNING | ns_ip_list | Response when EDNS ver=0, but not when 1.
N10_UNEXPECTED_RCODE | WARNING | ns_ip_list, rcode | Unexpected RCODE value when EDNS ver=1.
N10_EDNS_RESPONSE_ERROR | WARNING | ns_ip_list | Expected RCODE value when EDNS ver=1, but error in response.
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 IP ("No Response EDNS1 Query").
2. Name server IP and associated RCODE ("Unexpected RCODE").
3. Name server IP ("EDNS Response Error").
2. Create an SOA query for the *Child Zone* with an OPT record with EDNS version
set to "0" and with EDNS option of payload size ("bufsize") set to 512 and
other EDNS options and flags unset ("Query One").
3. Create an SOA query for the *Child Zone* with an OPT record with EDNS version
set to "1" and with EDNS option of payload size ("bufsize") set to 512 and
other EDNS options and flags unset ("Query Two").
4. Obtain the set of name server IP addresses using [Method4] and [Method5]
("Name Server IP").
5. For each name server in *Name Server IP* do:
1. Send *Query One* over UDP to the name server, collect the response and do:
1. If there is no DNS response then go to next name server.
2. Else, if the RCODE value is not "NOERROR" then go to next name server.
2. Send *Query Two* over UDP to the name server, collect the response and do:
1. If there is no DNS response, then add the name server IP to the
*No Response EDNS1 Query* set.
2. Else, if the DNS response does not have RCODE with value "BADVERS", then
add the name server IP and RCODE value to the *Unexpected RCODE* set.
3. Else, if the DNS response meet all the following three criteria, then
just go to the next name server (correct response):
1. It has the RCODE "BADVERS".
2. It has EDNS version 0.
3. The answer section is empty.
4. Else add the name server IP to the *EDNS Response Error* set.
6. If the *No Response EDNS1 Query* set is non-empty, then output
*[N10_NO_RESPONSE_EDNS1_QUERY]* with the name server IP addresses from the
set.
7. If the *Unexpected RCODE* set is non-empty, then for each RCODE value in the
set do:
* Output *[N10_UNEXPECTED_RCODE]* with the RCODE value and the name server
IP addresses for that RCODE value.
8. If the *EDNS Response Error* set is non-empty, then output
*[N10_EDNS_RESPONSE_ERROR]* 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, ignore the evaluation of the
result of any test using this transport protocol and log a message reporting
the ignored result.
## Intercase dependencies
None
## Terminology
No special terminology for this test case.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[ERROR]: ../SeverityLevelDefinitions.md#error
[IANA RCODE Registry]: 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
[N10_EDNS_RESPONSE_ERROR]: #summary
[N10_NO_RESPONSE_EDNS1_QUERY]: #summary
[N10_UNEXPECTED_RCODE]: #summary
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[Nameserver02]: ../Nameserver-TP/nameserver02.md
[RFC 1035#section-4.1.1]: https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.1
[RFC 4033#section-3]: https://datatracker.ietf.org/doc/html/rfc4033#section-3
[RFC 6891#section-6.1.3]: https://datatracker.ietf.org/doc/html/rfc6891#section-6.1.3
[RFC 6891]: https://datatracker.ietf.org/doc/html/rfc6891
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

View File

@@ -0,0 +1,195 @@
# NAMESERVER11: Test for unknown EDNS OPTION-CODE
## Test case identifier
**NAMESERVER11**
## 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
EDNS is a mechanism to announce capabilities of a DNS implementation,
and is now basically required by any new functionality in DNS such as
DNSSEC ([RFC 6891]).
[RFC 6891][RFC 6891, section 6.1.2], section 6.1.2, states that any OPTION-CODE values
not understood by a responder or requestor MUST be ignored. Unknown OPTION-CODE values
must be processed as though the OPTION-CODE was not even there.
In this test case, we will query with an unknown EDNS OPTION-CODE and expect
that the OPTION-CODE is not present in the response for the query.
## 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.
It is assumed that *Child Zone* has been tested and reported by [Nameserver02].
Running this test case without running [Nameserver02] can give an incomplete
report status of *Child Zone*.
## Inputs
"Child Zone" - The domain name to be tested.
## Summary
Message Tag | Level | Arguments | Message ID for message tag
:---------------------------------|:--------|-------------------|---------------------------------------------
N11_NO_EDNS | WARNING | ns_ip_list | The DNS response, on query with unknown EDNS option-code, does not contain any EDNS from name servers "{ns_ip_list}".
N11_NO_RESPONSE | WARNING | ns_ip_list | There is no response on query with unknown EDNS option-code from name servers "{ns_ip_list}".
N11_RETURNS_UNKNOWN_OPTION_CODE | WARNING | ns_ip_list | The DNS response, on query with unknown EDNS option-code, contains an unknown EDNS option-code from name servers "{ns_ip_list}".
N11_UNEXPECTED_ANSWER_SECTION | WARNING | ns_ip_list | The DNS response, on query with unknown EDNS option-code, does not contain the expected SOA record in the answer section from name servers "{ns_ip_list}".
N11_UNEXPECTED_RCODE | WARNING | ns_ip_list, rcode | The DNS response, on query with unknown EDNS option-code, has unexpected RCODE name "{rcode}" from name servers "{ns_ip_list}".
N11_UNSET_AA | WARNING | ns_ip_list | The DNS response, on query with unknown EDNS option-code, is unexpectedly not authoritative from name servers "{ns_ip_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].
## Test procedure
In this section and unless otherwise specified below, the term "[EDNS 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 [EDNS Response] in the same specification.
1. Create the following empty sets:
1. Name server IP address ("No Response on Unknown Option Code")
2. Name server IP address and [RCODE Name] ("Unexpected RCODE on Unknown Option Code")
3. Name server IP address ("No EDNS on Unknown Option Code")
4. Name server IP address ("Unexpected Answer Section on Unknown Option Code")
5. Name server IP address ("Unset AA on Unknown Option Code")
6. Name server IP address ("Returns Unknown Option Code")
2. Create a [EDNS Query] with query type SOA, *Child Zone* as query name and with
no EDNS options or flags ("SOA Query").
3. Create a [EDNS Query] with query type SOA, *Child Zone* as query name and with
EDNS OPTION-CODE set to anything other than what is already assigned in
the [IANA-DNSSYSTEM-PARAMETERS] and no other EDNS options or flags
("SOA Query with EDNS Option").
4. Obtain the set of name server IP addresses using [Method4] and [Method5]
("Name Server IP").
5. For each name server in *Name Server IP* do:
1. Send *SOA Query* to the name server and collect the response.
2. Go to next name server if at least one of the following criteria is met:
1. There is no DNS response from the server.
2. EDNS is unset in the response.
3. The [RCODE Name] in the response is not "NoError".
4. The AA flag is unset in the response.
5. The answer section has no SOA record with *Child Zone* as owner name.
3. Send *SOA Query with EDNS Option* to the name server and collect the
response.
1. If there is no DNS response from the server then add the name server to
the *No Response on Unknown Option Code* set.
2. Else, if the [RCODE Name] in the response is not "NoError" then add the
name server and [RCODE Name] to the
*Unexpected RCODE on Unknown Option Code* set.
server.
3. Else, if EDNS is unset in the response then add the name server to
the *No EDNS on Unknown Option Code* set.
4. Else, if the answer section has no SOA record with *Child Zone* as owner
name then add the name server to the
*Unexpected Answer Section on Unknown Option Code* set.
5. Else, if the AA flag is unset in the response then add the name server
to the *Unset AA on Unknown Option Code* set.
6. Else, if the "OPTION-CODE" from the query is present in the response,
then add name server to the *Returns Unknown Option Code* set.
7. Else, no issues were found.
5. If the *No Response on Unknown Option Code* set is non-empty, then output
*[N11_NO_RESPONSE]* with the name servers IP addresses from the set.
6. If the *Unexpected RCODE on Unknown Option Code* set is non-empty, then for
each [RCODE NAME] in the set output *[N11_UNEXPECTED_RCODE]* with the
[RCODE Name] and the name servers IP addresses for that [RCODE NAME] in the
set.
7. If the *No EDNS on Unknown Option Code* set is non-empty, then output
*[N11_NO_EDNS]* with the name servers IP addresses from the set.
8. If the *Unexpected Answer Section on Unknown Option Code* set is non-empty,
then output *[N11_UNEXPECTED_ANSWER_SECTION]* with the name servers IP
addresses from the set.
9. If the *Unset AA on Unknown Option Code* set is non-empty, then output
*[N11_UNSET_AA]* with the name servers IP addresses from the set.
11. If the *Returns Unknown Option Code* set is non-empty, then output
*[N11_RETURNS_UNKNOWN_OPTION_CODE]* with the name servers 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.
## 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
[EDNS Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-edns-query
[EDNS Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-an-edns-response
[ERROR]: ../SeverityLevelDefinitions.md#error
[IANA-DNSSYSTEM-PARAMETERS]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11
[INFO]: ../SeverityLevelDefinitions.md#info
[Message Tag Specification]: MessageTagSpecification.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
[Methods]: ../Methods.md
[N11_NO_EDNS]: #summary
[N11_NO_RESPONSE]: #summary
[N11_RETURNS_UNKNOWN_OPTION_CODE]: #summary
[N11_UNEXPECTED_ANSWER_SECTION]: #summary
[N11_UNEXPECTED_RCODE]: #summary
[N11_UNSET_AA]: #summary
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[Nameserver02]: ../Nameserver-TP/nameserver02.md
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 6891, section 6.1.2]: https://datatracker.ietf.org/doc/html/rfc6891#section-6.1.2
[RFC 6891]: https://datatracker.ietf.org/doc/html/rfc6891
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Test Case Identifier Specification]: TestCaseIdentifierSpecification.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

View File

@@ -0,0 +1,95 @@
# NAMESERVER12: Test for unknown EDNS flags
## Test case identifier
**NAMESERVER12**
## Objective
EDNS is a mechanism to announce capabilities of a dns implementation,
and is now basically required by any new functionality in dns such as
DNSSEC ([RFC 6891]).
[RFC 6891][RCF 6891#section-6.1.4], section 6.1.4, states that "Z"
flag bits must be set to zero by senders and ignored by receiver.
[IANA] lists the flags in the [EDNS Header Flags] assignment list.
In this test case, the query will have an unknown EDNS flag set, i.e.
one of the Z flag bits set to "1", and it is expected that all "Z"
bits to be clear in the response (set to "0").
## 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 a SOA query for the *Child Zone* with an OPT record with
one of the EDNS flag "Z" bits set to "1" and no other EDNS options or
flags set.
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 the SOA query to the name server and collect the response.
2. If there is no DNS response, output *[NO_RESPONSE]* and go to
next server.
3. Else, if the DNS response has the RCODE "FORMERR" then output
*[NO_EDNS_SUPPORT]*.
4. Else, if the pseudo-section has an OPT record with one or more Z
flag bits being set to "1", then output [Z_FLAGS_NOTCLEAR].
5. Else, if the DNS response meet the following four criteria,
then just go to the next name server (no error):
1. The SOA is obtained as response in the ANSWER section.
2. If the DNS response has the RCODE "NOERROR".
3. The pseudo-section response has an OPT record with version set to 0.
4. The "Z" bits are clear in the response
6. Else output *[NS_ERROR]*.
## 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
:---------------------------------|:----------------------------
NO_RESPONSE | DEBUG
NO_EDNS_SUPPORT | WARNING
NS_ERROR | WARNING
Z_FLAGS_NOTCLEAR | 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
[EDNS Header Flags]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13
[IANA]: https://www.iana.org/
[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
[RCF 6891#section-6.1.4]: https://datatracker.ietf.org/doc/html/rfc6891#section-6.1.4
[RFC 6891]: https://datatracker.ietf.org/doc/html/rfc6891
[Z_FLAGS_NOTCLEAR]: #outcomes

View File

@@ -0,0 +1,95 @@
# NAMESERVER13: Test for truncated response on EDNS query
## Test case identifier
**NAMESERVER13**
## Objective
EDNS is a mechanism to announce capabilities of a DNS implementation,
and is now basically required by any new functionality in DNS such as
DNSSEC ([RFC 6891]).
[RFC 6891, section 7] states that an OPT record must be included
in a truncated response, if the query includes an OPT pseudo record.
This Test Case will try to verify that if the response to a query with an OPT
record is truncated, then the response will contain an OPT record.
To trigger a truncated response, the OPT pseudo record 'DO' bit is set and the
buffer size is limited to 512 bytes. If the zone is not signed with DNSSEC, the
response will probably not be truncated anyway.
## 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 a DNSKEY query for the *Child Zone* that is signed with 'DO' bit
set to '1' and setting the buffer size to 512 bytes
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 the query to the name server and collect the response.
2. If there is no DNS response, output *[NO_RESPONSE]* and go to
next server.
3. Else, if the DNS response has the RCODE "FORMERR" then output
*[NO_EDNS_SUPPORT]* and go to the next server.
4. Else, if the DNS response meet the following criteria output
*[MISSING_OPT_IN_TRUNCATED]*:
1. The DNS response is truncated (the "TC" flag is set).
2. The DNS response has no OPT record.
5. Else, if the DNS response meet the following criteria,
then just go to the next name server (no error):
1. The DNS response has the RCODE "NOERROR".
2. The pseudo-section response has an OPT record with version set to 0.
6. Else output *[NS_ERROR]*.
## 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
NS_ERROR | WARNING
MISSING_OPT_IN_TRUNCATED | 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
[MISSING_OPT_IN_TRUNCATED]: #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 7]: https://datatracker.ietf.org/doc/html/rfc6891#section-7
[RFC 6891]: https://datatracker.ietf.org/doc/html/rfc6891

View File

@@ -0,0 +1,189 @@
# NAMESERVER15: Checking for revealed software version
## Test case identifier
**NAMESERVER15**
## 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
This Test Case verifies if a name server responds to TXT queries in the CHAOS
[DNS Class], specifically about its software version as it may sometimes be
desirable not to reveal that information. The CHAOS class identifier is usually
abbreviated as "CH".
A list of DNS classes and references for those are found in the
[IANA DNS Class database][DNS Class].
## 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.
## Summary
Message Tag | Level | Arguments | Message ID for message tag
:--------------------------|:--------|:----------------------------|:----------------------------------------------------------------------------------------------------------------------------
N15_ERROR_ON_VERSION_QUERY | NOTICE | ns_list, query_name | The following name server(s) do not respond or respond with SERVFAIL to software version query "{query_name}". Returned from name servers: "{ns_list}"
N15_NO_VERSION_REVEALED | INFO | ns_list | The following name server(s) do not reveal the software version. Returned from name servers: "{ns_list}"
N15_SOFTWARE_VERSION | NOTICE | ns_list, query_name, string | The following name server(s) respond to software version query "{query_name}" with string "{string}". Returned from name servers: "{ns_list}"
N15_WRONG_CLASS | WARNING | ns_list | The following name server(s) do not return CH class record(s) on CH class query. Returned 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
1. Create the following empty sets:
1. Name server IP, query name and string ("TXT Data")
2. Name server IP and query name ("Error On Version Query")
3. Name server IP ("Sending Version Query")
4. Name server IP ("Wrong Record Class")
2. Create a [DNS Query] with query type SOA and query name *Child Zone*
("SOA Query").
3. Create a [DNS Query] with query type TXT and [query class][DNS Class] CH
("TXT Query").
4. Create the set of query names with values "version.bind"
and "version.server" ("Query Names").
5. Obtain the set of name server IP addresses using [Method4] and
[Method5] ("Name Server IP").
6. For each name server in *Name Server IP* do:
1. Send *SOA Query* to the name server IP.
2. If there is no DNS response, then go to next name server IP.
3. Add the name server IP to the *Sending Version Query* set.
4. For each query name in *Query Names* do:
1. [Send] *TXT Query* with query name to the name server and collect the
response.
2. If there is no DNS response or the response has the [RCODE Name]
ServFail, add name server and query name to the
*Error On Version Query* set and go to next query name.
3. If the [DNS Response] does not have any TXT record in the answer
section with query name as owner name, go to next query name.
4. For each TXT record in the answer section of the [DNS Response] do:
1. If [DNS Class] of the TXT record is not CH, then add name server
to the *Wrong Record Class* set.
2. Extract and [concatenate] the string(s) from the RDATA of the
record.
3. Remove any leading or trailing [SPACE] (U+0020) or
[CHARACTER TABULATION] (horizontal tab, U+0009) characters from the
concatenated string.
4. If the extracted string is non-empty, add name server, query name
and the string to the *TXT Data* set.
7. If the *TXT Data* set is non-empty, then, for each unique string and query
name pair in the set, output *[N15_SOFTWARE_VERSION]* with name server IP
list, query name and string.
8. If the *Error On Version Query* set is non-empty, then for each query name
in the set output *[N15_ERROR_ON_VERSION_QUERY]* with the query name
and the list of name server IP addresses.
9. For each name server IP in the *Sending Version Query* set, remove that name
server IP from the set if the name server IP is also a member of the
*TXT Data* set.
10. If the *Sending Version Query* set is non-empty then output
*[N15_NO_VERSION_REVEALED]* with the list of the name servers in the
*Sending Version Query* set.
11. If the *Wrong Record Class* set is non-empty then output
*[N15_WRONG_CLASS]* with the list of the name servers in the
*Wrong Record Class* 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
The *Child Zone* must be a valid name meeting
"[Requirements and normalization of domain names in input]".
## Intercase dependencies
None
## Terminology
* "Concatenate" - The term is used to refer to the conversion of a TXT
resource records data to a single contiguous string, as specified in [RFC
7208, section 3.3][RFC7208#3.3].
* "Send" - The term is used when a DNS query is sent to
a specific name server (name server IP address).
[Argument List]: ../ArgumentsForTestCaseMessages.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[CHARACTER TABULATION]: https://codepoints.net/U+0009
[Concatenate]: #terminology
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[DEBUG]: ../SeverityLevelDefinitions.md#notice
[DNS Class]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2
[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
[Message Tag Specification]: ../../../../internal/templates/specifications/tests/MessageTagSpecification.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
[Methods]: ../Methods.md
[N15_ERROR_ON_VERSION_QUERY]: #summary
[N15_NO_VERSION_REVEALED]: #summary
[N15_SOFTWARE_VERSION]: #summary
[N15_WRONG_CLASS]: #summary
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC2929]: https://datatracker.ietf.org/doc/html/rfc2929#section-3.2
[RFC7208#3.3]: https://datatracker.ietf.org/doc/html/rfc7208#section-3.3
[Requirements and normalization of domain names in input]: ../RequirementsAndNormalizationOfDomainNames.md
[SPACE]: https://codepoints.net/U+0020
[Send]: #terminology
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[Test Case Identifier Specification]: ../../../../internal/templates/specifications/tests/TestCaseIdentifierSpecification.md
[Test procedure]: #test-procedure
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine Profile]: ../../../configuration/profiles.md

View File

@@ -0,0 +1,184 @@
# Zonemaster Test Case Specifications
**Table of contents**
* [Background]
* [Mapping the Test Requirements to Test Case]
* [Elaboration of the test case]
* [Document hierarchy]
* [Other documents]
* [List of Defined Test Cases]
## Background
This is the collection of **Test Case** specifications for the Zonemaster
project. All the details are in the [Master Test Plan].
* The test cases that has been elaborated as Test Case specifications have been
defined as a list of [test requirements]. Each test falls under a specific
category.
* The document hierarchy of the Test Case specifications could be found in the
[Master Test Plan].
## Mapping the Test Requirements to Test Case
* Each test level has been separated into a separate directory below this
directory.
* Under each test level directory there is a level document (README.md)
describing the test level. Links are found below.
* The Test Cases are listed below. The mapping from Test Requirement to Test Case
is found in the [Test requirements] document.
## Elaboration of the Test Case
Test cases are written for almost all Test Requirements. There could be the case
that a requirement can be implemented by doing more test cases than one, or
that several requirements are solved by only one test case.
## Document hierarchy
Each Test Level described in [Master Test Plan] should be linked directly to the
correct level document (the README.md in the test level directory). The level
documents are found here:
* [Address-TP]
* [Basic-TP]
* [Connectivity-TP]
* [Consistency-TP]
* [DNSSEC-TP]
* [Delegation-TP]
* [Nameserver-TP]
* [Syntax-TP]
* [Zone-TP]
## Other documents
The following documents are linked from and used by the Test Case
specifications listed in the table below:
* [DNS Query and Response Defaults]
* [Methods common to Test Case Specifications (version 1)]
* [Methods common to Test Case Specifications (version 2)]
* [Requirements and normalization of domain names in input]
* [Severity Level Definitions]
The following documents are useful documents when studying the
Test Case specifications:
* [Mapping test messages to Test Cases]
* [Implemented Test Cases]
* [Zonemaster Master Test Plan]
[Address-TP]: Address-TP/README.md
[Background]: #background
[Basic-TP]: Basic-TP/README.md
[Connectivity-TP]: Connectivity-TP/README.md
[Consistency-TP]: Consistency-TP/README.md
[DNS Query and Response Defaults]: DNSQueryAndResponseDefaults.md
[DNSSEC-TP]: DNSSEC-TP/README.md
[Delegation-TP]: Delegation-TP/README.md
[Document Hierarchy]: #document-hierarchy
[Elaboration of the test case]: #elaboration-of-the-test-case
[Implemented Test Cases]: ImplementedTestCases.md
[List of Defined Test Cases]: #list-of-defined-test-cases
[Mapping test messages to Test Cases]: TestMessages.md
[Mapping the Test Requirements to Test Case]: #mapping-the-test-requirements-to-test-case
[Master Test Plan]: MasterTestPlan.md
[Methods common to Test Case Specifications (version 1)]: Methods.md
[Methods common to Test Case Specifications (version 2)]: MethodsV2.md
[Nameserver-TP]: Nameserver-TP/README.md
[Other documents]: #other-documents
[Requirements and normalization of domain names in input]: RequirementsAndNormalizationOfDomainNames.md
[Severity Level Definitions]: SeverityLevelDefinitions.md
[Syntax-TP]: Syntax-TP/README.md
[Test requirements]: https://github.com/zonemaster/zonemaster/blob/master/docs/internal/test-requirements/TestRequirements.md
[Zone-TP]: Zone-TP/README.md
[Zonemaster Master Test Plan]: MasterTestPlan.md
## List of Defined Test Cases
<!-- Table generated by script generateTestCaseList.pl from Zonemaster/Zonemaster utils directory -->
|Test Plan/Test Case |Test Case Description|
|:-------------------|:--------------------|
|**Address-TP**| |
|[ADDRESS01](Address-TP/address01.md)|Name server address must be globally reachable|
|[ADDRESS02](Address-TP/address02.md)|Reverse DNS entry exists for name server IP address|
|[ADDRESS03](Address-TP/address03.md)|Reverse DNS entry matches name server name|
|**Basic-TP**| |
|[BASIC01](Basic-TP/basic01.md)|Check for the parent zone and the zone itself|
|[BASIC02](Basic-TP/basic02.md)|The domain must have at least one working name server|
|[BASIC03](Basic-TP/basic03.md)|The _Broken but functional_ test|
|**Connectivity-TP**| |
|[CONNECTIVITY01](Connectivity-TP/connectivity01.md)|UDP connectivity to name servers|
|[CONNECTIVITY02](Connectivity-TP/connectivity02.md)|TCP connectivity to name servers|
|[CONNECTIVITY03](Connectivity-TP/connectivity03.md)|AS Diversity|
|[CONNECTIVITY04](Connectivity-TP/connectivity04.md)|IP Prefix Diversity|
|**Consistency-TP**| |
|[CONSISTENCY01](Consistency-TP/consistency01.md)|SOA serial number consistency|
|[CONSISTENCY02](Consistency-TP/consistency02.md)|SOA RNAME consistency|
|[CONSISTENCY03](Consistency-TP/consistency03.md)|SOA timers consistency|
|[CONSISTENCY04](Consistency-TP/consistency04.md)|Name server NS consistency|
|[CONSISTENCY05](Consistency-TP/consistency05.md)|Consistency between glue and authoritative data|
|[CONSISTENCY06](Consistency-TP/consistency06.md)|SOA MNAME consistency|
|**DNSSEC-TP**| |
|[DNSSEC01](DNSSEC-TP/dnssec01.md)|Legal values for the DS hash digest algorithm|
|[DNSSEC02](DNSSEC-TP/dnssec02.md)|DS must match a valid DNSKEY in the child zone|
|[DNSSEC03](DNSSEC-TP/dnssec03.md)|Verify NSEC3 parameters|
|[DNSSEC04](DNSSEC-TP/dnssec04.md)|Check for too short or too long RRSIG lifetimes|
|[DNSSEC05](DNSSEC-TP/dnssec05.md)|Check for invalid DNSKEY algorithms|
|[DNSSEC06](DNSSEC-TP/dnssec06.md)|Verify DNSSEC additional processing|
|[DNSSEC07](DNSSEC-TP/dnssec07.md)|DNSSEC signed zone and DS in parent for signed zone|
|[DNSSEC08](DNSSEC-TP/dnssec08.md)|Valid RRSIG for DNSKEY|
|[DNSSEC09](DNSSEC-TP/dnssec09.md)|RRSIG(SOA) must be valid and created by a valid DNSKEY|
|[DNSSEC10](DNSSEC-TP/dnssec10.md)|Zone contains NSEC or NSEC3 records|
|[DNSSEC11](DNSSEC-TP/dnssec11.md)|DS in delegation requires signed zone|
|[DNSSEC12](DNSSEC-TP/dnssec12.md)|Test for DNSSEC Algorithm Completeness|
|[DNSSEC13](DNSSEC-TP/dnssec13.md)|All DNSKEY algorithms used to sign the zone|
|[DNSSEC14](DNSSEC-TP/dnssec14.md)|Check for valid RSA DNSKEY key size|
|[DNSSEC15](DNSSEC-TP/dnssec15.md)|Existence of CDS and CDNSKEY|
|[DNSSEC16](DNSSEC-TP/dnssec16.md)|Validate CDS|
|[DNSSEC17](DNSSEC-TP/dnssec17.md)|Validate CDNSKEY|
|[DNSSEC18](DNSSEC-TP/dnssec18.md)|Validate trust from DS to CDS and CDNSKEY|
|**Delegation-TP**| |
|[DELEGATION01](Delegation-TP/delegation01.md)|Minimum number of name servers |
|[DELEGATION02](Delegation-TP/delegation02.md)|Name servers must have distinct IP addresses|
|[DELEGATION03](Delegation-TP/delegation03.md)|No truncation of referrals|
|[DELEGATION04](Delegation-TP/delegation04.md)|Name server is authoritative|
|[DELEGATION05](Delegation-TP/delegation05.md)|Name server must not point at CNAME alias|
|[DELEGATION06](Delegation-TP/delegation06.md)|Existence of SOA|
|[DELEGATION07](Delegation-TP/delegation07.md)|Parent glue name records present in child|
|**Nameserver-TP**| |
|[NAMESERVER01](Nameserver-TP/nameserver01.md)|A name server should not be a recursor|
|[NAMESERVER02](Nameserver-TP/nameserver02.md)|Test of EDNS0 support|
|[NAMESERVER03](Nameserver-TP/nameserver03.md)|Test availability of zone transfer (AXFR)|
|[NAMESERVER04](Nameserver-TP/nameserver04.md)|Same source address|
|[NAMESERVER05](Nameserver-TP/nameserver05.md)|Behaviour against AAAA query|
|[NAMESERVER06](Nameserver-TP/nameserver06.md)|NS can be resolved|
|[NAMESERVER07](Nameserver-TP/nameserver07.md)|To check whether authoritative name servers return an upward referral|
|[NAMESERVER08](Nameserver-TP/nameserver08.md)|Testing QNAME case insensitivity |
|[NAMESERVER09](Nameserver-TP/nameserver09.md)|Testing QNAME case sensitivity|
|[NAMESERVER10](Nameserver-TP/nameserver10.md)|Test for undefined EDNS version|
|[NAMESERVER11](Nameserver-TP/nameserver11.md)|Test for unknown EDNS OPTION-CODE|
|[NAMESERVER12](Nameserver-TP/nameserver12.md)|Test for unknown EDNS flags|
|[NAMESERVER13](Nameserver-TP/nameserver13.md)|Test for truncated response on EDNS query|
|[NAMESERVER15](Nameserver-TP/nameserver15.md)|Checking for revealed software version|
|**Syntax-TP**| |
|[SYNTAX01](Syntax-TP/syntax01.md)|No illegal characters in the domain name|
|[SYNTAX02](Syntax-TP/syntax02.md)|No hyphen ('-') at the start or end of the domain name|
|[SYNTAX03](Syntax-TP/syntax03.md)|There must be no double hyphen ('--') in position 3 and 4 of the domain name|
|[SYNTAX04](Syntax-TP/syntax04.md)|The NS name must have a valid domain/hostname|
|[SYNTAX05](Syntax-TP/syntax05.md)|Misuse of '@' character in the SOA RNAME field|
|[SYNTAX06](Syntax-TP/syntax06.md)|No illegal characters in the SOA RNAME field|
|[SYNTAX07](Syntax-TP/syntax07.md)|No illegal characters in the SOA MNAME field|
|[SYNTAX08](Syntax-TP/syntax08.md)|MX name must have a valid hostname|
|**Zone-TP**| |
|[ZONE01](Zone-TP/zone01.md)|Fully qualified master nameserver in SOA|
|[ZONE02](Zone-TP/zone02.md)|SOA 'refresh' minimum value|
|[ZONE03](Zone-TP/zone03.md)|SOA 'retry' lower than 'refresh'|
|[ZONE04](Zone-TP/zone04.md)|SOA 'retry' at least 1 hour|
|[ZONE05](Zone-TP/zone05.md)|SOA 'expire' minimum value|
|[ZONE06](Zone-TP/zone06.md)|SOA 'minimum' maximum value|
|[ZONE07](Zone-TP/zone07.md)|SOA master is not an alias|
|[ZONE08](Zone-TP/zone08.md)|MX is not an alias|
|[ZONE09](Zone-TP/zone09.md)|MX record present|
|[ZONE10](Zone-TP/zone10.md)|No multiple SOA records|
|[ZONE11](Zone-TP/zone11.md)|SPF policy validation|

View File

@@ -0,0 +1,522 @@
# Requirements and normalization of domain names in input
## Table of contents
* [Objective](#objective)
* [Overview](#overview)
* [References](#references)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Detailed requirements]
* [ASCII domain name](#ascii-domain-name)
* [IDN name](#idn-name)
* [Length limitations](#length-limitations)
* [Root zone](#root-zone)
* [Creating IDNA2008 compatible format](#creating-idna2008-compatible-format)
* [Terminology](#terminology)
## Objective
This specification defines the requirements for zone name to be tested. The same
requirements are put on name server names in the input, if any. If the
requirements are not met, then Zonemaster will not start any tests.
This specification also defines some normalization that the domain names (zone
name and name server name) will go through. If a domain name is normalized it
means that an updated form of the name will be used. The updated form is
considered to be equal in meaning.
In order to execute the tests of the zone name from the input it must be a
valid domain name. If name servers are provided for the zone in the input, the
names of the name servers must also be valid domain names. Both types of domain
names, zone names and name server names, are tested and normalized by this test
case. The zone name is called *Child Zone* in Zonemaster test case
specifications.
## Overview
To be valid, *Domain Name* must be one of two:
1. a valid ASCII domain name, or
2. a valid IDN name (Internationalized Domain Name) as of [IDNA2008].
The process defined in this specification will normalize *Domain Name* and output
a normalized form to be used by all Zonemaster test cases. The objectives of the
normalization are
1. Optionally remove leading and trailing white space characters. This is done as
a pre-process in the client if appropriate, e.g. in fields in an HTML form in
a web form.
* If the preprocessing is not applied, then any leading or trailing space will be
caught as an illegal ASCII character.
2. Convert other dot characters to regular dot (or "FULL STOP").
3. Create legal IDNA 2008 U-labels from convenient alternative forms.
4. Create consistent representation of the same zone name.
The result of the normalization can be a new form of *Domain Name* to be used
by the tests in test cases, the normalized form. If the normalized form is
neither a valid ASCII domain name nor a valid IDN name, then *Domain Name*
cannot be used for Zonemaster testing.
If the outcome (see [Outcome(s)](#outcomes)) is not "fail" then *Domain Name* in
normalized form is returned to be used as input value for Zonemaster test cases.
See the details in the [Detailed requirements] section below.
### References
The following references are consulted for this specification:
* [RFC 1034]
* [RFC 1035]
* [RFC 1123]
* [RFC 2317]
* [RFC 2782]
* [RFC 5890]
* [RFC 5891]
* [RFC 5895]
* [Unicode TR 46]
## Scope
This specification only tests and creates a normalized form of the domain name
(zone name or name server name).
In this specification, ASCII is identical to the first 128 characters in
[Unicode] (0000..007F).
[RFC 1123][RFC 1123#2.1], section 2.1, specifies that a domain name label
may not start or end with a HYPHEN-MINUS ("-"), only digit or letter. This
restriction on HYPHEN-MINUS is disregarded in this specification and is assumed
to be handled in test case [Syntax02].
The use of the SOLIDUS ("/") and the LOW LINE ("_") in domain name is discussed
in the section "[ASCII domain name](#ascii-domain-name)" below. Any restrictions
on where in the domain name or label those could or should be used are
disregarded in this specification, and are assumed to be handled in test cases
[Syntax01] and [Syntax02].
## Inputs
* "Domain Name" - The domain name to be tested and normalized according to this
specification. It must be a non-empty string of [Unicode] characters.
## Summary
In the specification there are six scenarios that will result in the domain name
not being usable, i.e. it cannot be used for Zonemaster testing. Each scenario
is here listed with a message tag, level (always CRITICAL in this specification),
suitable argument to be used in the same descriptive message and a message that
can be returned to the user.
Message Tag | Level | Arguments | Message ID for message tag
:------------------------------|:---------|:-------------|:----------------------------------------------------------
AMBIGUOUS_DOWNCASING | CRITICAL | unicode_name | Ambiguous downcasing of character "{unicode_name}" in the domain name. Use all lower case instead.
DOMAIN_NAME_TOO_LONG | CRITICAL | | Domain name is too long (more than 253 characters with no final dot).
EMPTY_DOMAIN_NAME | CRITICAL | | Domain name is empty.
INITIAL_DOT | CRITICAL | | Domain name starts with dot.
INVALID_ASCII | CRITICAL | label | Domain name has an ASCII label ("{label}") with a character not permitted.
INVALID_U_LABEL | CRITICAL | label | Domain name has a non-ASCII label ("{label}") which is not a valid U-label.
LABEL_TOO_LONG | CRITICAL | label | Domain name has a label that is too long (more than 63 characters), "{label}".
REPEATED_DOTS | CRITICAL | | Domain name has repeated dots.
The value in the Level column is the default severity level of the message. 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
Tables 1, 2, 3 and 4 are found in the [Detailed requirements] section below.
1. Create the following sets
1. Set of permitted ASCII characters in Table 1 below ("Valid ASCII").
2. Set of Unicode white space characters in Table 3 below ("White Space")
3. Set of Unicode full stops (dot characters) in Table 4 below
("Unicode Full Stops").
2. This step only applies if removal of leading and trailing spaces has been
found to be appropriate for the client and context.
1. If *Domain Name* starts with one or more of *White Space* then those are
removed from *Domain Name* before further processing.
2. If *Domain Name* ends with one or more of *White Space* then those are
removed from *Domain Name* before further processing.
3. If *Domain Name* is an empty string then output *[EMPTY_DOMAIN_NAME]* and
terminate these test procedures.
4. If *Domain Name* contains [LATIN CAPITAL LETTER I WITH DOT ABOVE] then:
1. Output *[AMBIGUOUS_DOWNCASING]* and the Unicode name of the code point in
question.
2. Terminate these test procedures.
5. Create an empty, ordered list of labels ("Domain Labels").
6. Replace all instances of character from *Unicode Full Stops* in *Domain Name*
with the label separating, regular dot U+002E (see Table 2).
7. If *Domain Name* is the root zone, i.e. the exact string "." (U+002E), then
terminate these test procedures with no message tags.
8. If *Domain Name* starts with dot (".", U+002E) then output
*[INITIAL_DOT]* and terminate these test procedures.
9. If *Domain Name* has any instance of two or more consecutive dots (".",
U+002E) then output *[REPEATED_DOTS]* and terminate these test
procedures.
10. Remove trailing dot (".", U+002E) from *Domain Name*.
11. Split *Domain Name* into labels by dot "." (U+002E) and put them in the same
order in *Domain Labels*.
12. For each "Label" in *Domain Labels* do:
1. If all characters in *Label* are ASCII characters, then do:
1. If any character in *Label* is not listed in *Valid ASCII*, then output
*[INVALID_ASCII]* and *Label*, and terminate these test procedures.
2. Else, downcase all upper case characters as specified in section
"[Upper case](#upper-case)" below.
2. Else do:
1. Assume that *Label* is a U-label.
2. Downcase all upper case characters as specified in section
"[Upper case](#upper-case)" below.
3. Normalize *Label* to NFC as specified in [Unicode TR 15]. Also see
section "[Unicode normalization](#unicode-normalization)" below.
3. Convert *Label* to an A-label as specified by [IDNA2008].
1. If the conversion failed, then output *[INVALID_U_LABEL]*
and *Label*, and terminate these test procedures.
2. Else, replace the U-label in *Domain Labels* with the A-label from
the conversion above.
3. Go to next label.
13. For each "Label" in *Domain Labels* do:
1. If the length (number of characters) in *Label* is greater than 63 then
output *[LABEL_TOO_LONG]* and *Label*, and terminate these test
procedures.
14. Map the labels in *Domain Labels* back into *Domain Name* with one dot (".",
U+002E), between the labels (no dots if the there is only one label).
15. If the length of *Domain Name* is longer than 253 characters including the
dots, then output *[DOMAIN_NAME_TOO_LONG]* and terminate these test
procedures.
## Outcome(s)
The outcome of the tests in this specification consists of three parts
1. The outcome value as defined below in this section.
2. The message tags, if any, and data connected to the message tags, if any.
3. *Domain Name* in the normalized form to be used as input value for all test
cases. If the outcome value is "fail" then no *Domain Name* is
returned.
The outcome value of this specification is "fail" if there is at least one
message outputted. In other cases it is "pass".
## Special procedural requirements
The tests and normalizations defined in this specification must always be run
and evaluated before any Zonemaster test case is run.
If the outcome from this specification is "fail", then no test cases should be
run.
## Detailed requirements
This section describes the requirements on the domain name. Besides ensuring
that the domain name is valid, these requirements also ensure that the domain
name is used in a normalized form.
### ASCII domain name
An ASCII domain name is valid if it follows the rules defined in
[RFC 1123][RFC 1123#2.1], section 2.1, i.e. only consists of the ASCII characters
"a-z", "A-Z", "0-9", "." and "-" with the extension of the following two
characters:
1. The LOW LINE (underscore, "_") character standardized for e.g. SRV records
([RFC 2782]) and other record types and special names.
2. The SOLIDUS (forward slash, "/") used in reverse zone names for IPv4 networks
smaller than /24. See examples in [RFC 2317][RFC 2317#4], section 4.
In ASCII names, upper case A-Z are treated as equal to a-z
([RFC 1034][RFC 1034#3.1], section 3.1 and [RFC 1035][RFC 1035#2.3.3], section
2.3.3). The regular dot, or [FULL STOP] ("."), is used as label separator
([RFC 1034][RFC 1034#3.1], section 3.1). Also see Table 2 below.
*Table 1: A summary of the valid ASCII characters in labels using [Unicode]
codes.*
Unicode code or code range | Character or character range | Comment
:--------------------------|:-----------------------------|:--------------------
0061..007A | a-z |
0041..005A | A-Z | Upper case of a-z
0030..0039 | 0-9 |
U+002D | - | [HYPHEN-MINUS]
U+002F | / | [SOLIDUS] (forward slash)
U+005F | _ | [LOW LINE] (underscore)
*Table 2: A summary of the valid ASCII character between labels using [Unicode]
codes.*
Unicode code | Character | Comment
:------------|:----------|:--------------------
U+002E | . | [FULL STOP] (in this document referred to as "dot")
The fact that "." (U+002E) character is the delimiter between labels puts some
limitations on its use. The first label cannot be en empty label unless that is
the only label, i.e. the root domain name. With that exception (covered below) a
domain name cannot have a "." (dot) initially. Only the last label can be an
empty label (the root label), which means that there cannot be two or more
consecutive "." (dots) in a valid domain name. The domain name, as entered to
Zonemaster, can either have a final dot or not, and will be normalized as
described below.
### IDN name
A valid IDN name is a domain named where one or more labels are valid IDN label
([RFC 5890][RFC 5890#2.3.2.3]) and the remaining labels are valid ASCII labels as
defined above. An IDN label can be an A-label or a U-label
([RFC 5890][RFC 5890#2.3.2.1], section 2.3.2.1).
* A valid IDN name where all IDN labels are A-labels will automatically meet the
ASCII name requirements above given that the non-IDN labels meet them.
* A valid IDN name with one or more U-labels can be converted to a valid IDN name
where all IDN labels are A-labels.
A valid ASCII name is, by definition, encoded in ASCII. A valid IDN name must
either be encoded in ASCII (no U-labels) or in UTF-8 (at least one U-label). If
not, Zonemaster will not be able to process the domain name. Note that ASCII is a
subset of UTF-8.
A valid ASCII name consists, by definition, of only ASCII characters. A valid IDN
name must either consists of only ASCII characters (no U-labels, only A-labels)
or consist of at least one non-ASCII Unicode character in at least one label,
i.e. at least one U-label. U-labels and A-labels can be mixed, and IDN labels can
be mixed with non-IDN labels.
### Length limitations
There is a maximum length for the whole domain name and a maximum length for each
label. These limitations are defined for a domain name of ASCII characters only,
which means that any IDN U-label must be converted to the equivalent A-label
before the limitations can be checked.
The maximum total length of a domain name is 253 characters (or octets) if it
has no final dot, 254 with the final dot ([RFC 1035][RFC 1035#2.3.4], section
2.3.4). Note that he RFC defines the limit as 255 octets, but that is the
limitation in the DNS packet, where labels separation is done differently.
The maximum length of a label is 63 characters (or octets),
[RFC 1035][RFC 1035#2.3.4], section 2.3.4. A label must be at least one character
(octet) long unless it is the label representing the root domain name, which is
zero in length and always after the final dot.
### Root zone
If the root zone is to be tested, then it must be represented as a single dot "."
and in no other way. The label that represents the root zone is an empty label
after the dot.
### Creating IDNA2008 compatible format
For a discussion on pre-processing the domain name to achieve IDNA compatible
U-label from convenient alternative forms see [RFC 5895]. Unicode normalization
is covered by [RFC 5891] and [Unicode TR 15]
#### Unicode normalization
For Unicode strings normalization processes have been defined to make convert
different representations into a normalized form. Specifically, it is required
that an IDN label ([IDNA2008]) is in the so called "Normalized Form C" (NFC) as
of [RFC 5891][RFC 5891#5.2], section 5.2.
For ASCII domain names NFC is no issue since they are always in NFC format. For
an IDN name the situation is different. The letter "ö" in the IDN domain name
"malmö.se" can be represented as either the single Unicode code point U+00F6 or
as the Unicode code point sequence "006F 0308". Only the former is in NFC form,
which means that if the domain name is entered with the sequence it must be
preprocessed before entering [IDNA2008] processing, i.e. conversion to A-label
format. See [Unicode TR 15] for a specification of Unicode normalization and more
examples relevant to domain names.
Zonemaster (this specification) requires that any domain name must be converted
to NFC form before conversion to A-label. However, the domain name is entered in
A-label format, this specification does not require that the corresponding
U-label is in NFC format.
#### White space
In the user interface there may be a risk that leading or trailing white space
characters are added to the domain name by mistake. The domain name will in this
specification be normalized by removing such characters if appropriate for the
client and context. In Table 3 it is specified what counts as white space
characters. It should be pointed out that white space characters within the
domain name are not removed, and in the end count as invalid characters.
*Table 3: White space characters**
Unicode code | Name
:------------|:--------------------
U+0020 | [SPACE]
U+0009 | [CHARACTER TABULATION]
U+00A0 | [NO-BREAK SPACE]
U+2000 | [EN QUAD]
U+2001 | [EM QUAD]
U+2002 | [EN SPACE]
U+2003 | [EM SPACE]
U+2004 | [THREE-PER-EM SPACE]
U+2005 | [FOUR-PER-EM SPACE]
U+2006 | [SIX-PER-EM SPACE]
U+2007 | [FIGURE SPACE]
U+2008 | [PUNCTUATION SPACE]
U+2009 | [THIN SPACE]
U+200A | [HAIR SPACE]
U+205F | [MEDIUM MATHEMATICAL SPACE]
U+3000 | [IDEOGRAPHIC SPACE]
U+1680 | [OGHAM SPACE MARK]
#### Full stop
The regular dot "." expected in domain names is a U+002E (FULL STOP), see Table 2
above. There are other characters that may be entered instead due to the script
setting. Table 4 lists full stop characters that are to be mapped into the
ASCII FULL STOP ([Unicode TR 46][Unicode TR 46#Notation], section 2.3). That
mapping must be done before any verification or checks of the dot and before
splitting *Domain Name* into labels.
*Table 4: Non-ASCII dots (Full Stops) using [Unicode] codes*
Unicode code | Character | Name
:------------|:----------|:--------------------
U+FF0E | | [FULLWIDTH FULL STOP]
U+3002 | 。 | [IDEOGRAPHIC FULL STOP]
U+FF61 | 。 | [HALFWIDTH IDEOGRAPHIC FULL STOP]
#### Final dot
If the domain name has one final dot it should be removed to create a consistent
representation. The exception is the root zone which is always represented by
the exact string ".".
#### Upper case
If the domain name has any letters tagged as "upper case" by the [Unicode]
database, those should be mapped into the equivalent lower case letter. This
applies to both ASCII (i.e. "A-Z" mapped into "a-z") in both A- and U-labels and
non-ASCII characters found in U-labels ([RFC 5895][RFC 5895#2], section 2). This
mapping is done before a U-label is converted to A-label. A valid U-label must
not contain any upper case letters.
For Zonemaster special rules applies to U+0049 ([LATIN CAPITAL LETTER I]) and
U+0130 ([LATIN CAPITAL LETTER I WITH DOT ABOVE]).
* [LATIN CAPITAL LETTER I] is downcased to U+0069 ([LATIN SMALL LETTER I]) also
in Turkish and Azeri locale, i.e. not following the special Unicode rule in
those locale ([Unicode SpecialCasing]).
* Label with [LATIN CAPITAL LETTER I WITH DOT ABOVE] should be rejected since
normal downcasing gives a sequence not reasonable in a domain name context (see
"Lowercase Mapping" in [LATIN CAPITAL LETTER I WITH DOT ABOVE]).
#### A-label and U-label
DNS can only handle A-labels, not U-label. In the test core suite of Zonemaster
only A-labels are used. For normalization, all U-labels are converted to
A-labels. Test cases will only handle an ASCII-only *Domain Name*. Conversion
from U-label to A-label should be done as specified for [IDNA2008],
not IDNA2003.
## Terminology
No special terminology for this specification.
[AMBIGUOUS_DOWNCASING]: #summary
[Argument list]: ArgumentsForTestCaseMessages.md
[CHARACTER TABULATION]: https://codepoints.net/U+0009
[DOMAIN_NAME_TOO_LONG]: #summary
[Detailed requirements]: #detailed-requirements
[EM QUAD]: https://codepoints.net/U+2001
[EM SPACE]: https://codepoints.net/U+2003
[EMPTY_DOMAIN_NAME]: #summary
[EN QUAD]: https://codepoints.net/U+2000
[EN SPACE]: https://codepoints.net/U+2002
[FIGURE SPACE]: https://codepoints.net/U+2007
[FOUR-PER-EM SPACE]: https://codepoints.net/U+2005
[FULL STOP]: https://codepoints.net/U+002E
[FULLWIDTH FULL STOP]: https://codepoints.net/U+FF0E
[HAIR SPACE]: https://codepoints.net/U+200A
[HALFWIDTH IDEOGRAPHIC FULL STOP]: https://codepoints.net/U+FF61
[HYPHEN-MINUS]: https://codepoints.net/U+002D
[IDEOGRAPHIC FULL STOP]: https://codepoints.net/U+3002
[IDEOGRAPHIC SPACE]: https://codepoints.net/U+3000
[IDNA2008]: https://datatracker.ietf.org/doc/html/rfc5890#section-1.1
[INITIAL_DOT]: #summary
[INVALID_ASCII]: #summary
[INVALID_U_LABEL]: #summary
[LABEL_TOO_LONG]: #summary
[LATIN CAPITAL LETTER I WITH DOT ABOVE]: https://codepoints.net/U+0130
[LATIN CAPITAL LETTER I]: https://codepoints.net/U+0049
[LATIN SMALL LETTER DOTLESS I]: https://codepoints.net/U+0131
[LATIN SMALL LETTER I]: https://codepoints.net/U+0069
[LOW LINE]: https://codepoints.net/U+005F
[MEDIUM MATHEMATICAL SPACE]: https://codepoints.net/U+205F
[NO-BREAK SPACE]: https://codepoints.net/U+00A0
[OGHAM SPACE MARK]: https://codepoints.net/U+1680
[PUNCTUATION SPACE]: https://codepoints.net/U+2008
[REPEATED_DOTS]: #summary
[RFC 1034#3.1]: https://datatracker.ietf.org/doc/html/rfc1034#section-3.1
[RFC 1034]: https://datatracker.ietf.org/doc/html/rfc1034
[RFC 1035#2.3.3]: https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.3
[RFC 1035#2.3.4]: https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.4
[RFC 1035]: https://datatracker.ietf.org/doc/html/rfc1035
[RFC 1123#2.1]: https://datatracker.ietf.org/doc/html/rfc1123#section-2.1
[RFC 1123]: https://datatracker.ietf.org/doc/html/rfc1123
[RFC 2317#4]: https://datatracker.ietf.org/doc/html/rfc2317#section-4
[RFC 2317]: https://datatracker.ietf.org/doc/html/rfc2317
[RFC 2782]: https://datatracker.ietf.org/doc/html/rfc2782
[RFC 5890#1.1]: https://datatracker.ietf.org/doc/html/rfc5890#section-1.1
[RFC 5890#2.3.2.1]: https://datatracker.ietf.org/doc/html/rfc5890#section-2.3.2.1
[RFC 5890#2.3.2.3]: https://datatracker.ietf.org/doc/html/rfc5890#section-2.3.2.3
[RFC 5890]: https://datatracker.ietf.org/doc/html/rfc5890
[RFC 5891#5.2]: https://www.rfc-editor.org/rfc/rfc5891#section-5.2
[RFC 5891]: https://www.rfc-editor.org/rfc/rfc5891
[RFC 5895#2]: https://datatracker.ietf.org/doc/html/rfc5895#section-2
[RFC 5895]: https://datatracker.ietf.org/doc/html/rfc5895
[SIX-PER-EM SPACE]: https://codepoints.net/U+2006
[SOLIDUS]: https://codepoints.net/U+002F
[SPACE]: https://codepoints.net/U+0020
[Severity Level Definitions]: SeverityLevelDefinitions.md
[Syntax01]: Syntax-TP/syntax01.md
[Syntax02]: Syntax-TP/syntax02.md
[THIN SPACE]: https://codepoints.net/U+2009
[THREE-PER-EM SPACE]: https://codepoints.net/U+2004
[Unicode SpecialCasing]: https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt
[Unicode TR 15]: https://unicode.org/reports/tr15/
[Unicode TR 46#Notation]: http://unicode.org/reports/tr46/#Notation
[Unicode TR 46]: http://unicode.org/reports/tr46/
[Unicode]: https://unicode.org/main.html
[Zonemaster-Engine profile]: ../../configuration/profiles.md

View File

@@ -0,0 +1,82 @@
# Severity Level Definitions
The following severity levels are defined to be assigned to test result messages, one
at a time, and below it is specified what they intend to mean.
* CRITICAL
* ERROR
* WARNING
* NOTICE
* INFO
* DEBUG
* DEBUG2
* DEBUG3
## CRITICAL
A result at level CRITICAL means that the zone being tested has one or more problems
that are so severe that it is not possible to even test it. Examples can be that the
name requested is not syntactically possible, that it's situated under a domain that
does not exist, or that none of its nameservers are responding.
A zone with one or more CRITICAL errors can reasonably be said not to exist.
## ERROR
A result at level ERROR means a problem that is very likely (or possibly certain) to
negatively affect the function of the zone being tested, but not so severe that the
entire zone becomes unresolvable. Examples of ERROR level problems are nameservers
that do not respond to queries over TCP, only having a single nameserver and using a
reserved algorithm for DNSKEY records.
## WARNING
A result at level WARNING means something that will under some circumstances be a
problem, but that is unlikely to be noticed by a casual user. Problems at this level
may be an extra nameserver listed at the parent side, or unsuitable time values in a
SOA record.
## NOTICE
A result at level NOTICE means something that should be known by the zone's
administrator but that need not necessarily be a problem at all. An example of this
can be that different name servers for the zone reports slightly different SOA serial
numbers, which is a perfectly natural consequence of propagation delays but that the
admin should be aware of.
## INFO
A result at level INFO is something that may be of interest to the zone's administrator
but that definitely does not indicate a problem. Examples of this can be name server
software versions, the fact that the zone uses DNSCurve encryption or that a name server
does not recurse.
## DEBUG
Results at level DEBUG are related to the zone being tested, but not normally of
interest to anyone. Implementors of tests are encouraged to be generous with the
production of these messages. Examples can be that a test section started running, that
an ordinary action performed as expected or that a value was inside its normal range.
## DEBUG2
Results at level DEBUG2 are produced by the testing framework itself, and are intended
to only be displayed when trying to identify and diagnose unusual and hard to understand
problems in a zone. This level includes at least one line of information for every DNS
query sent and response received.
## DEBUG3
Results at level DEBUG3 have all the same attributes as those for DEBUG2, and are
even more voluminous. At this level, full string representations of all received
DNS packets will be included. At the time of writing, a test run for the same domain
produces about fifty times as much output on level DEBUG3 as it does on level DEBUG
and a thousand times as much as on the default NOTICE level.

View File

@@ -0,0 +1,25 @@
# Syntax Test Plan
These are tests of the syntax of different labels in DNS, such as domain
names and host names.
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|
|:---------|:--------------------|
|[SYNTAX01](syntax01.md)|No illegal characters in the domain name|
|[SYNTAX02](syntax02.md)|No hyphen ('-') at the start or end of the domain name|
|[SYNTAX03](syntax03.md)|There must be no double hyphen ('--') in position 3 and 4 of the domain name|
|[SYNTAX04](syntax04.md)|The NS name must have a valid domain/hostname|
|[SYNTAX05](syntax05.md)|Misuse of '@' character in the SOA RNAME field|
|[SYNTAX06](syntax06.md)|No illegal characters in the SOA RNAME field|
|[SYNTAX07](syntax07.md)|No illegal characters in the SOA MNAME field|
|[SYNTAX08](syntax08.md)|MX name must have a valid hostname|

View File

@@ -0,0 +1,38 @@
## SYNTAX01: No illegal characters in the domain name
### Test case identifier
**SYNTAX01** No illegal characters in the domain name
### Objective
There must be no illegal characters used in the domain name.
The domain name must follow the rules defined in section 2.3.1 of
[RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035),
section 2.1 of [RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123#section-2.1),
section 11 of
[RFC 2182](https://datatracker.ietf.org/doc/html/rfc2181#section-11) and section 2 of
[RFC 3696](https://datatracker.ietf.org/doc/html/rfc3696#section-2).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. The domain name of the test object is used as the input for the
validation.
2. Check for characters that are not allowed in the domain name according
to the rules defined in section 2.3.1 of
[RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035).
### Outcome(s)
If there are any invalid characters in the domain name, this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,34 @@
## SYNTAX02: No hyphen ('-') at the start or end of the domain name
### Test case identifier
**SYNTAX02** No hyphen ('-') at the start or end of the domain name
### Objective
There must be no hyphen ('-') at the start or end of the domain name.
The domain name must follow the rules defined in section 2.3.1 of [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035),
section 2.1 of [RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123#section-2.1), section 11 of
[RFC 2182](https://datatracker.ietf.org/doc/html/rfc2181#section-11) and section 2 of
[RFC 3696](https://datatracker.ietf.org/doc/html/rfc3696#section-2).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Each label of the domain name of the test object is used as the input for the validation.
2. If any label in the domain name start with a hyphen ('-') this test case fails.
3. If any label in the domain name ends with a hyphen ('-') this test case fails.
### Outcome(s)
If any label in the domain name start or ends with a hyphen ('-') this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,38 @@
## SYNTAX03: There must be no double hyphen ('--') in position 3 and 4 of the domain name
### Test case identifier
**SYNTAX02** No double hyphen ('--') in position 3 and 4 of the domain name
### Objective
There must be no double hyphen ('--') in position 3 and 4 of the domain name,
unless the domain name has the prefix 'xn--' which is used for
internationalization.
See section 5 of [RFC 3696](https://datatracker.ietf.org/doc/html/rfc3696#section-5),
"Implications of internationalization".
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Each label of the domain name of the test object is used as the input
for the validation.
2. If any label in the domain name contains hyphens ('-') in position 3 and 4,
go to next step.
3. Unless the prefix is 'xn', this test case fails.
### Outcome(s)
If any label in the domain name has a hyphen in position 3 and 4 of the label
and the prefix is not 'xn', this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,46 @@
## SYNTAX04: The NS name must have a valid domain/hostname
### Test case identifier
**SYNTAX04** The NS name must have a valid domain/hostname
### Objective
The Name Server name must be a valid hostname according to the rules defined
in [RFC 952](https://datatracker.ietf.org/doc/html/rfc952),
in section 2.1 in [RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123#section-2.1),
section 11 in [RFC 2182](https://datatracker.ietf.org/doc/html/rfc2181#section-11) and
section 2 and 5 in [RFC 3696](https://datatracker.ietf.org/doc/html/rfc3696#section-2).
Newer RFCs may override some rules defined in earlier documents.
### Inputs
The hostname to be tested. The hostnames comes from all the nameservers
used, from both the parent and the zone itself.
### Ordered description of steps to be taken to execute the test case
1. Obtain the list of name server hostnames from [Method2](../Methods.md) and
[Method3](../Methods.md)
(This is all the name servers from the parent delegation, and all the
name servers in the apex of the zone itself.)
2. Each label of the hostname of the test object is used as the input
for the validation.
3. If any label in the hostname does not contain a-z or 0-9 this test case
fails.
4. If the rightmost label (the TLD) contains only digits, this test case
fails.
5. If there is a hyphen ('-') in position 3 and 4 of the label, and the prefix
is not xn (used for internationalization), this test case fails.
### Outcome(s)
If any of the steps 3 to 5 in the ordered description of this test case fails,
the whole test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,41 @@
## SYNTAX05: Misuse of '@' character in the SOA RNAME field
### Test case identifier
**SYNTAX05** There must be no misused '@' character in the SOA RNAME field
### Objective
The SOA RNAME field does not allow the '@' characters to be used for
describing a mailbox. The first dot ('.') is thus translated into the
'@' character. This is a common mistake. The rules are defined in
[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 a set of name server IP addresses using [Method4] and [Method5].
2. Create a SOA query for the zone.
3. Send the SOA query over UDP to each name server IP address until a
response is received or until the set is exhausted.
4. Check if the RNAME field contains a '@' character.
### Outcome(s)
If there is any '@' character in any SOA/RNAME field, this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
The de-escaped output from this test is used by [SYNTAX08](syntax08.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

View File

@@ -0,0 +1,163 @@
# SYNTAX06: No illegal characters in the SOA RNAME field
## Test case identifier
**SYNTAX06**
## Objective
The SOA RNAME field is a mailbox address. The SOA RNAME field is defined
in [RFC 1035][RFC 1035#3.3.13], section 3.3.13 and in
[RFC 1912][RFC 1912#2.2], section 2.2. The RNAME
field should follow the rules of an e-mail address also defined in
[RFC 5322][RFC 5322#3.4.1], section 3.4.1.
## 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 IP addresses using [Method4] and [Method5]
("NS IP").
2. Create a SOA query for the apex of the *Child Zone* with RD flag unset.
3. For each name server IP in *NS IP* do:
1. Send the SOA query over UDP to the name server IP.
2. If the name server does not respond with a DNS response, then:
1. Output *[NO_RESPONSE]*.
2. Go to next name server IP.
3. If the DNS response does not include an SOA record in the
answer section, then:
1. Output *[NO_RESPONSE_SOA_QUERY]*.
2. Go to next name server IP.
4. Extract the RNAME from the SOA record (from the first SOA record if
multiple) and convert it to an email address ("Email Address" below)
using the following steps:
1. Convert the first "." without backslash quoting to an "@" in
the RNAME.
2. Convert any backslash quoted "." to a single "." without quoting
(see [RFC 1035], section [5.1][RFC 1035#5.1], [5.3][RFC 1035#5.3] and
[8][RFC 1035#8] for the use of backslash).
7. If *Email Address* does not meet the
mail address specification in [RFC 5322][RFC 5322#3.4.1],
section 3.4.1, then
1. Output *[RNAME_RFC822_INVALID]*.
2. Go to next name server IP.
8. Extract the domain part (to the right of "@") from the *Mail
address* ("Domain Part" below).
9. Create an MX query for the *Domain Part* and do a
[DNS Lookup][terminology] of that query.
10. If the lookup of MX does not return a DNS response with RCODE
"NOERROR", then:
1. Output *[RNAME_MAIL_DOMAIN_INVALID]*.
2. Go to next name server IP.
11. When doing the MX lookup, CNAME or a chain of CNAMEs are followed, if
any. If an MX record or records are found via CNAME, then
set *Domain Part* to be equal to the owner name of that MX record
(instead of being equal to the domain part of *Email Address*).
12. If the MX lookup returned a NO DATA response (no MX record),
then:
1. Create address queries (A and AAAA) for the *Domain Part* and
do:
1. Do [DNS Lookups][terminology] of those queries.
2. If the answer section contains a CNAME record output
*[RNAME_MAIL_ILLEGAL_CNAME]*.
3. Else, extract any A and AAAA records from the answer
sections of the DNS responses with *Domain Part* as owner
name.
2. If any A or AAAA record points at 127.0.0.1 or ::1 (localhost),
respectively, then output *[RNAME_MAIL_DOMAIN_LOCALHOST]*.
3. If no A or AAAA are extracted or any records points at
127.0.0.1 or ::1, then output *[RNAME_MAIL_DOMAIN_INVALID]*.
13. If the MX lookup returns one or more MX records, then for each
MX record extract the domain name in RDATA ("Mail Exchange")
and do:
1. Create address queries (A and AAAA) of *Mail Exchange* and do:
1. Do [DNS Lookups][terminology] of those queries.
2. If the answer section contains a CNAME record output
*[RNAME_MAIL_ILLEGAL_CNAME]*.
3. Else, extract any A and AAAA records from the answer
sections of the DNS responses with *Mail Exchange* as owner
name.
2. If any A or AAAA record points at 127.0.0.1 or ::1 (localhost),
respectively, then output *[RNAME_MAIL_DOMAIN_LOCALHOST]*.
3. If no A or AAAA are extracted or any records points at
127.0.0.1 or ::1, then output *[RNAME_MAIL_DOMAIN_INVALID]*.
4. If at least one name server IP has neither outputted *[NO_RESPONSE]*
nor *[NO_RESPONSE_SOA_QUERY]* and *[RNAME_MAIL_DOMAIN_INVALID]* has not
been outputted for any name server IP, then output *[RNAME_RFC822_VALID]*.
## 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_SOA_QUERY | DEBUG
RNAME_RFC822_INVALID | WARNING
RNAME_MAIL_DOMAIN_INVALID | WARNING
RNAME_MAIL_DOMAIN_LOCALHOST | WARNING
RNAME_MAIL_ILLEGAL_CNAME | WARNING
RNAME_RFC822_VALID | 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
* "Using Method" - When the term is used, names and IP addresses are fetched
using the defined [Methods].
* "Send" (to an IP address) - The term is used when a DNS query is sent to
a specific name server.
* "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.
[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
[Methods]: ../Methods.md
[NO_RESPONSE]: #outcomes
[NO_RESPONSE_SOA_QUERY]: #outcomes
[RFC 1035#3.3.13]: https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.13
[RFC 1035#5.1]: https://datatracker.ietf.org/doc/html/rfc1035#section-5.1
[RFC 1035#5.3]: https://datatracker.ietf.org/doc/html/rfc1035#section-5.3
[RFC 1035#8]: https://datatracker.ietf.org/doc/html/rfc1035#section-8
[RFC 1035]: https://datatracker.ietf.org/doc/html/rfc1035
[RFC 1912#2.2]: https://datatracker.ietf.org/doc/html/rfc1912#section-2.2
[RFC 5322#3.4.1]: https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1
[RNAME_MAIL_DOMAIN_INVALID]: #outcomes
[RNAME_MAIL_DOMAIN_LOCALHOST]:#outcomes
[RNAME_MAIL_ILLEGAL_CNAME]: #outcomes
[RNAME_RFC822_INVALID]: #outcomes
[RNAME_RFC822_VALID]: #outcomes
[terminology]: #terminology
[undelegated test]: ../../test-types/undelegated-test.md

View File

@@ -0,0 +1,47 @@
## SYNTAX07: No illegal characters in the SOA MNAME field
### Test case identifier
**SYNTAX07** There must be no illegal characters in the SOA MNAME field
### Objective
The SOA MNAME field is a hostname. Hostnames are valid according to the
rules defined in [RFC 952](https://datatracker.ietf.org/doc/html/rfc952),
in section 2.1 in [RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123#section-2.1),
section 11 in [RFC 2182](https://datatracker.ietf.org/doc/html/rfc2181#section-11) and
section 2 and 5 in [RFC 3696](https://datatracker.ietf.org/doc/html/rfc3696#section-2).
Newer RFCs may override some rules defined in earlier documents.
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve the SOA record from the zone being tested.
2. Get the MNAME from the SOA record.
3. Each label of the hostname of the test object is used as the input
for the validation.
4. If any label in the hostname does not contain a-z or 0-9 this test case
fails.
5. If any label of the hostname is longer than 63 characters, this test case
fails.
6. If the hostname is longer than 255 characters including separators, this
test case fails.
7. If the rightmost label (the TLD) contains only digits, this test case
fails.
8. If there is a hyphen ('-') in position 3 and 4 of the label, and the prefix
is not xn (used for internationalization), this test case fails.
### Outcome(s)
If any of the steps 4 to 8 in the ordered description of this test case fails,
the whole test case fails.
### Special procedural requirements
None.
### Intercase dependencies
This test case uses the same host name validator as test case [SYNTAX04](syntax04.md).

View File

@@ -0,0 +1,49 @@
## SYNTAX08: MX name must have a valid hostname
### Test case identifier
**SYNTAX08** The MX record name must be a valid hostname
### Objective
The MX record names used for delivering mail for a domain name address
must be valid hostnames according to the rules defined in
[RFC 952](https://datatracker.ietf.org/doc/html/rfc952),
in section 2.1 in [RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123#section-2.1),
section 11 in [RFC 2182](https://datatracker.ietf.org/doc/html/rfc2181#section-11) and
section 2 and 5 in [RFC 3696](https://datatracker.ietf.org/doc/html/rfc3696#section-2).
Newer RFCs may override some rules defined in earlier documents. The MX
records use of "Domain Names" is described in section 2.3.5 of
[RFC 5321](https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.5).
### Inputs
The hostnames to be tested. The hostnames comes from looking up the MX record
for the domain being tested.
### Ordered description of steps to be taken to execute the test case
1. Query for the MX record of the domain name.
2. For each hostname of the MX records found:
3. If any label in the hostname does not contain a-z or 0-9 this test case
fails.
4. If any label of the hostname is longer than 63 characters, this test case
fails.
5. If the hostname is longer than 255 characters including separators, this
test case fails.
6. If the rightmost label (the TLD) contains only digits, this test case
fails.
7. If there is a hyphen ('-') in position 3 and 4 of the label, and the prefix
is not xn (used for internationalization), this test case fails.
### Outcome(s)
If any of the steps 3 to 7 in the ordered description of this test case fails,
the whole test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,620 @@
<!-- File generated by generateTestMessages.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.-->
# Mapping test messages to Test Cases
Index of Text Cases are found in [README](README.md).
| Message tag from [Zonemaster-Engine] | Module | Method (implemented test case) |
|:-------------------------------------|:-------|:-------------------------------|
| A01_ADDR_NOT_GLOBALLY_REACHABLE | [Address](Address-TP/README.md) | [address01](Address-TP/address01.md) |
| A01_DOCUMENTATION_ADDR | [Address](Address-TP/README.md) | [address01](Address-TP/address01.md) |
| A01_GLOBALLY_REACHABLE_ADDR | [Address](Address-TP/README.md) | [address01](Address-TP/address01.md) |
| A01_LOCAL_USE_ADDR | [Address](Address-TP/README.md) | [address01](Address-TP/address01.md) |
| A01_NO_GLOBALLY_REACHABLE_ADDR | [Address](Address-TP/README.md) | [address01](Address-TP/address01.md) |
| A01_NO_NAME_SERVERS_FOUND | [Address](Address-TP/README.md) | [address01](Address-TP/address01.md) |
| NAMESERVERS_IP_WITH_REVERSE | [Address](Address-TP/README.md) | [address02](Address-TP/address02.md) |
| NAMESERVER_IP_WITHOUT_REVERSE | [Address](Address-TP/README.md) | [address02](Address-TP/address02.md) |
| NO_RESPONSE_PTR_QUERY | [Address](Address-TP/README.md) | [address02](Address-TP/address02.md) |
| TEST_CASE_END | [Address](Address-TP/README.md) | [address02](Address-TP/address02.md) |
| TEST_CASE_START | [Address](Address-TP/README.md) | [address02](Address-TP/address02.md) |
| NAMESERVER_IP_PTR_MATCH | [Address](Address-TP/README.md) | [address03](Address-TP/address03.md) |
| NAMESERVER_IP_PTR_MISMATCH | [Address](Address-TP/README.md) | [address03](Address-TP/address03.md) |
| NAMESERVER_IP_WITHOUT_REVERSE | [Address](Address-TP/README.md) | [address03](Address-TP/address03.md) |
| NO_RESPONSE_PTR_QUERY | [Address](Address-TP/README.md) | [address03](Address-TP/address03.md) |
| TEST_CASE_END | [Address](Address-TP/README.md) | [address03](Address-TP/address03.md) |
| TEST_CASE_START | [Address](Address-TP/README.md) | [address03](Address-TP/address03.md) |
| B01_CHILD_FOUND | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_CHILD_IS_ALIAS | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_INCONSISTENT_ALIAS | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_INCONSISTENT_DELEGATION | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_NO_CHILD | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_PARENT_DISREGARDED | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_PARENT_FOUND | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_PARENT_NOT_FOUND | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_PARENT_UNDETERMINED | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_ROOT_HAS_NO_PARENT | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B01_SERVER_ZONE_ERROR | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| TEST_CASE_END | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| TEST_CASE_START | [Basic](Basic-TP/README.md) | [basic01](Basic-TP/basic01.md) |
| B02_AUTH_RESPONSE_SOA | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| B02_NO_DELEGATION | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| B02_NO_WORKING_NS | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| B02_NS_BROKEN | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| B02_NS_NOT_AUTH | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| B02_NS_NO_IP_ADDR | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| B02_NS_NO_RESPONSE | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| B02_UNEXPECTED_RCODE | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| IPV4_DISABLED | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| IPV4_ENABLED | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| IPV6_DISABLED | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| IPV6_ENABLED | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| TEST_CASE_END | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| TEST_CASE_START | [Basic](Basic-TP/README.md) | [basic02](Basic-TP/basic02.md) |
| A_QUERY_NO_RESPONSES | [Basic](Basic-TP/README.md) | [basic03](Basic-TP/basic03.md) |
| HAS_A_RECORDS | [Basic](Basic-TP/README.md) | [basic03](Basic-TP/basic03.md) |
| IPV4_DISABLED | [Basic](Basic-TP/README.md) | [basic03](Basic-TP/basic03.md) |
| IPV4_ENABLED | [Basic](Basic-TP/README.md) | [basic03](Basic-TP/basic03.md) |
| IPV6_DISABLED | [Basic](Basic-TP/README.md) | [basic03](Basic-TP/basic03.md) |
| IPV6_ENABLED | [Basic](Basic-TP/README.md) | [basic03](Basic-TP/basic03.md) |
| NO_A_RECORDS | [Basic](Basic-TP/README.md) | [basic03](Basic-TP/basic03.md) |
| TEST_CASE_END | [Basic](Basic-TP/README.md) | [basic03](Basic-TP/basic03.md) |
| TEST_CASE_START | [Basic](Basic-TP/README.md) | [basic03](Basic-TP/basic03.md) |
| CN01_IPV4_DISABLED | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_IPV6_DISABLED | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_MISSING_NS_RECORD_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_MISSING_SOA_RECORD_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_NO_RESPONSE_NS_QUERY_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_NO_RESPONSE_SOA_QUERY_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_NO_RESPONSE_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_NS_RECORD_NOT_AA_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_SOA_RECORD_NOT_AA_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_UNEXPECTED_RCODE_NS_QUERY_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_UNEXPECTED_RCODE_SOA_QUERY_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_WRONG_NS_RECORD_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN01_WRONG_SOA_RECORD_UDP | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| IPV4_DISABLED | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| IPV6_DISABLED | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| TEST_CASE_END | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| TEST_CASE_START | [Connectivity](Connectivity-TP/README.md) | [connectivity01](Connectivity-TP/connectivity01.md) |
| CN02_MISSING_NS_RECORD_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_MISSING_SOA_RECORD_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_NO_RESPONSE_NS_QUERY_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_NO_RESPONSE_SOA_QUERY_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_NO_RESPONSE_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_NS_RECORD_NOT_AA_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_SOA_RECORD_NOT_AA_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_UNEXPECTED_RCODE_NS_QUERY_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_UNEXPECTED_RCODE_SOA_QUERY_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_WRONG_NS_RECORD_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| CN02_WRONG_SOA_RECORD_TCP | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| IPV4_DISABLED | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| IPV6_DISABLED | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| TEST_CASE_END | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| TEST_CASE_START | [Connectivity](Connectivity-TP/README.md) | [connectivity02](Connectivity-TP/connectivity02.md) |
| ASN_INFOS_ANNOUNCE_BY | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| ASN_INFOS_ANNOUNCE_IN | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| ASN_INFOS_RAW | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| EMPTY_ASN_SET | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| ERROR_ASN_DATABASE | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| IPV4_DIFFERENT_ASN | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| IPV4_ONE_ASN | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| IPV4_SAME_ASN | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| IPV6_DIFFERENT_ASN | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| IPV6_ONE_ASN | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| IPV6_SAME_ASN | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| TEST_CASE_END | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| TEST_CASE_START | [Connectivity](Connectivity-TP/README.md) | [connectivity03](Connectivity-TP/connectivity03.md) |
| ASN_INFOS_ANNOUNCE_IN | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| ASN_INFOS_RAW | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| CN04_EMPTY_PREFIX_SET | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| CN04_ERROR_PREFIX_DATABASE | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| CN04_IPV4_DIFFERENT_PREFIX | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| CN04_IPV4_SAME_PREFIX | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| CN04_IPV4_SINGLE_PREFIX | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| CN04_IPV6_DIFFERENT_PREFIX | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| CN04_IPV6_SAME_PREFIX | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| CN04_IPV6_SINGLE_PREFIX | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| TEST_CASE_END | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| TEST_CASE_START | [Connectivity](Connectivity-TP/README.md) | [connectivity04](Connectivity-TP/connectivity04.md) |
| IPV4_DISABLED | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| IPV6_DISABLED | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| MULTIPLE_SOA_SERIALS | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| NO_RESPONSE | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| NO_RESPONSE_SOA_QUERY | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| ONE_SOA_SERIAL | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| SOA_SERIAL | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| SOA_SERIAL_VARIATION | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| TEST_CASE_END | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| TEST_CASE_START | [Consistency](Consistency-TP/README.md) | [consistency01](Consistency-TP/consistency01.md) |
| IPV4_DISABLED | [Consistency](Consistency-TP/README.md) | [consistency02](Consistency-TP/consistency02.md) |
| IPV6_DISABLED | [Consistency](Consistency-TP/README.md) | [consistency02](Consistency-TP/consistency02.md) |
| MULTIPLE_SOA_RNAMES | [Consistency](Consistency-TP/README.md) | [consistency02](Consistency-TP/consistency02.md) |
| NO_RESPONSE | [Consistency](Consistency-TP/README.md) | [consistency02](Consistency-TP/consistency02.md) |
| NO_RESPONSE_SOA_QUERY | [Consistency](Consistency-TP/README.md) | [consistency02](Consistency-TP/consistency02.md) |
| ONE_SOA_RNAME | [Consistency](Consistency-TP/README.md) | [consistency02](Consistency-TP/consistency02.md) |
| SOA_RNAME | [Consistency](Consistency-TP/README.md) | [consistency02](Consistency-TP/consistency02.md) |
| TEST_CASE_END | [Consistency](Consistency-TP/README.md) | [consistency02](Consistency-TP/consistency02.md) |
| TEST_CASE_START | [Consistency](Consistency-TP/README.md) | [consistency02](Consistency-TP/consistency02.md) |
| IPV4_DISABLED | [Consistency](Consistency-TP/README.md) | [consistency03](Consistency-TP/consistency03.md) |
| IPV6_DISABLED | [Consistency](Consistency-TP/README.md) | [consistency03](Consistency-TP/consistency03.md) |
| MULTIPLE_SOA_TIME_PARAMETER_SET | [Consistency](Consistency-TP/README.md) | [consistency03](Consistency-TP/consistency03.md) |
| NO_RESPONSE | [Consistency](Consistency-TP/README.md) | [consistency03](Consistency-TP/consistency03.md) |
| NO_RESPONSE_SOA_QUERY | [Consistency](Consistency-TP/README.md) | [consistency03](Consistency-TP/consistency03.md) |
| ONE_SOA_TIME_PARAMETER_SET | [Consistency](Consistency-TP/README.md) | [consistency03](Consistency-TP/consistency03.md) |
| SOA_TIME_PARAMETER_SET | [Consistency](Consistency-TP/README.md) | [consistency03](Consistency-TP/consistency03.md) |
| TEST_CASE_END | [Consistency](Consistency-TP/README.md) | [consistency03](Consistency-TP/consistency03.md) |
| TEST_CASE_START | [Consistency](Consistency-TP/README.md) | [consistency03](Consistency-TP/consistency03.md) |
| IPV4_DISABLED | [Consistency](Consistency-TP/README.md) | [consistency04](Consistency-TP/consistency04.md) |
| IPV6_DISABLED | [Consistency](Consistency-TP/README.md) | [consistency04](Consistency-TP/consistency04.md) |
| MULTIPLE_NS_SET | [Consistency](Consistency-TP/README.md) | [consistency04](Consistency-TP/consistency04.md) |
| NO_RESPONSE | [Consistency](Consistency-TP/README.md) | [consistency04](Consistency-TP/consistency04.md) |
| NO_RESPONSE_NS_QUERY | [Consistency](Consistency-TP/README.md) | [consistency04](Consistency-TP/consistency04.md) |
| NS_SET | [Consistency](Consistency-TP/README.md) | [consistency04](Consistency-TP/consistency04.md) |
| ONE_NS_SET | [Consistency](Consistency-TP/README.md) | [consistency04](Consistency-TP/consistency04.md) |
| TEST_CASE_END | [Consistency](Consistency-TP/README.md) | [consistency04](Consistency-TP/consistency04.md) |
| TEST_CASE_START | [Consistency](Consistency-TP/README.md) | [consistency04](Consistency-TP/consistency04.md) |
| ADDRESSES_MATCH | [Consistency](Consistency-TP/README.md) | [consistency05](Consistency-TP/consistency05.md) |
| CHILD_NS_FAILED | [Consistency](Consistency-TP/README.md) | [consistency05](Consistency-TP/consistency05.md) |
| CHILD_ZONE_LAME | [Consistency](Consistency-TP/README.md) | [consistency05](Consistency-TP/consistency05.md) |
| EXTRA_ADDRESS_CHILD | [Consistency](Consistency-TP/README.md) | [consistency05](Consistency-TP/consistency05.md) |
| IN_BAILIWICK_ADDR_MISMATCH | [Consistency](Consistency-TP/README.md) | [consistency05](Consistency-TP/consistency05.md) |
| NO_RESPONSE | [Consistency](Consistency-TP/README.md) | [consistency05](Consistency-TP/consistency05.md) |
| OUT_OF_BAILIWICK_ADDR_MISMATCH | [Consistency](Consistency-TP/README.md) | [consistency05](Consistency-TP/consistency05.md) |
| TEST_CASE_END | [Consistency](Consistency-TP/README.md) | [consistency05](Consistency-TP/consistency05.md) |
| TEST_CASE_START | [Consistency](Consistency-TP/README.md) | [consistency05](Consistency-TP/consistency05.md) |
| MULTIPLE_SOA_MNAMES | [Consistency](Consistency-TP/README.md) | [consistency06](Consistency-TP/consistency06.md) |
| NO_RESPONSE | [Consistency](Consistency-TP/README.md) | [consistency06](Consistency-TP/consistency06.md) |
| NO_RESPONSE_SOA_QUERY | [Consistency](Consistency-TP/README.md) | [consistency06](Consistency-TP/consistency06.md) |
| ONE_SOA_MNAME | [Consistency](Consistency-TP/README.md) | [consistency06](Consistency-TP/consistency06.md) |
| TEST_CASE_END | [Consistency](Consistency-TP/README.md) | [consistency06](Consistency-TP/consistency06.md) |
| TEST_CASE_START | [Consistency](Consistency-TP/README.md) | [consistency06](Consistency-TP/consistency06.md) |
| ENOUGH_IPV4_NS_CHILD | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| ENOUGH_IPV4_NS_DEL | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| ENOUGH_IPV6_NS_CHILD | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| ENOUGH_IPV6_NS_DEL | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| ENOUGH_NS_CHILD | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| ENOUGH_NS_DEL | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NOT_ENOUGH_IPV4_NS_CHILD | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NOT_ENOUGH_IPV4_NS_DEL | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NOT_ENOUGH_IPV6_NS_CHILD | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NOT_ENOUGH_IPV6_NS_DEL | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NOT_ENOUGH_NS_CHILD | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NOT_ENOUGH_NS_DEL | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NO_IPV4_NS_CHILD | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NO_IPV4_NS_DEL | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NO_IPV6_NS_CHILD | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| NO_IPV6_NS_DEL | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| TEST_CASE_END | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| TEST_CASE_START | [Delegation](Delegation-TP/README.md) | [delegation01](Delegation-TP/delegation01.md) |
| CHILD_DISTINCT_NS_IP | [Delegation](Delegation-TP/README.md) | [delegation02](Delegation-TP/delegation02.md) |
| CHILD_NS_SAME_IP | [Delegation](Delegation-TP/README.md) | [delegation02](Delegation-TP/delegation02.md) |
| DEL_DISTINCT_NS_IP | [Delegation](Delegation-TP/README.md) | [delegation02](Delegation-TP/delegation02.md) |
| DEL_NS_SAME_IP | [Delegation](Delegation-TP/README.md) | [delegation02](Delegation-TP/delegation02.md) |
| DISTINCT_IP_ADDRESS | [Delegation](Delegation-TP/README.md) | [delegation02](Delegation-TP/delegation02.md) |
| SAME_IP_ADDRESS | [Delegation](Delegation-TP/README.md) | [delegation02](Delegation-TP/delegation02.md) |
| TEST_CASE_END | [Delegation](Delegation-TP/README.md) | [delegation02](Delegation-TP/delegation02.md) |
| TEST_CASE_START | [Delegation](Delegation-TP/README.md) | [delegation02](Delegation-TP/delegation02.md) |
| REFERRAL_SIZE_OK | [Delegation](Delegation-TP/README.md) | [delegation03](Delegation-TP/delegation03.md) |
| REFERRAL_SIZE_TOO_LARGE | [Delegation](Delegation-TP/README.md) | [delegation03](Delegation-TP/delegation03.md) |
| TEST_CASE_END | [Delegation](Delegation-TP/README.md) | [delegation03](Delegation-TP/delegation03.md) |
| TEST_CASE_START | [Delegation](Delegation-TP/README.md) | [delegation03](Delegation-TP/delegation03.md) |
| ARE_AUTHORITATIVE | [Delegation](Delegation-TP/README.md) | [delegation04](Delegation-TP/delegation04.md) |
| IPV4_DISABLED | [Delegation](Delegation-TP/README.md) | [delegation04](Delegation-TP/delegation04.md) |
| IPV6_DISABLED | [Delegation](Delegation-TP/README.md) | [delegation04](Delegation-TP/delegation04.md) |
| IS_NOT_AUTHORITATIVE | [Delegation](Delegation-TP/README.md) | [delegation04](Delegation-TP/delegation04.md) |
| TEST_CASE_END | [Delegation](Delegation-TP/README.md) | [delegation04](Delegation-TP/delegation04.md) |
| TEST_CASE_START | [Delegation](Delegation-TP/README.md) | [delegation04](Delegation-TP/delegation04.md) |
| NO_NS_CNAME | [Delegation](Delegation-TP/README.md) | [delegation05](Delegation-TP/delegation05.md) |
| NO_RESPONSE | [Delegation](Delegation-TP/README.md) | [delegation05](Delegation-TP/delegation05.md) |
| NS_IS_CNAME | [Delegation](Delegation-TP/README.md) | [delegation05](Delegation-TP/delegation05.md) |
| TEST_CASE_END | [Delegation](Delegation-TP/README.md) | [delegation05](Delegation-TP/delegation05.md) |
| TEST_CASE_START | [Delegation](Delegation-TP/README.md) | [delegation05](Delegation-TP/delegation05.md) |
| UNEXPECTED_RCODE | [Delegation](Delegation-TP/README.md) | [delegation05](Delegation-TP/delegation05.md) |
| IPV4_DISABLED | [Delegation](Delegation-TP/README.md) | [delegation06](Delegation-TP/delegation06.md) |
| IPV6_DISABLED | [Delegation](Delegation-TP/README.md) | [delegation06](Delegation-TP/delegation06.md) |
| SOA_EXISTS | [Delegation](Delegation-TP/README.md) | [delegation06](Delegation-TP/delegation06.md) |
| SOA_NOT_EXISTS | [Delegation](Delegation-TP/README.md) | [delegation06](Delegation-TP/delegation06.md) |
| TEST_CASE_END | [Delegation](Delegation-TP/README.md) | [delegation06](Delegation-TP/delegation06.md) |
| TEST_CASE_START | [Delegation](Delegation-TP/README.md) | [delegation06](Delegation-TP/delegation06.md) |
| EXTRA_NAME_CHILD | [Delegation](Delegation-TP/README.md) | [delegation07](Delegation-TP/delegation07.md) |
| EXTRA_NAME_PARENT | [Delegation](Delegation-TP/README.md) | [delegation07](Delegation-TP/delegation07.md) |
| NAMES_MATCH | [Delegation](Delegation-TP/README.md) | [delegation07](Delegation-TP/delegation07.md) |
| TEST_CASE_END | [Delegation](Delegation-TP/README.md) | [delegation07](Delegation-TP/delegation07.md) |
| TEST_CASE_START | [Delegation](Delegation-TP/README.md) | [delegation07](Delegation-TP/delegation07.md) |
| TOTAL_NAME_MISMATCH | [Delegation](Delegation-TP/README.md) | [delegation07](Delegation-TP/delegation07.md) |
| DS01_DS_ALGO_2_MISSING | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_DS_ALGO_DEPRECATED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_DS_ALGO_NOT_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_DS_ALGO_OK | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_DS_ALGO_PRIVATE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_DS_ALGO_RESERVED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_DS_ALGO_UNASSIGNED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_NO_RESPONSE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_PARENT_SERVER_NO_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_PARENT_ZONE_NO_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_ROOT_N_NO_UNDEL_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS01_UNDEL_N_NO_UNDEL_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec01](DNSSEC-TP/dnssec01.md) |
| DS02_ALGO_NOT_SUPPORTED_BY_ZM | [DNSSEC](DNSSEC-TP/README.md) | [dnssec02](DNSSEC-TP/dnssec02.md) |
| DS02_DNSKEY_NOT_FOR_ZONE_SIGNING | [DNSSEC](DNSSEC-TP/README.md) | [dnssec02](DNSSEC-TP/dnssec02.md) |
| DS02_DNSKEY_NOT_SEP | [DNSSEC](DNSSEC-TP/README.md) | [dnssec02](DNSSEC-TP/dnssec02.md) |
| DS02_DNSKEY_NOT_SIGNED_BY_ANY_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec02](DNSSEC-TP/dnssec02.md) |
| DS02_NO_DNSKEY_FOR_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec02](DNSSEC-TP/dnssec02.md) |
| DS02_NO_MATCHING_DNSKEY_RRSIG | [DNSSEC](DNSSEC-TP/README.md) | [dnssec02](DNSSEC-TP/dnssec02.md) |
| DS02_NO_MATCH_DS_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec02](DNSSEC-TP/dnssec02.md) |
| DS02_NO_VALID_DNSKEY_FOR_ANY_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec02](DNSSEC-TP/dnssec02.md) |
| DS02_RRSIG_NOT_VALID_BY_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec02](DNSSEC-TP/dnssec02.md) |
| DS03_ERR_MULT_NSEC3 | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_ILLEGAL_HASH_ALGO | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_ILLEGAL_ITERATION_VALUE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_ILLEGAL_SALT_LENGTH | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_INCONSISTENT_HASH_ALGO | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_INCONSISTENT_ITERATION | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_INCONSISTENT_NSEC3_FLAGS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_INCONSISTENT_SALT_LENGTH | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_LEGAL_EMPTY_SALT | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_LEGAL_HASH_ALGO | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_LEGAL_ITERATION_VALUE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_NO_DNSSEC_SUPPORT | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_NO_NSEC3 | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_NSEC3_OPT_OUT_DISABLED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_NSEC3_OPT_OUT_ENABLED_TLD | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_SERVER_NO_DNSSEC_SUPPORT | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_SERVER_NO_NSEC3 | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DS03_UNASSIGNED_FLAG_USED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec03](DNSSEC-TP/dnssec03.md) |
| DURATION_LONG | [DNSSEC](DNSSEC-TP/README.md) | [dnssec04](DNSSEC-TP/dnssec04.md) |
| DURATION_OK | [DNSSEC](DNSSEC-TP/README.md) | [dnssec04](DNSSEC-TP/dnssec04.md) |
| REMAINING_LONG | [DNSSEC](DNSSEC-TP/README.md) | [dnssec04](DNSSEC-TP/dnssec04.md) |
| REMAINING_SHORT | [DNSSEC](DNSSEC-TP/README.md) | [dnssec04](DNSSEC-TP/dnssec04.md) |
| RRSIG_EXPIRATION | [DNSSEC](DNSSEC-TP/README.md) | [dnssec04](DNSSEC-TP/dnssec04.md) |
| RRSIG_EXPIRED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec04](DNSSEC-TP/dnssec04.md) |
| TEST_CASE_END | [DNSSEC](DNSSEC-TP/README.md) | [dnssec04](DNSSEC-TP/dnssec04.md) |
| TEST_CASE_START | [DNSSEC](DNSSEC-TP/README.md) | [dnssec04](DNSSEC-TP/dnssec04.md) |
| DS05_ALGO_DEPRECATED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| DS05_ALGO_NOT_RECOMMENDED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| DS05_ALGO_NOT_ZONE_SIGN | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| DS05_ALGO_OK | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| DS05_ALGO_PRIVATE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| DS05_ALGO_RESERVED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| DS05_ALGO_UNASSIGNED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| DS05_NO_RESPONSE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| DS05_SERVER_NO_DNSSEC | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| DS05_ZONE_NO_DNSSEC | [DNSSEC](DNSSEC-TP/README.md) | [dnssec05](DNSSEC-TP/dnssec05.md) |
| EXTRA_PROCESSING_BROKEN | [DNSSEC](DNSSEC-TP/README.md) | [dnssec06](DNSSEC-TP/dnssec06.md) |
| EXTRA_PROCESSING_OK | [DNSSEC](DNSSEC-TP/README.md) | [dnssec06](DNSSEC-TP/dnssec06.md) |
| TEST_CASE_END | [DNSSEC](DNSSEC-TP/README.md) | [dnssec06](DNSSEC-TP/dnssec06.md) |
| TEST_CASE_START | [DNSSEC](DNSSEC-TP/README.md) | [dnssec06](DNSSEC-TP/dnssec06.md) |
| DS07_DS_FOR_SIGNED_ZONE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_DS_ON_PARENT_SERVER | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_INCONSISTENT_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_INCONSISTENT_SIGNED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_NON_AUTH_RESPONSE_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_NOT_SIGNED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_NOT_SIGNED_ON_SERVER | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_NO_DS_FOR_SIGNED_ZONE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_NO_DS_ON_PARENT_SERVER | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_NO_RESPONSE_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_SIGNED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_SIGNED_ON_SERVER | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS07_UNEXP_RCODE_RESP_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec07](DNSSEC-TP/dnssec07.md) |
| DS08_ALGO_NOT_SUPPORTED_BY_ZM | [DNSSEC](DNSSEC-TP/README.md) | [dnssec08](DNSSEC-TP/dnssec08.md) |
| DS08_DNSKEY_RRSIG_EXPIRED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec08](DNSSEC-TP/dnssec08.md) |
| DS08_DNSKEY_RRSIG_NOT_YET_VALID | [DNSSEC](DNSSEC-TP/README.md) | [dnssec08](DNSSEC-TP/dnssec08.md) |
| DS08_MISSING_RRSIG_IN_RESPONSE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec08](DNSSEC-TP/dnssec08.md) |
| DS08_NO_MATCHING_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec08](DNSSEC-TP/dnssec08.md) |
| DS08_RRSIG_NOT_VALID_BY_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec08](DNSSEC-TP/dnssec08.md) |
| DS09_ALGO_NOT_SUPPORTED_BY_ZM | [DNSSEC](DNSSEC-TP/README.md) | [dnssec09](DNSSEC-TP/dnssec09.md) |
| DS09_MISSING_RRSIG_IN_RESPONSE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec09](DNSSEC-TP/dnssec09.md) |
| DS09_NO_MATCHING_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec09](DNSSEC-TP/dnssec09.md) |
| DS09_RRSIG_NOT_VALID_BY_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec09](DNSSEC-TP/dnssec09.md) |
| DS09_SOA_RRSIG_EXPIRED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec09](DNSSEC-TP/dnssec09.md) |
| DS09_SOA_RRSIG_NOT_YET_VALID | [DNSSEC](DNSSEC-TP/README.md) | [dnssec09](DNSSEC-TP/dnssec09.md) |
| DS10_ALGO_NOT_SUPPORTED_BY_ZM | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_ERR_MULT_NSEC | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_ERR_MULT_NSEC3 | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_ERR_MULT_NSEC3PARAM | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_EXPECTED_NSEC_NSEC3_MISSING | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_HAS_NSEC | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_HAS_NSEC3 | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_INCONSISTENT_NSEC | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_INCONSISTENT_NSEC3 | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_INCONSISTENT_NSEC_NSEC3 | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_MIXED_NSEC_NSEC3 | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3PARAM_GIVES_ERR_ANSWER | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3PARAM_MISMATCHES_APEX | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3PARAM_QUERY_RESPONSE_ERR | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_ERR_TYPE_LIST | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_MISMATCHES_APEX | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_MISSING_SIGNATURE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_NODATA_MISSING_SOA | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_NODATA_WRONG_SOA | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_NO_VERIFIED_SIGNATURE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_RRSIG_EXPIRED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_RRSIG_NOT_YET_VALID | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_RRSIG_NO_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC3_RRSIG_VERIFY_ERROR | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_ERR_TYPE_LIST | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_GIVES_ERR_ANSWER | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_MISMATCHES_APEX | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_MISSING_SIGNATURE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_NODATA_MISSING_SOA | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_NODATA_WRONG_SOA | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_NO_VERIFIED_SIGNATURE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_QUERY_RESPONSE_ERR | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_RRSIG_EXPIRED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_RRSIG_NOT_YET_VALID | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_RRSIG_NO_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_NSEC_RRSIG_VERIFY_ERROR | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_SERVER_NO_DNSSEC | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS10_ZONE_NO_DNSSEC | [DNSSEC](DNSSEC-TP/README.md) | [dnssec10](DNSSEC-TP/dnssec10.md) |
| DS11_DS_BUT_UNSIGNED_ZONE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec11](DNSSEC-TP/dnssec11.md) |
| DS11_INCONSISTENT_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec11](DNSSEC-TP/dnssec11.md) |
| DS11_INCONSISTENT_SIGNED_ZONE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec11](DNSSEC-TP/dnssec11.md) |
| DS11_NS_WITH_SIGNED_ZONE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec11](DNSSEC-TP/dnssec11.md) |
| DS11_NS_WITH_UNSIGNED_ZONE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec11](DNSSEC-TP/dnssec11.md) |
| DS11_PARENT_WITHOUT_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec11](DNSSEC-TP/dnssec11.md) |
| DS11_PARENT_WITH_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec11](DNSSEC-TP/dnssec11.md) |
| DS11_UNDETERMINED_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec11](DNSSEC-TP/dnssec11.md) |
| DS11_UNDETERMINED_SIGNED_ZONE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec11](DNSSEC-TP/dnssec11.md) |
| DS13_ALGO_NOT_SIGNED_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec13](DNSSEC-TP/dnssec13.md) |
| DS13_ALGO_NOT_SIGNED_NS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec13](DNSSEC-TP/dnssec13.md) |
| DS13_ALGO_NOT_SIGNED_SOA | [DNSSEC](DNSSEC-TP/README.md) | [dnssec13](DNSSEC-TP/dnssec13.md) |
| DNSKEY_SMALLER_THAN_REC | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| DNSKEY_TOO_LARGE_FOR_ALGO | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| DNSKEY_TOO_SMALL_FOR_ALGO | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| IPV4_DISABLED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| IPV6_DISABLED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| KEY_SIZE_OK | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| NO_RESPONSE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| NO_RESPONSE_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| TEST_CASE_END | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| TEST_CASE_START | [DNSSEC](DNSSEC-TP/README.md) | [dnssec14](DNSSEC-TP/dnssec14.md) |
| DS15_HAS_CDNSKEY_NO_CDS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec15](DNSSEC-TP/dnssec15.md) |
| DS15_HAS_CDS_AND_CDNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec15](DNSSEC-TP/dnssec15.md) |
| DS15_HAS_CDS_NO_CDNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec15](DNSSEC-TP/dnssec15.md) |
| DS15_INCONSISTENT_CDNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec15](DNSSEC-TP/dnssec15.md) |
| DS15_INCONSISTENT_CDS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec15](DNSSEC-TP/dnssec15.md) |
| DS15_MISMATCH_CDS_CDNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec15](DNSSEC-TP/dnssec15.md) |
| DS15_NO_CDS_CDNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec15](DNSSEC-TP/dnssec15.md) |
| DS16_CDS_INVALID_RRSIG | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_CDS_MATCHES_NON_SEP_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_CDS_MATCHES_NON_ZONE_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_CDS_MATCHES_NO_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_CDS_NOT_SIGNED_BY_CDS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_CDS_UNSIGNED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_CDS_WITHOUT_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_DELETE_CDS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_DNSKEY_NOT_SIGNED_BY_CDS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS16_MIXED_DELETE_CDS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec16](DNSSEC-TP/dnssec16.md) |
| DS17_CDNSKEY_INVALID_RRSIG | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_CDNSKEY_IS_NON_SEP | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_CDNSKEY_IS_NON_ZONE | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_CDNSKEY_MATCHES_NO_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_CDNSKEY_NOT_SIGNED_BY_CDNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_CDNSKEY_SIGNED_BY_UNKNOWN_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_CDNSKEY_UNSIGNED | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_CDNSKEY_WITHOUT_DNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_DELETE_CDNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_DNSKEY_NOT_SIGNED_BY_CDNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS17_MIXED_DELETE_CDNSKEY | [DNSSEC](DNSSEC-TP/README.md) | [dnssec17](DNSSEC-TP/dnssec17.md) |
| DS18_NO_MATCH_CDNSKEY_RRSIG_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec18](DNSSEC-TP/dnssec18.md) |
| DS18_NO_MATCH_CDS_RRSIG_DS | [DNSSEC](DNSSEC-TP/README.md) | [dnssec18](DNSSEC-TP/dnssec18.md) |
| IS_A_RECURSOR | [Nameserver](Nameserver-TP/README.md) | [nameserver01](Nameserver-TP/nameserver01.md) |
| NO_RECURSOR | [Nameserver](Nameserver-TP/README.md) | [nameserver01](Nameserver-TP/nameserver01.md) |
| NO_RESPONSE | [Nameserver](Nameserver-TP/README.md) | [nameserver01](Nameserver-TP/nameserver01.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver01](Nameserver-TP/nameserver01.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver01](Nameserver-TP/nameserver01.md) |
| BREAKS_ON_EDNS | [Nameserver](Nameserver-TP/README.md) | [nameserver02](Nameserver-TP/nameserver02.md) |
| EDNS0_SUPPORT | [Nameserver](Nameserver-TP/README.md) | [nameserver02](Nameserver-TP/nameserver02.md) |
| EDNS_RESPONSE_WITHOUT_EDNS | [Nameserver](Nameserver-TP/README.md) | [nameserver02](Nameserver-TP/nameserver02.md) |
| EDNS_VERSION_ERROR | [Nameserver](Nameserver-TP/README.md) | [nameserver02](Nameserver-TP/nameserver02.md) |
| NO_EDNS_SUPPORT | [Nameserver](Nameserver-TP/README.md) | [nameserver02](Nameserver-TP/nameserver02.md) |
| NO_RESPONSE | [Nameserver](Nameserver-TP/README.md) | [nameserver02](Nameserver-TP/nameserver02.md) |
| NS_ERROR | [Nameserver](Nameserver-TP/README.md) | [nameserver02](Nameserver-TP/nameserver02.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver02](Nameserver-TP/nameserver02.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver02](Nameserver-TP/nameserver02.md) |
| AXFR_AVAILABLE | [Nameserver](Nameserver-TP/README.md) | [nameserver03](Nameserver-TP/nameserver03.md) |
| AXFR_FAILURE | [Nameserver](Nameserver-TP/README.md) | [nameserver03](Nameserver-TP/nameserver03.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver03](Nameserver-TP/nameserver03.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver03](Nameserver-TP/nameserver03.md) |
| DIFFERENT_SOURCE_IP | [Nameserver](Nameserver-TP/README.md) | [nameserver04](Nameserver-TP/nameserver04.md) |
| SAME_SOURCE_IP | [Nameserver](Nameserver-TP/README.md) | [nameserver04](Nameserver-TP/nameserver04.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver04](Nameserver-TP/nameserver04.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver04](Nameserver-TP/nameserver04.md) |
| AAAA_BAD_RDATA | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| AAAA_QUERY_DROPPED | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| AAAA_UNEXPECTED_RCODE | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| AAAA_WELL_PROCESSED | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| A_UNEXPECTED_RCODE | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| IPV4_DISABLED | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| IPV6_DISABLED | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| NO_RESPONSE | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver05](Nameserver-TP/nameserver05.md) |
| CAN_BE_RESOLVED | [Nameserver](Nameserver-TP/README.md) | [nameserver06](Nameserver-TP/nameserver06.md) |
| CAN_NOT_BE_RESOLVED | [Nameserver](Nameserver-TP/README.md) | [nameserver06](Nameserver-TP/nameserver06.md) |
| NO_RESOLUTION | [Nameserver](Nameserver-TP/README.md) | [nameserver06](Nameserver-TP/nameserver06.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver06](Nameserver-TP/nameserver06.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver06](Nameserver-TP/nameserver06.md) |
| NO_UPWARD_REFERRAL | [Nameserver](Nameserver-TP/README.md) | [nameserver07](Nameserver-TP/nameserver07.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver07](Nameserver-TP/nameserver07.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver07](Nameserver-TP/nameserver07.md) |
| UPWARD_REFERRAL | [Nameserver](Nameserver-TP/README.md) | [nameserver07](Nameserver-TP/nameserver07.md) |
| UPWARD_REFERRAL_IRRELEVANT | [Nameserver](Nameserver-TP/README.md) | [nameserver07](Nameserver-TP/nameserver07.md) |
| QNAME_CASE_INSENSITIVE | [Nameserver](Nameserver-TP/README.md) | [nameserver08](Nameserver-TP/nameserver08.md) |
| QNAME_CASE_SENSITIVE | [Nameserver](Nameserver-TP/README.md) | [nameserver08](Nameserver-TP/nameserver08.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver08](Nameserver-TP/nameserver08.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver08](Nameserver-TP/nameserver08.md) |
| CASE_QUERIES_RESULTS_DIFFER | [Nameserver](Nameserver-TP/README.md) | [nameserver09](Nameserver-TP/nameserver09.md) |
| CASE_QUERIES_RESULTS_OK | [Nameserver](Nameserver-TP/README.md) | [nameserver09](Nameserver-TP/nameserver09.md) |
| CASE_QUERY_DIFFERENT_ANSWER | [Nameserver](Nameserver-TP/README.md) | [nameserver09](Nameserver-TP/nameserver09.md) |
| CASE_QUERY_DIFFERENT_RC | [Nameserver](Nameserver-TP/README.md) | [nameserver09](Nameserver-TP/nameserver09.md) |
| CASE_QUERY_NO_ANSWER | [Nameserver](Nameserver-TP/README.md) | [nameserver09](Nameserver-TP/nameserver09.md) |
| CASE_QUERY_SAME_ANSWER | [Nameserver](Nameserver-TP/README.md) | [nameserver09](Nameserver-TP/nameserver09.md) |
| CASE_QUERY_SAME_RC | [Nameserver](Nameserver-TP/README.md) | [nameserver09](Nameserver-TP/nameserver09.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver09](Nameserver-TP/nameserver09.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver09](Nameserver-TP/nameserver09.md) |
| N10_EDNS_RESPONSE_ERROR | [Nameserver](Nameserver-TP/README.md) | [nameserver10](Nameserver-TP/nameserver10.md) |
| N10_NO_RESPONSE_EDNS1_QUERY | [Nameserver](Nameserver-TP/README.md) | [nameserver10](Nameserver-TP/nameserver10.md) |
| N10_UNEXPECTED_RCODE | [Nameserver](Nameserver-TP/README.md) | [nameserver10](Nameserver-TP/nameserver10.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver10](Nameserver-TP/nameserver10.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver10](Nameserver-TP/nameserver10.md) |
| N11_NO_EDNS | [Nameserver](Nameserver-TP/README.md) | [nameserver11](Nameserver-TP/nameserver11.md) |
| N11_NO_RESPONSE | [Nameserver](Nameserver-TP/README.md) | [nameserver11](Nameserver-TP/nameserver11.md) |
| N11_RETURNS_UNKNOWN_OPTION_CODE | [Nameserver](Nameserver-TP/README.md) | [nameserver11](Nameserver-TP/nameserver11.md) |
| N11_UNEXPECTED_ANSWER_SECTION | [Nameserver](Nameserver-TP/README.md) | [nameserver11](Nameserver-TP/nameserver11.md) |
| N11_UNEXPECTED_RCODE | [Nameserver](Nameserver-TP/README.md) | [nameserver11](Nameserver-TP/nameserver11.md) |
| N11_UNSET_AA | [Nameserver](Nameserver-TP/README.md) | [nameserver11](Nameserver-TP/nameserver11.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver11](Nameserver-TP/nameserver11.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver11](Nameserver-TP/nameserver11.md) |
| NO_EDNS_SUPPORT | [Nameserver](Nameserver-TP/README.md) | [nameserver12](Nameserver-TP/nameserver12.md) |
| NO_RESPONSE | [Nameserver](Nameserver-TP/README.md) | [nameserver12](Nameserver-TP/nameserver12.md) |
| NS_ERROR | [Nameserver](Nameserver-TP/README.md) | [nameserver12](Nameserver-TP/nameserver12.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver12](Nameserver-TP/nameserver12.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver12](Nameserver-TP/nameserver12.md) |
| Z_FLAGS_NOTCLEAR | [Nameserver](Nameserver-TP/README.md) | [nameserver12](Nameserver-TP/nameserver12.md) |
| MISSING_OPT_IN_TRUNCATED | [Nameserver](Nameserver-TP/README.md) | [nameserver13](Nameserver-TP/nameserver13.md) |
| NO_EDNS_SUPPORT | [Nameserver](Nameserver-TP/README.md) | [nameserver13](Nameserver-TP/nameserver13.md) |
| NO_RESPONSE | [Nameserver](Nameserver-TP/README.md) | [nameserver13](Nameserver-TP/nameserver13.md) |
| NS_ERROR | [Nameserver](Nameserver-TP/README.md) | [nameserver13](Nameserver-TP/nameserver13.md) |
| TEST_CASE_END | [Nameserver](Nameserver-TP/README.md) | [nameserver13](Nameserver-TP/nameserver13.md) |
| TEST_CASE_START | [Nameserver](Nameserver-TP/README.md) | [nameserver13](Nameserver-TP/nameserver13.md) |
| N15_ERROR_ON_VERSION_QUERY | [Nameserver](Nameserver-TP/README.md) | [nameserver15](Nameserver-TP/nameserver15.md) |
| N15_NO_VERSION_REVEALED | [Nameserver](Nameserver-TP/README.md) | [nameserver15](Nameserver-TP/nameserver15.md) |
| N15_SOFTWARE_VERSION | [Nameserver](Nameserver-TP/README.md) | [nameserver15](Nameserver-TP/nameserver15.md) |
| N15_WRONG_CLASS | [Nameserver](Nameserver-TP/README.md) | [nameserver15](Nameserver-TP/nameserver15.md) |
| NON_ALLOWED_CHARS | [Syntax](Syntax-TP/README.md) | [syntax01](Syntax-TP/syntax01.md) |
| ONLY_ALLOWED_CHARS | [Syntax](Syntax-TP/README.md) | [syntax01](Syntax-TP/syntax01.md) |
| TEST_CASE_END | [Syntax](Syntax-TP/README.md) | [syntax01](Syntax-TP/syntax01.md) |
| TEST_CASE_START | [Syntax](Syntax-TP/README.md) | [syntax01](Syntax-TP/syntax01.md) |
| INITIAL_HYPHEN | [Syntax](Syntax-TP/README.md) | [syntax02](Syntax-TP/syntax02.md) |
| NO_ENDING_HYPHENS | [Syntax](Syntax-TP/README.md) | [syntax02](Syntax-TP/syntax02.md) |
| TERMINAL_HYPHEN | [Syntax](Syntax-TP/README.md) | [syntax02](Syntax-TP/syntax02.md) |
| TEST_CASE_END | [Syntax](Syntax-TP/README.md) | [syntax02](Syntax-TP/syntax02.md) |
| TEST_CASE_START | [Syntax](Syntax-TP/README.md) | [syntax02](Syntax-TP/syntax02.md) |
| DISCOURAGED_DOUBLE_DASH | [Syntax](Syntax-TP/README.md) | [syntax03](Syntax-TP/syntax03.md) |
| NO_DOUBLE_DASH | [Syntax](Syntax-TP/README.md) | [syntax03](Syntax-TP/syntax03.md) |
| TEST_CASE_END | [Syntax](Syntax-TP/README.md) | [syntax03](Syntax-TP/syntax03.md) |
| TEST_CASE_START | [Syntax](Syntax-TP/README.md) | [syntax03](Syntax-TP/syntax03.md) |
| NAMESERVER_DISCOURAGED_DOUBLE_DASH | [Syntax](Syntax-TP/README.md) | [syntax04](Syntax-TP/syntax04.md) |
| NAMESERVER_NON_ALLOWED_CHARS | [Syntax](Syntax-TP/README.md) | [syntax04](Syntax-TP/syntax04.md) |
| NAMESERVER_NUMERIC_TLD | [Syntax](Syntax-TP/README.md) | [syntax04](Syntax-TP/syntax04.md) |
| NAMESERVER_SYNTAX_OK | [Syntax](Syntax-TP/README.md) | [syntax04](Syntax-TP/syntax04.md) |
| TEST_CASE_END | [Syntax](Syntax-TP/README.md) | [syntax04](Syntax-TP/syntax04.md) |
| TEST_CASE_START | [Syntax](Syntax-TP/README.md) | [syntax04](Syntax-TP/syntax04.md) |
| NO_RESPONSE_SOA_QUERY | [Syntax](Syntax-TP/README.md) | [syntax05](Syntax-TP/syntax05.md) |
| RNAME_MISUSED_AT_SIGN | [Syntax](Syntax-TP/README.md) | [syntax05](Syntax-TP/syntax05.md) |
| RNAME_NO_AT_SIGN | [Syntax](Syntax-TP/README.md) | [syntax05](Syntax-TP/syntax05.md) |
| TEST_CASE_END | [Syntax](Syntax-TP/README.md) | [syntax05](Syntax-TP/syntax05.md) |
| TEST_CASE_START | [Syntax](Syntax-TP/README.md) | [syntax05](Syntax-TP/syntax05.md) |
| NO_RESPONSE | [Syntax](Syntax-TP/README.md) | [syntax06](Syntax-TP/syntax06.md) |
| NO_RESPONSE_SOA_QUERY | [Syntax](Syntax-TP/README.md) | [syntax06](Syntax-TP/syntax06.md) |
| RNAME_MAIL_DOMAIN_INVALID | [Syntax](Syntax-TP/README.md) | [syntax06](Syntax-TP/syntax06.md) |
| RNAME_MAIL_DOMAIN_LOCALHOST | [Syntax](Syntax-TP/README.md) | [syntax06](Syntax-TP/syntax06.md) |
| RNAME_MAIL_ILLEGAL_CNAME | [Syntax](Syntax-TP/README.md) | [syntax06](Syntax-TP/syntax06.md) |
| RNAME_RFC822_INVALID | [Syntax](Syntax-TP/README.md) | [syntax06](Syntax-TP/syntax06.md) |
| RNAME_RFC822_VALID | [Syntax](Syntax-TP/README.md) | [syntax06](Syntax-TP/syntax06.md) |
| TEST_CASE_END | [Syntax](Syntax-TP/README.md) | [syntax06](Syntax-TP/syntax06.md) |
| TEST_CASE_START | [Syntax](Syntax-TP/README.md) | [syntax06](Syntax-TP/syntax06.md) |
| MNAME_DISCOURAGED_DOUBLE_DASH | [Syntax](Syntax-TP/README.md) | [syntax07](Syntax-TP/syntax07.md) |
| MNAME_NON_ALLOWED_CHARS | [Syntax](Syntax-TP/README.md) | [syntax07](Syntax-TP/syntax07.md) |
| MNAME_NUMERIC_TLD | [Syntax](Syntax-TP/README.md) | [syntax07](Syntax-TP/syntax07.md) |
| MNAME_SYNTAX_OK | [Syntax](Syntax-TP/README.md) | [syntax07](Syntax-TP/syntax07.md) |
| NO_RESPONSE_SOA_QUERY | [Syntax](Syntax-TP/README.md) | [syntax07](Syntax-TP/syntax07.md) |
| TEST_CASE_END | [Syntax](Syntax-TP/README.md) | [syntax07](Syntax-TP/syntax07.md) |
| TEST_CASE_START | [Syntax](Syntax-TP/README.md) | [syntax07](Syntax-TP/syntax07.md) |
| MX_DISCOURAGED_DOUBLE_DASH | [Syntax](Syntax-TP/README.md) | [syntax08](Syntax-TP/syntax08.md) |
| MX_NON_ALLOWED_CHARS | [Syntax](Syntax-TP/README.md) | [syntax08](Syntax-TP/syntax08.md) |
| MX_NUMERIC_TLD | [Syntax](Syntax-TP/README.md) | [syntax08](Syntax-TP/syntax08.md) |
| MX_SYNTAX_OK | [Syntax](Syntax-TP/README.md) | [syntax08](Syntax-TP/syntax08.md) |
| NO_RESPONSE_MX_QUERY | [Syntax](Syntax-TP/README.md) | [syntax08](Syntax-TP/syntax08.md) |
| TEST_CASE_END | [Syntax](Syntax-TP/README.md) | [syntax08](Syntax-TP/syntax08.md) |
| TEST_CASE_START | [Syntax](Syntax-TP/README.md) | [syntax08](Syntax-TP/syntax08.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_HAS_LOCALHOST_ADDR | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_IS_DOT | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_IS_LOCALHOST | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_IS_MASTER | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_MISSING_SOA_RECORD | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_NOT_AUTHORITATIVE | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_NOT_IN_NS_LIST | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_NOT_MASTER | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_NOT_RESOLVE | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_NO_RESPONSE | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| Z01_MNAME_UNEXPECTED_RCODE | [Zone](Zone-TP/README.md) | [zone01](Zone-TP/zone01.md) |
| NO_RESPONSE_SOA_QUERY | [Zone](Zone-TP/README.md) | [zone02](Zone-TP/zone02.md) |
| REFRESH_MINIMUM_VALUE_LOWER | [Zone](Zone-TP/README.md) | [zone02](Zone-TP/zone02.md) |
| REFRESH_MINIMUM_VALUE_OK | [Zone](Zone-TP/README.md) | [zone02](Zone-TP/zone02.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone02](Zone-TP/zone02.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone02](Zone-TP/zone02.md) |
| NO_RESPONSE_SOA_QUERY | [Zone](Zone-TP/README.md) | [zone03](Zone-TP/zone03.md) |
| REFRESH_HIGHER_THAN_RETRY | [Zone](Zone-TP/README.md) | [zone03](Zone-TP/zone03.md) |
| REFRESH_LOWER_THAN_RETRY | [Zone](Zone-TP/README.md) | [zone03](Zone-TP/zone03.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone03](Zone-TP/zone03.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone03](Zone-TP/zone03.md) |
| NO_RESPONSE_SOA_QUERY | [Zone](Zone-TP/README.md) | [zone04](Zone-TP/zone04.md) |
| RETRY_MINIMUM_VALUE_LOWER | [Zone](Zone-TP/README.md) | [zone04](Zone-TP/zone04.md) |
| RETRY_MINIMUM_VALUE_OK | [Zone](Zone-TP/README.md) | [zone04](Zone-TP/zone04.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone04](Zone-TP/zone04.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone04](Zone-TP/zone04.md) |
| EXPIRE_LOWER_THAN_REFRESH | [Zone](Zone-TP/README.md) | [zone05](Zone-TP/zone05.md) |
| EXPIRE_MINIMUM_VALUE_LOWER | [Zone](Zone-TP/README.md) | [zone05](Zone-TP/zone05.md) |
| EXPIRE_MINIMUM_VALUE_OK | [Zone](Zone-TP/README.md) | [zone05](Zone-TP/zone05.md) |
| NO_RESPONSE_SOA_QUERY | [Zone](Zone-TP/README.md) | [zone05](Zone-TP/zone05.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone05](Zone-TP/zone05.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone05](Zone-TP/zone05.md) |
| NO_RESPONSE_SOA_QUERY | [Zone](Zone-TP/README.md) | [zone06](Zone-TP/zone06.md) |
| SOA_DEFAULT_TTL_MAXIMUM_VALUE_HIGHER | [Zone](Zone-TP/README.md) | [zone06](Zone-TP/zone06.md) |
| SOA_DEFAULT_TTL_MAXIMUM_VALUE_LOWER | [Zone](Zone-TP/README.md) | [zone06](Zone-TP/zone06.md) |
| SOA_DEFAULT_TTL_MAXIMUM_VALUE_OK | [Zone](Zone-TP/README.md) | [zone06](Zone-TP/zone06.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone06](Zone-TP/zone06.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone06](Zone-TP/zone06.md) |
| MNAME_HAS_NO_ADDRESS | [Zone](Zone-TP/README.md) | [zone07](Zone-TP/zone07.md) |
| MNAME_IS_CNAME | [Zone](Zone-TP/README.md) | [zone07](Zone-TP/zone07.md) |
| MNAME_IS_NOT_CNAME | [Zone](Zone-TP/README.md) | [zone07](Zone-TP/zone07.md) |
| NO_RESPONSE_SOA_QUERY | [Zone](Zone-TP/README.md) | [zone07](Zone-TP/zone07.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone07](Zone-TP/zone07.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone07](Zone-TP/zone07.md) |
| MX_RECORD_IS_CNAME | [Zone](Zone-TP/README.md) | [zone08](Zone-TP/zone08.md) |
| MX_RECORD_IS_NOT_CNAME | [Zone](Zone-TP/README.md) | [zone08](Zone-TP/zone08.md) |
| NO_RESPONSE_MX_QUERY | [Zone](Zone-TP/README.md) | [zone08](Zone-TP/zone08.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone08](Zone-TP/zone08.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone08](Zone-TP/zone08.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_INCONSISTENT_MX | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_INCONSISTENT_MX_DATA | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_MISSING_MAIL_TARGET | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_MX_DATA | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_MX_FOUND | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_NON_AUTH_MX_RESPONSE | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_NO_MX_FOUND | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_NO_RESPONSE_MX_QUERY | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_NULL_MX_NON_ZERO_PREF | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_NULL_MX_WITH_OTHER_MX | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_ROOT_EMAIL_DOMAIN | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_TLD_EMAIL_DOMAIN | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| Z09_UNEXPECTED_RCODE_MX | [Zone](Zone-TP/README.md) | [zone09](Zone-TP/zone09.md) |
| MULTIPLE_SOA | [Zone](Zone-TP/README.md) | [zone10](Zone-TP/zone10.md) |
| NO_RESPONSE | [Zone](Zone-TP/README.md) | [zone10](Zone-TP/zone10.md) |
| NO_SOA_IN_RESPONSE | [Zone](Zone-TP/README.md) | [zone10](Zone-TP/zone10.md) |
| ONE_SOA | [Zone](Zone-TP/README.md) | [zone10](Zone-TP/zone10.md) |
| TEST_CASE_END | [Zone](Zone-TP/README.md) | [zone10](Zone-TP/zone10.md) |
| TEST_CASE_START | [Zone](Zone-TP/README.md) | [zone10](Zone-TP/zone10.md) |
| WRONG_SOA | [Zone](Zone-TP/README.md) | [zone10](Zone-TP/zone10.md) |
| Z11_DIFFERENT_SPF_POLICIES_FOUND | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
| Z11_INCONSISTENT_SPF_POLICIES | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
| Z11_NON_NULL_SPF_NON_MAIL_DOMAIN | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
| Z11_NO_SPF_FOUND | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
| Z11_NO_SPF_NON_MAIL_DOMAIN | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
| Z11_NULL_SPF_NON_MAIL_DOMAIN | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
| Z11_SPF_MULTIPLE_RECORDS | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
| Z11_SPF_SYNTAX_ERROR | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
| Z11_SPF_SYNTAX_OK | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
| Z11_UNABLE_TO_CHECK_FOR_SPF | [Zone](Zone-TP/README.md) | [zone11](Zone-TP/zone11.md) |
[Zonemaster-Engine]: https://github.com/zonemaster/zonemaster-engine

View File

@@ -0,0 +1,27 @@
# Zone Test Plan
These are tests of the zone content in DNS, such as SOA and MX records.
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|
|:---------|:--------------------|
|[ZONE01](zone01.md)|Fully qualified master nameserver in SOA|
|[ZONE02](zone02.md)|SOA 'refresh' minimum value|
|[ZONE03](zone03.md)|SOA 'retry' lower than 'refresh'|
|[ZONE04](zone04.md)|SOA 'retry' at least 1 hour|
|[ZONE05](zone05.md)|SOA 'expire' minimum value|
|[ZONE06](zone06.md)|SOA 'minimum' maximum value|
|[ZONE07](zone07.md)|SOA master is not an alias|
|[ZONE08](zone08.md)|MX is not an alias|
|[ZONE09](zone09.md)|MX record present|
|[ZONE10](zone10.md)|No multiple SOA records|
|[ZONE11](zone11.md)|SPF policy validation|

View File

@@ -0,0 +1,269 @@
## ZONE01: Fully qualified master nameserver in SOA
### Test case identifier
**ZONE01** Fully qualified master nameserver in SOA
## 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
The MNAME field from the SOA record of a zone is supposed to contain the master
name server for that zone. The hostname of the MNAME field may not be listed
in the NS records in the zone among the delegated name servers, but should
still be authoritative for the zone. MNAME may be used for other services
such as DNS NOTIFY described in [RFC1996].
[RFC1035], section 3.3.13, specifies that "the *domain-name* of the name server
that was the original or primary source of data for this zone".
[RFC1996], section 2, and [RFC2136], section 1, add that "the primary master is
named in the zone's SOA MNAME field and optionally by an NS RR.
There is by definition only one primary master server per zone".
[RFC2181], section 7.2, clarifies that "it is quite clear in the specifications,
yet seems to have been widely ignored, that the MNAME field of the SOA record
should contain the name of the primary (master) server for the zone identified
by the SOA. It should not contain the name of the zone itself. That information
would be useless, as to discover it, one needs to start with the domain name of
the SOA record - that is the name of the zone".
There exists an unstandardized practice to set the SOA MNAME to ".", which
should not be interpreted that there is no primary master server, but to
indicate that there is no default server for dynamic updates. With ".", SOA
MNAME has no server name. There is at least one old and expired Internet-Draft
that attempted to standardize that behavior, [draft-jabley-dnsop-missing-mname].
If the SOA MNAME is an empty name (".") this Test Case will not try to connect
to a server behind it since there will never be a server behind that name, as
the purpose is most definitely to follow that practice. Instead, a special
message will be outputted.
The operational consequences of errors on SOA MNAME are, however, limited. It is
never used for finding authoritative name servers for the zone, and is not part
of normal lookup. Therefore, the level set by this test case on SOA MNAME errors
is not higher than NOTICE.
This Test Case will check that:
- the SOA MNAME contains the master name server of *Child Zone*,
as best as it can be determined.
- the SOA MNAME name server is authoritative of *Child Zone*.
- the SOA SERIAL of the SOA MNAME is at least equal to the ones found
from the name servers in the NS record set of *Child Zone*.
This comparison must be done following [RFC1982].
- the SOA MNAME name server is listed as part of the NS record set of *Child Zone*.
## 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, except
if the name server is listed in the SOA MNAME.
The syntax of the SOA MNAME for *Child Zone* is not tested in this Test
Case, see [SYNTAX07].
The consistency of the SOA MNAME between different servers of *Child Zone*
is not tested by this Test Case, see [CONSISTENCY06].
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
Message Tag | Level | Arguments | Message ID for message tag
:---------------------------- |:--------|:-------------------------------------|:---------------------------------------------------------------------------------------
Z01_MNAME_HAS_LOCALHOST_ADDR | NOTICE | nsname, ns_ip | SOA MNAME name server "{nsname}" resolves to a localhost IP address ({ns_ip}).
Z01_MNAME_IS_DOT | NOTICE | ns_ip_list | SOA MNAME is specified as "." which usually means "no server". Fetched from name servers "{ns_ip_list}".
Z01_MNAME_IS_LOCALHOST | NOTICE | ns_ip_list | SOA MNAME name server is "localhost", which is invalid. Fetched from name servers "{ns_ip_list}".
Z01_MNAME_IS_MASTER | DEBUG | ns_list | SOA MNAME name server(s) "{ns_list}" appears to be master.
Z01_MNAME_MISSING_SOA_RECORD | NOTICE | ns | SOA MNAME name server "{ns}" responds to an SOA query with no SOA records in the answer section.
Z01_MNAME_NO_RESPONSE | NOTICE | ns | SOA MNAME name server "{ns}" does not respond to an SOA query.
Z01_MNAME_NOT_AUTHORITATIVE | NOTICE | ns | SOA MNAME name server "{ns}" is not authoritative for the zone.
Z01_MNAME_NOT_IN_NS_LIST | INFO | nsname | SOA MNAME name server "{nsname}" is not listed as NS record for the zone.
Z01_MNAME_NOT_MASTER | NOTICE | ns_list, soaserial, soaserial_list | SOA MNAME name server(s) "{ns_list}" do(es) not have the highest SOA SERIAL (expected "{soaserial}" but got "{soaserial_list}")
Z01_MNAME_NOT_RESOLVE | NOTICE | nsname | SOA MNAME name server "{nsname}" cannot be resolved into an IP address.
Z01_MNAME_UNEXPECTED_RCODE | NOTICE | ns, rcode | SOA MNAME name server "{ns}" gives unexpected RCODE name ("{rcode}") in response to 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 SOA MNAME name, SOA MNAME IP address(es), SOA SERIAL(s) ("MNAME Nameservers")
2. Name server SOA SERIAL ("SERIAL Nameservers")
3. Name server SOA MNAME name, SOA MNAME IP address, SOA SERIAL ("MNAME Not Master")
4. Name server SOA MNAME name, SOA MNAME IP address ("MNAME Is Master")
5. Name server IP address ("MNAME Is Localhost")
6. Name server IP address ("MNAME Is Dot")
3. Obtain the set of name server IP addresses using
[Method4] and [Method5] ("Name Server IP").
4. For each name server IP address in *Name Server IP* do:
1. Send *SOA Query* to the name server IP and collect the response.
2. Go to next name server IP address if at least one of
the following criteria is met:
1. There is no DNS response.
2. [RCODE Name] of the response is not "NoError".
3. The AA flag is not set in the response.
4. There is no SOA record with owner name matching the query.
3. From the DNS response, extract the name server name from the SOA MNAME field:
1. If the name is "localhost", then add name server IP address to
the *MNAME Is Localhost* set.
2. Else if the name is ".", then add name server IP address to
the *MNAME Is Dot* set.
3. Else, add SOA MNAME name server name to the *MNAME Nameservers* set.
4. From the SOA record in the DNS response, extract the value from the SOA SERIAL
field and add it to the *SERIAL Nameservers* set.
5. Go to next name server IP address.
5. If the set *MNAME Is Localhost* is non-empty, then output
*[Z01_MNAME_IS_LOCALHOST]* with name server(s) IP address(es).
6. If the set *MNAME Is Dot* is non-empty, then output
*[Z01_MNAME_IS_DOT]* with name server(s) IP address(es).
7. If the set *MNAME Nameservers* is empty, then terminate these procedures.
8. Obtain the set of name server names using [Method3] ("Child Nameservers").
9. For each SOA MNAME name server name in *MNAME Nameservers* do:
1. If the SOA MNAME name server name is not part of the
*Child Nameservers* set, then output *[Z01_MNAME_NOT_IN_NS_LIST]* with
SOA MNAME name server name.
2. Do a [DNS Lookup] of SOA MNAME name server name (A and AAAA) and add the
SOA MNAME name server IP address(es) found to the *MNAME Nameservers* set
for the same entry as the SOA MNAME name server name.
3. If at least one IP address from the previous step was found, then:
1. For each SOA MNAME name server IP address for the SOA MNAME name server name do:
1. If the IP address is a localhost address (127.0.0.1 or ::1), then output
*[Z01_MNAME_HAS_LOCALHOST_ADDR]* with SOA MNAME name server name and IP.
2. Else, send *SOA Query* to the name server IP and collect the response.
1. If there is a DNS response, with [RCODE Name] "NoError" and
an SOA record in the answer section, then:
1. If the AA flag is not set, then output *[Z01_MNAME_NOT_AUTHORITATIVE]*
with SOA MNAME name server name and IP address.
2. Else, add the SOA SERIAL value to the *MNAME Nameservers* set
for the SOA MNAME name server name and IP pair.
2. Else if [RCODE Name] is not "NoError", then output
*[Z01_MNAME_UNEXPECTED_RCODE]* with [RCODE Name], SOA MNAME name server
name and IP address.
3. Else if there is no SOA record in the answer section, then output
*[Z01_MNAME_MISSING_SOA_RECORD]* with SOA MNAME name server
name and IP address.
4. Else, output *[Z01_MNAME_NO_RESPONSE]* with SOA MNAME name server
name and IP address.
3. Go to next SOA MNAME name server IP.
4. Else, output *[Z01_MNAME_NOT_RESOLVE]* with SOA MNAME name server name.
5. Go to next SOA MNAME name server name.
10. If there is no SOA SERIAL in the *MNAME Nameservers* set, then
terminate these procedures.
11. For each SOA SERIAL (per SOA MNAME name server name and IP address pair)
in *MNAME Nameservers* do:
1. For each SOA SERIAL in *SERIAL Nameservers* do:
1. Compare both SOA SERIAL values (using the arithmetic in [RFC1982]).
2. If the one from *SERIAL Nameservers* is higher, then add SOA MNAME name
server name, IP address and SOA SERIAL of the current SOA SERIAL value from
the *MNAME Nameservers* set to the *MNAME Not Master* set, and go
to next SOA SERIAL (from the *MNAME Nameservers* set).
2. Add SOA MNAME name server name and IP address to the *MNAME Is Master* set.
12. If the set *MNAME Not Master* is non-empty, then output *[Z01_MNAME_NOT_MASTER]*
with SOA MNAME name server name(s), IP address(es) and SOA SERIAL from the set,
along with the SOA SERIAL values from the *SERIAL Nameservers* set.
13. If the set *MNAME Is Master* is non-empty, then output *[Z01_MNAME_IS_MASTER]*
with SOA MNAME name server name(s) and IP address(es) 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.
## Intercase dependencies
None.
## Terminology
* "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.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[CONNECTIVITY01]: ../Connectivity-TP/connectivity01.md
[CONSISTENCY06]: ../Consistency-TP/consistency06.md
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
[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
[draft-jabley-dnsop-missing-mname]: https://www.ietf.org/archive/id/draft-jabley-dnsop-missing-mname-00.html
[ERROR]: ../SeverityLevelDefinitions.md#error
[INFO]: ../SeverityLevelDefinitions.md#info
[Message Tag Specification]: MessageTagSpecification.md
[Methods]: ../Methods.md
[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
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC1035]: https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.13
[RFC1982]: https://datatracker.ietf.org/doc/html/rfc1982
[RFC1996]: https://datatracker.ietf.org/doc/html/rfc1996#section-2
[RFC2136]: https://datatracker.ietf.org/doc/html/rfc2136#section-1
[RFC2181]: https://datatracker.ietf.org/doc/html/rfc2181#section-7.3
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[SYNTAX07]: ../Syntax-TP/syntax07.md
[Test Case Identifier Specification]: TestCaseIdentifierSpecification.md
[Undelegated test]: ../../test-types/undelegated-test.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Zonemaster-Engine profile]: ../../../configuration/profiles.md
[Z01_MNAME_HAS_LOCALHOST_ADDR]: #summary
[Z01_MNAME_IS_DOT]: #summary
[Z01_MNAME_IS_LOCALHOST]: #summary
[Z01_MNAME_IS_MASTER]: #summary
[Z01_MNAME_MISSING_SOA_RECORD]: #summary
[Z01_MNAME_NO_RESPONSE]: #summary
[Z01_MNAME_NOT_AUTHORITATIVE]: #summary
[Z01_MNAME_NOT_IN_NS_LIST]: #summary
[Z01_MNAME_NOT_MASTER]: #summary
[Z01_MNAME_NOT_RESOLVE]: #summary
[Z01_MNAME_UNEXPECTED_RCODE]: #summary

View File

@@ -0,0 +1,47 @@
## ZONE02: SOA 'refresh' minimum value
### Test case identifier
**ZONE02** SOA 'refresh' minimum value
### Objective
The SOA refresh value is the number of seconds that describes
how often a secondary name server will poll the primary name server
to see if there is any updates. The SOA refresh value is described
in section 3.3.13 in [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035),
and clarified in section 2.2 of
[RFC 1912](https://datatracker.ietf.org/doc/html/rfc1912).
Setting the refresh value low will increase the DNS traffic between
the servers, and also increase the load on the master name server.
The primary name server will in most cases send DNS notifications to
tell the secondary name servers that zone content has been updated,
as described in [RFC 1996](https://datatracker.ietf.org/doc/html/rfc1996).
The [RIPE-203](https://www.ripe.net/publications/docs/ripe-203) recommendation
for the refresh value is 24 hours (86400 seconds). Older DNSCheck code
had a four hour minimum value, and this is the minimum value we
recommend.
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve the SOA record from a delegated name server for the domain.
2. If the answer from step 1 is not authoritative, iterate step 1 until there is an authoritative answer.
3. Retrieve the refresh value from the SOA record.
4. If the refresh value is less than 14400 (four hours in seconds)
this test case fails.
### Outcome(s)
If the SOA refresh value is less than 14400 this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,43 @@
## ZONE03: SOA 'retry' lower than 'refresh'
### Test case identifier
**ZONE03** SOA 'retry' lower than 'refresh'
### Objective
The SOA retry value is the number of seconds that describes
minimum time elapsed since a failed zone refresh from the primary
name server. The SOA refresh value is described
in section 3.3.13 in [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035),
and clarified in section 2.2 of
[RFC 1912](https://datatracker.ietf.org/doc/html/rfc1912).
> It's typically some fraction of the refresh interval.
Setting the retry value low will increase the DNS traffic between
the servers, and also increase the load on the master name server.
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve the SOA record from a delegated name server for the domain.
2. If the answer from step 1 is not authoritative, iterate step 1 until there is an authoritative answer.
3. Retrieve the retry value from the SOA record.
4. If the retry value is higher than or equal to the refresh value,
this test case fails.
### Outcome(s)
If the SOA retry value is higher than or equal to the refresh value,
this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,44 @@
## ZONE04: SOA 'retry' at least 1 hour
### Test case identifier
**ZONE04** SOA 'retry' at least 1 hour
### Objective
The SOA retry value is the number of seconds that describes
minimum time elapsed since a failed zone refresh from the primary
name server. The SOA refresh value is described
in section 3.3.13 in [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035),
and clarified in section 2.2 of
[RFC 1912](https://datatracker.ietf.org/doc/html/rfc1912).
Setting the retry value low will increase the DNS traffic between
the servers, and also increase the load on the master name server.
The [RIPE-203](https://www.ripe.net/publications/docs/ripe-203) recommendation
for the retry value is 2 hours (7200 seconds). Older DNSCheck code
had a one hour minimum value (3600 seconds), and this is the minimum
value we recommend.
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve the SOA record from a delegated name server for the domain.
2. If the answer from step 1 is not authoritative, iterate step 1 until there is an authoritative answer.
3. Retrieve the retry value from the SOA record.
4. If the retry value is less than 3600 seconds, this test case fails.
### Outcome(s)
If the retry value is less than 3600 seconds, this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,50 @@
## ZONE05: SOA 'expire' minimum value
### Test case identifier
**ZONE05** SOA 'expire' minimum value
### Objective
The SOA expire value specifies for how long any secondary name server
keeps the zone valid without any contact with the primary name server.
This value should be greater than how long a major outage would
typically last. The expire value should also be larger than the
refresh and retry values, as described in section 3.3.13 in
[RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035), and clarified in
section 2.2 of [RFC 1912](https://datatracker.ietf.org/doc/html/rfc1912).
Setting the expire value low will increase the risk of any unwanted
non-availability of the zone because of any failures in contacting
the primary name server.
The [RIPE-203](https://www.ripe.net/publications/docs/ripe-203) recommendation
for the expire value is 1000 hours (roughly 41 days). Older DNSCheck code
had a 7 day minimum value (604800 seconds), and this is the minimum
value we recommend as an absolute minimum.
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve the SOA record from a delegated name server for the domain.
2. If the answer from step 1 is not authoritative, iterate step 1 until there is an authoritative answer.
3. Retrieve the expire value and the refresh value from the SOA record.
4. If the expire value is less than 604800 seconds (7 days), this test
case fails.
5. If the expire value is lower than the refresh value, this test case
fails.
### Outcome(s)
If the expire value is less than 604800 seconds or if the expire value is
lower than the refresh value, this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,59 @@
## ZONE06: SOA 'minimum' maximum value
### Test case identifier
**ZONE06** SOA 'minimum' maximum value
### Objective
The SOA minimum field sets the default TTL for all records in a zone.
The recommended value is to be "cache-friendly". However, for a zone
that changes content often, there is a need to keep the TTL values
shorter. The use of the SOA minimum value today is the negative cache
(where a resolver find content is missing).
The SOA minimum field is described in section 3.3.13 in
[RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035), and clarified in
section 2.2 of [RFC 1912](https://datatracker.ietf.org/doc/html/rfc1912).
The description of the implementation of negative caching is in
[RFC 2308](https://datatracker.ietf.org/doc/html/rfc2308) (although it has been
updated by several DNSSEC related RFCs, it is still relevant for this
purpose).
The [RIPE-203](https://www.ripe.net/publications/docs/ripe-203) recommendation
for the minimum value 2 days, but the negative caching is now the norm.
DNSCheck has a recommended value of between 300 seconds (5 minutes) and
86400 seconds (1 day).
### 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 SOA query for the zone.
3. Send the SOA query over UDP to each name server IP address until
a response is received or until the set is exhausted.
4. If the answer from step 3 is not authoritative, iterate step 3 until there is an authoritative answer.
5. Retrieve the SOA minimum value from the SOA record.
6. If the minimum value is larger than 86400 seconds (1 day), this test
case fails.
7. If the minimum value is lower than 300 seconds (5 minutes), this test case
fails.
### Outcome(s)
If the minimum value is larger than 86400 seconds or if the minimum value is
lower than 300 seconds, this test case fails.
### Special procedural requirements
None.
### 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

View File

@@ -0,0 +1,46 @@
## ZONE07: SOA master is not an alias
### Test case identifier
**ZONE07** SOA master is not an alias
### Objective
Any NS type record should not be a CNAME. The SOA MNAME should in this
respect not be a CNAME.
Quote from 2.4 in [RFC 1912](https://datatracker.ietf.org/doc/html/rfc1912):
> Having NS records pointing to a CNAME is bad and may conflict badly
> with current BIND servers.
The SOA MNAME field is described in section 3.3.13 in
[RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035).
The [RIPE-203](https://www.ripe.net/publications/docs/ripe-203) recommendation
for the minimum value 2 days, but the negative caching is now the norm.
DNSCheck has a recommended value of between 300 seconds (5 minutes) and
86400 seconds (1 day).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Retrieve the SOA record from a delegated name server for the domain.
2. If the answer from step 1 is not authoritative, iterate step 1 until there is an authoritative answer.
3. Retrieve the SOA MNAME value from the SOA record.
4. Query for A and AAAA records for the host from MNAME.
5. If the answer to the query is a CNAME, this test case fails.
### Outcome(s)
If the SOA MNAME field is pointing to a CNAME, this test case fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,34 @@
## ZONE08: MX is not an alias
### Test case identifier
**ZONE08** MX is not an alias
### Objective
An MX type record for a domain must not resolve to a CNAME, following
the text in section 10.3 of [RFC 2181](https://datatracker.ietf.org/doc/html/rfc2181)
and section 2.3.5 in
[RFC 5321](https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.5).
### Inputs
The domain name to be tested.
### Ordered description of steps to be taken to execute the test case
1. Query the MX record from a delegated name server for the domain.
2. If the answer from step 1 is not authoritative, iterate step 1 until there is an authoritative answer.
3. If the MX answer is a CNAME, this test case fails.
### Outcome(s)
If the MX record for the domain is pointing to a CNAME, this test case
fails.
### Special procedural requirements
None.
### Intercase dependencies
None.

View File

@@ -0,0 +1,302 @@
# ZONE09: MX record present
## Test case identifier
**ZONE09**
## 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
It is strongly recommended in [RFC 2142][RFC 2142#section-7],
section 7, that every domain should have a mailbox named
HOSTMASTER@domain (where "domain" is *Child Zone* in this test case).
> For simplicity and regularity, it is strongly recommended that the
> well known mailbox name HOSTMASTER always be used
> \<HOSTMASTER@domain\>.
This test case therefore expects for every domain (zone), excluding some cases
described below, to publish an MX record in apex of the zone (i.e. in the same
node as the SOA record).
If MX is not present, SMTP *can* deliver email using an address record (A or
AAAA) as specified in [RFC 5321][RFC 5321#section-5.1], section 5.1, but that
possibility is not in common use. This test case only checks for MX record and
ignores the possibility to use address records for email.
Even if not mentioned in [RFC 2142], there are some exceptions to the
rule to include MX and mail target for a domain.
The purpose of a zone in the .ARPA tree is to hold infrastructural identifiers,
and it is not expected that such a zone name is used as [Email Domain]
([RFC 3172]). This also means that the well known mailbox is not expected for
reverse zones (zone under in-addr.arpa or ip6.arpa). Such zone are therefore
excluded by this test case from the requirement of MX in the apex.
The root zone cannot be an [Email Domain] since the email domain is
the part to the left of the trailing dot, and the root zone owner name has
nothing left of the trailing dot. The root zone is excluded by this test case from
the requirement of MX in the apex.
Top-level domains ([TLDs][TLD]) can technically function as
[Email Domains][Email Domain] ([RCF 5321][RFC 5321#section-2.3.5], section 2.3.5)
but they rarely have that function and are probably not meant to be included in
the specification in [RFC 2142]. [Internet Architecture Board]
concludes in a report "[Dotless Domains Considered Harmful][IAB Statement]" that
domain names that only consists of one label, e.g. "se", "fr" or "com", should
not be used for various Internet services. This means [TLD] names should not be
used as [Email Domains][Email Domain]. In this test case [TLDs][TLD] are not only
excluded from the requirement of being an [Email Domain], if found to be, a
message will be generated that points that out.
[RFC 7505] standardizes "[Null MX]" which means that there is no email service
for the domain. A "[Null MX]" is accepted for any type of domain.
[RFC 7505][RFC 7505#section-3], section 3, also specifies that the "[Null MX]"
must be the sole MX record and its preference must be zero.
In this test case, the following zone types are excluded from the requirement of
MX:
* Root zone
* [TLD] zone
* Zone in the .ARPA tree
The following zone type is expected not to have any MX (considered harmful,
see [IAB Statement]):
* [TLD] zone
## 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.
## Inputs
* "Child Zone" - The domain name to be tested.
## Summary
* A notify is issued if MX is missing, except for root, a zone in the ARPA tree
or a [TLD].
* A warning is issued if a [TLD] *has* a [non-Null MX][Null MX].
Message Tag | Level | Arguments | Message ID for message tag
:--------------------------|:------|:----------------------------|:--------------------------------------------
Z09_INCONSISTENT_MX |WARNING| | Some name servers return an MX RRset while others return none.
Z09_INCONSISTENT_MX_DATA |WARNING| | The MX RRset data is inconsistent between the name servers.
Z09_MISSING_MAIL_TARGET | NOTICE| | The child zone has no mail target (no MX).
Z09_MX_DATA | INFO | ns_ip_list, mailtarget_list | The mail targets in the MX RRset, "{mailtarget_list}", as returned by name servers "{ns_ip_list}".
Z09_MX_FOUND | INFO | ns_ip_list | MX RRset was returned by name servers "{ns_ip_list}".
Z09_NON_AUTH_MX_RESPONSE |WARNING| ns_ip_list | Non-authoritative response on MX query from name servers "{ns_ip_list}".
Z09_NO_MX_FOUND | INFO | ns_ip_list | No MX RRset was returned by name servers "{ns_ip_list}".
Z09_NO_RESPONSE_MX_QUERY |WARNING| ns_ip_list | No response on MX query from name servers "{ns_ip_list}".
Z09_NULL_MX_NON_ZERO_PREF | NOTICE| | The zone has a Null MX with non-zero preference.
Z09_NULL_MX_WITH_OTHER_MX |WARNING| | The zone has a Null MX mixed with other MX records.
Z09_ROOT_EMAIL_DOMAIN | NOTICE| | Root zone with an unexpected MX RRset (non-Null MX).
Z09_TLD_EMAIL_DOMAIN |WARNING| | The zone is a TLD and has an unexpected MX RRset (non-Null MX).
Z09_UNEXPECTED_RCODE_MX |WARNING | ns_ip_list, rcode | Unexpected RCODE value ({rcode}) in response to MX query. Responses from name servers "{ns_ip_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].
## 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 a [DNS Query] with query type MX and query name *Child Zone*
("MX Query").
3. Obtain the set of name server IP addresses using [Method4] and [Method5]
("Name Server IP").
4. Create the following empty sets
1. Name server IP address ("No Response MX Query").
2. Name server IP address and associated RCODE value
("Unexpected RCODE MX Response").
3. Name server IP address ("Non-authoritative MX").
4. Name server IP address ("No MX RRset").
5. Name server IP address and associated MX RRset ("MX RRset").
5. For each name server IP in *Name Server IP* do:
1. Send *SOA Query* over UDP to the name server.
2. 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 of the response is not "NoError" ([IANA RCODE List]).
3. The AA flag is not set in the response.
4. There is no SOA record with owner name matching the query.
2. Send *MX Query* over UDP to the name server and collect the
response, and:
1. If the response has the TC flag set, re-query over TCP and use that
response instead.
2. If there is no DNS response, then add the name server IP to the
*No Response MX Query* set.
3. Else, if the RCODE of response is not "NoError" ([IANA RCODE List]),
then add the name server IP and the RCODE to the
*Unexpected RCODE MX Response* set.
4. Else, if the AA flag is not set in the response, then add the name
server IP to the *Non-authoritative MX* set.
5. Else, if there is no MX record with matching owner name in the answer
section, then add the name server (IP) to the *No MX RRset* set.
6. Else do:
1. Extract the MX RRset from the response.
2. Add the name server IP and the MX RRset to the *MX RRset* set.
6. If the set *No Response MX Query* is non-empty, then output
*[Z09_NO_RESPONSE_MX_QUERY]* with the name server IP addresses from the set.
7. If the set *Unexpected RCODE MX Response* is non-empty, then for each RCODE
in the set, do:
* Output *[Z09_UNEXPECTED_RCODE_MX]* with the RCODE value
([IANA RCODE List]) and the name server IP addresses from the set.
8. If the set *Non-authoritative MX* is non-empty, then output
*[Z09_NON_AUTH_MX_RESPONSE]* with the name server IP addresses from
the set.
9. If both *No MX RRset* set and *MX RRset* set are non-empty then:
1. Output *[Z09_INCONSISTENT_MX]*.
2. Output *[Z09_NO_MX_FOUND]* with the name server IP addresses from the
*No MX RRset* set.
3. Output *[Z09_MX_FOUND]* with the name server IP addresses from the
*MX RRset* set.
10. If the *MX RRset* set is non-empty (the *No MX RRset* set is empty or
non-empty), then do:
1. If the RRsets in *MX RRset* are not equal for all name servers then do:
1. Output *[Z09_INCONSISTENT_MX_DATA]*.
2. For each RRset in *MX RRset*, output *[Z09_MX_DATA]* with the mail
targets from the RDATA and the associated name server IP addresses in
the set.
2. Else do:
1. If the mailtarget of any of the MX records in the RRset in *MX RRset*
is a [Null MX] then do:
1. If there are more than one record in the MX RRset, then output
*[Z09_NULL_MX_WITH_OTHER_MX]* with the mail targets from the RDATA
of MX records.
2. If the preference of the [Null MX] is non-zero then output
*[Z09_NULL_MX_NON_ZERO_PREF]*.
2. Else, if *Child Zone* is a [TLD] with a [non-Null MX][Null MX] then
output *[Z09_TLD_EMAIL_DOMAIN]*.
3. Else, if *Child Zone* is the root zone with a [non-Null MX][Null MX] then
output *[Z09_ROOT_EMAIL_DOMAIN]*.
4. Else, output *[Z09_MX_DATA]* with the mail targets from the RDATA and
the associated name server IP addresses in the set.
11. If the *No MX RRset* set is non-empty and the *MX RRset* set is empty, then
output *[Z09_MISSING_MAIL_TARGET]* unless
1. *Child Zone* is the root zone ("."), or
2. *Child Zone* is a [TLD], or
3. *Child Zone* is a zone in the .ARPA tree.
## 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 and log a message reporting
the ignored result.
## Intercase dependencies
None.
## Terminology
The term "Null MX" is used for an MX record where the mail target is "." as
defined in [RFC 7505] with the specific restrictions given in
[section 3][RFC 7505#section-3] of that RFC.
The term "TLD" is used for "Top Level Domain", i.e. a zone whose name consists
of a single label (ignoring the empty label after the final dot).
The term "Email Domain" is used for the domain name at right of the at-sign ("@")
in an email address.
[Argument list]: ../ArgumentsForTestCaseMessages.md
[Connectivity01]: ../Connectivity-TP/connectivity01.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
[Email Domain]: #terminology
[IAB Statement]: https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
[IANA RCODE List]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[INFO]: ../SeverityLevelDefinitions.md#info
[Internet Architecture Board]: https://en.wikipedia.org/wiki/Internet_Architecture_Board
[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
[Null MX]: #terminology
[RFC 2142#section-7]: https://datatracker.ietf.org/doc/html/rfc2142#section-7
[RFC 2142]: https://datatracker.ietf.org/doc/html/rfc2142
[RFC 3172]: https://datatracker.ietf.org/doc/html/rfc3172
[RFC 5321#section-2.3.5]: https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.5
[RFC 5321#section-5.1]: https://datatracker.ietf.org/doc/html/rfc5321#section-5.1
[RFC 7505#section-3]: https://datatracker.ietf.org/doc/html/rfc7505#section-3
[RFC 7505]: https://datatracker.ietf.org/doc/html/rfc7505
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[TLD]: #terminology
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Z09_INCONSISTENT_MX]: #summary
[Z09_INCONSISTENT_MX_DATA]: #summary
[Z09_MISSING_MAIL_TARGET]: #summary
[Z09_MX_DATA]: #summary
[Z09_MX_FOUND]: #summary
[Z09_NON_AUTH_MX_RESPONSE]: #summary
[Z09_NO_MX_FOUND]: #summary
[Z09_NO_RESPONSE_MX_QUERY]: #summary
[Z09_NULL_MX_NON_ZERO_PREF]: #summary
[Z09_NULL_MX_WITH_OTHER_MX]: #summary
[Z09_ROOT_EMAIL_DOMAIN]: #summary
[Z09_TLD_EMAIL_DOMAIN]: #summary
[Z09_UNEXPECTED_RCODE_MX]: #summary
[Zonemaster-Engine profile]: ../../../configuration/profiles.md

View File

@@ -0,0 +1,100 @@
# ZONE10: No multiple SOA records
## Test case identifier
**ZONE10**
## Objective
The SOA record is crucial for the DNS zone and "exactly one SOA RR should
be present at the top of the zone" ([RFC 1035][RFC 1035#5.2], section 5.2).
This test case will verify that the zone of the domain to be tested return
exactly one SOA record.
## 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 IP addresses using [Method4] and [Method5]
("NS IP").
2. Create a SOA query for the apex of the *Child Zone* with RD flag unset.
3. For each name server in *NS IP* do:
1. Send the SOA query over UDP to the name server.
2. If the name server does not respond with a DNS response, then
output *[NO_RESPONSE]*.
3. Else, if the DNS response does not include a SOA record in the
answer section, then output *[NO_SOA_IN_RESPONSE]*.
4. Else, if the SOA record or records in the answer section do not
have *Child Zone* as owner name, then output *[WRONG_SOA]*.
5. Else, if the DNS response includes multiple SOA records in the
answer section, then output *[MULTIPLE_SOA]*.
4. If no message is outputted for any server, then output *[ONE_SOA]*.
## 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
:-----------------------------|:-----------------------------------
MULTIPLE_SOA | ERROR
NO_RESPONSE | DEBUG
NO_SOA_IN_RESPONSE | DEBUG
ONE_SOA | INFO
WRONG_SOA | 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.
## Terminology
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.
[Connectivity01]: ../Connectivity-TP/connectivity01.md
[MULTIPLE_SOA]: #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
[Methods]: ../Methods.md
[NO_RESPONSE]: #outcomes
[NO_SOA_IN_RESPONSE]: #outcomes
[ONE_SOA]: #outcomes
[RFC 1035#5.2]: https://datatracker.ietf.org/doc/html/rfc1035#section-5.2
[WRONG_SOA]: #outcomes
[terminology]: #terminology

View File

@@ -0,0 +1,287 @@
# ZONE11: SPF policy validation
## Test case identifier
**ZONE11**
## 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
Sender Policy Framework (SPF) version 1, defined in [RFC 7208], is a mechanism
allowing domain name owners to specify which hosts are allowed to send mail
claiming to be from that domain. It is implemented by means of TXT records in
a structured format.
This test case looks up SPF records in the apex of *Child Zone*. It checks
that there is at most one published SPF policy and, if present, also checks
its syntax.
The root zone ("."), [TLD] zones and zones under .ARPA are treated
differently. These zones are not expected to be used as [Email Domains][Email
Domain]. For these zones, this test case generates a message if an [non-null
SPF][Null SPF] policy is found.
The root zone cannot be an [Email Domain] because according to the syntax
rules in [RFC 5321, section 4.1.2][RFC 5321#4.1.2], it is not possible to
construct an email address having the root name (".") as domain part.
Although top-level domains ([TLDs][TLD]) can technically function as [Email
Domains][Email Domain] ([RFC 5321, section 2.3.5][RFC 5321#2.3.5]), they
usually do not have this purpose. The [Internet Architecture Board] concludes
in a report named "[Dotless Domains Considered Harmful]" that domain names
that only consists of one label, e.g. "se", "fr" or "com", should not be used
for various Internet services. This means [TLD] names should not be used as
[Email Domains][Email Domain].
As for .ARPA, [RFC 3172] states that "This domain is termed an 'infrastructure
domain', as its role is to support the operating infrastructure of the
Internet. In particular, the 'arpa' domain is not to be used in the same
manner (e.g., for naming hosts) as other generic Top Level Domains are
commonly used". This means any name under .ARPA should not be used as [Email
Domains][Email Domain].
## Scope
It is assumed that *Child Zone* has been 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.
## Summary
Message Tag | Level | Arguments | Message ID for message tag
:--------------------------------|:--------|:----------------|:--------------------------------------------
Z11_DIFFERENT_SPF_POLICIES_FOUND | NOTICE | ns_list | The following name servers returned the same SPF policy. Name servers: {ns_list}.
Z11_INCONSISTENT_SPF_POLICIES | WARNING | | One or more name servers do not publish the same SPF policy as the others.
Z11_NO_SPF_FOUND | NOTICE | domain | No SPF policy was found for {domain}.
Z11_NO_SPF_NON_MAIL_DOMAIN | INFO | domain | No SPF policy was found for {domain}, which is a type of domain (root, TLD or under .ARPA) not expected to be used for email.
Z11_NON_NULL_SPF_NON_MAIL_DOMAIN | NOTICE | domain | A non-null SPF policy was found on {domain}, although this type of domain (root, TLD or under .ARPA) is not expected to be used for email.
Z11_NULL_SPF_NON_MAIL_DOMAIN | INFO | domain | A null SPF policy was found on {domain}, which is a type of domain (root, TLD or under .ARPA) not expected to be used for email.
Z11_SPF_MULTIPLE_RECORDS | WARNING | ns_list | The following name servers returned more than one SPF policy. Name servers: {ns_list}.
Z11_SPF_SYNTAX_ERROR | WARNING | domain, ns_list | The SPF policy of {domain} has a syntax error. Policy retrieved from the following nameservers: {ns_list}.
Z11_SPF_SYNTAX_OK | INFO | domain | The SPF policy of {domain} has correct syntax.
Z11_UNABLE_TO_CHECK_FOR_SPF | WARNING | | None of the zones name servers responded with an authoritative response to queries for SPF policies.
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].
Name servers may have multiple IP addresses bound to the same name, and the
same IP address may be used by multiple name server names. Message tags whose
argument lists include "ns_list" shall contain all such name and IP address
pairs.
## 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 a [DNS Query] with query type TXT and query name *Child Zone* ("TXT
query").
2. Create an empty set of pairs of (names and IP address) pairs and strings,
"SPF-Policies".
3. 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] ("Name
Servers").
4. For each distinct name server IP address in *Name Servers* do:
1. Send *TXT Query* to the name server and collect the [DNS Response].
2. Go to the next name server if at least one of the following criteria is
met:
1. There is no DNS response.
2. [RCODE Name] of the response is not "NoError".
3. The AA flag is not set in the response.
3. If the name server responds with no TXT record, then add the pair
consisting of the *Name Servers* and the empty string to the
*SPF-Policies* set.
4. If the name server responds with at least one TXT record and none is an
[SPF TXT record], then add the pair consisting of the *Name Servers*
and the empty string to the *SPF-Policies* set.
5. If the name server responds with at least one TXT record that is an [SPF
TXT record], then, for each [SPF TXT record] do:
1. [Concatenate] all strings in the RDATA field.
2. Lowercase the resulting string.
3. Add a pair consisting of the *Name Servers* and the lowercase
string thus derived from the RDATA field to the *SPF-Policies* set.
6. Go to the next name server.
5. If the *SPF-Policies* set is empty, then output
*[Z11_UNABLE_TO_CHECK_FOR_SPF]* and terminate the test.
6. If all the name server IPs in the *SPF-Policies* set contain empty strings
(no "SPF policy"), then:
1. If the *Child Zone* is the root zone ("."), a [TLD] or a zone under
.ARPA, then output *[Z11_NO_SPF_NON_MAIL_DOMAIN]* for *Child Zone* and
terminate the test.
2. Else, output *[Z11_NO_SPF_FOUND]* for *Child Zone* and terminate the
test.
7. For all messages outputted below, if an IP address in *Name Servers* is
connected to more than one name server name, then all names should be
included with the message tag.
8. Compare the set of *SPF-Policies* retrieved from all name servers (in the
*SPF-Policies* set). If at least two different name servers have returned
different sets of SPF policies, then:
1. Output *[Z11_INCONSISTENT_SPF_POLICIES]*.
2. Group *SPF-Policies* by equal sets of SPF policies, such that a set of
SPF policies is mapped to the list of *Name Servers* that returned it.
3. For each such group of name servers, output
*[Z11_DIFFERENT_SPF_POLICIES_FOUND]* with the set of name servers
("ns_list") in the group.
4. Terminate the test.
9. If the *SPF-Policies* set contains at least two entries with the same IP
address, then output *[Z11_SPF_MULTIPLE_RECORDS]* with the list of
name servers that returned more than one SPF policy and terminate the test.
10. The following steps assume that all name server IPs in the *SPF-Policies*
set have the same string ("SPF policy").
11. If the *SPF Policy* does not [pass the syntax check][passing the syntax
check] for SPF records, then output *[Z11_SPF_SYNTAX_ERROR]* for *Child
Zone* and the set of name servers from which the *SPF Policy* was
retrieved, and terminate the test.
12. If the *Child Zone* is the root zone ("."), a [TLD] or a zone under
.ARPA, then:
1. If the *SPF Policy* is a [Null SPF] policy, then output
*[Z11_NULL_SPF_NON_MAIL_DOMAIN]* for *Child Zone* and terminate the
test.
2. If the *SPF Policy* is not a [Null SPF] policy, then output
*[Z11_NON_NULL_SPF_NON_MAIL_DOMAIN]* for *Child Zone* and terminate the
test.
13. If no other message was outputted by this test case, then output
*[Z11_SPF_SYNTAX_OK]* for *Child 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, skip sending queries over that
transport protocol. A message will be outputted reporting that the transport
protocol has been skipped.
## Intercase dependencies
None.
## Terminology
* "concatenate" - The term is used to refer to the conversion of a TXT
resource records data to a single contiguous string, as specified in [RFC
7208, section 3.3][RFC 7208#3.3].
* "Email Domain" - the domain name at the right of the at-sign ("@") in an
email address.
* "passing the syntax check" - The term is used in this document to refer to
text that is valid according to the ABNF grammar published in [RFC 7208]
starting from [section 4.5][RFC 7208#4.5]. Alternatively, the reader may use
an [online SPF syntax validator]; however, such online validators should not
be used as normative references.
* "Null SPF" - The term is used to refer to a SPF policy record which contains
a single term, `-all`. It designates no server as permitted sender and
evaluation of such an SPF policy is therefore guaranteed to return a failure.
* "SPF TXT record" - The term is used to refer to a TXT resource record which,
after [concatenating][concatenate] all strings within that resource record
into one string, yields a string either equal to `v=spf1` or starting with
`v=spf1` followed by a space, irrespective of character case.
* "TLD" - The term is used to refer to a "Top Level Domain", i.e. a zone whose
name consists of a single label (ignoring the empty label after the final
dot).
[Argument list]: ../ArgumentsForTestCaseMessages.md
[argument]: #terminology
[concatenate]: #terminology
[Connectivity01]: ../Connectivity-TP/connectivity01.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
[Dotless Domains Considered Harmful]: https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
[Email Domain]: #terminology
[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
[Internet Architecture Board]: https://www.iab.org/
[Message Tag Specification]: MessageTagSpecification.md
[Null SPF]: #terminology
[NOTICE]: ../SeverityLevelDefinitions.md#notice
[online SPF syntax validator]: https://vamsoft.com/support/tools/spf-syntax-validator
[passing the syntax check]: #terminology
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 3172]: https://datatracker.ietf.org/doc/html/rfc3172
[RFC 5321#2.3.5]: https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.5
[RFC 5321#4.1.2]: https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.2
[RFC 7208#3.3]: https://www.rfc-editor.org/rfc/rfc7208#section-3.3
[RFC 7208#4.5]: https://www.rfc-editor.org/rfc/rfc7208#section-4.5
[RFC 7208]: https://www.rfc-editor.org/rfc/rfc7208
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
[SPF TXT record]: #terminology
[Test Case Identifier Specification]: TestCaseIdentifierSpecification.md
[TLD]: #terminology
[Undelegated test]: ../../test-types/undelegated-test.md
[WARNING]: ../SeverityLevelDefinitions.md#warning
[Z11_DIFFERENT_SPF_POLICIES_FOUND]: #summary
[Z11_INCONSISTENT_SPF_POLICIES]: #summary
[Z11_NO_SPF_FOUND]: #summary
[Z11_NO_SPF_NON_MAIL_DOMAIN]: #summary
[Z11_NON_NULL_SPF_NON_MAIL_DOMAIN]: #summary
[Z11_NULL_SPF_NON_MAIL_DOMAIN]: #summary
[Z11_SPF_MULTIPLE_RECORDS]: #summary
[Z11_SPF_SYNTAX_ERROR]: #summary
[Z11_SPF_SYNTAX_OK]: #summary
[Z11_UNABLE_TO_CHECK_FOR_SPF]: #summary
[Zone09 test specification]: zone09.md
[Zonemaster-Engine profile]: ../../../configuration/profiles.md