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:
1
zonemaster/docs/public/LICENSE.md
Symbolic link
1
zonemaster/docs/public/LICENSE.md
Symbolic link
@@ -0,0 +1 @@
|
||||
../../LICENSE
|
||||
59
zonemaster/docs/public/README.md
Normal file
59
zonemaster/docs/public/README.md
Normal file
@@ -0,0 +1,59 @@
|
||||
# Public documentation
|
||||
|
||||
*Click on [SUMMARY](SUMMARY.md) to view a linked tree structure of the public
|
||||
documentation.*
|
||||
|
||||
<!-- A copy of the text below is found in ../README-for-doc.zonemaster.net.md
|
||||
and if any update is done here, make sure to update there too. -->
|
||||
|
||||
The public documentation is divided into the following main categories:
|
||||
|
||||
* [Release information](RELEASE.md) gives release information of latest release.
|
||||
* [Installation](installation/README.md) contains documents that explain how to
|
||||
install the different components of Zonemaster.
|
||||
* [Upgrading](upgrading/README.md) contains documents that explain how to upgrade
|
||||
a Zonemaster installation.
|
||||
* [Configuration](configuration/README.md) contains documents that explain how a
|
||||
Zonemaster installation can be configured.
|
||||
* [Using](using/README.md) contains user guides to the different components of
|
||||
Zonemaster.
|
||||
* [Specifications](specifications/README.md) contains specifications of the
|
||||
Zonemaster test cases, test types and test zones.
|
||||
* [Development](development/README.md) contains information for developers both
|
||||
in and outside the Zonemaster project.
|
||||
* [License](LICENSE.md) gives the license information for Zonemaster.
|
||||
|
||||
## Rendering
|
||||
|
||||
Renderings of the public documentation are published to [doc.zonemaster.net] for
|
||||
every release version since v2023.1. It can be built locally using [mdbook], its
|
||||
[mdbook-linkcheck] plugin.
|
||||
|
||||
1. Get a copy of the source tree by cloning the [repository] or downloading an
|
||||
archive of one of the [releases].
|
||||
2. Change to the `docs/public` directory and build the book.
|
||||
```
|
||||
cd docs/public
|
||||
mdbook build
|
||||
```
|
||||
3. To view the content there are a few options:
|
||||
|
||||
* Open the index file if your OS has support for it:
|
||||
```
|
||||
open book/index.html
|
||||
```
|
||||
* Let mdbook serve it on local computer. Run the following command and open
|
||||
[localhost:3000] in your browser.
|
||||
```
|
||||
mdbook serve
|
||||
```
|
||||
* Copy the `book` directory with all files to your computer, go directly to
|
||||
that directory and open `book/index.html`.
|
||||
|
||||
|
||||
[doc.zonemaster.net]: https://doc.zonemaster.net
|
||||
[localhost:3000]: http://localhost:3000
|
||||
[releases]: https://github.com/zonemaster/zonemaster/releases
|
||||
[repository]: https://github.com/zonemaster/zonemaster
|
||||
[mdbook]: https://rust-lang.github.io/mdBook/
|
||||
[mdbook-linkcheck]: https://github.com/Michael-F-Bryan/mdbook-linkcheck
|
||||
60
zonemaster/docs/public/RELEASE.md
Normal file
60
zonemaster/docs/public/RELEASE.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# Release v2025.2.1 (2026-03-04)
|
||||
|
||||
### \[Release information\]
|
||||
- Fixes in [Zonemaster-LDNS], [Zonemaster-Engine] and [Zonemaster-GUI].
|
||||
|
||||
### \[Breaking changes\]
|
||||
- None for this release
|
||||
|
||||
### \[Deprecations\]
|
||||
- None for this release
|
||||
|
||||
### \[Fixes\]
|
||||
- Adds documentation on running Zonemaster-Backend through Docker, and update documentation on Zonemaster-GUI translation ([#1464])
|
||||
|
||||
### \[Zonemaster product\]
|
||||
This version of Zonemaster also consists of the following components. For each component, see its Changes file or Github release notes for complete release information.
|
||||
|
||||
Component | Github release notes | Changes file | Updated in this release
|
||||
---------------------|:----------------------:|----------------------------|:----------------------:
|
||||
[Zonemaster-LDNS] | [v5.0.2][ldns-tag] | [Changes][ldns-Changes] | Yes
|
||||
[Zonemaster-Engine] | [v8.1.1][engine-tag] | [Changes][engine-Changes] | Yes
|
||||
[Zonemaster-CLI] | [v8.0.1][cli-tag] | [Changes][cli-Changes] | No
|
||||
[Zonemaster-Backend] | [v12.0.0][backend-tag] | [Changes][backend-Changes] | No
|
||||
[Zonemaster-GUI] | [v5.0.1][gui-tag] | [Changes][gui-Changes] | Yes
|
||||
|
||||
For more information on previous versions of the Zonemaster product see the [Changes][zonemaster-Changes] file or the [releases] page on Github. For general information see the [README] file.
|
||||
|
||||
The public documentation is also found in a nicer format on the [documentation site]. Zonemaster can be used and tested on the [reference installation].
|
||||
|
||||
[README]: https://github.com/zonemaster/zonemaster/blob/master/README.md
|
||||
[releases]: https://github.com/zonemaster/zonemaster/releases
|
||||
[documentation site]: https://doc.zonemaster.net/
|
||||
[reference installation]: https://zonemaster.net/
|
||||
|
||||
[ldns-tag]: https://github.com/zonemaster/zonemaster-ldns/releases/tag/v5.0.2
|
||||
[engine-tag]: https://github.com/zonemaster/zonemaster-engine/releases/tag/v8.1.1
|
||||
[cli-tag]: https://github.com/zonemaster/zonemaster-cli/releases/tag/v8.0.1
|
||||
[backend-tag]: https://github.com/zonemaster/zonemaster-backend/releases/tag/v12.0.0
|
||||
[gui-tag]: https://github.com/zonemaster/zonemaster-gui/releases/tag/v5.0.1
|
||||
|
||||
[zonemaster-Changes]: https://github.com/zonemaster/zonemaster/blob/master/Changes
|
||||
[ldns-Changes]: https://github.com/zonemaster/zonemaster-ldns/blob/master/Changes
|
||||
[engine-Changes]: https://github.com/zonemaster/zonemaster-engine/blob/master/Changes
|
||||
[cli-Changes]: https://github.com/zonemaster/zonemaster-cli/blob/master/Changes
|
||||
[backend-Changes]: https://github.com/zonemaster/zonemaster-backend/blob/master/Changes
|
||||
[gui-Changes]: https://github.com/zonemaster/zonemaster-gui/blob/master/Changes
|
||||
|
||||
[Zonemaster-LDNS]: https://github.com/zonemaster/zonemaster-ldns
|
||||
[Zonemaster-Engine]: https://github.com/zonemaster/zonemaster-engine
|
||||
[Zonemaster-CLI]: https://github.com/zonemaster/zonemaster-cli
|
||||
[Zonemaster-Backend]: https://github.com/zonemaster/zonemaster-backend
|
||||
[Zonemaster-GUI]: https://github.com/zonemaster/zonemaster-gui
|
||||
|
||||
[NOTICE]: https://github.com/zonemaster/zonemaster/blob/master/docs/public/specifications/tests/SeverityLevelDefinitions.md#notice
|
||||
[WARNING]: https://github.com/zonemaster/zonemaster/blob/master/docs/public/specifications/tests/SeverityLevelDefinitions.md#warning
|
||||
|
||||
[#1464]: https://github.com/zonemaster/zonemaster/pull/1464
|
||||
|
||||
|
||||
|
||||
182
zonemaster/docs/public/SUMMARY.md
Normal file
182
zonemaster/docs/public/SUMMARY.md
Normal file
@@ -0,0 +1,182 @@
|
||||
<!-- This file must match the format described in
|
||||
https://rust-lang.github.io/mdBook/format/summary.html -->
|
||||
# Documents in public document tree
|
||||
|
||||
- [Overview](README.md)
|
||||
- [Release information](RELEASE.md)
|
||||
- [Installation](installation/README.md)
|
||||
- [Prerequisites](installation/prerequisites.md)
|
||||
- [Zonemaster-LDNS](installation/zonemaster-ldns.md)
|
||||
- [Zonemaster-Engine](installation/zonemaster-engine.md)
|
||||
- [Zonemaster-CLI](installation/zonemaster-cli.md)
|
||||
- [Zonemaster-Backend](installation/zonemaster-backend.md)
|
||||
- [Zonemaster-GUI](installation/zonemaster-gui.md)
|
||||
- [Docker](installation/docker.md)
|
||||
- [Upgrading](upgrading/README.md)
|
||||
- [GUI](upgrading/gui.md)
|
||||
- [Backend](upgrading/backend.md)
|
||||
- [v1.0.3](upgrading/backend/upgrade_zonemaster_backend_ver_1.0.3.md)
|
||||
- [v1.1.0](upgrading/backend/upgrade_zonemaster_backend_ver_1.1.0.md)
|
||||
- [v5.0.0](upgrading/backend/upgrade_zonemaster_backend_ver_5.0.0.md)
|
||||
- [v5.0.2](upgrading/backend/upgrade_zonemaster_backend_ver_5.0.2.md)
|
||||
- [v8.0.0](upgrading/backend/upgrade_zonemaster_backend_ver_8.0.0.md)
|
||||
- [v9.0.0](upgrading/backend/upgrade_zonemaster_backend_ver_9.0.0.md)
|
||||
- [v11.1.0](upgrading/backend/upgrade_zonemaster_backend_ver_11.1.0.md)
|
||||
- [v11.2.0](upgrading/backend/upgrade_zonemaster_backend_ver_11.2.0.md)
|
||||
- [Configuration](configuration/README.md)
|
||||
- [Profiles](configuration/profiles.md)
|
||||
- [Global Cache](configuration/global-cache.md)
|
||||
- [Backend configuration in "backend_config.ini"](configuration/backend.md)
|
||||
- [Backend environment variables](configuration/backend-environment-variables.md)
|
||||
- [GUI](configuration/gui/README.md)
|
||||
- [Building a custom Zonemaster-GUI](configuration/gui/building-custom-gui.md)
|
||||
- [Run-time configuration using "config.json"](configuration/gui/configuring-using-config-json.md)
|
||||
- [Simple build-time configuration using "config.ts"](configuration/gui/configuring-using-config-ts.md)
|
||||
- [Advanced build-time configuration using "tsconfig.json"](configuration/gui/configuring-using-tsconfig-json.md)
|
||||
- [Configuring using Theming](configuration/gui/configuring-using-theming.md)
|
||||
- [Using](using/README.md)
|
||||
- [CLI](using/cli.md)
|
||||
- [Backend](using/backend/README.md)
|
||||
- [Using Zonemaster-Backend JSON-RPC API](using/backend/Using-Zonemaster-Backend-JSON-RPC-API.md)
|
||||
- [Using Zonemaster-Backend for batch testing](using/backend/Using-Zonemaster-Backend-for-batch-testing.md)
|
||||
- [Using Zonemaster-Backend Docker container](using/backend/Using-Zonemaster-Backend-Docker.md)
|
||||
- [RPCAPI Reference](using/backend/rpcapi-reference.md)
|
||||
- [Telemetry](using/backend/telemetry.md)
|
||||
- [GUI](using/gui/README.md)
|
||||
- [API](using/gui/api.md)
|
||||
- [Specifications](specifications/README.md)
|
||||
- [Test Cases](specifications/tests/README.md)
|
||||
- [Master Test Plan](specifications/tests/MasterTestPlan.md)
|
||||
- [Methods](specifications/tests/Methods.md)
|
||||
- [MethodsV2](specifications/tests/MethodsV2.md)
|
||||
- [Test Messages](specifications/tests/TestMessages.md)
|
||||
- [Severity Level Definitions](specifications/tests/SeverityLevelDefinitions.md)
|
||||
- [DNS Query and Response](specifications/tests/DNSQueryAndResponseDefaults.md)
|
||||
- [Requirements and Normalization](specifications/tests/RequirementsAndNormalizationOfDomainNames.md)
|
||||
- [Arguments For Test Case Messages](specifications/tests/ArgumentsForTestCaseMessages.md)
|
||||
- [Implemented Test Cases](specifications/tests/ImplementedTestCases.md)
|
||||
- [Address-TP](specifications/tests/Address-TP/README.md)
|
||||
- [Address01](specifications/tests/Address-TP/address01.md)
|
||||
- [Address02](specifications/tests/Address-TP/address02.md)
|
||||
- [Address03](specifications/tests/Address-TP/address03.md)
|
||||
- [Basic-TP](specifications/tests/Basic-TP/README.md)
|
||||
- [Basic01](specifications/tests/Basic-TP/basic01.md)
|
||||
- [Basic02](specifications/tests/Basic-TP/basic02.md)
|
||||
- [Basic03](specifications/tests/Basic-TP/basic03.md)
|
||||
- [Connectivity-TP](specifications/tests/Connectivity-TP/README.md)
|
||||
- [Connectivity01](specifications/tests/Connectivity-TP/connectivity01.md)
|
||||
- [Connectivity02](specifications/tests/Connectivity-TP/connectivity02.md)
|
||||
- [Connectivity03](specifications/tests/Connectivity-TP/connectivity03.md)
|
||||
- [Connectivity04](specifications/tests/Connectivity-TP/connectivity04.md)
|
||||
- [Consistency-TP](specifications/tests/Consistency-TP/README.md)
|
||||
- [Consistency01](specifications/tests/Consistency-TP/consistency01.md)
|
||||
- [Consistency02](specifications/tests/Consistency-TP/consistency02.md)
|
||||
- [Consistency03](specifications/tests/Consistency-TP/consistency03.md)
|
||||
- [Consistency04](specifications/tests/Consistency-TP/consistency04.md)
|
||||
- [Consistency05](specifications/tests/Consistency-TP/consistency05.md)
|
||||
- [Consistency06](specifications/tests/Consistency-TP/consistency06.md)
|
||||
- [DNSSEC-TP](specifications/tests/DNSSEC-TP/README.md)
|
||||
- [DNSSEC01](specifications/tests/DNSSEC-TP/dnssec01.md)
|
||||
- [DNSSEC02](specifications/tests/DNSSEC-TP/dnssec02.md)
|
||||
- [DNSSEC03](specifications/tests/DNSSEC-TP/dnssec03.md)
|
||||
- [DNSSEC04](specifications/tests/DNSSEC-TP/dnssec04.md)
|
||||
- [DNSSEC05](specifications/tests/DNSSEC-TP/dnssec05.md)
|
||||
- [DNSSEC06](specifications/tests/DNSSEC-TP/dnssec06.md)
|
||||
- [DNSSEC07](specifications/tests/DNSSEC-TP/dnssec07.md)
|
||||
- [DNSSEC08](specifications/tests/DNSSEC-TP/dnssec08.md)
|
||||
- [DNSSEC09](specifications/tests/DNSSEC-TP/dnssec09.md)
|
||||
- [DNSSEC10](specifications/tests/DNSSEC-TP/dnssec10.md)
|
||||
- [DNSSEC11](specifications/tests/DNSSEC-TP/dnssec11.md)
|
||||
- [DNSSEC12](specifications/tests/DNSSEC-TP/dnssec12.md)
|
||||
- [DNSSEC13](specifications/tests/DNSSEC-TP/dnssec13.md)
|
||||
- [DNSSEC14](specifications/tests/DNSSEC-TP/dnssec14.md)
|
||||
- [DNSSEC15](specifications/tests/DNSSEC-TP/dnssec15.md)
|
||||
- [DNSSEC16](specifications/tests/DNSSEC-TP/dnssec16.md)
|
||||
- [DNSSEC17](specifications/tests/DNSSEC-TP/dnssec17.md)
|
||||
- [DNSSEC18](specifications/tests/DNSSEC-TP/dnssec18.md)
|
||||
- [Delegation-TP](specifications/tests/Delegation-TP/README.md)
|
||||
- [Delegation01](specifications/tests/Delegation-TP/delegation01.md)
|
||||
- [Delegation02](specifications/tests/Delegation-TP/delegation02.md)
|
||||
- [Delegation03](specifications/tests/Delegation-TP/delegation03.md)
|
||||
- [Delegation04](specifications/tests/Delegation-TP/delegation04.md)
|
||||
- [Delegation05](specifications/tests/Delegation-TP/delegation05.md)
|
||||
- [Delegation06](specifications/tests/Delegation-TP/delegation06.md)
|
||||
- [Delegation07](specifications/tests/Delegation-TP/delegation07.md)
|
||||
- [Nameserver-TP](specifications/tests/Nameserver-TP/README.md)
|
||||
- [Nameserver01](specifications/tests/Nameserver-TP/nameserver01.md)
|
||||
- [Nameserver02](specifications/tests/Nameserver-TP/nameserver02.md)
|
||||
- [Nameserver03](specifications/tests/Nameserver-TP/nameserver03.md)
|
||||
- [Nameserver04](specifications/tests/Nameserver-TP/nameserver04.md)
|
||||
- [Nameserver05](specifications/tests/Nameserver-TP/nameserver05.md)
|
||||
- [Nameserver06](specifications/tests/Nameserver-TP/nameserver06.md)
|
||||
- [Nameserver07](specifications/tests/Nameserver-TP/nameserver07.md)
|
||||
- [Nameserver08](specifications/tests/Nameserver-TP/nameserver08.md)
|
||||
- [Nameserver09](specifications/tests/Nameserver-TP/nameserver09.md)
|
||||
- [Nameserver10](specifications/tests/Nameserver-TP/nameserver10.md)
|
||||
- [Nameserver11](specifications/tests/Nameserver-TP/nameserver11.md)
|
||||
- [Nameserver12](specifications/tests/Nameserver-TP/nameserver12.md)
|
||||
- [Nameserver13](specifications/tests/Nameserver-TP/nameserver13.md)
|
||||
- [Nameserver15](specifications/tests/Nameserver-TP/nameserver15.md)
|
||||
- [Syntax-TP](specifications/tests/Syntax-TP/README.md)
|
||||
- [Syntax01](specifications/tests/Syntax-TP/syntax01.md)
|
||||
- [Syntax02](specifications/tests/Syntax-TP/syntax02.md)
|
||||
- [Syntax03](specifications/tests/Syntax-TP/syntax03.md)
|
||||
- [Syntax04](specifications/tests/Syntax-TP/syntax04.md)
|
||||
- [Syntax05](specifications/tests/Syntax-TP/syntax05.md)
|
||||
- [Syntax06](specifications/tests/Syntax-TP/syntax06.md)
|
||||
- [Syntax07](specifications/tests/Syntax-TP/syntax07.md)
|
||||
- [Syntax08](specifications/tests/Syntax-TP/syntax08.md)
|
||||
- [Zone-TP](specifications/tests/Zone-TP/README.md)
|
||||
- [Zone01](specifications/tests/Zone-TP/zone01.md)
|
||||
- [Zone02](specifications/tests/Zone-TP/zone02.md)
|
||||
- [Zone03](specifications/tests/Zone-TP/zone03.md)
|
||||
- [Zone04](specifications/tests/Zone-TP/zone04.md)
|
||||
- [Zone05](specifications/tests/Zone-TP/zone05.md)
|
||||
- [Zone06](specifications/tests/Zone-TP/zone06.md)
|
||||
- [Zone07](specifications/tests/Zone-TP/zone07.md)
|
||||
- [Zone08](specifications/tests/Zone-TP/zone08.md)
|
||||
- [Zone09](specifications/tests/Zone-TP/zone09.md)
|
||||
- [Zone10](specifications/tests/Zone-TP/zone10.md)
|
||||
- [Zone11](specifications/tests/Zone-TP/zone11.md)
|
||||
- [Test Types](specifications/test-types/README.md)
|
||||
- [Undelegated Test](specifications/test-types/undelegated-test.md)
|
||||
- [Test Zones](specifications/test-zones/README.md)
|
||||
- [Engine Perl modules](specifications/test-zones/Engine/README.md)
|
||||
- [Recursor-PM](specifications/test-zones/Engine/Recursor-PM/README.md)
|
||||
- [CNAME](specifications/test-zones/Engine/Recursor-PM/CNAME.md)
|
||||
- [MethodsV2](specifications/test-zones/MethodsV2/README.md)
|
||||
- [MethodsV2 test scenario specification](specifications/test-zones/MethodsV2/methodsv2.md)
|
||||
- [Address-TP](specifications/test-zones/Address-TP/README.md)
|
||||
- [Address01](specifications/test-zones/Address-TP/address01.md)
|
||||
- [Address03](specifications/test-zones/Address-TP/address03.md)
|
||||
- [Basic-TP](specifications/test-zones/Basic-TP/README.md)
|
||||
- [Basic01](specifications/test-zones/Basic-TP/basic01.md)
|
||||
- [Basic02](specifications/test-zones/Basic-TP/basic02.md)
|
||||
- [Connectivity-TP](specifications/test-zones/Connectivity-TP/README.md)
|
||||
- [Connectivity04](specifications/test-zones/Connectivity-TP/connectivity04.md)
|
||||
- [Consistency-TP](specifications/test-zones/Consistency-TP/README.md)
|
||||
- [Consistency05](specifications/test-zones/Consistency-TP/consistency05.md)
|
||||
- [Consistency06](specifications/test-zones/Consistency-TP/consistency06.md)
|
||||
- [DNSSEC-TP](specifications/test-zones/DNSSEC-TP/README.md)
|
||||
- [DNSSEC01](specifications/test-zones/DNSSEC-TP/dnssec01.md)
|
||||
- [DNSSEC03](specifications/test-zones/DNSSEC-TP/dnssec03.md)
|
||||
- [DNSSEC05](specifications/test-zones/DNSSEC-TP/dnssec05.md)
|
||||
- [DNSSEC07](specifications/test-zones/DNSSEC-TP/dnssec07.md)
|
||||
- [DNSSEC10](specifications/test-zones/DNSSEC-TP/dnssec10.md)
|
||||
- [DNSSEC16](specifications/test-zones/DNSSEC-TP/dnssec16.md)
|
||||
- [Delegation-TP](specifications/test-zones/Delegation-TP/README.md)
|
||||
- [Delegation01](specifications/test-zones/Delegation-TP/delegation01.md)
|
||||
- [Delegation02](specifications/test-zones/Delegation-TP/delegation02.md)
|
||||
- [Delegation03](specifications/test-zones/Delegation-TP/delegation03.md)
|
||||
- [Nameserver-TP](specifications/test-zones/Nameserver-TP/README.md)
|
||||
- [Nameserver11](specifications/test-zones/Nameserver-TP/nameserver11.md)
|
||||
- [Nameserver15](specifications/test-zones/Nameserver-TP/nameserver15.md)
|
||||
- [Zone-TP](specifications/test-zones/Zone-TP/README.md)
|
||||
- [Zone09](specifications/test-zones/Zone-TP/zone09.md)
|
||||
- [Zone11](specifications/test-zones/Zone-TP/zone11.md)
|
||||
- [Translation](translation/README.md)
|
||||
- [Translating Engine, CLI and Backend](translation/Translating-Engine-CLI-Backend.md)
|
||||
- [Translating GUI](translation/Translating-GUI.md)
|
||||
- [Development](development/README.md)
|
||||
- [CLI](development/cli.md)
|
||||
- [License](LICENSE.md)
|
||||
23
zonemaster/docs/public/book.toml
Normal file
23
zonemaster/docs/public/book.toml
Normal file
@@ -0,0 +1,23 @@
|
||||
[book]
|
||||
authors = [ "Zonemaster Team" ]
|
||||
description = "Zonemaster documentation"
|
||||
language = "en"
|
||||
src = "./"
|
||||
|
||||
[build]
|
||||
create-missing = false
|
||||
use-default-preprocessors = false
|
||||
|
||||
[output.html]
|
||||
no-section-label = true
|
||||
|
||||
[output.html.fold]
|
||||
enable = true
|
||||
level = 1
|
||||
|
||||
[output.linkcheck]
|
||||
optional = true
|
||||
warning-policy= "warn"
|
||||
follow-web-links = false
|
||||
traverse-parent-directories = false
|
||||
exclude = [ 'SUMMARY.md', 'LICENSE.md', 'zonemaster_logo_2021_color.png', 'localhost' ]
|
||||
17
zonemaster/docs/public/configuration/README.md
Normal file
17
zonemaster/docs/public/configuration/README.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Configuration
|
||||
|
||||
This section contains information about configuration of the different components
|
||||
of Zonemaster:
|
||||
|
||||
* Setting up or modifying the [profile] in Zonemaster-Engine.
|
||||
* Enabling the Zonemaster-Engine [global cache] feature.
|
||||
* Configuring Zonemaster-Backend in the [Backend configuration file].
|
||||
* Using [environment variables] for Zonemaster-Backend.
|
||||
* Configuring Zonemaster-GUI in the [GUI configuration section].
|
||||
|
||||
|
||||
[profile]: profiles.md
|
||||
[global cache]: global-cache.md
|
||||
[Backend configuration file]: backend.md
|
||||
[environment variables]: backend-environment-variables.md
|
||||
[GUI configuration section]: gui/README.md
|
||||
@@ -0,0 +1,35 @@
|
||||
# Environment variables
|
||||
|
||||
## Variable used by both RPCAPI daemon and Test Agent daemon
|
||||
|
||||
* `ZONEMASTER_BACKEND_CONFIG_FILE`: Set a custom path for the backend
|
||||
configuration file.
|
||||
|
||||
## Variables used by RPCAPI daemon only
|
||||
|
||||
* `ZM_BACKEND_RPCAPI_LOGLEVEL`: Configure the log level, `trace` by default.
|
||||
Accepted values are:
|
||||
* `trace`
|
||||
* `debug`
|
||||
* `info` (also accepted: `inform`)
|
||||
* `notice`
|
||||
* `warning` (also accepted: `warn`)
|
||||
* `error` (also accepted: `err`)
|
||||
* `critical` (also accepted: `crit`, `fatal`)
|
||||
* `alert`
|
||||
* `emergency`
|
||||
* `ZM_BACKEND_RPCAPI_LOGJSON`: Setting it to any thruthy value (non-empty
|
||||
string or non-zero number) will configure the logger to log in JSON format,
|
||||
undefined by default.
|
||||
|
||||
## Variables used by unit test scripts
|
||||
|
||||
* `TARGET`: Set the database to use. If empty or undefined, "SQLite" will be
|
||||
assumed. Accepted values are:
|
||||
* `SQLite`
|
||||
* `PostgreSQL`
|
||||
* `MySQL`
|
||||
|
||||
* `ZONEMASTER_RECORD`: Setting it to any thruthy value (non-empty string or
|
||||
non-zero number) will record the data from the test to a file. Otherwise the
|
||||
data is loaded from a file.
|
||||
415
zonemaster/docs/public/configuration/backend.md
Normal file
415
zonemaster/docs/public/configuration/backend.md
Normal file
@@ -0,0 +1,415 @@
|
||||
# Configuration
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Introduction](#introduction)
|
||||
* [RPCAPI section](#rpcapi-section)
|
||||
* [enable_batch_create](#enable_batch_create)
|
||||
* [enable_user_create](#enable_user_create)
|
||||
* [enable_add_batch_job](#enable_add_batch_job)
|
||||
* [enable_add_api_user](#enable_add_api_user)
|
||||
* [DB section](#db-section)
|
||||
* [engine](#engine)
|
||||
* [polling_interval](#polling_interval)
|
||||
* [MYSQL section](#mysql-section)
|
||||
* [host](#host)
|
||||
* [port](#port)
|
||||
* [user](#user)
|
||||
* [password](#password)
|
||||
* [database](#database)
|
||||
* [POSTGRESQL section](#postgresql-section)
|
||||
* [host](#host-1)
|
||||
* [port](#port-1)
|
||||
* [user](#user-1)
|
||||
* [password](#password-1)
|
||||
* [database](#database-1)
|
||||
* [SQLITE section](#sqlite-section)
|
||||
* [database_file](#database_file)
|
||||
* [LANGUAGE section](#language-section)
|
||||
* [locale](#locale)
|
||||
* [METRICS section](#metrics-section)
|
||||
* [statsd_host](#statsd_host)
|
||||
* [statsd_port](#statsd_port)
|
||||
* [PUBLIC PROFILES and PRIVATE PROFILES sections](#public-profiles-and-private-profiles-sections)
|
||||
* [ZONEMASTER section](#zonemaster-section)
|
||||
* [max_zonemaster_execution_time](#max_zonemaster_execution_time)
|
||||
* [number_of_processes_for_frontend_testing](#number_of_processes_for_frontend_testing)
|
||||
* [number_of_processes_for_batch_testing](#number_of_processes_for_batch_testing)
|
||||
* [lock_on_queue](#lock_on_queue)
|
||||
* [age_reuse_previous_test](#age_reuse_previous_test)
|
||||
|
||||
## Introduction
|
||||
|
||||
Zonemaster *Backend* is configured in
|
||||
`/etc/zonemaster/backend_config.ini` (Linux) or
|
||||
`/usr/local/etc/zonemaster/backend_config.ini` (FreeBSD). Following
|
||||
[Installation instructions] will create the file with factory settings.
|
||||
|
||||
Restart the `zm-rpcapi` and `zm-testagent` daemons to load the changes
|
||||
made to the `backend_config.ini` file.
|
||||
|
||||
The `backend_config.ini` file uses a file format in the INI family that is
|
||||
described in detail [here][File format].
|
||||
Repeating a key name in one section is forbidden.
|
||||
|
||||
Each section in `backend_config.ini` is documented below.
|
||||
|
||||
In addition to the configuration file, some settings can configured using
|
||||
[environment variables][Environment Variables].
|
||||
|
||||
## RPCAPI section
|
||||
|
||||
Available keys: `enable_batch_create`, `enable_user_create`,
|
||||
`enable_add_batch_job`, `enable_add_api_user`.
|
||||
|
||||
### enable_add_batch_job
|
||||
|
||||
Boolean value to enable the `add_batch_job` and `batch_create` methods of the API.
|
||||
|
||||
Accepted values: `true` or `false` (or `yes` or `no`),
|
||||
default to `true` (enabled).
|
||||
|
||||
**Deprecated:** The `yes`/`no` values are deprecated and will be rejected in
|
||||
v2026.2.
|
||||
Use `true`/`false` instead.
|
||||
|
||||
### enable_add_api_user
|
||||
|
||||
Boolean value to enable the `add_api_user` and `user_create` method of the API.
|
||||
|
||||
Accepted values: `true` or `false` (or `yes` or `no`),
|
||||
default to `false` (disabled).
|
||||
|
||||
**Deprecated:** The `yes`/`no` values are deprecated and will be rejected in
|
||||
v2026.2.
|
||||
Use `true`/`false` instead.
|
||||
|
||||
### enable_batch_create
|
||||
|
||||
An experimental alias for [enable_add_batch_job][RPCAPI.enable_add_batch_job].
|
||||
|
||||
### enable_user_create
|
||||
|
||||
An experimental alias for [enable_add_api_user][RPCAPI.enable_add_api_user].
|
||||
|
||||
|
||||
## DB section
|
||||
|
||||
Available keys : `engine`, `user`, `password`, `database_name`,
|
||||
`database_host`, `polling_interval`.
|
||||
|
||||
### engine
|
||||
|
||||
Specifies what database engine to use.
|
||||
|
||||
The value must be one of the following, case-insensitively: `MySQL`,
|
||||
`PostgreSQL` and `SQLite`.
|
||||
|
||||
This table declares what value to use for each supported database engine.
|
||||
|
||||
Database Engine | Value
|
||||
------------------|------
|
||||
MariaDB | `MySQL`
|
||||
MySQL | `MySQL`
|
||||
PostgreSQL | `PostgreSQL`
|
||||
SQLite | `SQLite`
|
||||
|
||||
### polling_interval
|
||||
|
||||
A strictly positive decimal number. Max 5 and 3 digits in the integer and fraction
|
||||
components respectively.
|
||||
|
||||
Time in seconds between database lookups by Test Agent.
|
||||
Default value: `0.5`.
|
||||
|
||||
|
||||
## MYSQL section
|
||||
|
||||
Available keys : `host`, `port`, `user`, `password`, `database`.
|
||||
|
||||
### host
|
||||
|
||||
An [LDH domain name] or IP address.
|
||||
|
||||
The host name of the machine on which the MySQL server is running.
|
||||
|
||||
### port
|
||||
|
||||
The port the MySQL server is listening on.
|
||||
Default value: `3306`.
|
||||
|
||||
If [MYSQL.host] is set to `localhost` (but neither `127.0.0.1` nor `::1`),
|
||||
then the value of the [MYSQL.port] property is discarded as the driver
|
||||
connects using a UNIX socket (see the [DBD::mysql documentation]).
|
||||
|
||||
### user
|
||||
|
||||
An ASCII-only [MariaDB unquoted identifier].
|
||||
Max length [80 characters][MariaDB identifier max lengths].
|
||||
|
||||
The name of the user with sufficient permission to access the database.
|
||||
|
||||
### password
|
||||
|
||||
A string of [US ASCII printable characters].
|
||||
The first character must be neither space nor `<`.
|
||||
Max length 100 characters.
|
||||
|
||||
The password of the configured user.
|
||||
|
||||
### database
|
||||
|
||||
A US ASCII-only [MariaDB unquoted identifier].
|
||||
Max length [64 characters][MariaDB identifier max lengths].
|
||||
|
||||
The name of the database to use.
|
||||
|
||||
|
||||
## POSTGRESQL section
|
||||
|
||||
Available keys : `host`, `port`, `user`, `password`, `database`.
|
||||
|
||||
### host
|
||||
|
||||
An [LDH domain name] or IP address.
|
||||
|
||||
The host name of the machine on which the PostgreSQL server is running.
|
||||
|
||||
### port
|
||||
|
||||
The port the PostgreSQL server is listening on.
|
||||
Default value: `5432`.
|
||||
|
||||
### user
|
||||
|
||||
A US ASCII-only [PostgreSQL identifier]. Max length 63 characters.
|
||||
|
||||
The name of the user with sufficient permission to access the database.
|
||||
|
||||
### password
|
||||
|
||||
A string of [US ASCII printable characters].
|
||||
The first character must be neither space nor `<`.
|
||||
Max length 100 characters.
|
||||
|
||||
The password of the configured user.
|
||||
|
||||
### database
|
||||
|
||||
A US ASCII-only [PostgreSQL identifier]. Max length 63 characters.
|
||||
|
||||
The name of the database to use.
|
||||
|
||||
|
||||
## SQLITE section
|
||||
|
||||
Available keys : `database_file`.
|
||||
|
||||
### database_file
|
||||
|
||||
An absolute path.
|
||||
|
||||
The full path to the SQLite main database file.
|
||||
|
||||
|
||||
## LANGUAGE section
|
||||
|
||||
The LANGUAGE section has one key, `locale`.
|
||||
|
||||
### locale
|
||||
|
||||
A string representing a space-separated list of one or more `locale tags`.
|
||||
Each tag consists of a two-lowercase-letter language code, an underscore
|
||||
character, and a two-uppercase-letter country code (i.e. it matches the regular
|
||||
expression `/^[a-z]{2}_[A-Z]{2}$/`).
|
||||
Each `locale tag` must have a unique language code.
|
||||
|
||||
Default value: `en_US`.
|
||||
|
||||
#### Design
|
||||
|
||||
The language code of a `locale tag` is intended to be an [ISO 639-1] code.
|
||||
The country code is intended to be an [ISO 3166-1 alpha-2] code.
|
||||
A `locale tag` is a locale setting for the available translation
|
||||
of messages without ".UTF-8", which is implied.
|
||||
|
||||
#### Usage
|
||||
|
||||
Removing a language from the configuration file just blocks that
|
||||
language from being allowed.
|
||||
|
||||
English is the Zonemaster default language, but it can be blocked
|
||||
from being allowed by RPC-API by including some `locale tag` in the
|
||||
configuration, but none starting with language code for English ("en").
|
||||
|
||||
#### Out-of-the-box support
|
||||
|
||||
The default installation and configuration supports the
|
||||
following languages.
|
||||
|
||||
Language | Locale tag value | Language code | Locale value used
|
||||
---------|------------------|---------------|------------------
|
||||
Danish | da_DK | da | da_DK.UTF-8
|
||||
English | en_US | en | en_US.UTF-8
|
||||
Spanish | es_ES | es | es_ES.UTF-8
|
||||
Finnish | fi_FI | fi | fi_FI.UTF-8
|
||||
French | fr_FR | fr | fr_FR.UTF-8
|
||||
Norwegian| nb_NO | nb | nb_NO.UTF-8
|
||||
Slovenian| sl_SI | sl | sl_SI.UTF-8
|
||||
Swedish | sv_SE | sv | sv_SE.UTF-8
|
||||
|
||||
Setting in the default configuration file:
|
||||
|
||||
```
|
||||
locale = da_DK en_US es_ES fi_FI fr_FR nb_NO sl_SI sv_SE
|
||||
```
|
||||
|
||||
#### Installation considerations
|
||||
|
||||
If a new `locale tag` is added to the configuration then the equivalent
|
||||
MO file should be added to Zonemaster-Engine at the correct place so
|
||||
that gettext can retrieve it, or else the added `locale tag` will not
|
||||
add any actual language support. The MO file should be created for the
|
||||
`language code` of the `locale tag` (see the table above), not the entire
|
||||
`locale tag`. E.g. if the `locale` configuration key includes "sv_SE" then
|
||||
a MO file for "sv" should be included in the installation.
|
||||
|
||||
Use of MO files based on the entire `locale tag` is *deprecated*.
|
||||
|
||||
See the [Zonemaster-Engine share directory] for the existing PO files that are
|
||||
converted to MO files during installation. (Here we should have a link
|
||||
to documentation instead.)
|
||||
|
||||
Each locale set in the configuration file, including the implied
|
||||
".UTF-8", must also be installed or activate on the system
|
||||
running the RPCAPI daemon for the translation to work correctly.
|
||||
|
||||
## METRICS section
|
||||
|
||||
### statsd_host
|
||||
|
||||
An [LDH domain name] or IP address.
|
||||
|
||||
The host name of the machine on which the StatsD receiver is running.
|
||||
|
||||
Leave unspecified to disable the metrics.
|
||||
|
||||
Note that this feature requires the `Net::Statsd` module to be installed.
|
||||
|
||||
### statsd_port
|
||||
|
||||
The port the StatsD receiver is listening on.
|
||||
Default value: `8125`.
|
||||
|
||||
|
||||
## PUBLIC PROFILES and PRIVATE PROFILES sections
|
||||
|
||||
The PUBLIC PROFILES and PRIVATE PROFILES sections together define the available [profiles].
|
||||
|
||||
Keys in both sections are `profile names`, and values are absolute file system
|
||||
paths to [profile JSON files]. The key must conform to the character limitation
|
||||
specified for `profile name` as specified in the API document
|
||||
[Profile name section]. Keys that only differ in case are considered to be equal.
|
||||
Keys must not be duplicated between or within the sections, and the key
|
||||
`default` must not be present in the PRIVATE PROFILES section.
|
||||
|
||||
There is a `default` profile that is special. It is always available even
|
||||
if not specified. If it is not explicitly mapped to a profile JSON file, it is implicitly
|
||||
mapped to the [Zonemaster Engine default profile].
|
||||
|
||||
Each profile JSON file contains a (possibly empty) set of overrides to
|
||||
the *Zonemaster Engine default profile*. Specifying a profile JSON file
|
||||
that contains a complete set of profile data is equivalent to specifying
|
||||
a profile JSON file with only the parts that differ from the *Zonemaster
|
||||
Engine default profile*.
|
||||
|
||||
Specifying a profile JSON file that contains no profile data is equivalent
|
||||
to specifying a profile JSON file containing the entire
|
||||
*Zonemaster Engine default profile*.
|
||||
|
||||
## ZONEMASTER section
|
||||
|
||||
The ZONEMASTER section has several keys :
|
||||
* max_zonemaster_execution_time
|
||||
* number_of_processes_for_frontend_testing
|
||||
* number_of_processes_for_batch_testing
|
||||
* lock_on_queue
|
||||
* age_reuse_previous_test
|
||||
|
||||
### max_zonemaster_execution_time
|
||||
|
||||
A strictly positive integer. Max length 5 digits.
|
||||
|
||||
Time in seconds before reporting an unfinished test as failed.
|
||||
Default value: `600`.
|
||||
|
||||
### number_of_processes_for_frontend_testing
|
||||
|
||||
A strictly positive integer. Max length 5 digits.
|
||||
|
||||
Number of processes allowed to run in parallel (added with
|
||||
`number_of_processes_for_batch_testing`).
|
||||
Default value: `20`.
|
||||
|
||||
Despite its name, this key does not limit the number of process used by the
|
||||
frontend, but is used in combination of
|
||||
`number_of_processes_for_batch_testing`.
|
||||
|
||||
### number_of_processes_for_batch_testing
|
||||
|
||||
A non-negative integer. Max length 5 digits.
|
||||
|
||||
Number of processes allowed to run in parallel (added with
|
||||
`number_of_processes_for_frontend_testing`).
|
||||
Default value: `20`.
|
||||
|
||||
Despite its name, this key does not limit the number of process used by any
|
||||
batch pool of tests, but is used in combination of
|
||||
`number_of_processes_for_frontend_testing`.
|
||||
|
||||
### lock_on_queue
|
||||
|
||||
A non-negative integer. Max length 5 digits.
|
||||
|
||||
A label to associate a test to a specific Test Agent.
|
||||
Default value: `0`.
|
||||
|
||||
### age_reuse_previous_test
|
||||
|
||||
A strictly positive integer. Max length 5 digits.
|
||||
|
||||
The shelf life of a test in seconds after its creation.
|
||||
Default value: `600`.
|
||||
|
||||
If a new test is requested for the same zone name and parameters within the
|
||||
shelf life of a previous test result, that test result is reused.
|
||||
Otherwise a new test request is enqueued.
|
||||
|
||||
|
||||
[API documentation]: ../using/backend/api.md
|
||||
[DBD::mysql documentation]: https://metacpan.org/pod/DBD::mysql#host
|
||||
[Default JSON profile file]: https://github.com/zonemaster/zonemaster-engine/blob/master/share/profile.json
|
||||
[Environment Variables]: backend-environment-variables.md
|
||||
[File format]: https://metacpan.org/pod/Config::IniFiles#FILE-FORMAT
|
||||
[ISO 3166-1 alpha-2]: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
|
||||
[ISO 639-1]: https://en.wikipedia.org/wiki/ISO_639-1
|
||||
[Installation instructions]: ../installation/zonemaster-backend.md
|
||||
[Language tag]: ../using/backend/api.md#language-tag
|
||||
[LDH domain name]: https://datatracker.ietf.org/doc/html/rfc3696#section-2
|
||||
[MariaDB identifier max lengths]: https://mariadb.com/kb/en/identifier-names/#maximum-length
|
||||
[MariaDB unquoted identifier]: https://mariadb.com/kb/en/identifier-names/#unquoted
|
||||
[MYSQL.host]: #host
|
||||
[MYSQL.port]: #port
|
||||
[PostgreSQL identifier]: https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
|
||||
[Profile JSON files]: profiles.md
|
||||
[Profile name section]: ../using/backend/rpcapi-reference.md#profile-name
|
||||
[Profiles]: https://github.com/zonemaster/zonemaster-backend/blob/master/docs/Architecture.md#profile
|
||||
[RPCAPI.enable_add_api_user]: #enable_add_api_user
|
||||
[RPCAPI.enable_add_batch_job]: #enable_add_batch_job
|
||||
[RPCAPI.enable_batch_create]: #enable_batch_create
|
||||
[RPCAPI.enable_user_create]: #enable_user_create
|
||||
[SQLITE.database_file]: #database_file
|
||||
[US ASCII printable characters]: https://en.wikipedia.org/wiki/ASCII#Printable_characters
|
||||
[Zonemaster-Engine share directory]: https://github.com/zonemaster/zonemaster-engine/tree/master/share
|
||||
[Zonemaster::Engine::Profile]: https://metacpan.org/pod/Zonemaster::Engine::Profile#PROFILE-PROPERTIES
|
||||
[Zonemaster Engine default profile]: profiles.md#default-profile
|
||||
123
zonemaster/docs/public/configuration/global-cache.md
Normal file
123
zonemaster/docs/public/configuration/global-cache.md
Normal file
@@ -0,0 +1,123 @@
|
||||
# Configuration: Global cache in Zonemaster-Engine
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Introduction](#introduction)
|
||||
* [Prerequisites](#prerequisites)
|
||||
* [Installation for global cache](#installation-for-global-cache)
|
||||
* [Create directory for custom profile](#create-directory-for-custom-profile)
|
||||
* [Enable global cache](#enable-global-cache)
|
||||
* [Using global cache](#using-global-cache)
|
||||
|
||||
|
||||
## Introduction
|
||||
Global cache is a feature that can increase performance when many tests are run
|
||||
within a short time frame, especially when they share some data such as using the
|
||||
same name server names. The global cache is meant for batch testing rather than
|
||||
single tests through the GUI. In the latter case it is desirable that Zonemaster
|
||||
checks again since the zone may have been corrected due to the report in a very
|
||||
recent test.
|
||||
|
||||
The global cache improves the caching function by making the DNS lookups from
|
||||
one test to be available for further tests. The cache is stored in `Redis`, a
|
||||
cache service running in a separate daemon.
|
||||
|
||||
To enable global caching, additional software has to be installed and custom
|
||||
profile has to be created, where global caching is enabled.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before installing or enabling global cache you must follow the
|
||||
[Zonemaster::Engine installation] first. The feature is available from version
|
||||
`v5.0.0` of Zonemaster-Engine.
|
||||
|
||||
For installation on FreeBSD being user root is assumed.
|
||||
|
||||
|
||||
## Installation for global cache
|
||||
|
||||
Install the `Redis` daemon and needed Perl library. And then start the `Redis`
|
||||
daemon. It will listen to localhost and default port.
|
||||
|
||||
### Rocky Linux
|
||||
```
|
||||
sudo dnf --assumeyes install redis perl-Redis perl-Data-MessagePack
|
||||
sudo systemctl enable redis
|
||||
sudo systemctl start redis
|
||||
```
|
||||
|
||||
### Debian and Ubuntu
|
||||
```
|
||||
sudo apt install redis libredis-perl libdata-messagepack-perl
|
||||
sudo systemctl enable redis
|
||||
sudo systemctl start redis
|
||||
```
|
||||
|
||||
### FreeBSD
|
||||
```
|
||||
pkg install -y redis p5-Redis p5-Data-MessagePack
|
||||
sysrc redis_enable="YES"
|
||||
service redis start
|
||||
```
|
||||
|
||||
## Create directory for custom profile
|
||||
|
||||
Create a directory to be used for a custom profile, which is here the same
|
||||
directory as used by Zonemaster-Backend. And then copy the default profile
|
||||
to this directory.
|
||||
|
||||
### Rocky Linux, Debian and Ubuntu
|
||||
```
|
||||
test -d /etc/zonemaster || sudo mkdir -v /etc/zonemaster
|
||||
perl -MZonemaster::Engine::Test -E 'say Zonemaster::Engine::Profile->default->to_json' | jq -S . | sudo tee /etc/zonemaster/profile.json > /dev/null
|
||||
```
|
||||
|
||||
### FreeBSD
|
||||
```
|
||||
test -d /usr/local/etc/zonemaster || mkdir -v /usr/local/etc/zonemaster
|
||||
perl -MZonemaster::Engine::Test -E 'say Zonemaster::Engine::Profile->default->to_json' | jq -S . > /usr/local/etc/zonemaster/profile.json
|
||||
```
|
||||
|
||||
## Enable global cache
|
||||
If there is no `profile.json` in `/etc/zonemaster/` (or `/usr/local/etc/zonemaster/`
|
||||
for FreeBSD), create it by extracting the default profile using the command in the
|
||||
[profile documentation].
|
||||
|
||||
Update `/etc/zonemaster/profile.json` (or `/usr/local/etc/zonemaster/profile.json`
|
||||
for FreeBSD) by adding a cache section. If the profile already has an empty cache
|
||||
section (i.e. `"cache": {}`) then it must be removed. Add the following section,
|
||||
```
|
||||
"cache": {
|
||||
"redis": {
|
||||
"server": "127.0.0.1:6379",
|
||||
"expire": 7200
|
||||
}
|
||||
},
|
||||
```
|
||||
|
||||
The `expire` value can be increased or decreased to increase or decrease the time
|
||||
in seconds that `Redis` will cache the data. Caching of specific DNS data is
|
||||
never longer than the normal DNS TTL value.
|
||||
|
||||
|
||||
## Using global cache
|
||||
|
||||
If [Zonemaster-CLI][Zonemaster::CLI installation] has been installed, then
|
||||
run `zonemaster-cli` with `--profile /etc/zonemaster/profile.json`
|
||||
(or `--profile /usr/local/etc/zonemaster/profile.json` for FreeBSD) to use the
|
||||
global cache. Caching will persist between test unless it has expired.
|
||||
|
||||
See `man zonemaster-cli` and look for `cli.args` for how to make it the custom
|
||||
profile being the default profile for `zonemaster-cli`.
|
||||
|
||||
See [Zonemaster::Backend configuration] for how to make the custom profile being
|
||||
used for Zonemaster-Backend and Zonemaster-GUI.
|
||||
|
||||
For more documentation on profiles, see [profile documentation].
|
||||
|
||||
|
||||
[profile documentation]: profiles.md
|
||||
[Zonemaster::Backend configuration]: backend.md
|
||||
[Zonemaster::CLI installation]: ../installation/zonemaster-cli.md
|
||||
[Zonemaster::Engine installation]: ../installation/zonemaster-engine.md
|
||||
20
zonemaster/docs/public/configuration/gui/README.md
Normal file
20
zonemaster/docs/public/configuration/gui/README.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# GUI Configuration
|
||||
|
||||
This section contains information about configuration of the GUI component.
|
||||
|
||||
* [Run-time configuring Zonemaster-GUI using "config.json"] is currently limited
|
||||
to creating or updating a message banner.
|
||||
* [Simple build-time configuring Zonemaster-GUI using "config.ts"] lists
|
||||
basic configuration options of Zonemaster-GUI.
|
||||
* [Advanced build-time configuring Zonemaster-GUI using "tsconfig.json"] can
|
||||
change the look-and-feel of Zonemaster-GUI.
|
||||
* [Configuring Zonemaster-GUI using Theming] gives further instructions for how
|
||||
to customize Zonemaster-GUI.
|
||||
* [Build a custom Zonemaster-GUI installation package]
|
||||
|
||||
|
||||
[Advanced build-time configuring Zonemaster-GUI using "tsconfig.json"]: configuring-using-tsconfig-json.md
|
||||
[Build a custom Zonemaster-GUI installation package]: building-custom-gui.md
|
||||
[Configuring Zonemaster-GUI using Theming]: configuring-using-theming.md
|
||||
[Run-time configuring Zonemaster-GUI using "config.json"]: configuring-using-config-json.md
|
||||
[Simple build-time configuring Zonemaster-GUI using "config.ts"]: configuring-using-config-ts.md
|
||||
173
zonemaster/docs/public/configuration/gui/building-custom-gui.md
Normal file
173
zonemaster/docs/public/configuration/gui/building-custom-gui.md
Normal file
@@ -0,0 +1,173 @@
|
||||
# Build a custom Zonemaster-GUI installation package
|
||||
|
||||
## Background
|
||||
|
||||
If you follow the [Zonemaster-GUI installation instructions] you can install an
|
||||
official package, and skip the instructions in this document.
|
||||
|
||||
However, if you have created a custom [config.ts], done theme settings in
|
||||
[tsconfig.json] or done some [theme updates] then you must create a custom
|
||||
installation package for your custom installation. That can be achieved by
|
||||
following the steps below.
|
||||
|
||||
It is also important to state that even though the installation package is
|
||||
created on Ubuntu 22.04 below, the resulting installation package can be
|
||||
installed on at least all OSs supported in the
|
||||
[Zonemaster-GUI installation instructions].
|
||||
|
||||
## Prepare build environment
|
||||
|
||||
Start by creating a build environment. Here we assume and base it on
|
||||
[Ubuntu] version 22.04. The instructions will probably work with other versions
|
||||
of Ubuntu, or with other Linux distributions or other OSs, but then you might
|
||||
need to adapt some of the commands. Note however that it is important that the
|
||||
system fully supports [npm].
|
||||
|
||||
### Install toolchain
|
||||
|
||||
1. Make a clean installation of Ubuntu 22.04.
|
||||
|
||||
2. Update the package database and install Curl and Git.
|
||||
|
||||
```sh
|
||||
sudo apt-get update
|
||||
sudo apt-get install curl git
|
||||
```
|
||||
|
||||
3. Install Node.js by using [NVM], a node version manager.
|
||||
|
||||
```sh
|
||||
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.2/install.sh | bash
|
||||
```
|
||||
|
||||
4. After installation, log out and log in again to handle [known issue], or just:
|
||||
|
||||
```sh
|
||||
source ~/.bashrc
|
||||
```
|
||||
|
||||
5. Install the supported Node.js version
|
||||
|
||||
```sh
|
||||
nvm install 24
|
||||
```
|
||||
|
||||
6. Switch to the previously installed version
|
||||
|
||||
```sh
|
||||
nvm use 24
|
||||
```
|
||||
|
||||
## Check out source code
|
||||
|
||||
You need to checkout the source code of Zonemaster-GUI. In the usual case
|
||||
you will start with the `master` branch latest Zonemaster-GUI release as
|
||||
shown below.
|
||||
|
||||
```sh
|
||||
git clone -b master https://github.com/zonemaster/zonemaster-gui.git
|
||||
cd zonemaster-gui
|
||||
```
|
||||
|
||||
If you already have a clone, make sure that you start from an up-to-date `master`
|
||||
branch.
|
||||
|
||||
```sh
|
||||
git checkout master
|
||||
git fetch --all
|
||||
git pull
|
||||
```
|
||||
|
||||
## Add customization
|
||||
|
||||
From there, you can start to do your own customization. The simplest case only
|
||||
requires an update to [config.ts]. See the [GUI Configuration][README] overview
|
||||
for more details.
|
||||
|
||||
You should then save any changed file by doing the following steps (see
|
||||
[Git tutorial]).
|
||||
|
||||
```sh
|
||||
git checkout -b MY-BRANCH
|
||||
git add FILE
|
||||
git commit -m 'What did I do?'
|
||||
```
|
||||
|
||||
## Build installation package
|
||||
|
||||
When building you should have a clean repository. Clean means that all temporary
|
||||
(i.e. non-versioned) files are removed.
|
||||
|
||||
1. List all files and changes that will be removed with next step.
|
||||
|
||||
```sh
|
||||
git status --ignored
|
||||
```
|
||||
|
||||
2. Remove all files and changes not included in a Git branch (listed in
|
||||
previous step).
|
||||
|
||||
```sh
|
||||
git clean -dfx
|
||||
git reset --hard
|
||||
```
|
||||
|
||||
3. Install [npm] libraries in the repository.
|
||||
|
||||
```sh
|
||||
npm install
|
||||
```
|
||||
|
||||
4. Build the Zonemaster-GUI.
|
||||
|
||||
```sh
|
||||
npm run build
|
||||
```
|
||||
|
||||
5. If building fails, go back to the "[Install toolchain]" section and repeat the
|
||||
two `nvm` commands and restart building.
|
||||
|
||||
6. Build a Zonemaster-GUI installation package (a zip file).
|
||||
|
||||
```sh
|
||||
npm run release
|
||||
```
|
||||
|
||||
If all steps worked well, there will be a zip file in the current repository that
|
||||
can be used for installation, i.e. by replacing the official installation package
|
||||
(zip file) with this new zip file in the [Zonemaster-GUI installation instructions].
|
||||
|
||||
If the build step above fails, go back to a safe branch and add your updates one
|
||||
by one, and repeating steps 1-5.
|
||||
|
||||
|
||||
## Testing the Build Locally
|
||||
|
||||
To test the static build locally, it must be served from the root path (/). You
|
||||
can use any static server. Here are two common options, and note that
|
||||
additional software has to be installed for those:
|
||||
|
||||
```sh
|
||||
python3 -m http.server 8000 --directory ./public
|
||||
```
|
||||
|
||||
```sh
|
||||
php -S localhost:8000 -t ./public
|
||||
```
|
||||
|
||||
Ensure you're serving the ./public directory (or your build output folder) as
|
||||
the root for all assets and routing to work correctly.
|
||||
|
||||
|
||||
[Git tutorial]: https://git-scm.com/docs/gittutorial
|
||||
[Known issue]: https://github.com/nvm-sh/nvm#troubleshooting-on-linux
|
||||
[NPM]: https://www.npmjs.com/
|
||||
[NVM]: https://github.com/nvm-sh/nvm
|
||||
[Node.js]: https://nodejs.org/en
|
||||
[README]: README.md
|
||||
[Ubuntu]: https://ubuntu.com/
|
||||
[Zonemaster-GUI installation instructions]: ../../installation/zonemaster-gui.md
|
||||
[config.ts]: configuring-using-config-ts.md
|
||||
[tsconfig.json]: configuring-using-tsconfig-json.md
|
||||
[theme updates]: configuring-using-theming.md
|
||||
[Install toolchain]: #install-toolchain
|
||||
@@ -0,0 +1,66 @@
|
||||
# Run-time configuring Zonemaster-GUI using "config.json"
|
||||
|
||||
The `config.json` configuration file can be used for *run-time* settings of the
|
||||
Zonemaster-GUI, i.e. no rebuild of the installation package is needed.
|
||||
|
||||
Currently, the only supported setting is creating, updating or removing a message
|
||||
banner. Other types of configuration require a rebuild of the GUI, and are covered
|
||||
in sibling documents of this document.
|
||||
|
||||
## Finding "config.json"
|
||||
|
||||
In the source tree the file is found as `static/config.json` relative to the
|
||||
root of the Git tree.
|
||||
|
||||
In a default installation, the file is found as
|
||||
`/var/www/html/zonemaster-web-gui/dist/config.json`.
|
||||
|
||||
## Reloading GUI after update
|
||||
|
||||
When the Web browser reloads the GUI, e.g. after running a new test, the
|
||||
changes are displayed by the GUI.
|
||||
|
||||
## Default "config.json" file
|
||||
|
||||
The `config.json` file contains configuration that is loaded at runtime.
|
||||
Currently, it includes settings for displaying banner messages in different
|
||||
languages:
|
||||
|
||||
```json
|
||||
{
|
||||
"msgBanner": {
|
||||
"en": "",
|
||||
"sv": "",
|
||||
"da": "",
|
||||
"es": "",
|
||||
"fi": "",
|
||||
"fr": "",
|
||||
"nb": ""
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Configuration Options
|
||||
|
||||
* **msgBanner**: An object containing message banner text for each supported
|
||||
language. These messages can be used to display important announcements or
|
||||
notifications to users in their preferred language.
|
||||
|
||||
The message banner is shown just below the top menu on all pages.
|
||||
|
||||
The string is set for each language, and may contain HTML code such as `<br>` or
|
||||
even `<a href>` if necessary. Take note not to break quoting as JSON requires
|
||||
quoting with `""` around the string.
|
||||
|
||||
To display a message banner, simply add the message text to the corresponding
|
||||
language key. E.g.:
|
||||
|
||||
```json
|
||||
{
|
||||
"msgBanner": {
|
||||
"en": "Scheduled system maintenance on 2025-12-09 from 10:00 to 12:00 UTC.",
|
||||
"sv": "Planerat systemunderhåll den 9 december 2025 kl. 10.00–12.00 UTC."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -0,0 +1,117 @@
|
||||
# Simple build-time configuring Zonemaster-GUI using "config.ts"
|
||||
|
||||
The `config.ts` configuration file can be used for *build-time* settings of
|
||||
the Zonemaster-GUI. Any changes to this file require a rebuild of the
|
||||
installation package.
|
||||
|
||||
## Finding "config.ts"
|
||||
|
||||
In the source tree the file is found as `config.ts` relative to the root of
|
||||
the Git tree. The installed GUI does not ship with this file, because the
|
||||
values defined in this file are baked in the GUI’s HTML and JavaScript files.
|
||||
|
||||
## Rebuilding Zonemaster-GUI after update
|
||||
|
||||
When `config.ts` is updated, Zonemaster-GUI has to be rebuilt. See
|
||||
[Build a custom Zonemaster-GUI installation package] for how to get the source
|
||||
tree and building a custom installation package.
|
||||
|
||||
## Default "config.ts" file
|
||||
|
||||
The `config.ts` file is the central configuration file for the Zonemaster-GUI
|
||||
application. It defines various settings that control the behavior and appearance
|
||||
of the application.
|
||||
|
||||
```typescript
|
||||
import type { Config } from '@/types.ts';
|
||||
import packageJson from './package.json';
|
||||
|
||||
const config: Config = {
|
||||
defaultLanguage: 'en',
|
||||
enabledLanguages: ['da', 'en', 'es', 'fi', 'fr', 'nb', 'sv', 'sl'],
|
||||
baseUrl: import.meta.env.PUBLIC_BASE_URL || '/',
|
||||
apiBaseUrl: import.meta.env.PUBLIC_API_URL || '/api',
|
||||
pollingInterval: import.meta.env.PUBLIC_POLLING_INTERVAL || 5000,
|
||||
clientInfo: {
|
||||
version: packageJson.version,
|
||||
id: 'Zonemaster-GUI',
|
||||
},
|
||||
siteInfo: {
|
||||
email: 'contact@zonemaster.net',
|
||||
siteName: '',
|
||||
},
|
||||
setTitle(title: string) {
|
||||
return `${title} – Zonemaster`;
|
||||
}
|
||||
};
|
||||
|
||||
export default config;
|
||||
```
|
||||
|
||||
## "config.ts" configuration options
|
||||
|
||||
* **defaultLanguage**: The default language to use when no language is specified.
|
||||
* The default language must be one of the enabled languages.
|
||||
* The default value is "en".
|
||||
* If this option is updated see [Updating Apache configuration] for required
|
||||
matching update of the Apache configuration.
|
||||
* **enabledLanguages**: An array of language codes that are supported by the
|
||||
application.
|
||||
* The array should match the list of language codes in the [Locale setting] in
|
||||
the Backend configuration.
|
||||
* The array must only include language codes also included in
|
||||
`project.inlang/settings.json`, but it may be fewer. To add new languages,
|
||||
see [Translating Zonemaster-GUI]. `project.inlang/settings.json` must only be
|
||||
updated in that process.
|
||||
* **baseUrl**: The base path Zonemaster-GUI is served on. By default it is "/".
|
||||
* For example, if Zonemaster-GUI is served at
|
||||
`http://domaintest.xa/zonemaster`, instead of just
|
||||
`http://domaintest.xa/`, then this option must be set to `/zonemaster`.
|
||||
* If this option is updated see [Updating Apache configuration] for required
|
||||
matching update of the Apache configuration.
|
||||
* **apiBaseUrl**: The base URL for API requests. The default value is `/api`
|
||||
and must be kept so if `baseUrl` has its default value.
|
||||
* If `baseUrl` is updated, then this option must also be updated so that this
|
||||
option is equal to `baseUrl` + '/api', i.e. '/zonemaster/api' in the
|
||||
example above.
|
||||
* **pollingInterval**: The interval (in milliseconds) for polling the API. This
|
||||
is taken from the `PUBLIC_POLLING_INTERVAL` environment variable (default
|
||||
empty) or defaults to 5000 ms.
|
||||
* **clientInfo**: Information about the client application. These details are
|
||||
included in every API request to start tests as (spoofable) indications of
|
||||
origin. Both are best left as default.
|
||||
* **version**: The version of the application, taken from package.json.
|
||||
* **id**: The identifier for the client application.
|
||||
* **siteInfo**: Information about the site.
|
||||
* **email**: The contact email address. To be set in the footer in a mailto
|
||||
URL, if non-empty.
|
||||
- **siteName**: The name of the site. To be set in the header if non-empty.
|
||||
|
||||
## Updating Apache configuration
|
||||
|
||||
Preferably do the updates to the `zonemaster.conf-example` file before building
|
||||
the installation package. If done so the normal installation instruction can be
|
||||
followed using the custom installation package.
|
||||
|
||||
### Finding "zonemaster.conf-example"
|
||||
|
||||
In the source tree the file is found as `zonemaster.conf-example` relative to the
|
||||
root of the Git tree. It is included in the installation package and is installed
|
||||
as `zonemaster.conf` in a default installation.
|
||||
|
||||
### defaultLanguage
|
||||
If `defaultLanguage` has been updated in `config.ts` the "DEFAULT_LANGUAGE"
|
||||
variable must be updated in `zonemaster.conf-example`. The same language code
|
||||
must be used.
|
||||
|
||||
### baseUrl
|
||||
|
||||
If `baseUrl` has been set to a non-default value in `config.ts` the "BASE_URL"
|
||||
variable must be defined with the same value. By default the variable is
|
||||
undefined (`baseUrl` equal to "/").
|
||||
|
||||
|
||||
[Build a custom Zonemaster-GUI installation package]: building-custom-gui.md
|
||||
[Locale setting]: ../backend.md#locale
|
||||
[Translating Zonemaster-GUI]: ../../translation/Translating-GUI.md
|
||||
[Updating Apache configuration]: #updating-apache-configuration
|
||||
@@ -0,0 +1,169 @@
|
||||
# Configuring Zonemaster-GUI using Theming
|
||||
|
||||
## Background
|
||||
|
||||
The Zonemaster-GUI is built to be cloned and customized. You have full control
|
||||
over the styling and layout. That said, to avoid troubles when syncing with
|
||||
the original repository, we recommend following a few simple guidelines:
|
||||
|
||||
- Start by customizing the **theme variables** — this is enough for most use cases.
|
||||
- If that's not enough, apply **custom CSS** targeting specific elements.
|
||||
- For large framework changes, **create a new theme** and update `tsconfig.json`.
|
||||
- For interactive components, **keep changes minimal** to avoid breaking functionality.
|
||||
- Use **headless mode** for major customizations or when building your own GUI.
|
||||
|
||||
## Related documents
|
||||
|
||||
For how to use `tsconfig.json` in connection to theming, see
|
||||
[Advanced build-time configuring Zonemaster-GUI using "tsconfig.json"]. Theming
|
||||
requires rebuilding Zonemaster-GUI, see
|
||||
[Build a custom Zonemaster-GUI installation package].
|
||||
|
||||
## Basic customization
|
||||
|
||||
The Zonemaster-GUI is built around a global theme based on CSS variables
|
||||
(`./src/themes/default/styles/theme.css`). The easiest way to make your own theme
|
||||
is to override theme variables in the `./src/themes/default/styles/custom.css` file.
|
||||
You can tweak colors, fonts, spacing, and more. You'll get surprisingly far by
|
||||
just updating the theme variables. All class names are prefixed with `zm-` to
|
||||
avoid conflicts with other styles. This makes it easy to apply custom CSS on top
|
||||
of the theme to target specific elements.
|
||||
|
||||
### Available theme variables
|
||||
|
||||
The theme includes variables for:
|
||||
- **Font sizes and families**: `--font-xxs` through
|
||||
`--font-supersize`, `--font-body-family`, etc.
|
||||
- **Spacing**: `--spacing-xxs` through `--spacing-xxl`
|
||||
- **Colors**: Various color palettes including main, secondary, black, danger,
|
||||
success, info, warning, and error
|
||||
- **GUI elements**: Background, text, borders, etc.
|
||||
- **Buttons**: Size, color, padding
|
||||
- **Layout**: Width, gaps, header height
|
||||
- **Breakpoints**: For responsive design
|
||||
|
||||
### Example customization
|
||||
|
||||
Here's a simple example of customizing the main color and font in `custom.css`:
|
||||
|
||||
```css
|
||||
:root {
|
||||
/* Change the primary color */
|
||||
--color-palette-main-50: #4285f4;
|
||||
--color-palette-main-70: #1a73e8;
|
||||
|
||||
/* Change the font */
|
||||
--font-body-family: 'Roboto', sans-serif;
|
||||
}
|
||||
```
|
||||
|
||||
### CSS loading order
|
||||
|
||||
The CSS files are loaded in the following order (defined in `styles.css`):
|
||||
1. theme.css (base theme variables)
|
||||
2. foundation.css and other core styles
|
||||
3. Component-specific CSS files
|
||||
4. custom.css (your customizations)
|
||||
|
||||
This ensures that your custom styles will override the default styles.
|
||||
|
||||
## Modifying structure and layout
|
||||
|
||||
There are two layers of the GUI.
|
||||
|
||||
### Framework
|
||||
|
||||
The framework is the foundation of the GUI and is built with [Astro]. These
|
||||
files are located under `./src/themes/default`. ' The starting point for these
|
||||
imports are pages. Pages are simple: they consist of a single component wrapped
|
||||
inside a layout. *We suggest not modifying the page files*. Instead, create your
|
||||
own theme, for example `./src/themes/my-theme`. You can still reuse components
|
||||
from the original theme in your new theme and mix and match the imports from your
|
||||
custom theme.
|
||||
|
||||
Then update tsconfig.json:
|
||||
|
||||
```diff
|
||||
{
|
||||
"extends": "astro/tsconfigs/strict",
|
||||
"include": [".astro/types.d.ts", "**/*"],
|
||||
"exclude": ["dist"],
|
||||
"compilerOptions": {
|
||||
"baseUrl": ".",
|
||||
"paths": {
|
||||
"@/*": ["./src/*"],
|
||||
- "@theme/*": ["./src/themes/default/*"]
|
||||
+ "@theme/*": ["./src/themes/my-theme/*"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Interactive components
|
||||
|
||||
All interactive components are built with [Svelte]. These files are located under
|
||||
`./src/lib/components`. These are referenced from Astro components. Although care
|
||||
was taken to make the components as self-contained as possible, some
|
||||
components may depend on others. In most cases you won't need to modify these
|
||||
files. A better approach is to modify the CSS.
|
||||
|
||||
If you absolutely need to modify these, the suggested method is to create new
|
||||
components in `./src/lib/components/my-theme` and reference them from the
|
||||
Astro components. These interactive components contain important functionality
|
||||
that needs to be carefully considered when modifying.
|
||||
|
||||
You might be better off creating a new component from scratch and integrate it
|
||||
with the RPCAPI yourself.
|
||||
|
||||
## Headless mode
|
||||
|
||||
For major customizations or when you need complete control over the GUI, you can
|
||||
use the "headless mode" approach. This involves using the Zonemaster API client
|
||||
directly without the GUI components.
|
||||
|
||||
For detailed information about headless mode, please refer to the [UI.md]
|
||||
documentation.
|
||||
|
||||
## Testing and troubleshooting
|
||||
|
||||
### Testing your theme changes
|
||||
|
||||
When making theme changes, it's important to test them across different pages and
|
||||
components to ensure consistency. Here are some tips:
|
||||
|
||||
1. **Test on different screen sizes**: Use your browser's developer tools to test
|
||||
responsive behavior.
|
||||
2. **Check all interactive states**: Verify hover, focus, active, and disabled
|
||||
states for interactive elements.
|
||||
3. **Test with different content**: Make sure your theme works well with both
|
||||
short and long content.
|
||||
4. **Verify accessibility**: Ensure sufficient color contrast and that focus
|
||||
states are visible.
|
||||
|
||||
### Common issues and solutions
|
||||
|
||||
- **Changes not appearing**: Make sure your `custom.css` file is being loaded.
|
||||
Check the browser's developer tools to verify.
|
||||
- **Specificity issues**: If your styles aren't overriding the defaults, you
|
||||
might need to increase specificity or use `!important` (sparingly).
|
||||
- **Responsive issues**: Check that your customizations work well at all
|
||||
breakpoints.
|
||||
- **Component styling conflicts**: If styling a specific component, target the
|
||||
component's class directly rather than modifying global variables.
|
||||
|
||||
### Development workflow
|
||||
|
||||
For a smoother development experience:
|
||||
1. Start the development server with `npm run dev`
|
||||
2. Make changes to your `custom.css` file
|
||||
3. The changes will be applied immediately thanks to hot module reloading
|
||||
4. Use browser developer tools to inspect elements and test different values
|
||||
|
||||
|
||||
[Advanced build-time configuring Zonemaster-GUI using "tsconfig.json"]: configuring-using-tsconfig-json.md
|
||||
[Build a custom Zonemaster-GUI installation package]: building-custom-gui.md
|
||||
[Astro]: https://astro.build/
|
||||
[Configuration of GUI]: https://doc.zonemaster.net/latest/configuration/gui/README.html
|
||||
[Svelte]: https://svelte.dev/
|
||||
[UI.md]: https://github.com/zonemaster/zonemaster-gui/blob/master/docs/UI.md#headless-mode
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
# Advanced build-time configuring Zonemaster-GUI using "tsconfig.json"
|
||||
|
||||
The `tsconfig.json` configuration file can be used for *build-time* settings of
|
||||
Zonemaster-GUI. Any changes to this file require a rebuild of the installation
|
||||
package.
|
||||
|
||||
## Finding "tsconfig.json"
|
||||
|
||||
In the source tree the file is found as `tsconfig.json` relative to the root of
|
||||
the Git tree. It does not exist in the installed Zonemaster-GUI, as the values
|
||||
have been built-in.
|
||||
|
||||
## Rebuilding Zonemaster-GUI after update
|
||||
|
||||
When `tsconfig.json` has been updated, Zonemaster-GUI has to be rebuilt. See
|
||||
[building installation package] for how to get the source tree and building a new
|
||||
installation package.
|
||||
|
||||
## Default "tsconfig`.json"
|
||||
|
||||
The `tsconfig.json` file is a TypeScript configuration file that includes path
|
||||
aliases like `@theme/*` to simplify imports and make theming more manageable.
|
||||
|
||||
|
||||
```json
|
||||
{
|
||||
"extends": "astro/tsconfigs/strict",
|
||||
"include": [".astro/types.d.ts", "**/*"],
|
||||
"exclude": ["dist"],
|
||||
"compilerOptions": {
|
||||
"baseUrl": ".",
|
||||
"paths": {
|
||||
"@/*": ["./src/*"],
|
||||
"@theme/*": ["./src/themes/default/*"]
|
||||
},
|
||||
"resolveJsonModule": true,
|
||||
"esModuleInterop": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## @theme/* Alias in "tsconfig.json"
|
||||
|
||||
The path alias configuration allows importing from the default theme directory
|
||||
using the `@theme` prefix, which makes it possible to create a customize the
|
||||
look-and-feel of the Zonemaster-GUI, e.g. set other colors and type faces.
|
||||
|
||||
```json
|
||||
{
|
||||
"paths": {
|
||||
"@/*": ["./src/*"],
|
||||
"@theme/*": ["./src/themes/default/*"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This alias makes it easier to import theme-specific components and styles
|
||||
in your code. For example, instead of writing:
|
||||
|
||||
```typescript
|
||||
import Button from '../../themes/default/components/Button';
|
||||
```
|
||||
|
||||
You can use:
|
||||
|
||||
```typescript
|
||||
import Button from '@theme/components/Button';
|
||||
```
|
||||
|
||||
This approach simplifies imports and makes it easier to switch between different
|
||||
themes by changing the alias path.
|
||||
|
||||
|
||||
## Theming
|
||||
|
||||
In the [Theming Zonemaster-GUI] document you will find instructions how to add
|
||||
custom theming to Zonemaster-GUI.
|
||||
|
||||
|
||||
[Building installation package]: building-custom-gui.md
|
||||
[Theming Zonemaster-GUI]: https://github.com/zonemaster/zonemaster-gui/blob/master/docs/theming-zonemaster-gui.md
|
||||
30
zonemaster/docs/public/configuration/profiles.md
Normal file
30
zonemaster/docs/public/configuration/profiles.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Profiles
|
||||
|
||||
## Default profile
|
||||
|
||||
The default profile is documented in the [profile properties] section
|
||||
of the Zonemaster::Engine::Profile module.
|
||||
|
||||
The default profile can be extracted from Zonemaster-Engine to a file using this command.
|
||||
|
||||
```sh
|
||||
perl -MZonemaster::Engine::Test -E 'say Zonemaster::Engine::Profile->default->to_json' | jq -S . > profile.json
|
||||
```
|
||||
|
||||
## Creating profiles
|
||||
|
||||
Some properties are empty by default such as `logfilter` and
|
||||
`test_cases_vars`. Those properties are not present in the default
|
||||
profile. For an example of their usage, refer to the additional file,
|
||||
[profile_additional_properties.json].
|
||||
|
||||
The content of the two files, as-is or modified, can be merged into a custom
|
||||
profile file that can be loaded by Zonemaster-Engine. Both Zonemaster-CLI and
|
||||
Zonemaster-Backend have direct options for loading a custom profile file.
|
||||
|
||||
A custom profile file only has to contain those [properties][profile properties]
|
||||
that it should override.
|
||||
|
||||
|
||||
[profile_additional_properties.json]: https://github.com/zonemaster/zonemaster-engine/blob/master/share/profile_additional_properties.json
|
||||
[Profile properties]: https://metacpan.org/pod/Zonemaster::Engine::Profile#PROFILE-PROPERTIES
|
||||
9
zonemaster/docs/public/development/README.md
Normal file
9
zonemaster/docs/public/development/README.md
Normal file
@@ -0,0 +1,9 @@
|
||||
# Zonemaster development guide
|
||||
|
||||
The development guide provides instructions for various tasks related to the
|
||||
development of each component of Zonemaster.
|
||||
|
||||
Development guides:
|
||||
* [Zonemaster-CLI development]
|
||||
|
||||
[Zonemaster-CLI development]: cli.md
|
||||
17
zonemaster/docs/public/development/cli.md
Normal file
17
zonemaster/docs/public/development/cli.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Development
|
||||
|
||||
## Overview
|
||||
|
||||
This is the development guide for Zonemaster-CLI.
|
||||
It provides instructions for various tasks related to the development of
|
||||
Zonemaster-CLI.
|
||||
|
||||
## Common Developer Actions
|
||||
|
||||
### Generate man page
|
||||
|
||||
To generate and view a development version of the man page:
|
||||
|
||||
```sh
|
||||
perldoc -oman script/zonemaster-cli
|
||||
```
|
||||
32
zonemaster/docs/public/installation/README.md
Normal file
32
zonemaster/docs/public/installation/README.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# Installation instructions
|
||||
|
||||
## Manual installation
|
||||
|
||||
Before installing Zonemaster, check the [prerequisites] first.
|
||||
|
||||
Start by installing the following components, in order:
|
||||
|
||||
* [Zonemaster-LDNS];
|
||||
* [Zonemaster-Engine];
|
||||
* [Zonemaster-CLI].
|
||||
|
||||
At this point, tests can be run from the command-line on the local machine.
|
||||
To install the Web GUI, install the following additional components, in order:
|
||||
|
||||
* [Zonemaster-Backend];
|
||||
* [Zonemaster-GUI].
|
||||
|
||||
## Docker
|
||||
|
||||
Most Zonemaster components are available as [Docker] containers. See the dedicated
|
||||
[Docker document] for more information.
|
||||
|
||||
[Docker]: https://www.docker.com/get-started/
|
||||
[Docker document]: docker.md
|
||||
[prerequisites]: prerequisites.md
|
||||
[prerequisites]: prerequisites.md
|
||||
[Zonemaster-Backend]: zonemaster-backend.md
|
||||
[Zonemaster-CLI]: zonemaster-cli.md
|
||||
[Zonemaster-Engine]: zonemaster-engine.md
|
||||
[Zonemaster-GUI]: zonemaster-gui.md
|
||||
[Zonemaster-LDNS]: zonemaster-ldns.md
|
||||
17
zonemaster/docs/public/installation/docker.md
Normal file
17
zonemaster/docs/public/installation/docker.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Docker
|
||||
|
||||
The following components are available on [Docker Hub], and can conveniently be
|
||||
downloaded and run without any installation. Through [Docker], Zonemaster can
|
||||
be run on Linux, MacOS and Windows.
|
||||
|
||||
- Zonemaster-CLI: see [Using Zonemaster-CLI Docker] for how to run Zonemaster-CLI on [Docker].
|
||||
- Zonemaster-Backend: see [Using Zonemaster-Backend Docker] for how to run Zonemaster-Backend
|
||||
and Zonemaster-CLI on [Docker].
|
||||
|
||||
To build your own Docker image, see the [Docker Image Creation] documentation.
|
||||
|
||||
[Docker]: https://www.docker.com/get-started/
|
||||
[Docker Hub]: https://hub.docker.com/u/zonemaster
|
||||
[Docker Image Creation]: https://github.com/zonemaster/zonemaster/blob/master/docs/internal/maintenance/ReleaseProcess-create-docker-image.md
|
||||
[Using Zonemaster-Backend Docker]: ../using/backend/Using-Zonemaster-Backend-Docker.md
|
||||
[Using Zonemaster-CLI Docker]: ../using/cli.md
|
||||
93
zonemaster/docs/public/installation/prerequisites.md
Normal file
93
zonemaster/docs/public/installation/prerequisites.md
Normal file
@@ -0,0 +1,93 @@
|
||||
# Prerequisites
|
||||
|
||||
Zonemaster comes with documentation for and has been tested on the operating systems
|
||||
and processor architecture listed below.
|
||||
|
||||
## Supported processor architectures
|
||||
|
||||
* x86_64 / amd64
|
||||
|
||||
## Supported operating system versions
|
||||
|
||||
| Operating System | Version |
|
||||
|:-----------------|:-------:|
|
||||
| [Debian] | 13 |
|
||||
| [Docker] | n/a |
|
||||
| [FreeBSD] | 14 |
|
||||
| [Rocky Linux] | 8 |
|
||||
| [Rocky Linux] | 9 |
|
||||
| [Rocky Linux] | 10 |
|
||||
| [Ubuntu] | 22.04 |
|
||||
| [Ubuntu] | 24.04 |
|
||||
|
||||
Only the latest long-term supported version of Debian and FreeBSD, respectively,
|
||||
is supported. All long-term supported versions of Rocky Linux and Ubuntu are
|
||||
supported, unless such a version has end of support before the expected next
|
||||
release of Zonemaster.
|
||||
|
||||
Only the Docker images provided by the Zonemaster project on [Docker Hub] are
|
||||
supported. Currently only Zonemaster-CLI is supported on Docker. Docker itself
|
||||
can run on any of the [Docker] supported OSs (Linux, macOS and Windows).
|
||||
|
||||
## Supported database engine versions
|
||||
|
||||
| Operating System | MariaDB | PostgreSQL |
|
||||
|------------------|---------|------------|
|
||||
| Debian 13 | 11.8 | 17 |
|
||||
| Docker | n/a | n/a |
|
||||
| FreeBSD 14 | 8.0 (*) | 17 |
|
||||
| Rocky Linux 8 | 10.3 | 10 |
|
||||
| Rocky Linux 9 | 10.5 | 13 |
|
||||
| Rocky Linux 10 | 10.11 | 16 |
|
||||
| Ubuntu 22.04 | 10.6 | 14 |
|
||||
| Ubuntu 24.04 | 10.11 | 16 |
|
||||
|
||||
* (*) FreeBSD uses MySQL, not MariaDB.
|
||||
* SQLite is bundled in Perl DBD::SQLite and loaded as a dependency to
|
||||
Zonemaster-Backend.
|
||||
* Zonemaster Backend has been tested with the combination of OS and database
|
||||
engine version listed in the table above.
|
||||
* Zonemaster depends on functionality introduced in PostgreSQL version 10, and
|
||||
earlier versions of PostgreSQL are as such not supported.
|
||||
* Zonemaster Backend has not been published on [Docker Hub].
|
||||
|
||||
## Supported Perl versions
|
||||
|
||||
| Operating System | Perl |
|
||||
|------------------|-------|
|
||||
| Debian 13 | 5.40 |
|
||||
| Docker | (*) |
|
||||
| FreeBSD 14 | 5.42 |
|
||||
| Rocky Linux 8 | 5.26 |
|
||||
| Rocky Linux 9 | 5.32 |
|
||||
| Rocky Linux 10 | 5.40 |
|
||||
| Ubuntu 22.04 | 5.34 |
|
||||
| Ubuntu 24.04 | 5.38 |
|
||||
|
||||
|
||||
* Zonemaster technically requires Perl version 5.26 or higher, but has only been tested with the versions in the table above.
|
||||
* Zonemaster has been tested with the default version of Perl in the OSs as
|
||||
listed in the table above.
|
||||
* (*) Perl is included in the Docker images published on [Docker Hub].
|
||||
|
||||
## Supported Client Browser versions
|
||||
|
||||
Zonemaster GUI is tested on the browsers in the table below.
|
||||
The latest version of the browser at the time of testing is used.
|
||||
|
||||
Browser |
|
||||
------- |
|
||||
Firefox |
|
||||
Chrome |
|
||||
|
||||
|
||||
Zonemaster GUI is tested manually and with testing tools. See the
|
||||
[Zonemaster-gui repository][Zonemaster-GUI] for more details.
|
||||
|
||||
[Debian]: https://www.debian.org/
|
||||
[Docker Hub]: https://hub.docker.com/u/zonemaster
|
||||
[Docker]: https://www.docker.com/get-started/
|
||||
[FreeBSD]: https://www.freebsd.org/
|
||||
[Rocky Linux]: https://rockylinux.org/
|
||||
[Ubuntu]: https://ubuntu.com/
|
||||
[Zonemaster-GUI]: https://github.com/zonemaster/zonemaster-gui
|
||||
842
zonemaster/docs/public/installation/zonemaster-backend.md
Normal file
842
zonemaster/docs/public/installation/zonemaster-backend.md
Normal file
@@ -0,0 +1,842 @@
|
||||
# Installation: Zonemaster-Backend
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [1. Overview](#1-overview)
|
||||
* [2. Prerequisites][prerequisites section]
|
||||
* [3. Installation on Rocky Linux](#3-installation-on-rocky-linux)
|
||||
* [3.1 Install Zonemaster::Backend and related dependencies (Rocky Linux)](#31-install-zonemasterbackend-and-related-dependencies-rocky-linux)
|
||||
* [3.2 Database engine installation (Rocky Linux)](#32-database-engine-installation-rocky-linux)
|
||||
* [3.3 Database configuration (Rocky Linux)](#33-database-configuration-rocky-linux)
|
||||
* [3.4 Service configuration and startup (Rocky Linux)](#34-service-configuration-and-startup-rocky-linux)
|
||||
* [3.5 Post-installation (Rocky Linux)](#35-post-installation-rocky-linux)
|
||||
* [4. Installation on Debian and Ubuntu](#4-installation-on-debian-and-ubuntu)
|
||||
* [4.1 Install Zonemaster::Backend and related dependencies (Debian/Ubuntu)](#41-install-zonemasterbackend-and-related-dependencies-debianubuntu)
|
||||
* [4.2 Database engine installation (Debian/Ubuntu)](#42-database-engine-installation-debianubuntu)
|
||||
* [4.3 Database configuration (Debian/Ubuntu)](#43-database-configuration-debianubuntu)
|
||||
* [4.4 Service configuration and startup (Debian/Ubuntu)](#44-service-configuration-and-startup-debianubuntu)
|
||||
* [4.5 Post-installation (Debian/Ubuntu)](#45-post-installation-debianubuntu)
|
||||
* [5. Installation on FreeBSD](#5-installation-on-freebsd)
|
||||
* [5.1 Install Zonemaster::Backend and related dependencies (FreeBSD)](#51-install-zonemasterbackend-and-related-dependencies-freebsd)
|
||||
* [5.2 Database engine installation (FreeBSD)](#52-database-engine-installation-freebsd)
|
||||
* [5.3 Database configuration (FreeBSD)](#53-database-configuration-freebsd)
|
||||
* [5.4 Service startup (FreeBSD)](#54-service-startup-freebsd)
|
||||
* [5.5 Post-installation (FreeBSD)](#55-post-installation-freebsd)
|
||||
* [6. Post-installation][Post-installation]
|
||||
* [6.1 Smoke test](#61-smoke-test)
|
||||
* [6.2 Troubleshooting installation](#62-troubleshooting-installation)
|
||||
* [6.3 What to do next?](#63-what-to-do-next)
|
||||
* [7. Installation with MariaDB](#7-installation-with-mariadb)
|
||||
* [7.1 MariaDB (Rocky Linux)][MariaDB instructions Rocky Linux]
|
||||
* [7.2. MariaDB (Debian/Ubuntu)][MariaDB instructions Debian]
|
||||
* [7.3. MySQL (FreeBSD)][MySQL instructions FreeBSD]
|
||||
* [8. Installation with PostgreSQL](#8-installation-with-postgresql)
|
||||
* [8.1. PostgreSQL (Rocky Linux)][PostgreSQL instructions Rocky Linux]
|
||||
* [8.2. PostgreSQL (Debian/Ubuntu)][PostgreSQL instructions Debian]
|
||||
* [8.3. PostgreSQL (FreeBSD)][PostgreSQL instructions FreeBSD]
|
||||
* [9. Cleaning up the database][Removing database]
|
||||
* [9.1. MariaDB and MySQL](#91-mariadb-and-mysql)
|
||||
* [9.2. PostgreSQL](#92-postgresql)
|
||||
* [9.3. SQLite](#93-sqlite)
|
||||
* [10. Optional features](#10-optional-features)
|
||||
* [10.1. Metrics](#101-metrics)
|
||||
* [10.2 Global cache](#102-global-cache)
|
||||
|
||||
|
||||
## 1. Overview
|
||||
|
||||
This document contains all steps needed to install Zonemaster::Backend. For an overview of the
|
||||
Zonemaster product, please see the [main Zonemaster Repository].
|
||||
|
||||
If you upgrade your Zonemaster installation with a newer version of
|
||||
Zonemaster::Backend instead, and want to keep the database, then see the
|
||||
[Upgrade document]. Otherwise [remove the database][Removing database] and
|
||||
continue with this installation document.
|
||||
|
||||
An alternative to installing Zonemaster-Backend is to run it under [Docker]. See [Using the Backend] for run it under Docker.
|
||||
|
||||
## 2. Prerequisites
|
||||
|
||||
Before installing Zonemaster::Backend, you should [install Zonemaster::Engine
|
||||
][Zonemaster::Engine installation].
|
||||
|
||||
> **Note:** [Zonemaster::Engine] and [Zonemaster::LDNS] are dependencies of
|
||||
> Zonemaster::Backend. Zonemaster::LDNS has a special installation requirement,
|
||||
> and Zonemaster::Engine has a list of dependencies that you may prefer to
|
||||
> install from your operating system distribution (rather than CPAN).
|
||||
> We recommend following the Zonemaster::Engine installation instruction.
|
||||
|
||||
Prerequisite for FreeBSD is that the package system is updated and activated
|
||||
(see the FreeBSD section of [Zonemaster::Engine installation]).
|
||||
|
||||
For details on supported versions of Perl, database engine and operating system
|
||||
for Zonemaster::Backend, see the [declaration of prerequisites].
|
||||
|
||||
|
||||
## 3. Installation on Rocky Linux
|
||||
|
||||
### 3.1 Install Zonemaster::Backend and related dependencies (Rocky Linux)
|
||||
|
||||
> **Note:** Zonemaster::LDNS and Zonemaster::Engine are not listed here as they
|
||||
> are dealt with in the [prerequisites section].
|
||||
|
||||
Install dependencies available from binary packages:
|
||||
|
||||
```sh
|
||||
sudo dnf install --assumeyes jq perl-Class-Method-Modifiers perl-Config-IniFiles perl-DBD-SQLite perl-DBI perl-File-ShareDir perl-File-Slurp perl-HTML-Parser perl-JSON-PP perl-libwww-perl perl-Log-Dispatch perl-Mojolicious perl-Moose perl-Net-Server perl-Parallel-ForkManager perl-Plack perl-Plack-Test perl-Role-Tiny perl-Test-Differences perl-Test-Exception perl-Test-Mojo perl-Test-NoWarnings perl-Try-Tiny perl-libintl perl-LWP-Protocol-https
|
||||
```
|
||||
|
||||
Install dependencies not available from binary packages:
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest Daemon::Control JSON::RPC JSON::Validator Log::Any Log::Any::Adapter::Dispatch Net::IP::XS Plack::Middleware::ReverseProxy Router::Simple Starman
|
||||
```
|
||||
|
||||
For Rocky Linux 8 only, install DBD::SQLite from CPAN as the one in the system packages repository is too old:
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest DBD::SQLite
|
||||
```
|
||||
|
||||
Install Zonemaster::Backend:
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest Zonemaster::Backend
|
||||
```
|
||||
|
||||
Add Zonemaster user (unless it already exists):
|
||||
|
||||
```sh
|
||||
sudo useradd --system --home-dir=/nonexistent --shell=/usr/sbin/nologin --comment="Zonemaster daemon user" zonemaster
|
||||
```
|
||||
|
||||
Install files to their proper locations:
|
||||
|
||||
```sh
|
||||
cd `perl -MFile::ShareDir=dist_dir -E 'say dist_dir("Zonemaster-Backend")'`
|
||||
sudo install -v -m 755 -d /etc/zonemaster
|
||||
sudo install -v -m 640 -g zonemaster ./backend_config.ini /etc/zonemaster/
|
||||
sudo install -v -m 775 -g zonemaster -d /var/log/zonemaster
|
||||
sudo install -v -m 644 ./tmpfiles.conf /usr/lib/tmpfiles.d/zonemaster.conf
|
||||
sudo install -v -m 644 -Z ./zm-rpcapi.service /etc/systemd/system/
|
||||
sudo install -v -m 644 -Z ./zm-testagent.service /etc/systemd/system/
|
||||
```
|
||||
|
||||
### 3.2 Database engine installation (Rocky Linux)
|
||||
|
||||
Check the [declaration of prerequisites] to make sure your preferred combination
|
||||
of operating system version and database engine version is supported.
|
||||
|
||||
The installation instructions below assumes that this is a new installation.
|
||||
|
||||
|
||||
#### 3.2.1 Instructions for SQLite (Rocky Linux)
|
||||
|
||||
> **Note:** Zonemaster with SQLite is not meant for an installation with heavy
|
||||
> load.
|
||||
|
||||
Create database directory:
|
||||
|
||||
```sh
|
||||
sudo install -v -m 755 -o zonemaster -g zonemaster -d /var/lib/zonemaster
|
||||
```
|
||||
|
||||
> Some parameters can be changed, see the [backend configuration] documentation
|
||||
> for details.
|
||||
|
||||
|
||||
#### 3.2.2 Instructions for other engines (Rocky Linux)
|
||||
|
||||
See sections for [MariaDB][MariaDB instructions Rocky Linux] and
|
||||
[PostgreSQL][PostgreSQL instructions Rocky Linux].
|
||||
|
||||
|
||||
### 3.3 Database configuration (Rocky Linux)
|
||||
|
||||
Create the database tables:
|
||||
|
||||
```sh
|
||||
(cd / && sudo --user=zonemaster $(perl -MFile::ShareDir -le 'print File::ShareDir::dist_dir("Zonemaster-Backend")')/create_db.pl)
|
||||
```
|
||||
|
||||
|
||||
### 3.4 Service configuration and startup (Rocky Linux)
|
||||
|
||||
Make sure our tmpfiles configuration takes effect:
|
||||
|
||||
```sh
|
||||
sudo systemd-tmpfiles --create /usr/lib/tmpfiles.d/zonemaster.conf
|
||||
```
|
||||
|
||||
Enable services at boot time and start them:
|
||||
|
||||
```sh
|
||||
sudo systemctl enable zm-rpcapi
|
||||
sudo systemctl enable zm-testagent
|
||||
sudo systemctl start zm-rpcapi
|
||||
sudo systemctl start zm-testagent
|
||||
```
|
||||
|
||||
If you have changed database daemon, restart the services:
|
||||
|
||||
```sh
|
||||
sudo systemctl restart zm-rpcapi
|
||||
sudo systemctl restart zm-testagent
|
||||
```
|
||||
|
||||
### 3.5 Post-installation (Rocky Linux)
|
||||
|
||||
To check if the daemons are running, do:
|
||||
|
||||
```sh
|
||||
sudo systemctl status --no-pager zm-rpcapi
|
||||
sudo systemctl status --no-pager zm-testagent
|
||||
```
|
||||
|
||||
See the [post-installation] section for post-installation matters.
|
||||
|
||||
|
||||
## 4. Installation on Debian and Ubuntu
|
||||
|
||||
### 4.1 Install Zonemaster::Backend and related dependencies (Debian/Ubuntu)
|
||||
|
||||
> **Note:** Zonemaster::LDNS and Zonemaster::Engine are not listed here as they
|
||||
> are dealt with in the [prerequisites section].
|
||||
|
||||
Install required locales:
|
||||
|
||||
```sh
|
||||
sudo perl -pi -e 's/^# (da_DK\.UTF-8.*|en_US\.UTF-8.*|es_ES\.UTF-8.*|fi_FI\.UTF-8.*|fr_FR\.UTF-8.*|nb_NO\.UTF-8.*|sl_SI\.UTF-8.*|sv_SE\.UTF-8.*)/$1/' /etc/locale.gen
|
||||
sudo locale-gen
|
||||
```
|
||||
|
||||
After the update, `locale -a` should at least list the following locales:
|
||||
```
|
||||
da_DK.utf8
|
||||
en_US.utf8
|
||||
es_ES.utf8
|
||||
fi_FI.utf8
|
||||
fr_FR.utf8
|
||||
nb_NO.utf8
|
||||
sl_SI.utf8
|
||||
sv_SE.utf8
|
||||
```
|
||||
|
||||
Install dependencies available from binary packages:
|
||||
|
||||
```sh
|
||||
sudo apt install jq libclass-method-modifiers-perl libconfig-inifiles-perl libdbd-sqlite3-perl libdaemon-control-perl libdbi-perl libfile-sharedir-perl libfile-slurp-perl libhtml-parser-perl libmojolicious-perl libio-stringy-perl libjson-pp-perl libjson-rpc-perl libjson-validator-perl liblog-any-adapter-dispatch-perl liblog-any-perl liblog-dispatch-perl libmoose-perl libparallel-forkmanager-perl libplack-perl libplack-middleware-debug-perl libplack-middleware-reverseproxy-perl librole-tiny-perl librouter-simple-perl libtest-nowarnings-perl libtest-differences-perl libtest-exception-perl libtry-tiny-perl libintl-perl perl-doc starman
|
||||
```
|
||||
> **Note**: libio-stringy-perl is listed here even though it's not a direct
|
||||
> dependency. It's an undeclared dependency of libconfig-inifiles-perl.
|
||||
|
||||
For Ubuntu 20.04 only, install JSON::Validator from CPAN as the one in the system packages repository is too old:
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest JSON::Validator
|
||||
```
|
||||
|
||||
Install Zonemaster::Backend:
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest Zonemaster::Backend
|
||||
```
|
||||
|
||||
Add Zonemaster user (unless it already exists):
|
||||
|
||||
```sh
|
||||
sudo useradd -r -c "Zonemaster daemon user" zonemaster
|
||||
```
|
||||
|
||||
Install files to their proper locations:
|
||||
|
||||
```sh
|
||||
cd `perl -MFile::ShareDir=dist_dir -E 'say dist_dir("Zonemaster-Backend")'`
|
||||
sudo install -v -m 755 -d /etc/zonemaster
|
||||
sudo install -v -m 775 -g zonemaster -d /var/log/zonemaster
|
||||
sudo install -v -m 640 -g zonemaster ./backend_config.ini /etc/zonemaster/
|
||||
sudo install -v -m 755 ./zm-rpcapi.lsb /etc/init.d/zm-rpcapi
|
||||
sudo install -v -m 755 ./zm-testagent.lsb /etc/init.d/zm-testagent
|
||||
sudo install -v -m 644 ./tmpfiles.conf /usr/lib/tmpfiles.d/zonemaster.conf
|
||||
```
|
||||
|
||||
> If this is an update of Zonemaster-Backend, you should remove any
|
||||
> `/etc/init.d/zm-backend.sh` (script from previous version of Zonemaster-Backend).
|
||||
|
||||
|
||||
### 4.2 Database engine installation (Debian/Ubuntu)
|
||||
|
||||
Check the [declaration of prerequisites] to make sure your preferred combination
|
||||
of operating system version and database engine version is supported.
|
||||
|
||||
The installation instructions below assumes that this is a new installation.
|
||||
|
||||
|
||||
#### 4.2.1 Instructions for SQLite (Debian/Ubuntu)
|
||||
|
||||
> **Note:** Zonemaster with SQLite is not meant for an installation with heavy
|
||||
> load.
|
||||
|
||||
Create database directory:
|
||||
|
||||
```sh
|
||||
sudo install -v -m 755 -o zonemaster -g zonemaster -d /var/lib/zonemaster
|
||||
```
|
||||
|
||||
> Some parameters can be changed, see the [backend configuration] documentation
|
||||
> for details.
|
||||
|
||||
|
||||
#### 4.2.2 Instructions for other engines (Debian/Ubuntu)
|
||||
|
||||
See sections for [MariaDB][MariaDB instructions Debian] and
|
||||
[PostgreSQL][PostgreSQL instructions Debian].
|
||||
|
||||
|
||||
### 4.3 Database configuration (Debian/Ubuntu)
|
||||
|
||||
Create the database tables:
|
||||
|
||||
```sh
|
||||
sudo -u zonemaster $(perl -MFile::ShareDir -le 'print File::ShareDir::dist_dir("Zonemaster-Backend")')/create_db.pl
|
||||
```
|
||||
|
||||
|
||||
### 4.4 Service configuration and startup (Debian/Ubuntu)
|
||||
|
||||
Make sure our tmpfiles configuration takes effect:
|
||||
|
||||
```sh
|
||||
sudo systemd-tmpfiles --create /usr/lib/tmpfiles.d/zonemaster.conf
|
||||
```
|
||||
|
||||
Enable services at boot time and start them:
|
||||
|
||||
```sh
|
||||
sudo systemctl enable zm-rpcapi
|
||||
sudo systemctl enable zm-testagent
|
||||
sudo systemctl start zm-rpcapi
|
||||
sudo systemctl start zm-testagent
|
||||
```
|
||||
|
||||
If you have changed database daemon, restart the services:
|
||||
|
||||
```sh
|
||||
sudo systemctl restart zm-rpcapi
|
||||
sudo systemctl restart zm-testagent
|
||||
```
|
||||
|
||||
### 4.5 Post-installation (Debian/Ubuntu)
|
||||
|
||||
To check if the daemons are running, do:
|
||||
|
||||
```sh
|
||||
sudo systemctl status zm-rpcapi
|
||||
sudo systemctl status zm-testagent
|
||||
```
|
||||
|
||||
See the [post-installation] section for post-installation matters.
|
||||
|
||||
|
||||
## 5. Installation on FreeBSD
|
||||
|
||||
For all commands below, acquire privileges, i.e. become root:
|
||||
|
||||
```sh
|
||||
su -l
|
||||
```
|
||||
|
||||
### 5.1 Install Zonemaster::Backend and related dependencies (FreeBSD)
|
||||
|
||||
> **Note:** Zonemaster::LDNS and Zonemaster::Engine are not listed here as they
|
||||
> are dealt with in the [prerequisites section].
|
||||
|
||||
Install dependencies available from binary packages:
|
||||
|
||||
```sh
|
||||
pkg install jq p5-Class-Method-Modifiers p5-Config-IniFiles p5-Daemon-Control p5-DBI p5-File-ShareDir p5-File-Slurp p5-HTML-Parser p5-JSON-PP p5-JSON-RPC p5-Mojolicious p5-Moose p5-Parallel-ForkManager p5-Plack p5-Plack-Middleware-ReverseProxy p5-Role-Tiny p5-Router-Simple p5-Starman p5-DBD-SQLite p5-Log-Dispatch p5-Log-Any p5-Log-Any-Adapter-Dispatch p5-JSON-Validator p5-YAML-LibYAML p5-Test-NoWarnings p5-Test-Differences p5-Test-Exception p5-Locale-libintl gmake
|
||||
```
|
||||
<!-- JSON::Validator requires YAML::PP, but p5-JSON-Validator currently lacks a dependency on p5-YAML-LibYAML -->
|
||||
|
||||
Install Zonemaster::Backend:
|
||||
|
||||
```sh
|
||||
cpanm --notest Zonemaster::Backend
|
||||
```
|
||||
|
||||
Unless they already exist, add `zonemaster` user and `zonemaster` group:
|
||||
|
||||
```sh
|
||||
cd `perl -MFile::ShareDir -le 'print File::ShareDir::dist_dir("Zonemaster-Backend")'`
|
||||
pw useradd zonemaster -C freebsd-pwd.conf -s /sbin/nologin -d /nonexistent -c "Zonemaster daemon user"
|
||||
```
|
||||
|
||||
Install files to their proper locations:
|
||||
|
||||
```sh
|
||||
cd `perl -MFile::ShareDir -le 'print File::ShareDir::dist_dir("Zonemaster-Backend")'`
|
||||
install -v -m 755 -d /usr/local/etc/zonemaster
|
||||
install -v -m 640 -g zonemaster ./backend_config.ini /usr/local/etc/zonemaster/
|
||||
install -v -m 775 -g zonemaster -d /var/log/zonemaster
|
||||
install -v -m 775 -g zonemaster -d /var/run/zonemaster
|
||||
install -v -m 755 ./zm_rpcapi-bsd /usr/local/etc/rc.d/zm_rpcapi
|
||||
install -v -m 755 ./zm_testagent-bsd /usr/local/etc/rc.d/zm_testagent
|
||||
```
|
||||
|
||||
### 5.2 Database engine installation (FreeBSD)
|
||||
|
||||
Check the [declaration of prerequisites] to make sure your preferred combination
|
||||
of operating system version and database engine version is supported.
|
||||
|
||||
The installation instructions below assumes that this is a new installation.
|
||||
|
||||
#### 5.2.1 Instructions for SQLite (FreeBSD)
|
||||
|
||||
> **Note:** Zonemaster with SQLite is not meant for an installation with heavy
|
||||
> load.
|
||||
|
||||
Configure Zonemaster::Backend to use the correct database path:
|
||||
|
||||
```sh
|
||||
sed -i '' '/[[:<:]]database_file[[:>:]]/ s:=.*:= /var/db/zonemaster/db.sqlite:' /usr/local/etc/zonemaster/backend_config.ini
|
||||
```
|
||||
|
||||
Create database directory:
|
||||
|
||||
```sh
|
||||
install -v -m 755 -o zonemaster -g zonemaster -d /var/db/zonemaster
|
||||
```
|
||||
|
||||
> Some parameters can be changed, see the [backend configuration] documentation
|
||||
> for details.
|
||||
|
||||
#### 5.2.2 Instructions for other engines (FreeBSD)
|
||||
|
||||
See sections for [MySQL][MySQL instructions FreeBSD] and
|
||||
[PostgreSQL][PostgreSQL instructions FreeBSD].
|
||||
|
||||
|
||||
### 5.3 Database configuration (FreeBSD)
|
||||
|
||||
Create the database tables:
|
||||
|
||||
```sh
|
||||
su -m zonemaster -c "`perl -MFile::ShareDir -le 'print File::ShareDir::dist_dir(qw(Zonemaster-Backend))'`/create_db.pl"
|
||||
```
|
||||
|
||||
|
||||
### 5.4 Service startup (FreeBSD)
|
||||
|
||||
Enable services at startup and start service:
|
||||
|
||||
```sh
|
||||
sysrc zm_rpcapi_enable="YES"
|
||||
sysrc zm_testagent_enable="YES"
|
||||
service zm_rpcapi start
|
||||
service zm_testagent start
|
||||
```
|
||||
|
||||
If you have changed database daemon, restart the services:
|
||||
|
||||
```sh
|
||||
service zm_rpcapi restart
|
||||
service zm_testagent restart
|
||||
```
|
||||
|
||||
### 5.5 Post-installation (FreeBSD)
|
||||
|
||||
To check that the running daemons run:
|
||||
|
||||
```sh
|
||||
service zm_rpcapi status
|
||||
service zm_testagent status
|
||||
```
|
||||
|
||||
See the [post-installation] section for post-installation matters.
|
||||
|
||||
|
||||
## 6. Post-installation
|
||||
|
||||
### 6.1 Smoke test
|
||||
|
||||
If you have followed the installation instructions for Zonemaster::Backend above,
|
||||
you should be able to use the API on localhost port 5000 as below.
|
||||
|
||||
```sh
|
||||
zmtest zonemaster.net
|
||||
```
|
||||
|
||||
The command is expected to immediately print out a testid,
|
||||
followed by a percentage ticking up from 0% to 100%.
|
||||
Once the number reaches 100% a JSON object is printed and zmtest terminates.
|
||||
|
||||
### 6.2 Troubleshooting installation
|
||||
|
||||
If you have any issue with installation, and installed with `cpanm`, redo the
|
||||
installation above but without the `--notest` and with the `--verbose` option.
|
||||
Installation will take longer time.
|
||||
|
||||
### 6.3. What to do next?
|
||||
|
||||
* For the Zonemaster-Backend functions see the following documents:
|
||||
* [Using Zonemaster-Backend JSON-RPC API]
|
||||
* Backend [JSON-RPC API] documentation
|
||||
* [Using Zonemaster-Backend for batch testing]
|
||||
* [Backend configuration]
|
||||
* Zonemaster [Profiles]
|
||||
* [Backend Environment variables]
|
||||
* For a web interface, follow the [Zonemaster::GUI installation] instructions.
|
||||
* For a command line interface, follow the [Zonemaster::CLI installation] instruction.
|
||||
|
||||
## 7. Installation with MariaDB
|
||||
|
||||
First follow the installation instructions for the OS in question, and then go
|
||||
to this section to install MariaDB.
|
||||
|
||||
### 7.1. MariaDB (Rocky Linux)
|
||||
|
||||
Configure Zonemaster::Backend to use the correct database engine:
|
||||
|
||||
```sh
|
||||
sudo sed -i '/\bengine\b/ s/=.*/= MySQL/' /etc/zonemaster/backend_config.ini
|
||||
```
|
||||
|
||||
> **Note:** See the [backend configuration] documentation for details.
|
||||
|
||||
Install database engine:
|
||||
|
||||
```sh
|
||||
sudo dnf -y install mariadb-server perl-DBD-mysql
|
||||
```
|
||||
|
||||
To create the database and the database user (unless you keep an old database).
|
||||
Edit the commands first if you want a non-default database name, user name or
|
||||
password. To be safe, run the commands one by one.
|
||||
|
||||
```sh
|
||||
sudo systemctl start mariadb
|
||||
sudo mysql -e "CREATE DATABASE zonemaster;"
|
||||
sudo mysql -e "CREATE USER 'zonemaster'@'localhost' IDENTIFIED BY 'zonemaster';"
|
||||
sudo mysql -e "GRANT ALL ON zonemaster.* TO 'zonemaster'@'localhost';"
|
||||
```
|
||||
|
||||
Update the `/etc/zonemaster/backend_config.ini` file with database name,
|
||||
username and password if non-default values are used.
|
||||
|
||||
Now go back to "[Database configuration](#33-database-configuration-rocky-linux)"
|
||||
to create the database tables and then continue with the steps after that.
|
||||
|
||||
|
||||
### 7.2. MariaDB (Debian/Ubuntu)
|
||||
|
||||
Configure Zonemaster::Backend to use the correct database engine:
|
||||
|
||||
```sh
|
||||
sudo sed -i '/\bengine\b/ s/=.*/= MySQL/' /etc/zonemaster/backend_config.ini
|
||||
```
|
||||
|
||||
> **Note:** See the [backend configuration] documentation for details.
|
||||
|
||||
Install the database engine and its dependencies:
|
||||
|
||||
```sh
|
||||
sudo apt install mariadb-server libdbd-mysql-perl
|
||||
```
|
||||
|
||||
To create the database and the database user (unless you keep an old database).
|
||||
Edit the commands first if you want a non-default database name, user name or
|
||||
password. To be safe, run the commands one by one.
|
||||
|
||||
```sh
|
||||
sudo mysql -e "CREATE DATABASE zonemaster;"
|
||||
```
|
||||
```sh
|
||||
sudo mysql -e "CREATE USER 'zonemaster'@'localhost' IDENTIFIED BY 'zonemaster';"
|
||||
```
|
||||
```sh
|
||||
sudo mysql -e "GRANT ALL ON zonemaster.* TO 'zonemaster'@'localhost';"
|
||||
```
|
||||
|
||||
Update the `/etc/zonemaster/backend_config.ini` file with database name, username
|
||||
and password if non-default values are used.
|
||||
|
||||
Now go back to "[Database configuration](#43-database-configuration-debianubuntu)"
|
||||
to create the database tables and then continue with the steps after that.
|
||||
|
||||
|
||||
### 7.3. MySQL (FreeBSD)
|
||||
|
||||
> MariaDB is not compatible with Zonemaster on FreeBSD. MySQL is used instead.
|
||||
|
||||
Configure Zonemaster::Backend to use the correct database engine:
|
||||
|
||||
```sh
|
||||
sed -i '' '/[[:<:]]engine[[:>:]]/ s/=.*/= MySQL/' /usr/local/etc/zonemaster/backend_config.ini
|
||||
```
|
||||
> **Note:** See the [backend configuration] documentation for details.
|
||||
|
||||
Install, configure and start database engine (and Perl bindings):
|
||||
|
||||
```sh
|
||||
pkg install mysql80-server p5-DBD-mysql
|
||||
```
|
||||
|
||||
```sh
|
||||
sysrc mysql_enable="YES"
|
||||
service mysql-server start
|
||||
```
|
||||
|
||||
By default the MySQL root password is empty. Just press ENTER if prompted for
|
||||
password. The advice is to set a password.
|
||||
|
||||
To create the database and the database user (unless you keep an old database).
|
||||
Edit the command first if you want a non-default database name, user name or
|
||||
password. Run the command on one line. Use the MySQL root password when
|
||||
prompted.
|
||||
|
||||
```sh
|
||||
mysql -u root -p -e "CREATE DATABASE zonemaster;" -e "CREATE USER 'zonemaster'@'localhost' IDENTIFIED BY 'zonemaster';" -e "GRANT ALL ON zonemaster.* TO 'zonemaster'@'localhost';"
|
||||
```
|
||||
|
||||
Update the `/usr/local/etc/zonemaster/backend_config.ini` file with database
|
||||
name, username and password if non-default values are used.
|
||||
|
||||
Now go back to "[Database configuration](#53-database-configuration-freebsd)"
|
||||
to create the database tables and then continue with the steps after that.
|
||||
|
||||
|
||||
## 8. Installation with PostgreSQL
|
||||
|
||||
First follow the installation instructions for the OS in question, and then go
|
||||
to this section to install PostgreSQL.
|
||||
|
||||
### 8.1. PostgreSQL (Rocky Linux)
|
||||
|
||||
Configure Zonemaster::Backend to use the correct database engine:
|
||||
|
||||
```sh
|
||||
sudo sed -i '/\bengine\b/ s/=.*/= PostgreSQL/' /etc/zonemaster/backend_config.ini
|
||||
```
|
||||
|
||||
> **Note:** See the [backend configuration] documentation for details.
|
||||
|
||||
Install, initialize and configure database engine:
|
||||
|
||||
```sh
|
||||
sudo dnf -y install postgresql-server perl-DBD-Pg
|
||||
sudo postgresql-setup --initdb --unit postgresql
|
||||
sudo sed -i '/^[^#]/ s/ident$/md5/' /var/lib/pgsql/data/pg_hba.conf
|
||||
```
|
||||
|
||||
To create the database and the database user (unless you keep an old database).
|
||||
Edit the command first if you want a non-default database name, user name or
|
||||
password. To be safe run the commands one by one.
|
||||
|
||||
```sh
|
||||
sudo systemctl start postgresql
|
||||
sudo --login --user=postgres psql -c "CREATE USER zonemaster WITH PASSWORD 'zonemaster';"
|
||||
sudo --login --user=postgres psql -c "CREATE DATABASE zonemaster WITH OWNER 'zonemaster' ENCODING 'UTF8';"
|
||||
```
|
||||
|
||||
> **Note:** You may get error messages from these commands about lack of
|
||||
> permission to change directory. You can safely ignore those messages.
|
||||
|
||||
Update the `/etc/zonemaster/backend_config.ini` file with database name, username
|
||||
and password if non-default values are used.
|
||||
|
||||
Now go back to "[Database configuration](#33-database-configuration-rocky-linux)"
|
||||
to create the database tables and then continue with the steps after that.
|
||||
|
||||
|
||||
### 8.2. PostgreSQL (Debian/Ubuntu)
|
||||
|
||||
Configure Zonemaster::Backend to use the correct database engine:
|
||||
|
||||
```sh
|
||||
sudo sed -i '/\bengine\b/ s/=.*/= PostgreSQL/' /etc/zonemaster/backend_config.ini
|
||||
```
|
||||
|
||||
Install the database engine and Perl bindings:
|
||||
|
||||
```sh
|
||||
sudo apt install postgresql libdbd-pg-perl
|
||||
```
|
||||
|
||||
> **Note:** See the [backend configuration] documentation for details.
|
||||
|
||||
To create the database and the database user (unless you keep an old database).
|
||||
Edit the command first if you want a non-default database name, user name or
|
||||
password. To be safe run the commands one by one.
|
||||
|
||||
```sh
|
||||
sudo -u postgres psql -c "CREATE USER zonemaster WITH PASSWORD 'zonemaster';"
|
||||
|
||||
```
|
||||
```sh
|
||||
sudo -u postgres psql -c "CREATE DATABASE zonemaster WITH OWNER 'zonemaster' ENCODING 'UTF8';"
|
||||
|
||||
```
|
||||
|
||||
Update the `/etc/zonemaster/backend_config.ini` file with database name, username
|
||||
and password if non-default values are used.
|
||||
|
||||
Now go back to "[Database configuration](#43-database-configuration-debianubuntu)"
|
||||
to create the database tables and then continue with the steps after that.
|
||||
|
||||
|
||||
### 8.3. PostgreSQL (FreeBSD)
|
||||
|
||||
Configure Zonemaster::Backend to use the correct database engine:
|
||||
|
||||
```sh
|
||||
sed -i '' '/[[:<:]]engine[[:>:]]/ s/=.*/= PostgreSQL/' /usr/local/etc/zonemaster/backend_config.ini
|
||||
```
|
||||
> **Note:** See the [backend configuration] documentation for details.
|
||||
|
||||
Install, configure and start database engine and Perl bindings:
|
||||
|
||||
```sh
|
||||
pkg install p5-DBD-Pg
|
||||
```
|
||||
|
||||
The Perl bindings library (`p5-DBD-Pg`) has a dependency to a specific version
|
||||
of `postgresql-client`. Determine what version was installed:
|
||||
|
||||
```sh
|
||||
pkg info | grep postgresql | grep client
|
||||
```
|
||||
Replace `XX` in the command below to install `postgresql-server` with the same
|
||||
major version as the installed `postgresql-client`, e.g. `17`.
|
||||
|
||||
```sh
|
||||
pkg install postgresqlXX-server
|
||||
```
|
||||
|
||||
Enable daemon, initiate and start:
|
||||
|
||||
```sh
|
||||
sysrc postgresql_enable="YES"
|
||||
service postgresql initdb
|
||||
service postgresql start
|
||||
```
|
||||
|
||||
To create the database and the database user (unless you keep an old database).
|
||||
Edit the commands first if you want a non-default database name, user name or
|
||||
password.
|
||||
|
||||
```sh
|
||||
psql -U postgres -c "CREATE USER zonemaster WITH PASSWORD 'zonemaster';"
|
||||
psql -U postgres -c "CREATE DATABASE zonemaster WITH OWNER 'zonemaster' ENCODING 'UTF8';"
|
||||
```
|
||||
|
||||
Update the `/usr/local/etc/zonemaster/backend_config.ini` file with database
|
||||
name, username and password if non-default values are used.
|
||||
|
||||
Now go back to "[Database configuration](#53-database-configuration-freebsd)"
|
||||
to create the database tables and then continue with the steps after that.
|
||||
|
||||
|
||||
## 9. Cleaning up the database
|
||||
|
||||
If, at some point, you want to delete all traces of Zonemaster in the database,
|
||||
you can run the file `cleanup-mysql.sql` or file `cleanup-postgres.sql`
|
||||
as a database administrator. Commands
|
||||
for locating and running the file are below. It removes the user and drops the
|
||||
database (obviously taking all data with it).
|
||||
|
||||
> Each script uses default values, you may need to adapt them to your setup.
|
||||
|
||||
### 9.1. MariaDB and MySQL
|
||||
|
||||
Rocky Linux, Debian and Ubuntu:
|
||||
|
||||
```sh
|
||||
sudo mysql --user=root < `perl -MFile::ShareDir -le 'print File::ShareDir::dist_dir("Zonemaster-Backend")'`/cleanup-mysql.sql
|
||||
```
|
||||
|
||||
FreeBSD (you will get prompted for MySQL password):
|
||||
|
||||
```sh
|
||||
mysql --user=root -p < `perl -MFile::ShareDir -le 'print File::ShareDir::dist_dir("Zonemaster-Backend")'`/cleanup-mysql.sql
|
||||
```
|
||||
|
||||
### 9.2. PostgreSQL
|
||||
|
||||
Rocky Linux, Debian and Ubuntu:
|
||||
|
||||
```sh
|
||||
sudo -u postgres psql -f $(perl -MFile::ShareDir=dist_dir -E 'say dist_dir("Zonemaster-Backend")')/cleanup-postgres.sql
|
||||
```
|
||||
|
||||
FreeBSD (as root):
|
||||
|
||||
```sh
|
||||
psql -U postgres -f `perl -MFile::ShareDir -le 'print File::ShareDir::dist_dir("Zonemaster-Backend")'`/cleanup-postgres.sql
|
||||
```
|
||||
|
||||
### 9.3. SQLite
|
||||
|
||||
Remove the database file and recreate it following the installation instructions above.
|
||||
|
||||
## 10. Optional features
|
||||
|
||||
### 10.1 Metrics
|
||||
|
||||
Statsd metrics are available, to enable the feature install the additional
|
||||
`Net::Statsd` module. See the [configuration][Backend configuration] to
|
||||
configure the receiver.
|
||||
|
||||
The list of metrics is available in the [Telemetry document][metrics].
|
||||
|
||||
### 10.1.1 Installation on Rocky Linux
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest Net::Statsd
|
||||
```
|
||||
|
||||
### 10.1.2 Installation on Debian / Ubuntu
|
||||
|
||||
|
||||
```sh
|
||||
sudo apt install libnet-statsd-perl
|
||||
```
|
||||
|
||||
### 10.1.3 Installation on Freebsd
|
||||
|
||||
```sh
|
||||
cpanm --notest Net::Statsd
|
||||
```
|
||||
|
||||
### 10.2 Global cache
|
||||
|
||||
If Zonemaster-Backend is to be used for large batches, global cache can improve
|
||||
performance. See [Global cache in Zonemaster-Engine].
|
||||
|
||||
|
||||
[Backend Environment variables]: ../configuration/backend-environment-variables.md
|
||||
[Backend configuration]: ../configuration/backend.md
|
||||
[Declaration of prerequisites]: prerequisites.md
|
||||
[Global cache in Zonemaster-Engine]: ../configuration/global-cache.md
|
||||
[JSON-RPC API]: ../using/backend/rpcapi-reference.md
|
||||
[Main Zonemaster repository]: https://github.com/zonemaster/zonemaster/blob/master/README.md
|
||||
[MariaDB instructions Debian]: #72-mariadb-debianubuntu
|
||||
[MariaDB instructions Rocky Linux]: #71-mariadb-rocky-linux
|
||||
[Metrics]: ../using/backend/telemetry.md#metrics
|
||||
[MySQL instructions FreeBSD]: #73-mysql-freebsd
|
||||
[Post-installation]: #6-post-installation
|
||||
[PostgreSQL instructions Debian]: #82-postgresql-debianubuntu
|
||||
[PostgreSQL instructions FreeBSD]: #83-postgresql-freebsd
|
||||
[PostgreSQL instructions Rocky Linux]: #81-postgresql-rocky-linux
|
||||
[Prerequisites section]: #2-prerequisites
|
||||
[Profiles]: ../configuration/profiles.md
|
||||
[Removing database]: #9-cleaning-up-the-database
|
||||
[Upgrade document]: ../upgrading/backend.md
|
||||
[Using Zonemaster-Backend for batch testing]: ../using/backend/Using-Zonemaster-Backend-for-batch-testing.md
|
||||
[Using Zonemaster-Backend JSON-RPC API]: ../using/backend/Using-Zonemaster-Backend-JSON-RPC-API.md
|
||||
[Zonemaster::CLI installation]: zonemaster-cli.md
|
||||
[Zonemaster::Engine installation]: zonemaster-engine.md
|
||||
[Zonemaster::Engine]: https://github.com/zonemaster/zonemaster-engine/blob/master/README.md
|
||||
[Zonemaster::GUI installation]: zonemaster-gui.md
|
||||
[Zonemaster::LDNS]: https://github.com/zonemaster/zonemaster-ldns/blob/master/README.md
|
||||
[Docker]: https://en.wikipedia.org/wiki/Docker_(software)
|
||||
[Using the Backend]: ../using/backend/
|
||||
200
zonemaster/docs/public/installation/zonemaster-cli.md
Normal file
200
zonemaster/docs/public/installation/zonemaster-cli.md
Normal file
@@ -0,0 +1,200 @@
|
||||
# Installation: Zonemaster-CLI
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Overview](#overview)
|
||||
* [Prerequisites for CPAN installation](#prerequisites-for-cpan-installation)
|
||||
* [Local installation](#local-installation)
|
||||
* [Installation on Rocky Linux](#installation-on-rocky-linux)
|
||||
* [Installation on Debian and Ubuntu](#installation-on-debian-and-ubuntu)
|
||||
* [Installation on FreeBSD](#installation-on-freebsd)
|
||||
* [Post-installation sanity check](#post-installation-sanity-check)
|
||||
* [Using Zonemaster-CLI](#using-zonemaster-cli)
|
||||
* [Global cache](#global-cache)
|
||||
* [What to do next?](#what-to-do-next)
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
Zonemaster-CLI provides a CLI (command line interface) to Zonemaster. To install
|
||||
follow the instructions below. An alternative to installing Zonemaster-CLI is to
|
||||
run it under [Docker]. See [Using the CLI] for run it under Docker.
|
||||
|
||||
|
||||
## Prerequisites for CPAN installation
|
||||
|
||||
Before installing Zonemaster::CLI from CPAN, you should [install
|
||||
Zonemaster::Engine][Zonemaster::Engine installation], unless you are
|
||||
to install on Debian using pre-built packages (see below).
|
||||
|
||||
> **Note:** [Zonemaster::Engine] and [Zonemaster::LDNS] are dependencies of
|
||||
> Zonemaster::CLI. Zonemaster::LDNS has a special installation requirement,
|
||||
> and Zonemaster::Engine has a list of dependencies that you may prefer to
|
||||
> install from your operating system distribution (rather than CPAN).
|
||||
> We recommend following the [Zonemaster::Engine installation] instruction.
|
||||
|
||||
Prerequisite for FreeBSD is that the package system is updated and activated
|
||||
(see the FreeBSD section of [Zonemaster::Engine installation]).
|
||||
|
||||
For details on supported versions of Perl and operating system for
|
||||
Zonemaster::CLI, see the [declaration of prerequisites].
|
||||
|
||||
|
||||
## Local installation
|
||||
|
||||
### Installation on Rocky Linux
|
||||
|
||||
1) Install dependencies:
|
||||
|
||||
```sh
|
||||
sudo dnf install --assumeyes perl-JSON-XS perl-Try-Tiny perl-Test-Deep perl-Mojolicious
|
||||
```
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest JSON::Validator
|
||||
```
|
||||
|
||||
> Note: Test::Deep and Mojolicious are indirect dependencies. They are dependencies
|
||||
> of JSON::Validator.
|
||||
|
||||
2) Install Zonemaster::CLI
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest Zonemaster::CLI
|
||||
```
|
||||
|
||||
|
||||
### Installation on Debian and Ubuntu
|
||||
|
||||
Using pre-built packages is the preferred method for Debian and Ubuntu.
|
||||
|
||||
#### Installation from pre-built packages
|
||||
|
||||
1) Add Zonemaster packages repository to repository list
|
||||
```sh
|
||||
curl -LOs https://package.zonemaster.net/setup.sh
|
||||
sudo sh setup.sh
|
||||
```
|
||||
2) Install Zonemaster CLI
|
||||
```sh
|
||||
sudo apt install zonemaster-cli
|
||||
```
|
||||
3) Update configuration of "locale"
|
||||
|
||||
```sh
|
||||
sudo perl -pi -e 's/^# (da_DK\.UTF-8.*|en_US\.UTF-8.*|es_ES\.UTF-8.*|fi_FI\.UTF-8.*|fr_FR\.UTF-8.*|nb_NO\.UTF-8.*|sl_SI\.UTF-8.*|sv_SE\.UTF-8.*)/$1/' /etc/locale.gen
|
||||
sudo locale-gen
|
||||
```
|
||||
|
||||
After the update, `locale -a` should at least list the following locales:
|
||||
```
|
||||
da_DK.utf8
|
||||
en_US.utf8
|
||||
es_ES.utf8
|
||||
fi_FI.utf8
|
||||
fr_FR.utf8
|
||||
nb_NO.utf8
|
||||
sl_SI.utf8
|
||||
sv_SE.utf8
|
||||
```
|
||||
|
||||
#### Installation from CPAN
|
||||
|
||||
1) Install dependencies:
|
||||
|
||||
```sh
|
||||
sudo apt-get install locales libmodule-install-perl libtry-tiny-perl libjson-validator-perl
|
||||
```
|
||||
|
||||
2) Install Zonemaster::CLI:
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest Zonemaster::CLI
|
||||
```
|
||||
3) Update configuration of "locale"
|
||||
|
||||
```sh
|
||||
sudo perl -pi -e 's/^# (da_DK\.UTF-8.*|en_US\.UTF-8.*|es_ES\.UTF-8.*|fi_FI\.UTF-8.*|fr_FR\.UTF-8.*|nb_NO\.UTF-8.*|sl_SI\.UTF-8.*|sv_SE\.UTF-8.*)/$1/' /etc/locale.gen
|
||||
sudo locale-gen
|
||||
```
|
||||
|
||||
After the update, `locale -a` should at least list the following locales:
|
||||
```
|
||||
da_DK.utf8
|
||||
en_US.utf8
|
||||
es_ES.utf8
|
||||
fi_FI.utf8
|
||||
fr_FR.utf8
|
||||
nb_NO.utf8
|
||||
sl_SI.utf8
|
||||
sv_SE.utf8
|
||||
```
|
||||
|
||||
### Installation on FreeBSD
|
||||
|
||||
1) Become root:
|
||||
|
||||
```sh
|
||||
su -l
|
||||
```
|
||||
|
||||
2) Install dependencies available from binary packages:
|
||||
|
||||
```sh
|
||||
pkg install gmake p5-JSON-XS p5-Locale-libintl p5-Try-Tiny p5-JSON-Validator
|
||||
```
|
||||
|
||||
3) Install Zonemaster::CLI:
|
||||
|
||||
```sh
|
||||
cpanm --notest Zonemaster::CLI
|
||||
```
|
||||
|
||||
## Post-installation sanity check
|
||||
|
||||
Run the zonemaster-cli command:
|
||||
|
||||
```sh
|
||||
zonemaster-cli --test basic zonemaster.net
|
||||
```
|
||||
|
||||
The command is expected to take a few seconds and print some results about the
|
||||
delegation of zonemaster.net.
|
||||
|
||||
Also, verify that the manual page is properly installed:
|
||||
|
||||
```sh
|
||||
man zonemaster-cli
|
||||
```
|
||||
|
||||
|
||||
## Using Zonemaster-CLI
|
||||
|
||||
See [Using the CLI] for an overview on how to use `zonemaster-cli` after
|
||||
installation.
|
||||
|
||||
|
||||
## Global cache
|
||||
|
||||
If Zonemaster-CLI is to be used for large batches, global cache can improve
|
||||
performance. See [Global cache in Zonemaster-Engine].
|
||||
|
||||
|
||||
## What to do next?
|
||||
|
||||
* For a web GUI, follow the [Zonemaster::Backend][Zonemaster::Backend
|
||||
installation] and [Zonemaster::GUI installation] instructions.
|
||||
* For a [JSON-RPC][JSON-RPC API] frontend, follow the [Zonemaster::Backend
|
||||
installation] instruction.
|
||||
|
||||
|
||||
[Declaration of prerequisites]: prerequisites.md
|
||||
[Docker]: https://en.wikipedia.org/wiki/Docker_(software)
|
||||
[Global cache in Zonemaster-Engine]: ../configuration/global-cache.md
|
||||
[JSON-RPC API]: ../using/backend/rpcapi-reference.md
|
||||
[Using the CLI]: ../using/cli.md
|
||||
[Zonemaster::Backend installation]: zonemaster-backend.md
|
||||
[Zonemaster::Engine installation]: zonemaster-engine.md
|
||||
[Zonemaster::Engine]: https://github.com/zonemaster/zonemaster-engine/blob/master/README.md
|
||||
[Zonemaster::GUI installation]: zonemaster-gui.md
|
||||
[Zonemaster::LDNS]: https://github.com/zonemaster/zonemaster-ldns/blob/master/README.md
|
||||
195
zonemaster/docs/public/installation/zonemaster-engine.md
Normal file
195
zonemaster/docs/public/installation/zonemaster-engine.md
Normal file
@@ -0,0 +1,195 @@
|
||||
# Installation: Zonemaster-Engine
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Local installation](#local-installation)
|
||||
* [Installation on Rocky Linux](#installation-on-rocky-linux)
|
||||
* [Installation on Debian and Ubuntu](#installation-on-debian-and-ubuntu)
|
||||
* [Installation on FreeBSD](#installation-on-freebsd)
|
||||
* [Post-installation sanity check](#post-installation-sanity-check)
|
||||
* [Troubleshooting installation](#troubleshooting-installation)
|
||||
* [Global cache](#global-cache)
|
||||
* [What to do next](#what-to-do-next)
|
||||
|
||||
|
||||
## Local installation
|
||||
|
||||
### Installation on Rocky Linux
|
||||
|
||||
1) Install the [EPEL] repository:
|
||||
|
||||
```sh
|
||||
sudo dnf install --assumeyes epel-release
|
||||
sudo crb enable
|
||||
```
|
||||
|
||||
2) Enable SHA-1 in the crypto policy:
|
||||
|
||||
```sh
|
||||
sudo tee /etc/crypto-policies/policies/modules/DNSSEC.pmod <<'EOF'
|
||||
hash@openssl = SHA1+
|
||||
sign@openssl = RSA-SHA1+
|
||||
EOF
|
||||
sudo update-crypto-policies --set DEFAULT:DNSSEC
|
||||
```
|
||||
|
||||
3) Install locales:
|
||||
|
||||
```sh
|
||||
sudo dnf install --assumeyes glibc-all-langpacks
|
||||
```
|
||||
|
||||
4) Install binary packages:
|
||||
|
||||
```sh
|
||||
sudo dnf install --assumeyes cpanminus gcc libidn2-devel openssl-devel perl-Class-Accessor perl-Clone perl-core perl-Devel-CheckLib perl-ExtUtils-PkgConfig perl-File-ShareDir perl-File-Slurp perl-libintl perl-IO-Socket-INET6 perl-List-Compare perl-List-MoreUtils perl-Mail-SPF perl-Module-Find perl-Module-Install perl-Net-DNS perl-Pod-Coverage perl-Readonly perl-Sub-Override perl-Test-Differences perl-Test-Exception perl-Test-Fatal perl-Test-NoWarnings perl-Test-Pod perl-Text-CSV perl-Test-Simple
|
||||
```
|
||||
|
||||
5) Install packages from CPAN:
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest Email::Valid Locale::PO Log::Any MIME::Base32 Module::Install::XSUtil Net::IP::XS YAML::XS
|
||||
```
|
||||
|
||||
6) Install Zonemaster::LDNS and Zonemaster::Engine:
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest Zonemaster::LDNS Zonemaster::Engine
|
||||
```
|
||||
|
||||
### Installation on Debian and Ubuntu
|
||||
|
||||
Using pre-built packages is the preferred method for Debian and Ubuntu.
|
||||
|
||||
#### Installation from pre-built packages
|
||||
|
||||
1) Upgrade to latest patch level
|
||||
|
||||
```sh
|
||||
sudo apt update && sudo apt upgrade
|
||||
```
|
||||
|
||||
2) Add Zonemaster packages repository to repository list
|
||||
```sh
|
||||
curl -LOs https://package.zonemaster.net/setup.sh
|
||||
sudo sh setup.sh
|
||||
```
|
||||
|
||||
3) Install Zonemaster Engine
|
||||
```sh
|
||||
sudo apt install libzonemaster-engine-perl
|
||||
```
|
||||
|
||||
#### Installation from CPAN
|
||||
|
||||
1) Upgrade to latest patch level
|
||||
|
||||
```sh
|
||||
sudo apt update && sudo apt upgrade
|
||||
```
|
||||
|
||||
2) Install dependencies from binary packages:
|
||||
|
||||
```sh
|
||||
sudo apt install autoconf automake build-essential cpanminus libclass-accessor-perl libclone-perl libdevel-checklib-perl libemail-valid-perl libextutils-pkgconfig-perl libfile-sharedir-perl libfile-slurp-perl libidn2-dev libintl-perl libio-socket-inet6-perl liblist-compare-perl liblist-moreutils-perl liblocale-po-perl liblog-any-perl libmail-spf-perl libmime-base32-perl libmodule-find-perl libmodule-install-perl libmodule-install-xsutil-perl libnet-dns-perl libnet-ip-xs-perl libpod-coverage-perl libreadonly-perl libssl-dev libsub-override-perl libtest-differences-perl libtest-exception-perl libtest-fatal-perl libtest-nowarnings-perl libtest-pod-perl libtext-csv-perl libyaml-libyaml-perl libtool m4
|
||||
```
|
||||
|
||||
3) Install Zonemaster::LDNS and Zonemaster::Engine.
|
||||
|
||||
```sh
|
||||
sudo cpanm --notest Zonemaster::LDNS Zonemaster::Engine
|
||||
```
|
||||
|
||||
### Installation on FreeBSD
|
||||
|
||||
1) Become root:
|
||||
|
||||
```sh
|
||||
su -l
|
||||
```
|
||||
|
||||
2) Update list of package repositories:
|
||||
|
||||
Create the file `/usr/local/etc/pkg/repos/FreeBSD.conf` with the
|
||||
following content, unless it is already updated:
|
||||
|
||||
```
|
||||
FreeBSD: {
|
||||
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
|
||||
}
|
||||
```
|
||||
|
||||
3) Check or activate the package system:
|
||||
|
||||
Run the following command, and accept the installation of the `pkg` package
|
||||
if suggested.
|
||||
|
||||
```
|
||||
pkg info -E pkg
|
||||
```
|
||||
|
||||
4) Update local package repository:
|
||||
|
||||
```
|
||||
pkg update -f
|
||||
```
|
||||
|
||||
5) Install dependencies from binary packages:
|
||||
|
||||
```sh
|
||||
pkg install devel/gmake dns/ldns libidn2 p5-App-cpanminus p5-Class-Accessor p5-Clone p5-Devel-CheckLib p5-Email-Valid p5-ExtUtils-PkgConfig p5-File-ShareDir p5-File-Slurp p5-IO-Socket-INET6 p5-List-Compare p5-List-MoreUtils p5-Locale-libintl p5-Locale-PO p5-Log-Any p5-Mail-SPF p5-MIME-Base32 p5-Module-Find p5-Module-Install p5-Module-Install-XSUtil p5-Net-DNS p5-Net-IP-XS p5-Pod-Coverage p5-Readonly p5-Sub-Override p5-Test-Differences p5-Test-Exception p5-Test-Fatal p5-Test-NoWarnings p5-Test-Pod p5-Text-CSV p5-YAML-LibYAML
|
||||
```
|
||||
|
||||
6) Install Zonemaster::LDNS:
|
||||
|
||||
```sh
|
||||
cpanm --notest --configure-args="--no-internal-ldns" Zonemaster::LDNS
|
||||
```
|
||||
|
||||
7) Install Zonemaster::Engine:
|
||||
|
||||
```sh
|
||||
cpanm --notest Zonemaster::Engine
|
||||
```
|
||||
|
||||
## Post-installation sanity check
|
||||
|
||||
Make sure Zonemaster::Engine is properly installed.
|
||||
|
||||
```sh
|
||||
time perl -MZonemaster::Engine -E 'say join "\n", Zonemaster::Engine->test_module("BASIC", "zonemaster.net")'
|
||||
```
|
||||
|
||||
The command is expected to take a few seconds and print some results about the
|
||||
delegation of zonemaster.net.
|
||||
|
||||
|
||||
## Troubleshooting installation
|
||||
|
||||
If you have any issue with installation, and installed with `cpanm`, redo the
|
||||
installation above but without the `--notest` and with the `--verbose` option.
|
||||
Installation will take longer time.
|
||||
|
||||
|
||||
## Global cache
|
||||
|
||||
Global cache is a feature that can be enabled in Zonemaster-Engine and consists
|
||||
in a shared, persistent cache. It can increase the performance when many tests
|
||||
are run within a short time frame. See [global cache configuration].
|
||||
|
||||
|
||||
## What to do next
|
||||
|
||||
* For a command line interface, follow the [Zonemaster::CLI installation] instruction.
|
||||
* For a web interface, follow the [Zonemaster::Backend installation] and [Zonemaster::GUI installation] instructions.
|
||||
* For a [JSON-RPC API], follow the [Zonemaster::Backend installation] instruction.
|
||||
* For a Perl API, see the [Zonemaster::Engine API] documentation.
|
||||
|
||||
|
||||
[EPEL]: https://docs.fedoraproject.org/en-US/epel/
|
||||
[Global cache configuration]: ../configuration/global-cache.md
|
||||
[JSON-RPC API]: ../using/backend/rpcapi-reference.md
|
||||
[Zonemaster::Backend installation]: zonemaster-backend.md
|
||||
[Zonemaster::CLI installation]: zonemaster-cli.md
|
||||
[Zonemaster::Engine API]: https://metacpan.org/pod/Zonemaster::Engine
|
||||
[Zonemaster::GUI installation]: zonemaster-gui.md
|
||||
284
zonemaster/docs/public/installation/zonemaster-gui.md
Normal file
284
zonemaster/docs/public/installation/zonemaster-gui.md
Normal file
@@ -0,0 +1,284 @@
|
||||
# Installation: Zonemaster-GUI
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before installing Zonemaster-GUI, you should [install Zonemaster::Engine
|
||||
][Zonemaster::Engine installation] and [Zonemaster::Backend][Zonemaster::Backend
|
||||
installation].
|
||||
|
||||
Prerequisite for FreeBSD is that the package system is updated and activated,
|
||||
see FreeBSD section of [install Zonemaster::Engine][Zonemaster::Engine
|
||||
installation].
|
||||
|
||||
## Upgrading or installation of custom built Zonemaster-GUI
|
||||
|
||||
### Upgrading
|
||||
|
||||
If this installation is an upgrade or reinstallation of Zonemaster-GUI and if
|
||||
changes were made to the shipped configuration files
|
||||
(`/var/www/html/zonemaster-web-gui/dist/config.json` and the `zonemaster.conf`
|
||||
Apache configuration file), make sure to back up these files beforehand.
|
||||
|
||||
You should also consider saving the old version under a new path instead of
|
||||
just removing it.
|
||||
|
||||
Else upgrading is as simple as removing the old version and installing the new
|
||||
version in the same way as a new installation.
|
||||
|
||||
### Installing a custom built Zonemaster-GUI
|
||||
|
||||
If you have done a custom build of Zonemaster-GUI following the instructions in
|
||||
[building GUI] you will have a zip file that you will use instead of downloading
|
||||
it from GitHub. Else you can follow the instructions below.
|
||||
|
||||
## Installation
|
||||
|
||||
This instruction covers the following operating systems:
|
||||
|
||||
1. [Rocky Linux](#1-rocky-linux)
|
||||
2. [Debian and Ubuntu](#2-debian-and-ubuntu)
|
||||
3. [FreeBSD](#3-freebsd)
|
||||
|
||||
|
||||
### 1. Rocky Linux
|
||||
|
||||
#### Install Apache
|
||||
|
||||
```sh
|
||||
sudo dnf update
|
||||
sudo dnf -y install httpd unzip
|
||||
```
|
||||
|
||||
#### Remove old Zonemaster-GUI
|
||||
|
||||
If an old version is installed, remove it first:
|
||||
```sh
|
||||
sudo rm -r /var/www/html/zonemaster-web-gui
|
||||
```
|
||||
|
||||
#### Install Zonemaster-GUI
|
||||
|
||||
```sh
|
||||
curl -L -O https://github.com/zonemaster/zonemaster-gui/releases/download/v5.0.1/zonemaster_web_gui_v5.0.1.zip
|
||||
sudo install -vd /var/www/html/zonemaster-web-gui
|
||||
sudo install -vd /var/log/zonemaster
|
||||
sudo unzip -d /var/www/html/zonemaster-web-gui zonemaster_web_gui_v5.0.1.zip
|
||||
rm -f zonemaster_web_gui_v5.0.1.zip
|
||||
```
|
||||
|
||||
#### Configure Apache site
|
||||
|
||||
```sh
|
||||
sudo chcon -R -t httpd_sys_content_t /var/www/html/zonemaster-web-gui/dist
|
||||
sudo chcon -R -t httpd_sys_rw_content_t /var/log/zonemaster
|
||||
sudo setsebool -P httpd_can_network_connect=1
|
||||
sudo install -v /var/www/html/zonemaster-web-gui/zonemaster.conf-example /etc/httpd/conf.d/zonemaster.conf
|
||||
```
|
||||
|
||||
Optionally update the zonemaster.conf.
|
||||
E.g. if Zonemaster-Backend RPCAPI runs on another server or on another port (not
|
||||
port 5000), update ProxyPass and ProxyPassReserve.
|
||||
Or if you want provide your own settings for ServerName, ServerAlias and ServerAdmin.
|
||||
|
||||
```sh
|
||||
sudoedit /etc/httpd/conf.d/zonemaster.conf
|
||||
```
|
||||
|
||||
#### Start Apache and allow remote access
|
||||
|
||||
```sh
|
||||
sudo systemctl enable httpd
|
||||
sudo systemctl start httpd
|
||||
sudo firewall-cmd --add-service http --permanent
|
||||
sudo firewall-cmd --reload
|
||||
```
|
||||
|
||||
### 2. Debian and Ubuntu
|
||||
|
||||
#### Install Apache
|
||||
|
||||
```sh
|
||||
sudo apt-get update && sudo apt-get upgrade -y
|
||||
sudo apt-get install -y apache2 unzip
|
||||
```
|
||||
|
||||
#### Basic Apache configuration
|
||||
|
||||
```sh
|
||||
sudo a2enmod proxy proxy_http rewrite
|
||||
sudo a2dissite 000-default
|
||||
sudo systemctl enable apache2
|
||||
sudo systemctl restart apache2
|
||||
```
|
||||
|
||||
#### Remove old Zonemaster-GUI
|
||||
|
||||
If an old version is installed, remove it first:
|
||||
```sh
|
||||
sudo rm -r /var/www/html/zonemaster-web-gui
|
||||
```
|
||||
|
||||
#### Install Zonemaster-GUI
|
||||
|
||||
```sh
|
||||
wget https://github.com/zonemaster/zonemaster-gui/releases/download/v5.0.1/zonemaster_web_gui_v5.0.1.zip -O zonemaster_web_gui_v5.0.1.zip
|
||||
sudo unzip -d /var/www/html/zonemaster-web-gui zonemaster_web_gui_v5.0.1.zip
|
||||
sudo install -vd /var/log/zonemaster
|
||||
sudo install -v /var/www/html/zonemaster-web-gui/zonemaster.conf-example /etc/apache2/sites-available/zonemaster.conf
|
||||
rm -f zonemaster_web_gui_v5.0.1.zip
|
||||
```
|
||||
|
||||
#### Configure Zonemaster-GUI
|
||||
|
||||
```sh
|
||||
sudo a2ensite zonemaster #Activate the website
|
||||
```
|
||||
Then update the zonemaster.conf file with your own ServerName, ServerAlias and ServerAdmin.
|
||||
For testing on a local machine, you can edit zonemaster.conf and change the "*:80" part of
|
||||
to the host's IP or using localhost as ServerName if that is appropriate.
|
||||
|
||||
|
||||
#### Reload Apache
|
||||
|
||||
```sh
|
||||
sudo systemctl reload apache2
|
||||
```
|
||||
|
||||
### 3. FreeBSD
|
||||
|
||||
For all commands below become root:
|
||||
|
||||
```sh
|
||||
su -l
|
||||
```
|
||||
|
||||
#### Update list of package repositories
|
||||
Create the file `/usr/local/etc/pkg/repos/FreeBSD.conf` with the following
|
||||
content, unless it is already updated:
|
||||
|
||||
```
|
||||
FreeBSD: {
|
||||
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
|
||||
}
|
||||
```
|
||||
|
||||
#### Check or activate the package system
|
||||
|
||||
Run the following command, and accept the installation of the `pkg` package
|
||||
if suggested.
|
||||
|
||||
```
|
||||
pkg info -E pkg
|
||||
```
|
||||
|
||||
Update local package repository:
|
||||
|
||||
```
|
||||
pkg update -f
|
||||
```
|
||||
|
||||
#### Install Apache and its dependencies
|
||||
|
||||
See [tutorial on Apache on FreeBSD].
|
||||
|
||||
```sh
|
||||
pkg install apache24
|
||||
```
|
||||
|
||||
#### Enable Apache as a service
|
||||
|
||||
```sh
|
||||
sysrc apache24_enable=yes
|
||||
```
|
||||
|
||||
#### Enable three apache modules in Apache configuration file
|
||||
|
||||
```sh
|
||||
perl -pi -e 's/^#(LoadModule (proxy_module|proxy_http_module|rewrite_module) libexec)/$1/' /usr/local/etc/apache24/httpd.conf
|
||||
```
|
||||
|
||||
#### Start Apache
|
||||
|
||||
```sh
|
||||
service apache24 start
|
||||
```
|
||||
|
||||
If you want Apache to listen to an external IP address and it says that it only
|
||||
listens to localhost (127.0.0.1/::1) then you have to set `ServerName` in
|
||||
`/usr/local/etc/apache24/httpd.conf`, e.g. `ServerName 192.0.2.246:80`, and
|
||||
restart Apache.
|
||||
|
||||
#### Remove old Zonemaster-GUI
|
||||
|
||||
If an old version is installed, remove it first:
|
||||
```sh
|
||||
rm -r /var/www/html/zonemaster-web-gui
|
||||
```
|
||||
|
||||
#### Install Zonemaster-GUI
|
||||
|
||||
```sh
|
||||
fetch https://github.com/zonemaster/zonemaster-gui/releases/download/v5.0.1/zonemaster_web_gui_v5.0.1.zip
|
||||
mkdir -p /var/www/html/zonemaster-web-gui
|
||||
mkdir -p /var/log/zonemaster
|
||||
unzip -d /var/www/html/zonemaster-web-gui zonemaster_web_gui_v5.0.1.zip
|
||||
rm zonemaster_web_gui_v5.0.1.zip
|
||||
```
|
||||
|
||||
#### Basic Apache configuration
|
||||
|
||||
```sh
|
||||
install /var/www/html/zonemaster-web-gui/zonemaster.conf-example /usr/local/etc/apache24/Includes/zonemaster.conf
|
||||
```
|
||||
Then update `/usr/local/etc/apache24/Includes/zonemaster.conf` with your own ServerAdmin.
|
||||
If Zonemaster-Backend RPCAPI runs on another server or on another port (not port 5000)
|
||||
then update the URL for the `ProxyPass` and `ProxyPassReverse` keys in the same
|
||||
file so that it points to correct IP address or server name and correct port.
|
||||
|
||||
|
||||
#### Restart Apache
|
||||
```sh
|
||||
service apache24 restart
|
||||
```
|
||||
|
||||
|
||||
## Post-installation sanity check
|
||||
|
||||
Make sure Zonemaster-GUI is properly installed.
|
||||
|
||||
1. Point your browser at `http://localhost/` (or the address of the server where
|
||||
you installed Zonemaster-GUI).
|
||||
|
||||
2. Verify that the Zonemaster-GUI is shown with the text "Program versions" in
|
||||
its page footer.
|
||||
|
||||
3. Verify that when you mouse over this text the versions of the following
|
||||
Zonemaster components are shown: Zonemaster-LDNS, Zonemaster-Engine,
|
||||
Zonemaster-Backend and Zonemaster-GUI.
|
||||
|
||||
## What to do next?
|
||||
|
||||
* For a JSON-RPC API, see the Zonemaster::Backend [JSON-RPC API] documentation.
|
||||
* For a command line interface, follow the [Zonemaster::CLI installation] instruction.
|
||||
* For a Perl API, see the [Zonemaster::Engine API] documentation.
|
||||
* For HTTPS, see [Let's Encrypt / Certbot] or providers of public certificates.
|
||||
|
||||
## Configuring and customizing GUI
|
||||
|
||||
It is possible to change the behavior and visual aspects of GUI. See
|
||||
section [configuring GUI] for how to customize the GUI.
|
||||
|
||||
|
||||
[building GUI]: ../configuration/gui/building-custom-gui.md
|
||||
[JSON-RPC API]: ../using/backend/rpcapi-reference.md
|
||||
[Let's Encrypt / Certbot]: https://certbot.eff.org/instructions
|
||||
[Main Zonemaster repository]: https://github.com/zonemaster/zonemaster/blob/master/README.md
|
||||
[Tutorial on Apache on FreeBSD]: https://www.digitalocean.com/community/tutorials/how-to-install-an-apache-mysql-and-php-famp-stack-on-freebsd-10-1
|
||||
[Zonemaster::Backend installation]: zonemaster-backend.md
|
||||
[Zonemaster::Backend]: https://github.com/zonemaster/zonemaster-backend/blob/master/README.md
|
||||
[Zonemaster::CLI installation]: zonemaster-cli.md
|
||||
[Zonemaster::Engine API]: https://metacpan.org/dist/Zonemaster-Engine/view/lib/Zonemaster/Engine/Overview.pod
|
||||
[Zonemaster::Engine installation]: zonemaster-engine.md
|
||||
[Zonemaster::Engine]: https://github.com/zonemaster/zonemaster-engine/blob/master/README.md
|
||||
[Zonemaster::LDNS]: https://github.com/zonemaster/zonemaster-ldns/blob/master/README.md
|
||||
[Configuring GUI]: ../configuration/gui/README.md
|
||||
149
zonemaster/docs/public/installation/zonemaster-ldns.md
Normal file
149
zonemaster/docs/public/installation/zonemaster-ldns.md
Normal file
@@ -0,0 +1,149 @@
|
||||
# Installation: Zonemaster-LDNS
|
||||
|
||||
## Recommended installation
|
||||
|
||||
The recommended way to install Zonemaster::LDNS is to follow the
|
||||
[installation instructions for Zonemaster::Engine] where you will find all
|
||||
prerequisites and dependencies for Zonemaster::LDNS before installing it.
|
||||
|
||||
## Installation from source
|
||||
|
||||
Override the default set of features by appending `--FEATURE` and/or
|
||||
`--no-FEATURE` options to the `perl Makefile.PL` command.
|
||||
|
||||
```sh
|
||||
git clone https://github.com/zonemaster/zonemaster-ldns
|
||||
cd zonemaster-ldns
|
||||
perl Makefile.PL
|
||||
make
|
||||
make test
|
||||
make install
|
||||
```
|
||||
|
||||
> **Note:** The source ZIP files downloaded from GitHub are broken with
|
||||
> respect to this instruction.
|
||||
|
||||
|
||||
### Optional features
|
||||
|
||||
When installing from source, you can choose to enable or disable a number
|
||||
of optional features using command line options to the `perl Makefile.PL`
|
||||
commands.
|
||||
|
||||
#### Ed25519
|
||||
|
||||
Enabled by default.
|
||||
Disabled with `--no-ed25519`
|
||||
|
||||
Requires support for algorithms Ed25519 and Ed448 in both openssl and ldns.
|
||||
|
||||
>
|
||||
> *Note:* Zonemaster Engine relies on this feature for its analysis when Ed25519
|
||||
> (DNSKEY algorithm 15) or Ed448 (DNSKEY algorithm 16) is being used in DNSSEC
|
||||
> signatures.
|
||||
>
|
||||
|
||||
#### IDN
|
||||
|
||||
Enabled by default.
|
||||
Disable with `--no-idn`.
|
||||
|
||||
If the IDN feature is enabled, the GNU `libidn2` library will be used to
|
||||
add a simple function that converts strings from Perl's internal encoding
|
||||
to IDNA domain name format.
|
||||
In order to convert strings from whatever encoding you have to Perl's
|
||||
internal format, use L<Encode>.
|
||||
If you need any kind of control or options, use [Net::LibIDN].
|
||||
The included function here is only meant to assist in the most basic case,
|
||||
although that should cover a lot of real-world use cases.
|
||||
|
||||
> **Note:** The Zonemaster Engine test suite assumes this feature
|
||||
> is enabled.
|
||||
|
||||
#### Internal ldns
|
||||
|
||||
Enabled by default.
|
||||
Disable with `--no-internal-ldns`.
|
||||
|
||||
When enabled, an included version of ldns is statically linked into
|
||||
Zonemaster::LDNS.
|
||||
When disabled, libldns is dynamically linked just like other dependencies.
|
||||
|
||||
#### Custom OpenSSL
|
||||
|
||||
Disabled by default.
|
||||
Enabled with `--prefix-openssl=/path/to/openssl` or
|
||||
`--openssl-inc=/path/to/openssl_inc` or `--openssl-lib=/path/to/openssl_lib`.
|
||||
|
||||
Enabling this makes the build tools look for OpenSSL in a non-standard place.
|
||||
|
||||
Technically this does two things:
|
||||
* Libcrypto is sought in the `lib` directory under the given directory.
|
||||
* The `include` directory under the given directory is added to the include
|
||||
path.
|
||||
|
||||
> **Note:** The `lib` directory under the given path must be known to the
|
||||
> dynamic linker or feature checks will fail.
|
||||
|
||||
If both headers and libraries directories (`include` and `lib`) are not in the
|
||||
same parent directory, use `--openssl-inc` and `--openssl-lib` options to
|
||||
specify both paths.
|
||||
|
||||
|
||||
#### Custom LDNS
|
||||
|
||||
Disabled by default.
|
||||
Enabled with `--ldns-inc=/path/to/ldns_inc` or `--ldns-lib=/path/to/ldns_lib`.
|
||||
|
||||
Enabling this makes the build tools look for LDNS in a non-standard place.
|
||||
|
||||
> Requires [Internal LDNS] to be disabled.
|
||||
|
||||
|
||||
#### Custom Libidn
|
||||
|
||||
Disabled by default.
|
||||
Enabled with `--libidn-inc=/path/to/libidn_inc` or
|
||||
`--libidn-lib=/path/to/ldns_lib`.
|
||||
|
||||
Enabling this makes the build tools look for Libidn in a non-standard place.
|
||||
|
||||
> Requires [IDN] to be enabled.
|
||||
|
||||
|
||||
#### Debug
|
||||
|
||||
Disabled by default.
|
||||
Enabled with `--debug`.
|
||||
|
||||
Gives a more verbose output.
|
||||
|
||||
|
||||
## Post-installation sanity check
|
||||
|
||||
```sh
|
||||
perl -MZonemaster::LDNS -E 'say Zonemaster::LDNS->new("8.8.8.8")->query("zonemaster.net")->string'
|
||||
```
|
||||
|
||||
The above command should print some `dig`-like output.
|
||||
|
||||
|
||||
### Testing
|
||||
|
||||
Some of the unit tests depend on data on the Internet, which may change. To avoid
|
||||
false fails, those unit tests are only run if the environment variable
|
||||
`TEST_WITH_NETWORK` is `true`. By default that variable is unset (those tests are
|
||||
not run). To run all tests, execute
|
||||
|
||||
```sh
|
||||
TEST_WITH_NETWORK=1 make test
|
||||
```
|
||||
|
||||
|
||||
[Docker Hub]: https://hub.docker.com/u/zonemaster
|
||||
[Docker Image Creation]: ../../internal/maintenance/ReleaseProcess-create-docker-image.md
|
||||
[IDN]: #idn
|
||||
[Installation instructions for Zonemaster::Engine]: zonemaster-engine.md
|
||||
[Internal LDNS]: #internal-ldns
|
||||
[Net::LibIDN]: https://metacpan.org/pod/Net::LibIDN
|
||||
[USING]: ../using/
|
||||
9
zonemaster/docs/public/specifications/README.md
Normal file
9
zonemaster/docs/public/specifications/README.md
Normal file
@@ -0,0 +1,9 @@
|
||||
# Specifications
|
||||
|
||||
* [Test Cases](tests/README.md): contains the specifications of the *Test Cases*
|
||||
that the Zonemaster implementation is based on.
|
||||
* [Test types](test-types/README.md): contains the specification of *Test Types*,
|
||||
currently only for undelegated tests.
|
||||
* [Test zones](test-zones/README.md): contains the specifications of *Test Zones*
|
||||
for the verification of Test Case implementation.
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
# Test Types
|
||||
|
||||
This directory contains **Test Type** specifications, currently only
|
||||
specification for undelegated tests.
|
||||
|
||||
* [undelegated-test.md](undelegated-test.md)
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
# Undelegated tests
|
||||
|
||||
## Objective
|
||||
|
||||
The purpose of an undelegated test is to test a possible future delegation
|
||||
before it is put in production. Hence, while testing an undelegated test,
|
||||
extra information (such as name servers, IP addresses) must be provided
|
||||
as input, and Zonemaster should run the test cases with the provided
|
||||
information.
|
||||
|
||||
## Specification
|
||||
|
||||
An undelegated test should mimic the a delegated test. The information for the
|
||||
test must be provided when starting the test.
|
||||
|
||||
An undelegated test can be run on a already delegated domain, but then
|
||||
Zonemaster must disregard the specific information for that domain found
|
||||
in public DNS.
|
||||
|
||||
Information that is part of the delegation must be provided with the initiation of
|
||||
the test. That following information is used for the undelegated test:
|
||||
|
||||
* Domain (zone) to be tested. Mandatory information.
|
||||
|
||||
* NS records. No NS records may be looked up before the test
|
||||
starts, the complete RR set must be provided. Mandatory information.
|
||||
|
||||
* Glue records. The IP addresses of the name server names that belong to the delegated
|
||||
zone or below must be provided. They must not be looked up before the test starts. If
|
||||
not provided or only partly provided, the information will be treated as an incomplete
|
||||
delegation.
|
||||
|
||||
* DS records. If no DS records are provided, then it is assumed that there are no DS
|
||||
records for the zone. They must not be looked up.
|
||||
|
||||
* Name server addresses. Addresses of name server names that belong to the delegated
|
||||
zone is covered under "glue records" above. Addresses of other name servers may be
|
||||
provided, of else they are looked up. If at least one address (IPv4 or IPv6) is provided
|
||||
for a name server, then no further lookup shall be done for that name during the
|
||||
test (neither IPv4 nor IPv6).
|
||||
|
||||
The complete set of "NS records", the "Glue records" and the "DS records" is considered
|
||||
to be equivalent to what must be provided by the delegating zone, and replaces that, if
|
||||
the delegation exists. If the delegation does not exists, the provided set works as if
|
||||
the delegation existed.
|
||||
|
||||
The Name server addresses provided, if any, are considered to replace the real IP
|
||||
addresses for those name server names.
|
||||
@@ -0,0 +1,8 @@
|
||||
# Specification of test scenarios for Address-TP
|
||||
|
||||
|
||||
Test scenario specifications are available for:
|
||||
|
||||
* Address01 *not yet available*
|
||||
* Address02 *not yet available*
|
||||
* [Address03](address03.md)
|
||||
@@ -0,0 +1,216 @@
|
||||
# Specification of test scenarios for ADDRESS01
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file].
|
||||
|
||||
## Test Case
|
||||
This document specifies defined test scenarios for test case [ADDRESS01].
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [ADDRESS01] is run on a test zone.
|
||||
The message tags are defined in the test case ([ADDRESS01]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test zone README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`address01.xa`) and that subdomain having the same name as the
|
||||
scenario. The names of those zones are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
## All tags
|
||||
|
||||
The test case can output any of these message tags, but not necessarily in any combination.
|
||||
|
||||
- A01_ADDR_NOT_GLOBALLY_REACHABLE
|
||||
- A01_DOCUMENTATION_ADDR
|
||||
- A01_GLOBALLY_REACHABLE_ADDR
|
||||
- A01_LOCAL_USE_ADDR
|
||||
- A01_NO_GLOBALLY_REACHABLE_ADDR
|
||||
- A01_NO_NAME_SERVERS_FOUND
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
| Scenario name | Mandatory message tag | Forbidden message tags |
|
||||
|:--------------------|:------------------------------------------------------------------------------------------------------------|:-----------------------|
|
||||
| GOOD-1 | A01_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| MIXED-LOCAL-DOC-1 | A01_LOCAL_USE_ADDR, A01_DOCUMENTATION_ADDR, A01_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| MIXED-LOCAL-DOC-2 | A01_LOCAL_USE_ADDR, A01_DOCUMENTATION_ADDR, A01_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| MIXED-LOCAL-OTHER-1 | A01_LOCAL_USE_ADDR, A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| MIXED-LOCAL-OTHER-2 | A01_LOCAL_USE_ADDR, A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| MIXED-DOC-OTHER-1 | A01_DOCUMENTATION_ADDR, A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| MIXED-DOC-OTHER-2 | A01_DOCUMENTATION_ADDR, A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| MIXED-ALL-1 | A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_DOCUMENTATION_ADDR, A01_LOCAL_USE_ADDR, A01_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| MIXED-ALL-2 | A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_DOCUMENTATION_ADDR, A01_LOCAL_USE_ADDR, A01_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| ALL-NON-REACHABLE | A01_ADDR_NOT_GLOBALLY_REACHABLE, A01_LOCAL_USE_ADDR, A01_DOCUMENTATION_ADDR, A01_NO_GLOBALLY_REACHABLE_ADDR | 2) |
|
||||
| NO_NAME_SERVERS | A01_NO_NAME_SERVERS_FOUND | 2) |
|
||||
|
||||
|
||||
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the scenario specifications unless otherwise specified for
|
||||
the specific scenario:
|
||||
* The child zone is `SCENARIO.address01.xa`.
|
||||
* There is no zone file or zone data for the child zone.
|
||||
* For each scenario zone there are two NS records (ns\[1-2]).
|
||||
* All NS are in-bailiwick
|
||||
* All NS have both IPv4 and IPv6 addresses
|
||||
* All required glue are present in the delegation.
|
||||
* EDNS, version 0, is included in all responses on queries with EDNS.
|
||||
* EDNS is not included in responses on queries without EDNS.
|
||||
|
||||
| Address designation | Meaning |
|
||||
|:-----------------------|:------------------------------------------------------------------------------------------------------|
|
||||
| OK | Globally routable, public IPv4 address or global IPv6 address (not from any special purpose registry) |
|
||||
| OK_SPECIAL | Globally routable IPv4 or IPv6 address from one of the special purpose registries |
|
||||
| LOCAL_USE_ADDR | Address part of range used for private networks (loopback, RFC1918, Provider shared, etc.) |
|
||||
| DOCUMENTATION_ADDR | Address part of range used for documentation purposes |
|
||||
| NOT_GLOBALLY_REACHABLE | Address part of any other range listed as not globally reachable |
|
||||
|
||||
Designations are based on the address block ranges from the
|
||||
[Special purpose IPv4 addresses] and [Special purpose IPv6 addresses] registries.
|
||||
|
||||
### GOOD-1
|
||||
The "happy path". Everything is fine.
|
||||
|
||||
* Zone: good-1.address01.xa
|
||||
* ns1
|
||||
* IPv4 address OK
|
||||
* IPv6 address OK
|
||||
* ns2
|
||||
* IPv4 address OK_SPECIAL
|
||||
* IPv6 address OK_SPECIAL
|
||||
|
||||
### MIXED-LOCAL-DOC-1
|
||||
|
||||
* Zone: mixed-local-doc-1.address01.xa
|
||||
* ns1
|
||||
* IPv4 address LOCAL_USE_ADDR
|
||||
* IPv6 address OK
|
||||
* ns2
|
||||
* IPv4 address OK
|
||||
* IPv6 address DOCUMENTATION_ADDR
|
||||
|
||||
### MIXED-LOCAL-DOC-2
|
||||
|
||||
* Zone: mixed-local-doc-2.address01.xa
|
||||
* ns1
|
||||
* IPv4 address DOCUMENTATION_ADDR
|
||||
* IPv6 address OK
|
||||
* ns2
|
||||
* IPv4 address OK
|
||||
* IPv6 address LOCAL_USE_ADDR
|
||||
|
||||
### MIXED-DOC-OTHER-1
|
||||
|
||||
* Zone: mixed-doc-other-1.address01.xa
|
||||
* ns1
|
||||
* IPv4 address DOCUMENTATION_ADDR
|
||||
* IPv6 address OK
|
||||
* ns2
|
||||
* IPv4 address OK
|
||||
* IPv6 address NOT_GLOBALLY_REACHABLE
|
||||
|
||||
### MIXED-DOC-OTHER-2
|
||||
|
||||
* Zone: mixed-doc-other-2.address01.xa
|
||||
* ns1
|
||||
* IPv4 address NOT_GLOBALLY_REACHABLE
|
||||
* IPv6 address OK
|
||||
* ns2
|
||||
* IPv4 address OK
|
||||
* IPv6 address DOCUMENTATION_ADDR
|
||||
|
||||
### MIXED-LOCAL-OTHER-1
|
||||
|
||||
* Zone: mixed-local-other-1.address01.xa
|
||||
* ns1
|
||||
* IPv4 address LOCAL_USE_ADDR
|
||||
* IPv6 address OK
|
||||
* ns2
|
||||
* IPv4 address OK
|
||||
* IPv6 address NOT_GLOBALLY_REACHABLE
|
||||
|
||||
### MIXED-LOCAL-OTHER-2
|
||||
|
||||
* Zone: mixed-local-other-2.address01.xa
|
||||
* ns1
|
||||
* IPv4 address NOT_GLOBALLY_REACHABLE
|
||||
* IPv6 address OK
|
||||
* ns2
|
||||
* IPv4 address OK
|
||||
* IPv6 address LOCAL_USE_ADDR
|
||||
|
||||
### MIXED-ALL-1
|
||||
|
||||
* Zone: mixed-all-1.address01.xa
|
||||
* ns1
|
||||
* IPv4 address LOCAL_USE_ADDR
|
||||
* IPv6 address OK
|
||||
* ns2
|
||||
* IPv4 address DOCUMENTATION_ADDR
|
||||
* IPv6 address NOT_GLOBALLY_REACHABLE
|
||||
|
||||
### MIXED-ALL-2
|
||||
|
||||
* Zone: mixed-all-2.address01.xa
|
||||
* ns1
|
||||
* IPv4 address NOT_GLOBALLY_REACHABLE
|
||||
* IPv6 address LOCAL_USE_ADDR
|
||||
* ns2
|
||||
* IPv4 address OK
|
||||
* IPv6 address DOCUMENTATION_ADDR
|
||||
|
||||
### ALL-NON-REACHABLE
|
||||
All addresses of all nameservers falls within one of the address blocks listed
|
||||
as not globally reachable. Delegation contains three name servers to cover all
|
||||
combinations of defined address block types.
|
||||
|
||||
* Zone: all-non-reachable.address01.xa
|
||||
* ns1
|
||||
* IPv4 address LOCAL_USE_ADDR
|
||||
* IPv6 address NOT_GLOBALLY_REACHABLE
|
||||
* ns2
|
||||
* IPv4 address DOCUMENTATION_ADDR
|
||||
* IPv6 address LOCAL_USE_ADDR
|
||||
+ ns3
|
||||
* IPv4 address NOT_GLOBALLY_REACHABLE
|
||||
* IPv6 address DOCUMENTATION_ADDR
|
||||
|
||||
### NO_NAME_SERVERS
|
||||
No delegation for the zone and the zone does not exist.
|
||||
|
||||
* Zone: no-name-servers.address01.xa
|
||||
* No delegation
|
||||
* No zone
|
||||
|
||||
[ADDRESS01]: ../../tests/Address-TP/address01.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Special purpose IPv4 addresses]: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml
|
||||
[Special purpose IPv6 addresses]: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml
|
||||
[Test zone README file]: ../README.md
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
@@ -0,0 +1,249 @@
|
||||
# Specification of Test Scenarios for Address03
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test scenarios and setup of test zones]
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
|
||||
This document specifies defined test scenarios for test case [Address03].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [Address03] is run on a test zone.
|
||||
The message tags are defined in the test case ([Address03]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`address03.xa`) and that subdomain having the same name as
|
||||
the scenario. The names of those zones are given in section "[Test scenarios
|
||||
and setup of test zones]" below.
|
||||
|
||||
## All message tags
|
||||
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [Address03] for the specification of the tags.
|
||||
|
||||
* NAMESERVER_IP_PTR_MATCH
|
||||
* NAMESERVER_IP_PTR_MISMATCH
|
||||
* NAMESERVER_IP_WITHOUT_REVERSE
|
||||
* NO_RESPONSE_PTR_QUERY
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
| Scenario name | Mandatory message tags | Forbidden message tags |
|
||||
|:---------------------------|:------------------------------|:----------------------------------------------------|
|
||||
| ALL-NS-HAVE-PTR-1 | NAMESERVER_IP_PTR_MATCH | 2) |
|
||||
| ALL-NS-HAVE-PTR-2 | NAMESERVER_IP_PTR_MATCH | 2) |
|
||||
| NO-NS-HAVE-PTR | NAMESERVER_IP_WITHOUT_REVERSE | 2) |
|
||||
| INCOMPLETE-PTR-1 | NAMESERVER_IP_WITHOUT_REVERSE | 2) |
|
||||
| INCOMPLETE-PTR-2 | NAMESERVER_IP_WITHOUT_REVERSE | 2) |
|
||||
| NON-MATCHING-NAMES | NAMESERVER_IP_PTR_MISMATCH | 2) |
|
||||
| PTR-IS-GOOD-CNAME-1 | NAMESERVER_IP_PTR_MATCH | 2) |
|
||||
| PTR-IS-GOOD-CNAME-2 | NAMESERVER_IP_PTR_MATCH | 2) |
|
||||
| PTR-IS-DANGLING-CNAME | NAMESERVER_IP_WITHOUT_REVERSE | 2) |
|
||||
| PTR-IS-ILLEGAL-CNAME | NAMESERVER_IP_WITHOUT_REVERSE | NAMESERVER_IP_PTR_MATCH, NAMESERVER_IP_PTR_MISMATCH |
|
||||
| PTR-RESOLUTION-NO-RESPONSE | NO_RESPONSE_PTR_QUERY | NAMESERVER_IP_PTR_MATCH, NAMESERVER_IP_PTR_MISMATCH |
|
||||
| PTR-RESOLUTION-SERVFAIL | NO_RESPONSE_PTR_QUERY | NAMESERVER_IP_PTR_MATCH, NAMESERVER_IP_PTR_MISMATCH |
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
|
||||
## Test scenarios and setup of test zones
|
||||
|
||||
### Default zone configuration
|
||||
Unless otherwise specified in the specific scenario specification, the test zone
|
||||
for the scenario will follow the default setup as stated below. The `child zone`
|
||||
is the zone to be tested for the scenario.
|
||||
|
||||
* The child zone is `SCENARIO.address03.xa`.
|
||||
* There is a zone file for the child zone.
|
||||
* The child zone is delegated to two out-of-bailiwick name servers.
|
||||
* Both name servers have the same content.
|
||||
* The authoritative name servers for the zone all have an IPv4 and an IPv6
|
||||
address, and the reverse zones contain a single PTR resource record
|
||||
matching their names for all of their addresses.
|
||||
* The NS record set in the child zone is consistent with the parent zone’s
|
||||
delegation.
|
||||
* The parent zone is `address03.xa`.
|
||||
* It is served by two in-bailiwick NS (ns1.address03.xa and
|
||||
ns2.address03.xa).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue in the delegation of the parent
|
||||
zone.
|
||||
* The records matching glue in the zone are identical to the glue records.
|
||||
* All authoritative name servers for the scenario’s child zones have names
|
||||
matching ns\<NUMBER\>.child.address03.xa. These name servers’s names are
|
||||
abbreviated by leaving out address03.xa from their names.
|
||||
* All responses will have the AA bit set.
|
||||
* All responses will have the [RCODE Name] "NoError".
|
||||
|
||||
### ALL-NS-HAVE-PTR-1
|
||||
|
||||
A happy path: a zone whose name server IP addresses have single and correct
|
||||
PTR records.
|
||||
|
||||
* Zone: all-ns-have-ptr-1.address03.xa
|
||||
* Delegated to: ns1.child and ns2.child.
|
||||
|
||||
### ALL-NS-HAVE-PTR-2
|
||||
|
||||
Another happy path: like ALL-NS-HAVE-PTR-1, but for one of the name servers,
|
||||
both its IPv4 and IPv6 addresses have multiple PTR records. In each PTR
|
||||
resource record set, one of the PTR records matches the name server’s name.
|
||||
|
||||
* Zone: all-ns-have-ptr-2.address03.xa
|
||||
* Delegated to: ns1.child and ns3.child.
|
||||
* ns3.child’s IP addresses have multiple PTR records, among which one points
|
||||
to ns3.child.
|
||||
|
||||
### NO-NS-HAVE-PTR
|
||||
|
||||
None of the name server’s IP addresses have PTR records at all. For one of
|
||||
them, NODATA is returned on PTR query; for the other, NXDOMAIN is returned.
|
||||
|
||||
* Zone: no-ns-have-ptr.address03.xa
|
||||
* Delegated to: ns4.child and ns5.child.
|
||||
* ns4.child’s IP addresses have no PTR records; the reverse zone is
|
||||
configured to provoke NODATA responses on PTR queries by making the
|
||||
expected node an empty non-terminal.
|
||||
* ns5.child’s IP addresses have no PTR records; the reverse zone is
|
||||
configured to provoke NXDOMAIN responses on PTR queries.
|
||||
|
||||
### INCOMPLETE-PTR-1
|
||||
|
||||
For one of the name servers, the PTR record is missing for its IPv4 address.
|
||||
|
||||
* Zone: incomplete-ptr-1.address03.xa
|
||||
* Delegated to: ns1.child and ns6.child.
|
||||
* ns6.child’s IPv4 address has no PTR record, but its IPv6 address does.
|
||||
|
||||
### INCOMPLETE-PTR-2
|
||||
|
||||
For one of the name servers, the PTR record is missing for its IPv6 address.
|
||||
|
||||
* Zone: incomplete-ptr-2.address03.xa
|
||||
* Delegated to: ns1.child and ns7.child.
|
||||
* ns7.child’s IPv4 address has a PTR record, but its IPv6 address does not.
|
||||
|
||||
### NON-MATCHING-NAMES
|
||||
|
||||
Both name server’s IP addresses have one or more PTR records, but none
|
||||
matching the name server name.
|
||||
|
||||
* Zone: non-matching-names.address03.xa
|
||||
* Delegated to: ns8.child and ns9.child.
|
||||
* ns8.child’s IP addresses have a single PTR record, but its hostname in
|
||||
RDATA is different from the name server’s name.
|
||||
* ns9.child’s IP addresses have more than one PTR record, and each of them
|
||||
has a hostname in RDATA different from the name server’s name.
|
||||
|
||||
### PTR-IS-GOOD-CNAME-1
|
||||
|
||||
The reverse name of one of the name servers’ IP address has an alias (CNAME)
|
||||
whose target, with a PTR record, is in the same reverse zone.
|
||||
|
||||
* Zone: ptr-is-good-cname-1.address03.xa
|
||||
* Delegated to: ns1.child and ns10.child.
|
||||
* ns10.child’s IP addresses have reverse names that are aliased (CNAME) to
|
||||
another name in the same zone. In other words, resolving the PTR resource
|
||||
records for their IP addresses returns a CNAME resource record and the PTR
|
||||
record after walking the CNAME chain.
|
||||
|
||||
### PTR-IS-GOOD-CNAME-2
|
||||
|
||||
The reverse name of one of the name servers’ IP address has an alias (CNAME)
|
||||
whose target, with a PTR record, is in a different zone.
|
||||
|
||||
* Zone: ptr-is-good-cname-2.address03.xa
|
||||
* Delegated to: ns1.child and ns11.child.
|
||||
* ns11.child’s IP addresses have reverse names that are aliased (CNAME) to
|
||||
another name in a different zone. In other words, resolving the PTR
|
||||
resource records for their IP addresses returns only a CNAME resource
|
||||
record, and another query for the name at the target of the CNAME resource
|
||||
record is needed.
|
||||
|
||||
### PTR-IS-DANGLING-CNAME
|
||||
|
||||
The reverse name of one of the name servers’ IP address has an alias (CNAME)
|
||||
whose target does not exist.
|
||||
|
||||
* Zone: ptr-is-dangling-cname.address03.xa
|
||||
* Delegated to: ns5.child and ns12.child.
|
||||
* ns5.child is configured as described in the NO-NS-HAVE-PTR scenario.
|
||||
* ns12.child’s IP addresses have reverse names that are aliased to a
|
||||
nonexistent node. In other words, there is a CNAME pointing to a node
|
||||
that does not exist.
|
||||
|
||||
### PTR-IS-ILLEGAL-CNAME
|
||||
|
||||
One of the name servers has IP addresses whose reverse names contain more than
|
||||
one CNAME resource record.
|
||||
|
||||
* Zone: ptr-is-illegal-cname.address03.xa
|
||||
* Delegated to: ns4.child and ns13.child.
|
||||
* ns4.child is configured as described in the NO-NS-HAVE-PTR scenario.
|
||||
* ns13.child’s IP addresses have reverse names that give two CNAME
|
||||
resource records.
|
||||
|
||||
Whether or not NO_RESPONSE_PTR_QUERY is allowed to be outputted is
|
||||
intentionally left unspecified.
|
||||
|
||||
### PTR-RESOLUTION-NO-RESPONSE
|
||||
|
||||
One of the name servers has IP addresses whose reverse names fail to resolve
|
||||
because the authoritative name server for the reverse zone does not respond.
|
||||
|
||||
One of the name servers’ IP addresses fail to resolve to PTR records because
|
||||
an attempt at querying corresponding node in the `in-addr.arpa` or `ip6.arpa`
|
||||
subtrees returns no response.
|
||||
|
||||
* Zone: ptr-resolution-no-response.address03.xa
|
||||
* Delegated to: ns1.child and ns14.child.
|
||||
* Querying the PTR records for ns14.child’s IP addresses return no response.
|
||||
|
||||
Whether or not NAMESERVER_IP_WITHOUT_REVERSE is allowed to be outputted is
|
||||
intentionally left unspecified.
|
||||
|
||||
### PTR-RESOLUTION-SERVFAIL
|
||||
|
||||
One of the name servers has IP addresses whose reverse names fail to resolve
|
||||
because the authoritative name server for the reverse zone gives a response
|
||||
whose [RCODE Name] is neither "NoError" nor "NXDomain".
|
||||
|
||||
* Zone: ptr-resolution-no-response.address03.xa
|
||||
* Delegated to: ns1.child and ns15.child.
|
||||
* Querying the PTR records for ns15.child’s IP addresses return a "ServFail"
|
||||
response.
|
||||
|
||||
Whether or not NAMESERVER_IP_WITHOUT_REVERSE is allowed to be outputted is
|
||||
intentionally left unspecified.
|
||||
|
||||
[ADDRESS03]: ../../tests/Address-TP/address03.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[test scenario README file]: ../README.md
|
||||
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
|
||||
@@ -0,0 +1,7 @@
|
||||
# Specification of test scenarios for Basic-TP
|
||||
|
||||
Test scenario specifications are available for:
|
||||
|
||||
* [Basic01](basic01.md)
|
||||
* [Basic02](basic02.md)
|
||||
* Basic03 *not yet available*
|
||||
@@ -0,0 +1,502 @@
|
||||
# Specification of test zones for Basic01
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies defined test zones for test case [Basic01].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [Basic01] is run on a test zone.
|
||||
The message tags are defined in the test case ([Basic01]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test zone README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain (or lower
|
||||
zone) delegated from the base name (`basic01.xa`) and that subdomain having the
|
||||
same name as the scenario. The names of those zones are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
|
||||
## All tags
|
||||
The test case can output any of these message tags, but not necessarily in any combination.
|
||||
|
||||
* B01_CHILD_FOUND
|
||||
* B01_CHILD_IS_ALIAS
|
||||
* B01_INCONSISTENT_ALIAS
|
||||
* B01_INCONSISTENT_DELEGATION
|
||||
* B01_NO_CHILD
|
||||
* B01_PARENT_DISREGARDED
|
||||
* B01_PARENT_FOUND
|
||||
* B01_PARENT_NOT_FOUND
|
||||
* B01_PARENT_UNDETERMINED
|
||||
* B01_ROOT_HAS_NO_PARENT
|
||||
* B01_SERVER_ZONE_ERROR
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:-------------------------|:----------------------------------------------------------------------------------|:----------------------
|
||||
GOOD-1 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
|
||||
GOOD-MIXED-1 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
|
||||
GOOD-MIXED-2 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
|
||||
GOOD-PARENT-HOST-1 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
|
||||
GOOD-GRANDPARENT-HOST-1 | B01_CHILD_FOUND, B01_PARENT_FOUND | 2)
|
||||
GOOD-UNDEL-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
|
||||
GOOD-MIXED-UNDEL-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
|
||||
GOOD-MIXED-UNDEL-2 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
|
||||
NO-DEL-UNDEL-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
|
||||
NO-DEL-MIXED-UNDEL-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
|
||||
NO-DEL-MIXED-UNDEL-2 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
|
||||
NO-CHILD-1 | B01_NO_CHILD, B01_PARENT_FOUND | 2)
|
||||
NO-CHILD-2 | B01_NO_CHILD, B01_PARENT_FOUND | 2)
|
||||
NO-CHLD-PAR-UNDETER-1 | B01_NO_CHILD, B01_PARENT_FOUND, B01_PARENT_UNDETERMINED | 2)
|
||||
CHLD-FOUND-PAR-UNDET-1 | B01_CHILD_FOUND, B01_PARENT_FOUND, B01_PARENT_UNDETERMINED | 2)
|
||||
CHLD-FOUND-INCONSIST-1 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
|
||||
CHLD-FOUND-INCONSIST-2 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
|
||||
CHLD-FOUND-INCONSIST-3 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
|
||||
CHLD-FOUND-INCONSIST-4 | B01_CHILD_IS_ALIAS, B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND| 2)
|
||||
CHLD-FOUND-INCONSIST-5 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
|
||||
CHLD-FOUND-INCONSIST-6 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
|
||||
CHLD-FOUND-INCONSIST-7 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
|
||||
CHLD-FOUND-INCONSIST-8 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
|
||||
CHLD-FOUND-INCONSIST-9 | B01_CHILD_IS_ALIAS, B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND| 2)
|
||||
CHLD-FOUND-INCONSIST-10 | B01_CHILD_FOUND, B01_INCONSISTENT_DELEGATION, B01_PARENT_FOUND | 2)
|
||||
NO-DEL-UNDEL-NO-PAR-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
|
||||
NO-DEL-UNDEL-PAR-UND-1 | B01_CHILD_FOUND, B01_PARENT_DISREGARDED | 2)
|
||||
NO-CHLD-NO-PAR-1 | B01_NO_CHILD, B01_PARENT_NOT_FOUND, B01_SERVER_ZONE_ERROR | 2)
|
||||
CHILD-ALIAS-1 | B01_CHILD_IS_ALIAS, B01_NO_CHILD, B01_PARENT_FOUND | 2)
|
||||
CHILD-ALIAS-2 | B01_CHILD_IS_ALIAS, B01_NO_CHILD, B01_INCONSISTENT_ALIAS, B01_PARENT_FOUND | 2)
|
||||
ZONE-ERR-GRANDPARENT-1 | B01_CHILD_FOUND, B01_PARENT_FOUND, B01_SERVER_ZONE_ERROR | 2)
|
||||
ZONE-ERR-GRANDPARENT-2 | B01_CHILD_FOUND, B01_PARENT_FOUND, B01_SERVER_ZONE_ERROR | 2)
|
||||
ZONE-ERR-GRANDPARENT-3 | B01_CHILD_FOUND, B01_PARENT_FOUND, B01_SERVER_ZONE_ERROR | 2)
|
||||
ROOT-ZONE | B01_CHILD_FOUND, B01_ROOT_HAS_NO_PARENT | 2)
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the scenario specifications unless otherwise specified for
|
||||
the specific scenario:
|
||||
|
||||
* The child zone is `child.parent.SCENARIO.basic01.xa`.
|
||||
* It is delegated to two name servers, `ns1-delegated-child.basic01.xa`
|
||||
and `ns2-delegated-child.basic01.xa`.
|
||||
* The name server names have A and AAAA records to avoid non-relevant error
|
||||
messages.
|
||||
* There is no zone file or zone data for the child zone.
|
||||
* If there is an undelegated "version" of the child zone, it is
|
||||
referred to `ns3-undelegated-child.basic01.xa` and
|
||||
`ns4-undelegated-child.basic01.xa`.
|
||||
* The name server names have A and AAAA records to avoid non-relevant error
|
||||
messages.
|
||||
* There is no zone file or zone data for the undelegated "version".
|
||||
* The parent zone is `parent.SCENARIO.basic01.xa`.
|
||||
* It is served by two in-bailiwick NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* The delegation from the grand parent has the same NS with complete glue.
|
||||
* The grandparent zone is `SCENARIO.basic01.xa`.
|
||||
* It is served by two in-bailiwick NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* The delegation from the SCENARIO zone has the same NS with complete glue.
|
||||
* Responds with a A record for the zone on query for A.
|
||||
* Responds with a AAAA record for the zone on query for AAAA.
|
||||
* All responses are authoritative with [RCODE Name] "NoError"
|
||||
* EDNS, version 0, is included in all responses on queries with EDNS.
|
||||
* EDNS is not included in responses on queries without EDNS.
|
||||
* Standard test zone root is used.
|
||||
* In all cases, delegation and zone are consistent.
|
||||
* Same NS.
|
||||
* Any required glue matches address records in zone.
|
||||
* No extra address records for the NS names.
|
||||
|
||||
### GOOD-1
|
||||
A "happy path". Everything is fine.
|
||||
|
||||
* Zone: child.parent.good-1.basic01.xa
|
||||
|
||||
### GOOD-MIXED-1
|
||||
One grandparent server also serves parent zone.
|
||||
|
||||
* Zone: child.parent.good-mixed-1.basic01.xa
|
||||
* Parent zone `parent.good-mixed-1.basic01.xa` is served by `ns1`, `ns2` and on
|
||||
`ns4.good-mixed-1.basic01.xa`.
|
||||
* Grandparent zone `good-mixed-1.basic01.xa` is served on `ns1` and `ns4`.
|
||||
|
||||
### GOOD-MIXED-2
|
||||
One parent server also hosts the child zone.
|
||||
|
||||
* Zone: child.parent.good-mixed-2.basic01.xa
|
||||
* Child zone is served by `ns1`, `ns2` and
|
||||
`ns4.parent.good-mixed-2.basic01.xa`.
|
||||
* Child zone exists.
|
||||
* There is a zone file for the child zone, and that is loaded on the child
|
||||
zone name servers.
|
||||
* Parent zone `parent.good-mixed-2.basic01.xa` is served by `ns1` and `ns4`.
|
||||
|
||||
### GOOD-PARENT-HOST-1
|
||||
The child is hosted on parent servers only.
|
||||
|
||||
* Zone: child.parent.good-parent-host-1.basic01.xa
|
||||
* Child zone is served by `ns1.parent.good-parent-host-1.basic01.xa` and
|
||||
`ns2.parent.good-parent-host-1.basic01.xa`.
|
||||
* There is a zone file for the child zone.
|
||||
|
||||
### GOOD-GRANDPARENT-HOST-1
|
||||
The child is hosted on grandparent servers only.
|
||||
|
||||
* Zone: child.parent.good-grandparent-host-1.basic01.xa
|
||||
* Child zone is served by `ns1.good-grandparent-host-1.basic01.xa` and
|
||||
`ns2.good-grandparent-host-1.basic01.xa`.
|
||||
* There is a zone file for the child zone.
|
||||
|
||||
### GOOD-UNDEL-1
|
||||
The child zone is delegated, but there is also an undelegated version which is
|
||||
the one tested.
|
||||
|
||||
* Zone: child.parent.good-undel-1.basic01.xa
|
||||
* Child zone is delegated, but there is also an undelegated version.
|
||||
* There are no zone files for child (delegated or undelegated).
|
||||
* Undelegated data:
|
||||
* ns3-undelegated-child.basic01.xa
|
||||
* ns4-undelegated-child.basic01.xa
|
||||
|
||||
### GOOD-MIXED-UNDEL-1
|
||||
The child zone is delegated, but there is also an undelegated version which is
|
||||
the one tested. One grandparent server, in the delegated tree, also serves
|
||||
parent zone.
|
||||
|
||||
* Zone: child.parent.good-mixed-undel-1.basic01.xa
|
||||
* Parent zone `parent.good-mixed-undel-1.basic01.xa` is served by `ns1`, `ns2` and on
|
||||
`ns4.good-mixed-undel-1.basic01.xa`.
|
||||
* Grandparent zone `good-mixed-undel-1.basic01.xa` is served on `ns1` and `ns4`.
|
||||
* Child zone is delegated, but there is also an undelegated version.
|
||||
* No child zone exists.
|
||||
* Undelegated data:
|
||||
* ns3-undelegated-child.basic01.xa
|
||||
* ns4-undelegated-child.basic01.xa
|
||||
|
||||
### GOOD-MIXED-UNDEL-2
|
||||
The child zone is delegated, but there is also an undelegated version. One parent
|
||||
server also serves the delegated child zone.
|
||||
|
||||
* Zone: child.parent.good-mixed-undel-2.basic01.xa
|
||||
* Child zone is served by `ns1`, `ns2` and
|
||||
`ns6.parent.good-mixed-undel-2.basic01.xa`.
|
||||
* Child zone exists.
|
||||
* Parent zone `parent.good-mixed-undel-2.basic01.xa` is served by `ns1` and
|
||||
`ns6`.
|
||||
* Child zone is delegated, but there is also an undelegated version, but no
|
||||
zone for the undelegated version.
|
||||
* Undelegated data:
|
||||
* ns3-undelegated-child.basic01.xa
|
||||
* ns4-undelegated-child.basic01.xa
|
||||
|
||||
### NO-DEL-UNDEL-1
|
||||
The child zone is not delegated, but there is an undelegated version.
|
||||
|
||||
* Zone: child.parent.no-del-undel-1.basic01.xa
|
||||
* Undelegated data:
|
||||
* ns3-undelegated-child.basic01.xa
|
||||
* ns4-undelegated-child.basic01.xa
|
||||
|
||||
### NO-DEL-MIXED-UNDEL-1
|
||||
The child zone is not delegated, but there is an undelegated version that is
|
||||
tested. One grandparent server also serves the parent zone.
|
||||
|
||||
* Zone: child.parent.no-del-mixed-undel-1.basic01.xa
|
||||
* Parent zone `parent.no-del-mixed-undel-1.basic01.xa` is served by `ns1`, `ns2` and on
|
||||
`ns4.no-del-mixed-undel-1.basic01.xa`.
|
||||
* Grandparent zone `no-del-mixed-undel-1.basic01.xa` is served on `ns1` and `ns4`.
|
||||
* Child zone is not delegated, but there is an undelegated version, but no zone file.
|
||||
* Undelegated data:
|
||||
* ns3-undelegated-child.basic01.xa
|
||||
* ns4-undelegated-child.basic01.xa
|
||||
|
||||
### NO-DEL-MIXED-UNDEL-2
|
||||
The child zone is not delegated, but there is an undelegated version that is
|
||||
tested. One grandparent server also serves the parent zone. There are extra empty
|
||||
nodes between the zone cuts.
|
||||
|
||||
* Zone: child.w.x.parent.y.z.no-del-mixed-undel-2.basic01.xa
|
||||
* Parent zone `parent.y.z.no-del-mixed-undel-2.basic01.xa` is served by `ns1`,
|
||||
`ns2` and on `ns4.no-del-mixed-undel-2.basic01.xa`.
|
||||
* Grandparent zone `no-del-mixed-undel-2.basic01.xa` is served on `ns1` and `ns4`.
|
||||
* There are no zone cuts at `w`, `x`, `y` and `z`.
|
||||
* Child zone is not delegated, but there is also an undelegated version, but no
|
||||
zone file.
|
||||
* Undelegated data:
|
||||
* ns3-undelegated-child.basic01.xa
|
||||
* ns4-undelegated-child.basic01.xa
|
||||
|
||||
### NO-CHILD-1
|
||||
The child zone is not delegated. Parent zone returns NXDOMAIN.
|
||||
|
||||
* Zone: child.parent.no-child-1.basic01.xa
|
||||
* Child zone does not exist and is not served by any NS.
|
||||
|
||||
### NO-CHILD-2
|
||||
The child zone is not delegated. Parent zone returns NODATA.
|
||||
|
||||
* Zone: child.parent.no-child-2.basic01.xa
|
||||
* Child zone does not exist and is not served by any NS.
|
||||
* The name child.parent.no-child-2.basic01.xa exists as a TXT record.
|
||||
|
||||
### NO-CHLD-PAR-UNDETER-1
|
||||
The child zone is not delegated. One grandparent NS lacks delegation of parent
|
||||
and return NXDOMAIN of child. The parent zone lacks delegation of child.
|
||||
|
||||
* Zone: child.parent.no-chld-par-undeter-1.basic01.xa
|
||||
* Child zone does not exist is not served by any NS.
|
||||
* Grandparent `ns1` lacks delegation of parent.
|
||||
* Grandparent `ns2` has delegation of parent (to both parent NS).
|
||||
* Parent zone lacks delegation of child.
|
||||
|
||||
### CHLD-FOUND-PAR-UNDET-1
|
||||
The child zone is delegated from one grandparent NS and from the parent zone.
|
||||
|
||||
* Zone: child.parent.chld-found-par-undet-1.basic01.xa
|
||||
* Grandparent `ns1` has delegation of child but lacks delegation of parent.
|
||||
* Grandparent `ns2` has delegation of parent (to both parent NS).
|
||||
* Parent zone has delegation of child.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-1
|
||||
The child is delegated from one parent NS. The other responds with NXDOMAIN.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-1.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child (NXDOMAIN).
|
||||
|
||||
### CHLD-FOUND-INCONSIST-2
|
||||
The child is delegated from one parent NS. On the other there is an CNAME
|
||||
response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-2.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, and has a CNAME on that name,
|
||||
pointing at `no-child.parent.chld-found-inconsist-2.basic01.xa`, which has
|
||||
two address records (A and AAAA) with the IP addresses of child `ns2`.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-3
|
||||
The child is delegated from one parent NS. On the other there is a CNAME
|
||||
to another name, and that other name is delegated.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-3.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, and has a CNAME on the name,
|
||||
pointing at `sister.parent.chld-found-inconsist-3.basic01.xa`, which is
|
||||
delegated to `ns1-delegated-child.basic01.xa` and
|
||||
`ns2-delegated-child.basic01.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-4
|
||||
The child is delegated from one parent NS. On the other there is a DNAME to
|
||||
another name.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-4.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` has a DNAME on `child` pointing at
|
||||
`sister.parent.chld-found-inconsist-4.basic01.xa` which is delegated to
|
||||
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-5
|
||||
The child is delegated from one parent NS. On the other there is a NODATA
|
||||
response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-5.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, instead `child` has two address
|
||||
records (A and AAAA) with the IP addresses of child `ns2`.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-6
|
||||
The child is delegated from one parent NS, which is also NS for the child.
|
||||
On the other there is an NXDOMAIN response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-6.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to the two child NS.
|
||||
* Parent `ns2` lacks delegation of child (NXDOMAIN).
|
||||
* Child shares `ns1.parent.chld-found-inconsist-6.basic01.xa` with parent.
|
||||
* Child also uses child `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-7
|
||||
The child is delegated from one parent NS, which is also NS for the child. On the
|
||||
other there is a CNAME response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-7.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, and has a CNAME on that name,
|
||||
pointing at `no-child.parent.chld-found-inconsist-7.basic01.xa`, which has
|
||||
two address records (A and AAAA) with the IP addresses of child `ns2`.
|
||||
* Child shares `ns1.parent.chld-found-inconsist-7.basic01.xa` with parent.
|
||||
* Child also uses `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-8
|
||||
The child is delegated from one parent NS, which is also NS for the child. On
|
||||
the other there is a CNAME to another name, and that other name is delegated.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-8.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, and has a CNAME on the name,
|
||||
pointing at `sister.parent.chld-found-inconsist-8.basic01.xa`, which is
|
||||
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
* Child shares `ns1.parent.chld-found-inconsist-8.basic01.xa` with parent.
|
||||
* Child also uses `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-9
|
||||
The child is delegated from one parent NS, which is also NS for the child. On
|
||||
the other there is a DNAME to another name.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-9.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` has a DNAME on `child` pointing at
|
||||
`sister.parent.chld-found-inconsist-9.basic01.xa` which is delegated to
|
||||
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
* Child shares `ns1.parent.chld-found-inconsist-9.basic01.xa` with parent.
|
||||
* Child also uses `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-10
|
||||
The child is delegated from one parent NS, which is also NS for the child. On the
|
||||
other there is a NODATA response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-10.basic01.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, instead `child` has two address
|
||||
records (A and AAAA) with the IP addresses of child `ns2`.
|
||||
* Child shares `ns1.parent.chld-found-inconsist-10.basic01.xa` with parent.
|
||||
* Child also uses `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### NO-DEL-UNDEL-NO-PAR-1
|
||||
The child is not delegated, but there is undelegated data to test. Both
|
||||
grandparent NS return SERVFAIL.
|
||||
|
||||
* Zone: child.parent.no-del-undel-no-par-1.basic01.xa
|
||||
* Grandparent `ns1` and `ns2` both return SERVFAIL.
|
||||
* No need of parent zone.
|
||||
* Child zone is not delegated, but there is an undelegated version.
|
||||
* Undelgated data:
|
||||
* ns3-undelegated-child.basic01.xa
|
||||
* ns4-undelegated-child.basic01.xa
|
||||
|
||||
### NO-DEL-UNDEL-PAR-UND-1
|
||||
The child is not delegated, but there is an undelegated data to test. One
|
||||
grandparent NS lacks delegation of parent and return NXDOMAIN of child. The
|
||||
parent zone lacks delegation of child.
|
||||
|
||||
* Zone: child.parent.no-del-undel-par-und-1.basic01.xa
|
||||
* Child zone does not exist is not served by any NS.
|
||||
* Grandparent `ns1` lacks delegation of parent.
|
||||
* Grandparent `ns2` has delegation of parent (to both parent NS).
|
||||
* Parent zone lacks delegation of child.
|
||||
* Child zone is not delegated, but there is an undelegated version.
|
||||
* Undelegated data:
|
||||
* ns3-undelegated-child.basic01.xa
|
||||
* ns4-undelegated-child.basic01.xa
|
||||
|
||||
### NO-CHLD-NO-PAR-1
|
||||
The child is not delegated. Both grandparent NS return SERVFAIL.
|
||||
|
||||
* Zone: child.parent.no-chld-no-par-1.basic01.xa
|
||||
* Grandparent `ns1` and `ns2` both return SERVFAIL.
|
||||
* No need of parent zone.
|
||||
* Child zone is not delegated, and there is no undelegated data.
|
||||
* No need of child zone.
|
||||
|
||||
### CHILD-ALIAS-1
|
||||
The child zone does not exist, instead there is a DNAME in the parent zone.
|
||||
|
||||
* Zone: child.parent.child-alias-1.basic01.xa
|
||||
* Parent has a DNAME on `child` pointing at
|
||||
`sister.parent.child-alias-1.basic01.xa` which is delegated to
|
||||
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
|
||||
### CHILD-ALIAS-2
|
||||
The child zone does not exist, instead there is a DNAME in the parent zone,
|
||||
however, different DNAME targets in the two parents.
|
||||
|
||||
* Zone: child.parent.child-alias-2.basic01.xa
|
||||
* On `ns1` parent has a DNAME on `child` pointing at
|
||||
`sister.parent.child-alias-2.basic01.xa` which is delegated to
|
||||
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
* On `ns2` parent has a DNAME on `child` pointing at
|
||||
`brother.parent.child-alias-2.basic01.xa` which is delegated to
|
||||
`ns1-delegated-child.basic01.xa` and `ns2-delegated-child.basic01.xa`.
|
||||
* Zone `brother` does not exist.
|
||||
|
||||
### ZONE-ERR-GRANDPARENT-1
|
||||
Grandparent `ns2` responds with AA bit unset on queries for grandparent zone.
|
||||
|
||||
* Zone: child.parent.zone-err-grandparent-1.basic01.xa
|
||||
* Normal response on grandparent `ns1`.
|
||||
* Grandparent `ns2` responds with AA bit unset on queries for the
|
||||
grandparent zone.
|
||||
|
||||
### ZONE-ERR-GRANDPARENT-2
|
||||
Grandparent `ns2` responds with NODATA on NS query for grandparent zone.
|
||||
|
||||
* Zone: child.parent.zone-err-grandparent-2.basic01.xa
|
||||
* Normal response on grandparent `ns1`.
|
||||
* Grandparent `ns2` responds with NODATA on NS query for the
|
||||
grandparent zone.
|
||||
|
||||
### ZONE-ERR-GRANDPARENT-3
|
||||
Grandparent `ns2` responds with wrong owner name on NS
|
||||
on query for grandparent zone NS.
|
||||
|
||||
* Zone: child.parent.zone-err-grandparent-3.basic01.xa
|
||||
* Normal response on grandparent `ns1`.
|
||||
* Grandparent `ns2` responds with other owner name on NS query for
|
||||
`zone-err-grandparent-3.basic01.xa`:
|
||||
* Owner name `oncle.zone-err-grandparent-3.basic01.xa` instead.
|
||||
|
||||
### ROOT-ZONE
|
||||
Test on the standard root zone.
|
||||
|
||||
* Zone: .
|
||||
* No special zone files are to be created.
|
||||
|
||||
|
||||
|
||||
[Basic01]: ../../tests/Basic-TP/basic01.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../README.md
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
|
||||
@@ -0,0 +1,416 @@
|
||||
# Specification of Test Scenarios for Basic02
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test scenarios and setup of test zones](#test-scenarios-and-setup-of-test-zones)
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies defined test scenarios for test case [Basic02].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [Basic02] is run on a test zone.
|
||||
The message tags are defined in the test case ([Basic02]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone or zones for each test scenario in this document is a subdomain
|
||||
(or lower zone) delegated from the base name (`basic02.xa`) and that subdomain
|
||||
having the same name as the scenario. The names of those zones are given in
|
||||
section "[Test scenarios and setup of test zones]" below.
|
||||
|
||||
|
||||
## All message tags
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [Basic02] for the specification of the tags.
|
||||
|
||||
* B02_AUTH_RESPONSE_SOA
|
||||
* B02_NO_DELEGATION
|
||||
* B02_NO_WORKING_NS
|
||||
* B02_NS_BROKEN
|
||||
* B02_NS_NOT_AUTH
|
||||
* B02_NS_NO_IP_ADDR
|
||||
* B02_NS_NO_RESPONSE
|
||||
* B02_UNEXPECTED_RCODE
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:------------------------------|:-------------------------------------------|:----------------------
|
||||
GOOD-1 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-2 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-1 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-2 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-3 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-4 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-5 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-6 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-7 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-8 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-9 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-10 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
GOOD-UNDEL-11 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
MIXED-1 | B02_AUTH_RESPONSE_SOA | 2)
|
||||
NO-DELEGATION-1 | B02_NO_DELEGATION | 2)
|
||||
NS-BROKEN-1 | B02_NS_BROKEN, B02_NO_WORKING_NS | 2)
|
||||
NS-NOT-AUTH-1 | B02_NS_NOT_AUTH, B02_NO_WORKING_NS | 2)
|
||||
NS-NO-IP-1 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
|
||||
NS-NO-IP-2 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
|
||||
NS-NO-IP-3 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
|
||||
NS-NO-IP-UNDEL-1 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
|
||||
NS-NO-IP-UNDEL-2 | B02_NS_NO_IP_ADDR, B02_NO_WORKING_NS | 2)
|
||||
NS-NO-RESPONSE-1 | B02_NS_NO_RESPONSE, B02_NO_WORKING_NS | 2)
|
||||
UNEXPECTED-RCODE-1 | B02_UNEXPECTED_RCODE, B02_NO_WORKING_NS | 2)
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
|
||||
## Test scenarios and setup of test zones
|
||||
|
||||
### Default zone configuration
|
||||
Unless otherwise specified in the specific scenario specification, the test zone
|
||||
or zones for the scenario will follow the default setup as stated below. The
|
||||
`child zone` is the zone to be tested for the scenario.
|
||||
|
||||
`basic02.xb` is a zone for out-of-bailiwick name servers for applicable
|
||||
scenario.
|
||||
|
||||
* The child zone is `SCENARIO.basic02.xa`.
|
||||
* It is delegated to two name servers, `ns1.SCENARIO.basic02.xa`
|
||||
and `ns2.SCENARIO.basic02.xa`.
|
||||
* The name server names have A and AAAA records to avoid non-relevant error
|
||||
messages.
|
||||
* The delegation of the child zone is complete with glue records.
|
||||
* There is a zone file for the child zone.
|
||||
* All child zone servers give the same response.
|
||||
* All responses will have the AA bit set.
|
||||
* All responses will have the [RCODE Name] "NoError".
|
||||
* NS and any glue matches NS and authoritative address records in zone.
|
||||
* If NS are out of bailiwick, the names are defined in another zone with correct
|
||||
A and AAAA records.
|
||||
|
||||
### GOOD-1
|
||||
A "happy path". Everything is fine.
|
||||
|
||||
* Zone: good-1.basic02.xa
|
||||
* Zone is set up as default.
|
||||
|
||||
### GOOD-2
|
||||
Like GOOD-1 but name servers are out-of-bailiwick.
|
||||
|
||||
* Zone: good-1.basic02.xa
|
||||
* ns1 is ns1.good-2.basic02.xb.
|
||||
* ns2 is ns2.good-2.basic02.xb.
|
||||
* Delegation is without glue.
|
||||
|
||||
### Overview of the GOOD-UNDEL-x scenarios
|
||||
|
||||
Scenario name | Delegated zone | Undelegated data
|
||||
:--------------|:------------------------------|:--------------------
|
||||
GOOD-UNDEL-1 | no delegation | IB with glue
|
||||
GOOD-UNDEL-2 | no delegation | OOB without glue, NS names are defined
|
||||
GOOD-UNDEL-3 | IB, no response | OOB without glue, NS names are defined
|
||||
GOOD-UNDEL-4 | IB, no glue | OOB without glue, NS names are defined
|
||||
GOOD-UNDEL-5 | IB, no glue | IB with glue
|
||||
GOOD-UNDEL-6 | OOB, no response | IB with glue
|
||||
GOOD-UNDEL-7 | OOB, no address records | OOB with glue, NS names are undefined
|
||||
GOOD-UNDEL-8 | IB, no response | IB, IP redefined
|
||||
GOOD-UNDEL-9 | OOB, no response | OOB, IP redefined
|
||||
GOOD-UNDEL-10 | OOB, SERVFAIL/REFUSED | OOB
|
||||
GOOD-UNDEL-11 | OOB, cannot look addr up | OOB, IP through lookup
|
||||
|
||||
### GOOD-UNDEL-1
|
||||
The zone is not delegated. Undelegated data provides a working zone.
|
||||
|
||||
* Zone: good-undel-1.basic02.xa
|
||||
* The zone is not delegated.
|
||||
* Else, the zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* ns1.good-undel-1.basic02.xa/IPv4
|
||||
* ns1.good-undel-1.basic02.xa/IPv6
|
||||
* ns2.good-undel-1.basic02.xa/IPv4
|
||||
* ns2.good-undel-1.basic02.xa/IPv6
|
||||
|
||||
### GOOD-UNDEL-2
|
||||
The zone is not delegated. Undelegated data provides a working zone. NS are
|
||||
out-of-bailiwick.
|
||||
|
||||
* Zone: good-undel-2.basic02.xa
|
||||
* The zone is not delegated.
|
||||
* The undelegated data has out-of-bailiwick name servers without glue.
|
||||
* Normal lookup provides IP addresses for the name server names.
|
||||
* Else, the zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* ns1.good-undel-2.basic02.xb
|
||||
* ns2.good-undel-2.basic02.xb
|
||||
|
||||
### GOOD-UNDEL-3
|
||||
Delegated zone does not respond. There is a working zone from undelegated data.
|
||||
Those NS are out-of-bailiwick.
|
||||
|
||||
* Zone: good-undel-3.basic02.xa
|
||||
* The name servers in delegation are ns1 and ns2.
|
||||
* Name servers from delegation do not respond.
|
||||
* The undelegated data has out-of-bailiwick name servers without glue.
|
||||
* Normal lookup provides IP addresses for the name server names.
|
||||
* Else, the zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* ns3.good-undel-3.basic02.xb
|
||||
* ns4.good-undel-3.basic02.xb
|
||||
|
||||
### GOOD-UNDEL-4
|
||||
Delegation of zone lacks glue. There is a working zone from undelegated data.
|
||||
Those NS are out-of-bailiwick.
|
||||
|
||||
* Zone: good-undel-4.basic02.xa
|
||||
* The name servers in delegation are ns1 and ns2.
|
||||
* There is no glue for ns1 and ns2.
|
||||
* The undelegated data has out-of-bailiwick name servers without glue.
|
||||
* Normal lookup provides IP addresses for the name server names.
|
||||
* Else, the zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* ns1.good-undel-4.basic02.xb
|
||||
* ns2.good-undel-4.basic02.xb
|
||||
|
||||
### GOOD-UNDEL-5
|
||||
Delegation of zone lacks glue. There is a working zone from undelegated data.
|
||||
|
||||
* Zone: good-undel-5.basic02.xa
|
||||
* The name servers in delegation ns1 and ns2.
|
||||
* There is no glue for ns1 and ns2.
|
||||
* The undelegated data has the same NS names with glue.
|
||||
* Else, the zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* ns1.good-undel-5.basic02.xa/IPv4
|
||||
* ns1.good-undel-5.basic02.xa/IPv6
|
||||
* ns2.good-undel-5.basic02.xa/IPv4
|
||||
* ns2.good-undel-5.basic02.xa/IPv6
|
||||
|
||||
### GOOD-UNDEL-6
|
||||
Zone is delegated to out-of-bailiwick NS, but with no response. There is a
|
||||
working zone from undelegated data.
|
||||
|
||||
* Zone: good-undel-6.basic02.xa
|
||||
* The name servers in delegation are ns1.good-undel-6.basic02.xb and
|
||||
ns2.good-undel-6.basic02.xb.
|
||||
* Normal lookup provides IP addresses for the name server names.
|
||||
* The servers in delegation do not respond.
|
||||
* The zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* ns3.good-undel-6.basic02.xa/IPv4
|
||||
* ns3.good-undel-6.basic02.xa/IPv6
|
||||
* ns4.good-undel-6.basic02.xa/IPv4
|
||||
* ns4.good-undel-6.basic02.xa/IPv6
|
||||
|
||||
### GOOD-UNDEL-7
|
||||
Zone is delegated to out-of-bailiwick NS, but with no IP for NS. There is a
|
||||
working zone from undelegated data, also out-of-bailiwick.
|
||||
|
||||
* Zone: good-undel-7.basic02.xa
|
||||
* The name servers in delegation are ns1.good-undel-7.basic02.xb and
|
||||
ns2.good-undel-7.basic02.xb.
|
||||
* ns1 and ns2 are defined, but with no address records.
|
||||
* The NS in undelegated data use names that are not defined.
|
||||
* The zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* ns3.good-undel-7.basic02.xb/IPv4
|
||||
* ns3.good-undel-7.basic02.xb/IPv6
|
||||
* ns4.good-undel-7.basic02.xb/IPv4
|
||||
* ns5.good-undel-7.basic02.xb/IPv6
|
||||
|
||||
### GOOD-UNDEL-8
|
||||
Zone is delegated, but no response from the NS of delegation. There is a working
|
||||
zone from undelegated data.
|
||||
|
||||
* Zone: good-undel-8.basic02.xa
|
||||
* The name servers in delegation are dns1 and dns2.
|
||||
* There is no response from dns1 and dns2.
|
||||
* The NS in undelegated data use the same NS names with other IP addresses.
|
||||
* Else, the zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* dns1.good-undel-8.basic02.xa/IPv4
|
||||
* dns1.good-undel-8.basic02.xa/IPv6
|
||||
* dns2.good-undel-8.basic02.xa/IPv4
|
||||
* dns2.good-undel-8.basic02.xa/IPv6
|
||||
|
||||
### GOOD-UNDEL-9
|
||||
Zone is delegated to out-of-bailiwick NS, but with no response. There is a
|
||||
working zone from undelegated data.
|
||||
|
||||
* Zone: good-undel-9.basic02.xa
|
||||
* The name servers in delegation are dns1.good-undel-9.basic02.xb and
|
||||
dns2.good-undel-9.basic02.xb.
|
||||
* Normal lookup provides IP addresses for the name server names.
|
||||
* The servers in delegation do not respond.
|
||||
* The NS in undelegated data use the same NS names with other IP addresses.
|
||||
* The zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* dns1.good-undel-9.basic02.xb/IPv4
|
||||
* dns1.good-undel-9.basic02.xb/IPv6
|
||||
* dns2.good-undel-9.basic02.xb/IPv4
|
||||
* dns2.good-undel-9.basic02.xb/IPv6
|
||||
|
||||
### GOOD-UNDEL-10
|
||||
Zone is delegated to out-of-bailiwick NS, but with SERVFAIL or REFUSED response.
|
||||
There is a working zone from undelegated data, also out-of-bailiwick.
|
||||
|
||||
* Zone: good-undel-10.basic02.xa
|
||||
* The name servers in delegation are ns1.good-undel-10.basic02.xb and
|
||||
ns2.good-undel-10.basic02.xb.
|
||||
* Normal lookup provides IP addresses for the name server names.
|
||||
* The servers in delegation respond with SERVFAIL (ns1) or REFUSED (ns2).
|
||||
* The NS in undelegated data use other IP addresses.
|
||||
* The zone from undelegated data is set up as default.
|
||||
* Undelegated data:
|
||||
* ns3.good-undel-10.basic02.xb/IPv4
|
||||
* ns3.good-undel-10.basic02.xb/IPv6
|
||||
* ns4.good-undel-10.basic02.xb/IPv4
|
||||
* ns4.good-undel-10.basic02.xb/IPv6
|
||||
|
||||
### GOOD-UNDEL-11
|
||||
Zone is delegated to out-of-bailiwick NS whose names are in a zone that is
|
||||
not reachable (addresses cannot be looked up). There is a working zone from
|
||||
undelegated data, also out-of-bailiwick.
|
||||
|
||||
* Zone: good-undel-11.basic02.xa
|
||||
* The name servers in delegation are ns1.delegated.good-undel-11.basic02.xb
|
||||
and ns2.delegated.good-undel-11.basic02.xb.
|
||||
* Normal lookup fails to provides IP addresses for the name server names
|
||||
since zone delegated.good-undel-11.basic02.xb cannot be reached.
|
||||
* delegated.good-undel-11.basic02.xb is delegated to dns1 and dns2 relative
|
||||
to that domain.
|
||||
* There is no actual zone for the delegated data (not needed).
|
||||
* The zone from undelegated data is set up as default.
|
||||
* The addresses for the NS for the undelegated zone are found via lookup.
|
||||
* Undelegated data:
|
||||
* ns3.good-undel-11.basic02.xb
|
||||
* ns4.good-undel-11.basic02.xb
|
||||
|
||||
### MIXED-1
|
||||
The zone is delegated to four NS, of which ns1 responds correctly, ns2 does
|
||||
not respond, ns3 returns SERVFAIL and ns4 is not authoritative.
|
||||
|
||||
* Zone: mixed-1.basic02.xa
|
||||
* The zone is set-up as default, but with four NS (ns1-4).
|
||||
* ns1 gives correct response.
|
||||
* ns2 does not respond.
|
||||
* ns3 returns SERVFAIL on all queries.
|
||||
* ns4 returns all responses with AA flag unset.
|
||||
|
||||
### NO-DELEGATION
|
||||
There is no delegation for the zone.
|
||||
|
||||
* Zone: no-delegation.basic02.xa
|
||||
* No zone.
|
||||
* No name servers.
|
||||
* No delegation.
|
||||
|
||||
### NS-BROKEN-1
|
||||
The servers for the zone do not respond with SOA record on SOA query.
|
||||
|
||||
* Zone: ns-broken-1.basic02.xa
|
||||
* No SOA record in response from ns1 and ns2.
|
||||
* RCODE is NOERROR and AA bit is set.
|
||||
|
||||
### NS-NOT-AUTH-1
|
||||
The servers for the zone do not give authoritative responses.
|
||||
|
||||
* Zone: ns-not-auth-1.basic02.xa
|
||||
* AA bit is unset in responses from ns1 and ns2.
|
||||
|
||||
### NS-NO-IP-1
|
||||
The delegation is without glue.
|
||||
|
||||
* Zone: ns-no-ip-1.basic02.xa
|
||||
* There is no glue in delegation for ns1 and ns2.
|
||||
* No zone is set up.
|
||||
|
||||
### NS-NO-IP-2
|
||||
The name server are out-of-bailiwick but have no address records.
|
||||
|
||||
* Zone: ns-no-ip-2.basic02.xa
|
||||
* ns1 and ns2 are out-of-bailiwick.
|
||||
* ns1 is ns1.ns-no-ip-2.basic02.xb.
|
||||
* ns2 is ns2.ns-no-ip-2.basic02.xb.
|
||||
* ns1 and ns2 exist as names, but have no address records.
|
||||
* No zone is set up.
|
||||
|
||||
### NS-NO-IP-3
|
||||
The name server are out-of-bailiwick but the names are not defined.
|
||||
|
||||
* Zone: ns-no-ip-3.basic02.xa
|
||||
* ns1 and ns2 are out-of-bailiwick.
|
||||
* ns1 is ns1.ns-no-ip-3.basic02.xb.
|
||||
* ns2 is ns2.ns-no-ip-3.basic02.xb.
|
||||
* ns1 and ns2 do not exist as names.
|
||||
* No zone is set up.
|
||||
|
||||
### NS-NO-IP-UNDEL-1
|
||||
The delegated zone works correctly. The undelegated data has in-bailiwick NS
|
||||
without glue.
|
||||
|
||||
* Zone: ns-no-ip-undel-1.basic02.xa
|
||||
* ns1 and ns2 serves a working zone.
|
||||
* The undelegated data uses the same NS names but without glue.
|
||||
* There is no need for a zone for undelegated data.
|
||||
* Undelegated data:
|
||||
* ns1.ns-no-ip-undel-1.basic02.xa
|
||||
* ns2.ns-no-ip-undel-1.basic02.xa
|
||||
|
||||
### NS-NO-IP-UNDEL-2
|
||||
The delegated zone works correctly. The undelegated data has out-of-bailiwick NS
|
||||
without glue. The NS names have no address records.
|
||||
|
||||
* Zone: ns-no-ip-undel-2.basic02.xa
|
||||
* ns1 and ns2 serves a working zone.
|
||||
* The undelegated data uses out-of-bailiwick NS.
|
||||
* NS names exists.
|
||||
* NS names do not resolve to address records.
|
||||
* There is no need for a zone for undelegated data.
|
||||
* Undelegated data:
|
||||
* ns1.ns-no-ip-undel-2.basic02.xb
|
||||
* ns2.ns-no-ip-undel-2.basic02.xb
|
||||
|
||||
### NS-NO-RESPONSE-1
|
||||
The name servers do not respond on the queries.
|
||||
|
||||
* Zone: ns-no-response-1.basic02.xa
|
||||
* ns1 and ns2 do not respond to queries.
|
||||
* No zone is set up.
|
||||
|
||||
### UNEXPECTED-RCODE-1
|
||||
The name servers respond with NXDOMAIN, REFUSED or SERVFAIL on SOA query.
|
||||
|
||||
* Zone: unexpected-rcode-1.basic02.xa
|
||||
* ns1 responds with NXDOMAIN.
|
||||
* ns2 responds with REFUSED.
|
||||
* ns3 responds with SERVFAIL.
|
||||
* No actual zone exists.
|
||||
|
||||
|
||||
[Basic02]: ../../tests/Basic-TP/basic02.md
|
||||
[test scenario README file]: ../README.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
|
||||
@@ -0,0 +1,6 @@
|
||||
# Specification of test scenarios for Connectivity-TP
|
||||
|
||||
|
||||
Test scenario specifications are available for:
|
||||
|
||||
* [Connectivity04](connectivity04.md)
|
||||
@@ -0,0 +1,301 @@
|
||||
# Specification of Test Scenarios for Connectivity04
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test scenarios and setup of test zones]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies defined test scenarios for test case [Connectivity04].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [Connectivity04] is run on a test zone.
|
||||
The message tags are defined in the test case ([Connectivity04]) and the
|
||||
scenarios are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone or zones for each test scenario in this document is a subdomain
|
||||
(or lower zone) delegated from the base name (`connectivity04.xa`) and that subdomain
|
||||
having the same name as the scenario. The names of those zones are given in
|
||||
section "[Test scenarios and setup of test zones]" below.
|
||||
|
||||
|
||||
## All message tags
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [Connectivity04] for the specification of the tags.
|
||||
|
||||
* CN04_EMPTY_PREFIX_SET
|
||||
* CN04_ERROR_PREFIX_DATABASE
|
||||
* CN04_IPV4_DIFFERENT_PREFIX
|
||||
* CN04_IPV4_SAME_PREFIX
|
||||
* CN04_IPV4_SINGLE_PREFIX
|
||||
* CN04_IPV6_DIFFERENT_PREFIX
|
||||
* CN04_IPV6_SAME_PREFIX
|
||||
* CN04_IPV6_SINGLE_PREFIX
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:------------------------|:----------------------------------------------------------------------------------|:--------------------
|
||||
GOOD-1 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
|
||||
GOOD-2 | CN04_IPV4_DIFFERENT_PREFIX | 2)
|
||||
GOOD-3 | CN04_IPV6_DIFFERENT_PREFIX | 2)
|
||||
EMPTY-PREFIX-SET-1 | CN04_EMPTY_PREFIX_SET | 2)
|
||||
EMPTY-PREFIX-SET-2 | CN04_EMPTY_PREFIX_SET | 2)
|
||||
ERROR-PREFIX-DATABASE-1 | CN04_ERROR_PREFIX_DATABASE | 2)
|
||||
ERROR-PREFIX-DATABASE-2 | CN04_ERROR_PREFIX_DATABASE | 2)
|
||||
ERROR-PREFIX-DATABASE-3 | CN04_ERROR_PREFIX_DATABASE | 2)
|
||||
ERROR-PREFIX-DATABASE-6 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX, CN04_ERROR_PREFIX_DATABASE| 2)
|
||||
ERROR-PREFIX-DATABASE-7 | CN04_ERROR_PREFIX_DATABASE | 2)
|
||||
ERROR-PREFIX-DATABASE-8 | CN04_ERROR_PREFIX_DATABASE | 2)
|
||||
HAS-NON-ASN-TXT-1 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
|
||||
HAS-NON-ASN-TXT-2 | CN04_EMPTY_PREFIX_SET | 2)
|
||||
IPV4-ONE-PREFIX-1 | CN04_IPV4_SAME_PREFIX, CN04_IPV4_SINGLE_PREFIX | 2)
|
||||
IPV4-TWO-PREFIXES-1 | CN04_IPV4_SAME_PREFIX, CN04_IPV4_DIFFERENT_PREFIX | 2)
|
||||
IPV6-ONE-PREFIX-1 | CN04_IPV6_SAME_PREFIX, CN04_IPV6_SINGLE_PREFIX | 2)
|
||||
IPV6-TWO-PREFIXES-1 | CN04_IPV6_SAME_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
|
||||
IPV4-SINGLE-NS-1 | CN04_IPV4_SINGLE_PREFIX, CN04_IPV4_DIFFERENT_PREFIX | 2)
|
||||
IPV6-SINGLE-NS-1 | CN04_IPV6_SINGLE_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
|
||||
DOUBLE-PREFIX-1 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
|
||||
DOUBLE-PREFIX-2 | CN04_IPV4_DIFFERENT_PREFIX, CN04_IPV6_DIFFERENT_PREFIX | 2)
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
|
||||
## Test scenarios and setup of test zones
|
||||
|
||||
### Default zone configuration
|
||||
Unless otherwise specified in the specific scenario specification, the test zone
|
||||
or zones for the scenario will follow the default setup as stated below. The
|
||||
`child zone` is the zone to be tested for the scenario.
|
||||
|
||||
* The child zone is `SCENARIO.connectivity04.xa`.
|
||||
* It is delegated to out-of-bailiwick NS, specified per scenario.
|
||||
* The names of the NS exist in the parent zone.
|
||||
* The NS for a child will only reply to NS query and do that
|
||||
consistently.
|
||||
* The parent zone is `connectivity04.xa`.
|
||||
* It is served by two in-bailiwick NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* All responses will have the [RCODE Name] "NoError".
|
||||
|
||||
### GOOD-1
|
||||
Everything is fine.
|
||||
|
||||
* Zone: good-1.connectivity04.xa
|
||||
* 2 NS.
|
||||
* Both with IPv4 and IPv6.
|
||||
* Each NS IP in different prefixes.
|
||||
|
||||
### GOOD-2
|
||||
Everything is fine. IPv4 only.
|
||||
|
||||
* Zone: good-2.connectivity04.xa
|
||||
* 2 NS.
|
||||
* IPv4 only.
|
||||
* Each NS IP in different prefixes.
|
||||
|
||||
### GOOD-3
|
||||
Everything is fine. IPv6 only.
|
||||
|
||||
* Zone: good-3.connectivity04.xa
|
||||
* 2 NS.
|
||||
* IPv4 only.
|
||||
* Each NS IP in different prefixes.
|
||||
|
||||
### EMPTY-PREFIX-SET-1
|
||||
No ASN data (NXDOMAIN).
|
||||
|
||||
* Zone: empty-prefix-set-1.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv4 and IPv6 on NS.
|
||||
* The ASN-lookup returns [RCODE Name] NXDOMAIN.
|
||||
|
||||
### EMPTY-PREFIX-SET-2
|
||||
No ASN data (NODATA).
|
||||
|
||||
* Zone: empty-prefix-set-2.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv4 and IPv6 on NS.
|
||||
* The ASN-lookup returns no TXT record (NODATA).
|
||||
|
||||
### ERROR-PREFIX-DATABASE-1
|
||||
No ASN data due to SERVFAIL.
|
||||
|
||||
* Zone: error-prefix-database-1.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv4 and IPv6 on NS.
|
||||
* The ASN-lookup returns SERVFAIL.
|
||||
|
||||
### ERROR-PREFIX-DATABASE-2
|
||||
No ASN data due to REFUSED.
|
||||
|
||||
* Zone: error-prefix-database-2.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv4 and IPv6 on NS.
|
||||
* The ASN-lookup returns REFUSED.
|
||||
|
||||
### ERROR-PREFIX-DATABASE-3
|
||||
No ASN data, no DNS response at all.
|
||||
|
||||
* Zone: error-prefix-database-3.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv4 and IPv6 on NS.
|
||||
* The ASN-lookup returns no DNS response (no response at all).
|
||||
|
||||
### ERROR-PREFIX-DATABASE-4
|
||||
(Renamed)
|
||||
|
||||
### ERROR-PREFIX-DATABASE-5
|
||||
(Renamed)
|
||||
|
||||
### ERROR-PREFIX-DATABASE-6
|
||||
Extra ASN lookup TXT record with wrong IP prefix.
|
||||
|
||||
* Zone: error-prefix-database-6.connectivity04.xa
|
||||
* 2 NS.
|
||||
* Both with IPv4 and IPv6.
|
||||
* Each NS IP in different prefixes.
|
||||
* For one NS (both IPs) the ASN lookup returns an extra TXT with an IP prefix
|
||||
that does not match the IP address.
|
||||
|
||||
### ERROR-PREFIX-DATABASE-7
|
||||
ASN lookup TXT record with wrong IP prefix.
|
||||
|
||||
* Zone: error-prefix-database-7.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv4 and IPv6 on NS.
|
||||
* The ASN-lookup returns one TXT record for both IP with an IP prefix that
|
||||
does not match the IP address.
|
||||
|
||||
### ERROR-PREFIX-DATABASE-8
|
||||
ASN lookup gives no TXT-record but a CNAME.
|
||||
|
||||
* Zone: error-prefix-database-8.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv4 and IPv6 on NS.
|
||||
* The ASN-lookup returns no TXT record for both IP but a CNAME record.
|
||||
|
||||
### HAS-NON-ASN-TXT-1
|
||||
IPv4 and IPv6. Extra non-ASN lookup TXT record.
|
||||
|
||||
* Zone: has-non-asn-txt-1.connectivity04.xa
|
||||
* 2 NS.
|
||||
* Both NS with IPv4 and IPv6.
|
||||
* Each NS IP in different prefixes.
|
||||
* For one NS (both IPs) the ASN lookup returns an extra TXT record with the
|
||||
text "This is not ASN data".
|
||||
|
||||
### HAS-NON-ASN-TXT-2
|
||||
No ASN data, some other TXT record.
|
||||
|
||||
* Zone: has-non-asn-txt-2.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv4 and IPv6 on NS.
|
||||
* The ASN-lookup returns one TXT record for both IP with the string
|
||||
"This is not ASN data".
|
||||
|
||||
### IPV4-ONE-PREFIX-1
|
||||
All NS IPs in the same prefix. IPv4 only.
|
||||
|
||||
* Zone: ipv4-one-prefix-1.connectivity04.xa
|
||||
* 2 NS.
|
||||
* IPv4 only.
|
||||
* Both NS in the same prefix.
|
||||
|
||||
### IPV4-TWO-PREFIXES-1
|
||||
Two NS in the same prefix. One NS in its own prefix. IPv4 only.
|
||||
|
||||
* Zone: ipv4-two-prefixes-1.connectivity04.xa
|
||||
* 3 NS.
|
||||
* IPv4 only.
|
||||
* Two NS in the same prefix.
|
||||
* One NS in its own prefix.
|
||||
|
||||
### IPV6-ONE-PREFIX-1
|
||||
All NS IPs in the same prefix. IPv6 only.
|
||||
|
||||
* Zone: ipv6-one-prefix-1.connectivity04.xa
|
||||
* 2 NS.
|
||||
* Ipv6 only.
|
||||
* Both NS in the same prefix.
|
||||
|
||||
### IPV6-TWO-PREFIXES-1
|
||||
Two NS in the same prefix. One NS in its own prefix. IPv6 only.
|
||||
|
||||
* Zone: ipv6-two-prefixes-1.connectivity04.xa
|
||||
* 3 NS.
|
||||
* IPv6 only.
|
||||
* Two NS in the same prefix.
|
||||
* One NS in its own prefix.
|
||||
|
||||
### IPV4-SINGLE-NS-1
|
||||
One NS, IPv4 only.
|
||||
|
||||
* Zone: ipv4-single-ns-1.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv4 only.
|
||||
|
||||
### IPV6-SINGLE-NS-1
|
||||
One NS, IPv6 only.
|
||||
|
||||
* Zone: ipv6-single-ns-1.connectivity04.xa
|
||||
* 1 NS.
|
||||
* IPv6 only.
|
||||
|
||||
### DOUBLE-PREFIX-1
|
||||
The IP addresses of the NS are announced from both a larger prefix and a more
|
||||
specific one.
|
||||
|
||||
* Zone: double-prefix-1.connectivity04.xa
|
||||
* 2 NS
|
||||
* IPv4 and IPv6.
|
||||
* The two IPv4 addresses are announced in one large (less specific) prefix that includes
|
||||
both NS IP addresses.
|
||||
* Each NS IP address is also announced in a more specific prefix only including
|
||||
that IP address.
|
||||
* Same with IPv6.
|
||||
|
||||
|
||||
### DOUBLE-PREFIX-2
|
||||
The IP addresses of the NS are announced in a larger (less specific) prefix that
|
||||
includes both NS IP. The addresses of one NS are also announced in more
|
||||
specific prefixes.
|
||||
|
||||
* Zone: double-prefix-2.connectivity04.xa
|
||||
* 2 NS
|
||||
* IPv4 and IPv6.
|
||||
* The two IPv4 addresses are announced in one large (less specific) prefix that
|
||||
includes both IP addresses.
|
||||
* The address of one of the NS is also announced in a more specific prefix.
|
||||
* Same with IPv6.
|
||||
|
||||
[Connectivity04]: ../../tests/Connectivity-TP/connectivity04.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test scenario README file]: ../README.md
|
||||
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
# Specification of test zones for Consistency-TP
|
||||
|
||||
|
||||
Test zone specifications are available for:
|
||||
|
||||
* [CONSISTENCY05](consistency05.md)
|
||||
* [CONSISTENCY06](consistency06.md)
|
||||
@@ -0,0 +1,282 @@
|
||||
# Specification of test zones for CONSISTENCY05
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies defined test zones for test case [CONSISTENCY05].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [CONSISTENCY05] is run on a test zone.
|
||||
The message tags are defined in the test case ([CONSISTENCY05]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test zone README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`consistency05.xa`) and that subdomain having the same name as the
|
||||
scenario. The names of those zones are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:-------------------------|:---------------------------------|:-------------------------------------------
|
||||
ADDRESSES-MATCH-1 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
|
||||
ADDRESSES-MATCH-2 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
|
||||
ADDRESSES-MATCH-3 | ADDRESSES_MATCH, CHILD_NS_FAILED | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, NO_RESPONSE
|
||||
ADDRESSES-MATCH-4 | ADDRESSES_MATCH, CHILD_NS_FAILED | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, NO_RESPONSE
|
||||
ADDRESSES-MATCH-5 | ADDRESSES_MATCH, NO_RESPONSE | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED
|
||||
ADDRESSES-MATCH-6 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
|
||||
ADDRESSES-MATCH-7 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
|
||||
ADDR-MATCH-DEL-UNDEL-1 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
|
||||
ADDR-MATCH-DEL-UNDEL-2 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
|
||||
ADDR-MATCH-NO-DEL-UNDEL-1 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
|
||||
ADDR-MATCH-NO-DEL-UNDEL-2 | ADDRESSES_MATCH | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE
|
||||
CHILD-ZONE-LAME-1 | CHILD_ZONE_LAME, NO_RESPONSE | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_NS_FAILED, ADDRESSES_MATCH
|
||||
CHILD-ZONE-LAME-2 | CHILD_ZONE_LAME, CHILD_NS_FAILED | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, ADDRESSES_MATCH, NO_RESPONSE
|
||||
IB-ADDR-MISMATCH-1 | IN_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD | OUT_OF_BAILIWICK_ADDR_MISMATCH, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
|
||||
IB-ADDR-MISMATCH-2 | IN_BAILIWICK_ADDR_MISMATCH | OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
|
||||
IB-ADDR-MISMATCH-3 | IN_BAILIWICK_ADDR_MISMATCH, NO_RESPONSE | OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
|
||||
IB-ADDR-MISMATCH-4 | IN_BAILIWICK_ADDR_MISMATCH | OUT_OF_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
|
||||
EXTRA-ADDRESS-CHILD | EXTRA_ADDRESS_CHILD | IN_BAILIWICK_ADDR_MISMATCH, OUT_OF_BAILIWICK_ADDR_MISMATCH, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
|
||||
OOB-ADDR-MISMATCH | OUT_OF_BAILIWICK_ADDR_MISMATCH | IN_BAILIWICK_ADDR_MISMATCH, EXTRA_ADDRESS_CHILD, CHILD_ZONE_LAME, CHILD_NS_FAILED, NO_RESPONSE, ADDRESSES_MATCH
|
||||
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the scenario specifications unless otherwise specified for
|
||||
the specific scenario:
|
||||
* For each scenario zone there are two name servers configured.
|
||||
* Both NS (ns1 and ns2) are equal in delegation and in zone.
|
||||
* Both NS are in-bailiwick
|
||||
* Both NS have both IPv4 and IPv6 addresses
|
||||
* All required glue are present in the delegation.
|
||||
* All glue exactly matches the authoritative address records in correct
|
||||
zone (not more and not less records).
|
||||
* All NS IP addresses respond with identical zone content.
|
||||
* Responds with a A record for the zone on query for A.
|
||||
* Responds with a AAAA record for the zone on query for AAAA.
|
||||
* All responses are authoritative with [RCODE Name] "NoError"
|
||||
* EDNS, version 0, is included in all responses on queries with EDNS.
|
||||
* EDNS is not included in responses on queries without EDNS.
|
||||
* In undelegated data, `IPv4` and `IPv6`, respectively, are placeholders for the
|
||||
actual IP addresses used for the scenario. They are to be found where the data
|
||||
is specified.
|
||||
* If no placeholder is given with the name server name, then no IP address is
|
||||
given and might be looked up.
|
||||
* The format for undelegated data follow the format used for `zonemaster-cli`
|
||||
(after `--ns`).
|
||||
|
||||
### ADDRESSES-MATCH-1
|
||||
The "happy path". Everything is fine.
|
||||
|
||||
* Zone: addresses-match-1.consistency05.xa
|
||||
|
||||
### ADDRESSES-MATCH-2
|
||||
Also the "happy path". Out-of-bailiwick NS this time. And no glue.
|
||||
|
||||
* Zone: addresses-match-2.consistency05.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick under the xb tree.
|
||||
* ns1 is "ns1.addresses-match-2.consistency05.xb"
|
||||
* ns2 is "ns2.addresses-match-2.consistency05.xb"
|
||||
* Delegation is without glue.
|
||||
* The zone has no address records for the NS names
|
||||
* The "addresses-match-2.consistency05.xb" zone has a full set of the
|
||||
address records for ns1 and ns2.
|
||||
|
||||
### ADDRESSES-MATCH-3
|
||||
One NS does not give AA answer, but else fine.
|
||||
|
||||
* Zone: addresses-match-3.consistency05.xa
|
||||
* ns1 responds with AA flag unset.
|
||||
|
||||
### ADDRESSES-MATCH-4
|
||||
One NS does give SERVFAIL response, but else fine.
|
||||
|
||||
* Zone: addresses-match-4.consistency05.xa
|
||||
* ns1 responds with [RCODE Name] "ServFail".
|
||||
|
||||
### ADDRESSES-MATCH-5
|
||||
One NS does not respond, but else fine.
|
||||
|
||||
* Zone: addresses-match-5.consistency05.xa
|
||||
* ns1 gives no response at all.
|
||||
|
||||
### ADDRESSES-MATCH-6
|
||||
Also "happy path". Out-of-bailiwick NS, but with glue.
|
||||
|
||||
* Zone: child.addresses-match-6.consistency05.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick
|
||||
* ns1 is "ns1.sibbling.addresses-match-6.consistency05.xa"
|
||||
* ns2 is "ns2.sibbling.addresses-match-6.consistency05.xa"
|
||||
* Delegation is with glue.
|
||||
* The test zone ("child") has no address records for the NS names, but the
|
||||
"sibbling" zone has full set of address records.
|
||||
|
||||
### ADDRESSES-MATCH-7
|
||||
Also "happy path". NS in subdomain.
|
||||
|
||||
* Zone: addresses-match-7.consistency05.xa
|
||||
* ns1 is "ns1.subdomain.addresses-match-7.consistency05.xa."
|
||||
* ns2 is "ns2.subdomain.addresses-match-7.consistency05.xa."
|
||||
* Delegation is with glue.
|
||||
* "subdomain.addresses-match-7.consistency05.xa" is delegated to the same
|
||||
ns1 and ns2.
|
||||
* ns1 and ns2 are defined with address records in the "subdomain" zone.
|
||||
|
||||
### ADDR-MATCH-DEL-UNDEL-1
|
||||
Also the "happy path". But there is an undelegated zone to be tested.
|
||||
|
||||
* Zone: addr-match-del-undel-1.consistency05.xa
|
||||
* Delegated zone on ns1 and ns2.
|
||||
* Undelegated zone on ns3 and ns4.
|
||||
* Delegated zone has neither ns1, ns2, ns3 nor ns4 as address records.
|
||||
* Undelegated zone has neither ns1 nor ns2 as an address record, but it
|
||||
has both ns3 and ns4 as address records.
|
||||
* Undelgated data:
|
||||
* ns3.addr-match-del-undel-1.consistency05.xa/IPv4
|
||||
* ns3.addr-match-del-undel-1.consistency05.xa/IPv6
|
||||
* ns4.addr-match-del-undel-1.consistency05.xa/IPv4
|
||||
* ns4.addr-match-del-undel-1.consistency05.xa/IPv6
|
||||
|
||||
### ADDR-MATCH-DEL-UNDEL-2
|
||||
Also the "happy path". But there is an undelegated zone to be tested, and its
|
||||
NS are out-of-bailiwick.
|
||||
|
||||
* Zone: addr-match-del-undel-2.consistency05.xa
|
||||
* Delegated zone on ns1 and ns2.
|
||||
* Undelegated zone on "ns3.addr-match-del-undel-2.consistency05.xb" and
|
||||
"ns4.addr-match-del-undel-2.consistency05.xb".
|
||||
* Delegated and undelegated zone, respectively, do not have neither ns1 nor ns2
|
||||
as an address record.
|
||||
* Undelegated data:
|
||||
* ns3.addr-match-del-undel-2.consistency05.xb
|
||||
* ns4.addr-match-del-undel-2.consistency05.xb
|
||||
|
||||
### ADDR-MATCH-NO-DEL-UNDEL-1
|
||||
Also the "happy path". No delegation but there is an undelegated zone to be
|
||||
tested.
|
||||
|
||||
* Zone: addr-match-no-del-undel-1.consistency05.xa
|
||||
* No delegated zone.
|
||||
* Undelegated zone on ns1 and ns2.
|
||||
* Undelegated data:
|
||||
* ns1.addr-match-no-del-undel-1.consistency05.xa/IPv4
|
||||
* ns1.addr-match-no-del-undel-1.consistency05.xa/IPv6
|
||||
* ns2.addr-match-no-del-undel-1.consistency05.xa/IPv4
|
||||
* ns2.addr-match-no-del-undel-1.consistency05.xa/IPv6
|
||||
|
||||
### ADDR-MATCH-NO-DEL-UNDEL-2
|
||||
Also the "happy path". No delegation but there is an undelegated zone to be
|
||||
tested. NS are out-of-bailiwick.
|
||||
|
||||
* Zone: addr-match-no-del-undel-2.consistency05.xa
|
||||
* No delegated zone.
|
||||
* Undelegated zone on "ns3.addr-match-no-del-undel-2.consistency05.xb" and
|
||||
"ns4.addr-match-no-del-undel-2.consistency05.xb".
|
||||
* Undelegated data:
|
||||
* ns3.addr-match-no-del-undel-2.consistency05.xb
|
||||
* ns4.addr-match-no-del-undel-2.consistency05.xb
|
||||
|
||||
### CHILD-ZONE-LAME-1
|
||||
Lame. No NS responds.
|
||||
|
||||
* Zone: child-zone-lame-1.consistency05.xa
|
||||
* ns1 and ns2 do not respond.
|
||||
|
||||
### CHILD-ZONE-LAME-2
|
||||
Lame. One NS non-AA and one NS SERVFAIL.
|
||||
|
||||
* Zone: child-zone-lame-2.consistency05.xa
|
||||
* ns1 responses with AA bit unset.
|
||||
* ns2 responds with [RCODE Name] "ServFail".
|
||||
|
||||
### IB-ADDR-MISMATCH-1
|
||||
For one NS (in-bailiwick), the addresses in the glue do not match those in the
|
||||
authoritative data from the zone.
|
||||
|
||||
* Zone: ib-addr-mismatch-1.consistency05.xa
|
||||
* ns2 is defined in the zone, but with different addresses (IPv4 and IPv6),
|
||||
i.e. not the same as in glue.
|
||||
* Both ns2 servers (IP address sets from glue and child, respectively) must
|
||||
give identical DNS responses.
|
||||
|
||||
### IB-ADDR-MISMATCH-2
|
||||
For one NS (in-bailiwick), address records exist in the glue, but not in the
|
||||
authoritative data for the zone.
|
||||
|
||||
* Zone: ib-addr-mismatch-2.consistency05.xa
|
||||
* ns2 is not defined in the zone, i.e. there are no address records for ns2
|
||||
(IPv4 or IPv6) in the zone.
|
||||
|
||||
### IB-ADDR-MISMATCH-3
|
||||
For ns2 (in-bailiwick), there is no NS for ns2 and the glue does not match any
|
||||
address records in the zone. Furthermore, ns2 does not respond.
|
||||
|
||||
* Zone: ib-addr-mismatch-3.consistency05.xa
|
||||
* There is no NS record with ns2 in RDATA.
|
||||
* ns2 is not defined in the zone, i.e. there are no address records for ns2
|
||||
(IPv4 or IPv6) in the zone.
|
||||
* ns2 does not respond (but it is in the delegation)
|
||||
|
||||
### IB-ADDR-MISMATCH-4
|
||||
Both NS are in-bailiwick and exist with correct glue in the delegation, but there
|
||||
are no address records in the zone matching the glue records.
|
||||
|
||||
* Zone: ib-addr-mismatch-4.consistency05.xa
|
||||
* Neither ns1 nor ns2 are defined in the zone as address records.
|
||||
* The correct NS records are in the zone.
|
||||
|
||||
### EXTRA-ADDRESS-CHILD
|
||||
Child zone has one extra address record on the NS name.
|
||||
|
||||
* Zone: extra-address-child.consistency05.xa
|
||||
* The zone has address records for ns2 that match glue, but in addition
|
||||
the zone has extra A and AAAA records for ns2.
|
||||
* Both ns2 servers (both sets of IP addresses from child) must give identical
|
||||
DNS responses.
|
||||
|
||||
### OOB-ADDR-MISMATCH
|
||||
For one NS (out-of-bailiwick, but with glue) glue does not match AA address
|
||||
response.
|
||||
|
||||
* Zone: child.oob-addr-mismatch.consistency05.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick
|
||||
* ns1 is "ns1.sibbling.oob-addr-mismatch.consistency05.xa"
|
||||
* ns2 is "ns2.sibbling.oob-addr-mismatch.consistency05.xa"
|
||||
* Delegation is with glue.
|
||||
* The test zone ("child") has no address records for the NS names.
|
||||
* The "sibling" zone has full set of address records
|
||||
* ns1 in the "sibling" zone matches the addresses of glue.
|
||||
* ns2 in the "sibling" zone does not match the addresses of glue.
|
||||
* All IP addresses of ns1 and ns2 must serve identical versions of the zone.
|
||||
|
||||
|
||||
[CONSISTENCY05]: ../../tests/Consistency-TP/consistency05.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../README.md
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
|
||||
@@ -0,0 +1,162 @@
|
||||
# Specification of test zones for CONSISTENCY06
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies defined test zones for test case [CONSISTENCY06].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [CONSISTENCY06] is run on a test zone.
|
||||
The message tags are defined in the test case ([CONSISTENCY06]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test zone README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`consistency06.xa`) and that subdomain having the same name as the
|
||||
scenario. The names of those zones are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:------------------------------|:-------------------------------------|:-------------------------------------------
|
||||
ONE-SOA-MNAME-1 | ONE_SOA_MNAME | NO_RESPONSE, NO_RESPONSE_SOA_QUERY, MULTIPLE_SOA_MNAMES
|
||||
ONE-SOA-MNAME-2 | ONE_SOA_MNAME, NO_RESPONSE | NO_RESPONSE_SOA_QUERY, MULTIPLE_SOA_MNAMES
|
||||
ONE-SOA-MNAME-3 | ONE_SOA_MNAME, NO_RESPONSE_SOA_QUERY | NO_RESPONSE, MULTIPLE_SOA_MNAMES
|
||||
ONE-SOA-MNAME-4 | ONE_SOA_MNAME, NO_RESPONSE | NO_RESPONSE_SOA_QUERY, MULTIPLE_SOA_MNAMES
|
||||
MULTIPLE-SOA-MNAMES-1 | MULTIPLE_SOA_MNAMES | NO_RESPONSE, NO_RESPONSE_SOA_QUERY, ONE_SOA_MNAME
|
||||
MULTIPLE-SOA-MNAMES-2 | MULTIPLE_SOA_MNAMES,NO_RESPONSE | NO_RESPONSE_SOA_QUERY, ONE_SOA_MNAME
|
||||
MULT-SOA-MNAMES-NO-DEL-UNDEL-1 | MULTIPLE_SOA_MNAMES | NO_RESPONSE, NO_RESPONSE_SOA_QUERY, ONE_SOA_MNAME
|
||||
MULT-SOA-MNAMES-NO-DEL-UNDEL-2 | MULTIPLE_SOA_MNAMES | NO_RESPONSE, NO_RESPONSE_SOA_QUERY, ONE_SOA_MNAME
|
||||
NO-RESPONSE | NO_RESPONSE | NO_RESPONSE_SOA_QUERY, MULTIPLE_SOA_MNAMES, ONE_SOA_MNAME
|
||||
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the scenario specifications unless otherwise specified for
|
||||
the specific scenario:
|
||||
* For each scenario zone there are two name servers configured.
|
||||
* Both NS (ns1 and ns2) are equal in delegation and in zone.
|
||||
* Both NS are in-bailiwick
|
||||
* Both NS have both IPv4 and IPv6 addresses
|
||||
* All required glue are present in the delegation.
|
||||
* All NS IP addresses respond with identical zone content.
|
||||
* All queries for SOA are responded with a SOA record in an
|
||||
authoritative answer.
|
||||
* ns1 and ns2 respond with identical SOA records.
|
||||
* All responses, to zone content, are authoritative with
|
||||
[RCODE Name] "NoError"
|
||||
* EDNS, version 0, is included in all responses on queries with EDNS.
|
||||
* EDNS is not included in responses on queries without EDNS.
|
||||
* In undelegated data, `IPv4` and `IPv6`, respectively, are placeholders for the
|
||||
actual IP addresses used for the scenario. They are to be found where the data
|
||||
is specified.
|
||||
* If no placeholder is given with the name server name, then no IP address is
|
||||
given and might be looked up.
|
||||
* The format for undelegated data follow the format used for `zonemaster-cli`
|
||||
(after `--ns`).
|
||||
|
||||
### ONE-SOA-MNAME-1
|
||||
The "happy path". Everything is fine.
|
||||
|
||||
* Zone: one-soa-mname-1.consistency06.xa.
|
||||
|
||||
### ONE-SOA-MNAME-2
|
||||
Not so "happy path". One name server does not respond.
|
||||
|
||||
* Zone: one-soa-mname-2.consistency06.xa.
|
||||
* ns1 gives no response at all.
|
||||
|
||||
### ONE-SOA-MNAME-3
|
||||
Not so "happy path". One name server responds without SOA
|
||||
|
||||
* Zone: one-soa-mname-3.consistency06.xa.
|
||||
* ns1 responds, but with no SOA record in the answer section
|
||||
(maybe answering but not having the zone).
|
||||
|
||||
### ONE-SOA-MNAME-4
|
||||
Not so "happy path". One name server does not respond. That ns is also missing in
|
||||
the zone.
|
||||
|
||||
* Zone: one-soa-mname-4.consistency06.xa.
|
||||
* ns2 gives no response at all.
|
||||
* ns2 is missing in the zone (but available in the delegation)
|
||||
|
||||
### MULTIPLE-SOA-MNAMES-1
|
||||
Different SOA MNAME on the servers
|
||||
|
||||
* Zone: multiple-soa-mnames-1.consistency06.xa.
|
||||
* MNAME in SOA on ns1 equal to ns1
|
||||
* MNAME in SOA on ns2 equal to ns2
|
||||
|
||||
### MULTIPLE-SOA-MNAMES-2
|
||||
Different SOA MNAME on two servers and a third not responding server
|
||||
|
||||
* Zone: multiple-soa-mnames-2.consistency06.xa.
|
||||
* MNAME in SOA on ns1 equal to ns1
|
||||
* MNAME in SOA on ns2 equal to ns2
|
||||
* Also delegated to ns3, for which there is no response.
|
||||
|
||||
### MULT-SOA-MNAMES-NO-DEL-UNDEL-1
|
||||
Zone not delegated, but there is an undelegated version. Different SOA MNAME on
|
||||
the servers.
|
||||
|
||||
* Zone: mult-soa-mnames-no-del-undel-1.consistency06.xa.
|
||||
* MNAME in SOA on ns1 equal to ns1
|
||||
* MNAME in SOA on ns2 equal to ns2
|
||||
* Undelegated data:
|
||||
* ns1.mult-soa-mnames-no-del-undel-1.consistency06.xa/IPv4
|
||||
* ns1.mult-soa-mnames-no-del-undel-1.consistency06.xa/IPv6
|
||||
* ns2.mult-soa-mnames-no-del-undel-1.consistency06.xa/IPv4
|
||||
* ns2.mult-soa-mnames-no-del-undel-1.consistency06.xa/IPv6
|
||||
|
||||
### MULT-SOA-MNAMES-NO-DEL-UNDEL-2
|
||||
Zone not delegated, but there is an undelegated version. Different SOA MNAME on
|
||||
the servers. NS are out-of-bailiwick.
|
||||
|
||||
* Zone: mult-soa-mnames-no-del-undel-2.consistency06.xa.
|
||||
* NS are out-of-bailiwick, "ns3.mult-soa-mnames-no-del-undel-2.consistency06.xb"
|
||||
and "ns4.mult-soa-mnames-no-del-undel-2.consistency06.xb".
|
||||
* MNAME in SOA on ns3 equal to ns3
|
||||
* MNAME in SOA on ns4 equal to ns4
|
||||
* Undelegated data:
|
||||
* ns3.mult-soa-mnames-no-del-undel-2.consistency06.xb
|
||||
* ns4.mult-soa-mnames-no-del-undel-2.consistency06.xb
|
||||
|
||||
### NO-RESPONSE
|
||||
No name server responds.
|
||||
|
||||
* Zone: no-response.consistency06.xa.
|
||||
* ns1 gives no response at all.
|
||||
* ns2 gives no response at all.
|
||||
|
||||
|
||||
[CONSISTENCY06]: ../../tests/Consistency-TP/consistency06.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../README.md
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
# Specification of test scenarios for DNSSEC-TP
|
||||
|
||||
|
||||
Test scenario specifications are available for:
|
||||
|
||||
* [DNSSEC01](dnssec01.md)
|
||||
* [DNSSEC03](dnssec03.md)
|
||||
* [DNSSEC05](dnssec05.md)
|
||||
* [DNSSEC07](dnssec07.md)
|
||||
* [DNSSEC10](dnssec10.md)
|
||||
* [DNSSEC16](dnssec16.md)
|
||||
@@ -0,0 +1,311 @@
|
||||
# Specification of Test Scenarios for DNSSEC01
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test scenarios and setup of test zones]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
|
||||
This document specifies defined test scenarios for test case [DNSSEC01].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [DNSSEC01] is run on a test zone. The
|
||||
message tags are defined in the test case ([DNSSEC01]) and the scenarios are
|
||||
defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone or zones for each test scenario in this document is a subdomain
|
||||
(or lower zone) delegated from the base name (`dnssec01.xa`) and that subdomain
|
||||
having the same name as the scenario. The names of those zones are given in
|
||||
section "[Test scenarios and setup of test zones]" below.
|
||||
|
||||
|
||||
## All message tags
|
||||
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [DNSSEC01] for the specification of the tags.
|
||||
|
||||
* DS01_DS_ALGO_2_MISSING
|
||||
* DS01_DS_ALGO_DEPRECATED
|
||||
* DS01_DS_ALGO_NOT_DS
|
||||
* DS01_DS_ALGO_OK
|
||||
* DS01_DS_ALGO_PRIVATE
|
||||
* DS01_DS_ALGO_RESERVED
|
||||
* DS01_DS_ALGO_UNASSIGNED
|
||||
* DS01_NO_RESPONSE
|
||||
* DS01_PARENT_SERVER_NO_DS
|
||||
* DS01_PARENT_ZONE_NO_DS
|
||||
* DS01_ROOT_N_NO_UNDEL_DS
|
||||
* DS01_UNDEL_N_NO_UNDEL_DS
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
| Scenario name | Mandatory tags | Forbidden tags |
|
||||
|:----------------------|:---------------------------------------------------------------|:---------------|
|
||||
| ALGO-DEPRECATED-1 | DS01_DS_ALGO_DEPRECATED, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-DEPRECATED-3 | DS01_DS_ALGO_DEPRECATED, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-NOT-DS-0 | DS01_DS_ALGO_NOT_DS, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-OK-2 | DS01_DS_ALGO_OK | 2) |
|
||||
| ALGO-OK-4 | DS01_DS_ALGO_OK, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-OK-5 | DS01_DS_ALGO_OK, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-OK-6 | DS01_DS_ALGO_OK, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-PRIVATE-253 | DS01_DS_ALGO_PRIVATE, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-PRIVATE-254 | DS01_DS_ALGO_PRIVATE, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-RESERVED-128 | DS01_DS_ALGO_RESERVED, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-RESERVED-188 | DS01_DS_ALGO_RESERVED, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-RESERVED-252 | DS01_DS_ALGO_RESERVED, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-UNASSIGNED-7 | DS01_DS_ALGO_UNASSIGNED, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-UNASSIGNED-67 | DS01_DS_ALGO_UNASSIGNED, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| ALGO-UNASSIGNED-127 | DS01_DS_ALGO_UNASSIGNED, DS01_DS_ALGO_2_MISSING | 2) |
|
||||
| MIXED-ALGO-1 | DS01_DS_ALGO_DEPRECATED, DS01_DS_ALGO_PRIVATE, DS01_DS_ALGO_OK | 2) |
|
||||
| SHARED-IP-1 | DS01_DS_ALGO_OK | 2) |
|
||||
| SHARED-IP-2 | DS01_DS_ALGO_OK | 2) |
|
||||
| NO-RESPONSE-1 | DS01_NO_RESPONSE | 2) |
|
||||
| NO-VALID-RESPONSE-1 | DS01_NO_RESPONSE | 2) |
|
||||
| PARENT-SERVER-NO-DS-1 | DS01_PARENT_SERVER_NO_DS, DS01_DS_ALGO_OK | 2) |
|
||||
| PARENT-ZONE-NO-DS-1 | DS01_PARENT_ZONE_NO_DS | 2) |
|
||||
| UNDEL-NO-UNDEL-DS-1 | DS01_UNDEL_N_NO_UNDEL_DS | 2) |
|
||||
| UNDEL-WITH-UNDEL-DS-1 | DS01_DS_ALGO_OK | 2) |
|
||||
| ROOT-NO-UNDEL-DS-1 | DS01_ROOT_N_NO_UNDEL_DS | 2) |
|
||||
| ROOT-WITH-UNDEL-DS-1 | DS01_DS_ALGO_OK | 2) |
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory tags"
|
||||
|
||||
## Test scenarios and setup of test zones
|
||||
|
||||
### Default zone configuration
|
||||
Unless otherwise specified in the specific scenario specification, the test zone
|
||||
or zones for the scenario will follow the default setup as stated below. The
|
||||
`child zone` is the zone to be tested for the scenario.
|
||||
|
||||
* The child zone is `SCENARIO.dnssec01.xa`.
|
||||
* It is delegated to two name servers, `ns1.SCENARIO.dnssec01.xa`
|
||||
and `ns2.SCENARIO.dnssec01.xa`.
|
||||
* The name server names have A and AAAA records to avoid non-relevant error
|
||||
messages.
|
||||
* The delegation of the child zone is to an OOB NS.
|
||||
* NS can be resolved through the `dnssec01.xa` zone.
|
||||
* There is a zone file for the child zone.
|
||||
* All child zone servers give the same response.
|
||||
* The only responses that can be assumed are queries for
|
||||
* NS
|
||||
* SOA
|
||||
* The parent zone will respond with one DS record per child zone.
|
||||
* The parent zone is `dnssec01.xa`.
|
||||
* It is served by two in-bailiwick NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* All responses will have the AA bit set.
|
||||
* All responses will have the [RCODE Name] "NoError".
|
||||
* The DS digest algorithm is 2 unless specified for the scenario.
|
||||
* The DS record can be technically invalid. Only the format is valid and
|
||||
only the digest algorithm value is checked.
|
||||
* The zone is not signed.
|
||||
|
||||
### ALGO-DEPRECATED-1
|
||||
The DS digest algorithm number is 1
|
||||
|
||||
* Zone: algo-deprecated-1.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 1.
|
||||
|
||||
### ALGO-DEPRECATED-3
|
||||
The DS digest algorithm number is 3
|
||||
|
||||
* Zone: algo-deprecated-3.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 3.
|
||||
|
||||
### ALGO-RESERVED-128
|
||||
The DS digest algorithm number is 128
|
||||
|
||||
* Zone: algo-reserved-128.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 128.
|
||||
|
||||
### ALGO-RESERVED-188
|
||||
The DS digest algorithm number is 188
|
||||
|
||||
* Zone: algo-reserved-188.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 188.
|
||||
|
||||
### ALGO-RESERVED-252
|
||||
The DS digest algorithm number is 252
|
||||
|
||||
* Zone: algo-reserved-252.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 252.
|
||||
|
||||
### ALGO-UNASSIGNED-7
|
||||
The DS digest algorithm number is 7
|
||||
|
||||
* Zone: algo-unassigned-7.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 7.
|
||||
|
||||
### ALGO-UNASSIGNED-67
|
||||
The DS digest algorithm number is 67
|
||||
|
||||
* Zone: algo-unassigned-67.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 67.
|
||||
|
||||
### ALGO-UNASSIGNED-127
|
||||
The DS digest algorithm number is 127
|
||||
|
||||
* Zone: algo-unassigned-127.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 127.
|
||||
|
||||
### ALGO-PRIVATE-253
|
||||
The DS digest algorithm number is 253
|
||||
|
||||
* Zone: algo-private-253.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 253.
|
||||
|
||||
### ALGO-PRIVATE-254
|
||||
The DS digest algorithm number is 254
|
||||
|
||||
* Zone: algo-private-254.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 254.
|
||||
|
||||
### ALGO-NOT-DS-0
|
||||
The DS digest algorithm number is 0
|
||||
|
||||
* Zone: algo-not-ds-0.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 0.
|
||||
|
||||
### ALGO-OK-2
|
||||
The DS digest algorithm number is 2
|
||||
|
||||
* Zone: algo-ok-2.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 2.
|
||||
|
||||
### ALGO-OK-4
|
||||
The DS digest algorithm number is 4
|
||||
|
||||
* Zone: algo-ok-4.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 4.
|
||||
|
||||
### ALGO-OK-5
|
||||
The DS digest algorithm number is 5
|
||||
|
||||
* Zone: algo-ok-5.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 5.
|
||||
|
||||
### ALGO-OK-6
|
||||
The DS digest algorithm number is 6
|
||||
|
||||
* Zone: algo-ok-6.dnssec01.xa.
|
||||
* The algorithm of the DS digest in the response is 6.
|
||||
|
||||
### MIXED-ALGO-1
|
||||
Three DS with different algorithms.
|
||||
|
||||
* Zone: mixed-algo-1.dnssec01.xa.
|
||||
* The response has three DS with different algorithms:
|
||||
* 1
|
||||
* 2
|
||||
* 253
|
||||
|
||||
### SHARED-IP-1
|
||||
Two parent name servers resolv to the same IP address.
|
||||
|
||||
* Zone: child.shared-ip-1.dnssec01.xa.
|
||||
* The parent zone is "shared-ip-1.dnssec01.xa" and the grandparent zone is
|
||||
"dnssec01.xa".
|
||||
* The parent is delegated to IB ns1a and ns1b with the same IPv4 and IPv6
|
||||
addresses.
|
||||
|
||||
### SHARED-IP-2
|
||||
Delegation of parent does not use the same name server name as parent zone.
|
||||
|
||||
* Zone: child.shared-ip-2.dnssec01.xa.
|
||||
* The parent zone is "shared-ip-2.dnssec01.xa" and the grandparent zone is
|
||||
"dnssec01.xa".
|
||||
* The parent is delegated to IB ns1 and ns2, but in the parent zone the names
|
||||
are dns1 and dns2.
|
||||
* ns1 and dns1 resolve to the same IP addresses.
|
||||
* ns2 and dns2 resolve to the same IP addresses.
|
||||
|
||||
### NO-RESPONSE-1
|
||||
No response from any of the servers on the DS query.
|
||||
|
||||
* Zone: child.no-response-1.dnssec01.xa.
|
||||
* No response at all from parent ns1 and ns2.
|
||||
|
||||
### NO-VALID-RESPONSE-1
|
||||
No valid response from any of the servers on the DS query.
|
||||
|
||||
* Zone: child.no-valid-response-1.dnssec01.xa.
|
||||
* Response from parent ns1 has RCODE SERVFAIL.
|
||||
* Response from parent ns2 has RCODE REFUSED.
|
||||
* Child zone does not exist
|
||||
|
||||
### PARENT-SERVER-NO-DS-1
|
||||
No DS from parent ns1.
|
||||
|
||||
* Zone: child.parent-server-no-ds-1.dnssec01.xa.
|
||||
* Response from parent ns1 is NODATA (no DS).
|
||||
* Response from parent ns2 is normal.
|
||||
|
||||
### PARENT-ZONE-NO-DS-1
|
||||
No DS from neither parent ns1 nor parent ns2.
|
||||
|
||||
* Zone: parent-zone-no-ds-1.dnssec01.xa.
|
||||
* Responses from parent ns1 and parent ns2 are NODATA (no DS).
|
||||
|
||||
### UNDEL-NO-UNDEL-DS-1
|
||||
Zone is not delegated, but undelegated data is provided. No DS.
|
||||
|
||||
* Zone: undel-no-undel-ds-1.dnssec01.xa.
|
||||
* The zone is not delegated, but there is undelegated data.
|
||||
* ns1 and ns2 are OOB.
|
||||
* No undelegated DS is provided.
|
||||
|
||||
### UNDEL-WITH-UNDEL-DS-1
|
||||
Zone is not delegated, but undelegated data is provided with DS.
|
||||
|
||||
* Zone: undel-with-undel-ds-1.dnssec01.xa.
|
||||
* The zone is not delegated, but there is undelegated data.
|
||||
* ns1 and ns2 are OOB.
|
||||
* Undelegated DS is provided.
|
||||
|
||||
### ROOT-NO-UNDEL-DS-1
|
||||
Zone is the root zone, and no undelegated DS is provided.
|
||||
|
||||
* Zone: "."
|
||||
* ns1 and ns2 are IB.
|
||||
* The zone exists.
|
||||
|
||||
### ROOT-WITH-UNDEL-DS-1
|
||||
Zone is the root zone, and undelegated DS is provided.
|
||||
|
||||
* Zone: "."
|
||||
* ns1 and ns2 are IB.
|
||||
* The zone exists.
|
||||
|
||||
|
||||
[DNSSEC01]: ../../tests/DNSSEC-TP/dnssec01.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test scenario README file]: ../README.md
|
||||
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
|
||||
@@ -0,0 +1,197 @@
|
||||
# Specification of test zones for DNSSEC03
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
* [Terminology](#terminology)
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
|
||||
This document specifies defined test zones for test case [DNSSEC03].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [DNSSEC03] is run on a test zone. The
|
||||
message tags are defined in the test case ([DNSSEC03]) and the scenarios are
|
||||
defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test zone README file].
|
||||
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`dnssec03.xa`) and that subdomain having the same name as the
|
||||
scenario except where the test domain must be the root zone, a TLD or a domain
|
||||
under `.arpa`. The names of those zones are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
|
||||
|
||||
Scenario name | Mandatory message tags | Forbidden message tags
|
||||
:----------------------------|:--------------------------------------------------|:-------------------------------------------
|
||||
NO-DNSSEC-SUPPORT | DS03_NO_DNSSEC_SUPPORT | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
NO-NSEC3 | DS03_NO_NSEC3 | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NO_DNSSEC_SUPPORT, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
GOOD-VALUES | DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
ERR-MULT-NSEC3 | DS03_ERR_MULT_NSEC3, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
BAD-VALUES | DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD | DS03_ERR_MULT_NSEC3, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
INCONSISTENT-VALUES | DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD | DS03_ERR_MULT_NSEC3, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
NSEC3-OPT-OUT-ENABLED-TLD | DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
SERVER-NO-DNSSEC-SUPPORT | DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
SERVER-NO-NSEC3 | DS03_SERVER_NO_NSEC3, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
UNASSIGNED-FLAG-USED | DS03_UNASSIGNED_FLAG_USED, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
ERROR-RESPONSE-NSEC-QUERY | DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED, DS03_ERROR_RESPONSE_NSEC_QUERY | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_NO_RESPONSE_NSEC_QUERY
|
||||
NO-RESPONSE-NSEC-QUERY | DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NO_RESPONSE_NSEC_QUERY | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED, DS03_ERROR_RESPONSE_NSEC_QUERY
|
||||
ERROR-NSEC-QUERY | DS03_ERROR_RESPONSE_NSEC_QUERY, DS03_NO_RESPONSE_NSEC_QUERY | DS03_ERR_MULT_NSEC3, DS03_ILLEGAL_HASH_ALGO, DS03_ILLEGAL_ITERATION_VALUE, DS03_ILLEGAL_SALT_LENGTH, DS03_INCONSISTENT_HASH_ALGO, DS03_INCONSISTENT_ITERATION, DS03_INCONSISTENT_NSEC3_FLAGS, DS03_INCONSISTENT_SALT_LENGTH, DS03_LEGAL_EMPTY_SALT, DS03_LEGAL_HASH_ALGO, DS03_LEGAL_ITERATION_VALUE, DS03_NO_DNSSEC_SUPPORT, DS03_NO_NSEC3, DS03_NSEC3_OPT_OUT_DISABLED, DS03_NSEC3_OPT_OUT_ENABLED_NON_TLD, DS03_NSEC3_OPT_OUT_ENABLED_TLD, DS03_SERVER_NO_DNSSEC_SUPPORT, DS03_SERVER_NO_NSEC3, DS03_UNASSIGNED_FLAG_USED
|
||||
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the scenario specifications, unless stated otherwise for the
|
||||
specific scenario:
|
||||
1. Each zone is hosted by two NS, ns1 and ns2.
|
||||
2. Both ns have equal hosting.
|
||||
3. NS in delegation is equal to NS in zone.
|
||||
4. All responses are authoritative.
|
||||
5. RRSIG in responses are disregarded.
|
||||
6. The actual owner name of the NSEC3 record will not be verified.
|
||||
7. The record type list of the NSEC3 record will not be verified.
|
||||
8. The zone is to respond with one SOA record with the zone name as owner name
|
||||
on SOA query.
|
||||
9. The zone is to respond with one DNSKEY record with the zone name as owner
|
||||
name on DNSKEY query.
|
||||
10. The zone is to respond with one NSEC3 record with a hash owner name in
|
||||
authority section on NSEC query (note, NSEC not NSEC3). NODATA response.
|
||||
11. The NSEC3 record is to have the following settings:
|
||||
* Hash algo = 1
|
||||
* Flags = 0
|
||||
* Iteration = 0
|
||||
* Salt = "-" (no salt)
|
||||
|
||||
### NO-DNSSEC-SUPPORT
|
||||
No DNSSEC support in the zone.
|
||||
|
||||
* Zone: "no-dnssec-support.dnssec03.xa."
|
||||
* No DNSKEY in query for DNSKEY (9).
|
||||
|
||||
### NO-NSEC3
|
||||
No NSEC3 support in the zone.
|
||||
|
||||
* Zone: "no-nsec3.dnssec03.xa."
|
||||
* No NSEC3 in query for NSEC (10).
|
||||
|
||||
### GOOD-VALUES
|
||||
Happy path
|
||||
|
||||
* Zone: "good-values.dnssec03.xa."
|
||||
|
||||
### ERR-MULT-NSEC3
|
||||
Strange response with two NSEC3 records.
|
||||
|
||||
* Zone: "err-mult-nsec3.dnssec03.xa."
|
||||
* Two NSEC3 records, with different hash owner name are to be included in the
|
||||
response. RDATA can be identical. (10)
|
||||
|
||||
### BAD-VALUES
|
||||
The NSEC3 record has values no permitted by RFC 9276, see the specification of
|
||||
test case [DNSSEC03].
|
||||
|
||||
* Zone: "bad-values.dnssec03.xa."
|
||||
* The following values in NSEC3 (11):
|
||||
* Hash algo = 2
|
||||
* Flags = 1
|
||||
* Iteration = 1
|
||||
* Salt = "8104"
|
||||
|
||||
### INCONSISTENT-VALUES
|
||||
The NSEC3 records returned from the two NS are not equal.
|
||||
|
||||
* Zone: "inconsistent-values.dnssec03.xa."
|
||||
* Both NS give the same owner name of the NSEC3 record, but
|
||||
ns1 gives standard values, whereas ns2 responds with an NSEC3 record with
|
||||
the following values: (2, 11)
|
||||
* Hash algo = 2
|
||||
* Flags = 1
|
||||
* Iteration = 1
|
||||
* Salt = "8104"
|
||||
|
||||
### NSEC3-OPT-OUT-ENABLED-TLD
|
||||
On a TLD, opt-out just gives an INFO message.
|
||||
|
||||
* Zone: "nsec3-opt-out-enabled-tld-dnssec03." (TLD)
|
||||
* NSEC3 record with the following value: (11)
|
||||
* Flags = 1
|
||||
|
||||
### SERVER-NO-DNSSEC-SUPPORT
|
||||
One NS of two does not support DNSSEC (no DNSKEY)
|
||||
|
||||
* Zone: "server-no-dnssec-support.dnssec03.xa"
|
||||
* ns2 does not return any DNSKEY record on DNSKEY query (2, 9)
|
||||
|
||||
### SERVER-NO-NSEC3
|
||||
One NS of two does not have NSEC3
|
||||
|
||||
* Zone: "server-no-nsec3.dnssec03.xa"
|
||||
* ns2 does not return any NSEC3 record on NSEC query (2, 10)
|
||||
|
||||
### UNASSIGNED-FLAG-USED
|
||||
Unassigned flag used.
|
||||
|
||||
* Zone: "unassigned-flag-used.dnssec03.xa"
|
||||
* NSEC3 record with the following value: (11)
|
||||
* Flags = 2
|
||||
|
||||
### ERROR-RESPONSE-NSEC-QUERY
|
||||
Error in response from one NS on NSEC query.
|
||||
|
||||
* Zone: "error-response-nsec-query.dnssec03.xa"
|
||||
* Normal response on DNSKEY query from ns1.
|
||||
* RCODE name SERVFAIL on NSEC query from ns1.
|
||||
* Normal responses from ns2.
|
||||
|
||||
|
||||
### NO-RESPONSE-NSEC-QUERY
|
||||
No response from one NS on NSEC query.
|
||||
|
||||
* Zone: "no-response-nsec-query.dnssec03.xa"
|
||||
* Normal responses from ns1.
|
||||
* Normal response on DNSKEY query from ns2.
|
||||
* No response on NSEC query from ns2.
|
||||
|
||||
### ERROR-NSEC-QUERY
|
||||
No response and error in response on NSEC query, respectively, from two NS.
|
||||
|
||||
* Zone: "error-nsec-query.dnssec03.xa"
|
||||
* Normal response on DNSKEY query from ns1 and ns2.
|
||||
* RCODE name SERVFAIL on NSEC query from ns1.
|
||||
* No response on NSEC query from ns2.
|
||||
|
||||
|
||||
|
||||
[DNSSEC03]: ../../tests/DNSSEC-TP/dnssec03.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../README.md
|
||||
[Well Formed CDS Record]: #terminology
|
||||
[Well Formed DNSKEY Record]: #terminology
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
|
||||
@@ -0,0 +1,350 @@
|
||||
# Specification of Test Scenarios for DNSSEC05
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test scenarios and setup of test zones]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
|
||||
This document specifies defined test scenarios for test case [DNSSEC05].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [DNSSEC05] is run on a test zone. The
|
||||
message tags are defined in the test case ([DNSSEC05]) and the scenarios are
|
||||
defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone or zones for each test scenario in this document is a subdomain
|
||||
(or lower zone) delegated from the base name (`dnssec05.xa`) and that subdomain
|
||||
having the same name as the scenario. The names of those zones are given in
|
||||
section "[Test scenarios and setup of test zones]" below.
|
||||
|
||||
|
||||
## All message tags
|
||||
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [DNSSEC05] for the specification of the tags.
|
||||
|
||||
* DS05_ALGO_DEPRECATED
|
||||
* DS05_ALGO_NOT_RECOMMENDED
|
||||
* DS05_ALGO_NOT_ZONE_SIGN
|
||||
* DS05_ALGO_OK
|
||||
* DS05_ALGO_PRIVATE
|
||||
* DS05_ALGO_RESERVED
|
||||
* DS05_ALGO_UNASSIGNED
|
||||
* DS05_NO_RESPONSE
|
||||
* DS05_SERVER_NO_DNSSEC
|
||||
* DS05_ZONE_NO_DNSSEC
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
| Scenario name | Mandatory message tags | Forbidden message tags |
|
||||
|:------------------------|:--------------------------------------------------------------|:-----------------------|
|
||||
| ALGO-DEPRECATED-1 | DS05_ALGO_DEPRECATED | 2) |
|
||||
| ALGO-DEPRECATED-3 | DS05_ALGO_DEPRECATED | 2) |
|
||||
| ALGO-DEPRECATED-5 | DS05_ALGO_DEPRECATED | 2) |
|
||||
| ALGO-DEPRECATED-6 | DS05_ALGO_DEPRECATED | 2) |
|
||||
| ALGO-DEPRECATED-7 | DS05_ALGO_DEPRECATED | 2) |
|
||||
| ALGO-DEPRECATED-12 | DS05_ALGO_DEPRECATED | 2) |
|
||||
| ALGO-NOT-RECOMMENDED-10 | DS05_ALGO_NOT_RECOMMENDED | 2) |
|
||||
| ALGO-NOT-ZONE-SIGN-0 | DS05_ALGO_NOT_ZONE_SIGN | 2) |
|
||||
| ALGO-NOT-ZONE-SIGN-2 | DS05_ALGO_NOT_ZONE_SIGN | 2) |
|
||||
| ALGO-NOT-ZONE-SIGN-252 | DS05_ALGO_NOT_ZONE_SIGN | 2) |
|
||||
| ALGO-OK-8 | DS05_ALGO_OK | 2) |
|
||||
| ALGO-OK-13 | DS05_ALGO_OK | 2) |
|
||||
| ALGO-OK-14 | DS05_ALGO_OK | 2) |
|
||||
| ALGO-OK-15 | DS05_ALGO_OK | 2) |
|
||||
| ALGO-OK-16 | DS05_ALGO_OK | 2) |
|
||||
| ALGO-OK-17 | DS05_ALGO_OK | 2) |
|
||||
| ALGO-OK-23 | DS05_ALGO_OK | 2) |
|
||||
| ALGO-PRIVATE-253 | DS05_ALGO_PRIVATE | 2) |
|
||||
| ALGO-PRIVATE-254 | DS05_ALGO_PRIVATE | 2) |
|
||||
| ALGO-RESERVED-4 | DS05_ALGO_RESERVED | 2) |
|
||||
| ALGO-RESERVED-9 | DS05_ALGO_RESERVED | 2) |
|
||||
| ALGO-RESERVED-11 | DS05_ALGO_RESERVED | 2) |
|
||||
| ALGO-RESERVED-123 | DS05_ALGO_RESERVED | 2) |
|
||||
| ALGO-RESERVED-251 | DS05_ALGO_RESERVED | 2) |
|
||||
| ALGO-RESERVED-255 | DS05_ALGO_RESERVED | 2) |
|
||||
| ALGO-UNASSIGNED-20 | DS05_ALGO_UNASSIGNED | 2) |
|
||||
| ALGO-UNASSIGNED-122 | DS05_ALGO_UNASSIGNED | 2) |
|
||||
| MIXED-ALGO-1 | DS05_ALGO_DEPRECATED, DS05_ALGO_NOT_RECOMMENDED, DS05_ALGO_OK | 2) |
|
||||
| NO-RESPONSE-1 | DS05_NO_RESPONSE | 2) |
|
||||
| NO-RESPONSE-2 | DS05_NO_RESPONSE | 2) |
|
||||
| SERVER-NO-DNSSEC-1 | DS05_SERVER_NO_DNSSEC, DS05_ALGO_OK | 2) |
|
||||
| SHARED-IP-1 | DS05_ALGO_OK | 2) |
|
||||
| ZONE-NO-DNSSEC-1 | DS05_ZONE_NO_DNSSEC | 2) |
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
|
||||
## Test scenarios and setup of test zones
|
||||
|
||||
### Default zone configuration
|
||||
Unless otherwise specified in the specific scenario specification, the test zone
|
||||
or zones for the scenario will follow the default setup as stated below. The
|
||||
`child zone` is the zone to be tested for the scenario.
|
||||
|
||||
* The child zone is `SCENARIO.dnssec05.xa`.
|
||||
* It is delegated to two name servers, `ns1.SCENARIO.dnssec05.xa`
|
||||
and `ns2.SCENARIO.dnssec05.xa`.
|
||||
* The name server names have A and AAAA records to avoid non-relevant error
|
||||
messages.
|
||||
* The delegation of the child zone is to an OOB NS.
|
||||
* NS can be resolved through the `dnssec05.xa` zone.
|
||||
* There is a zone file for the child zone.
|
||||
* All child zone servers give the same response.
|
||||
* The only responses that can be assumed are queries for
|
||||
* DNSKEY
|
||||
* NS
|
||||
* SOA
|
||||
* The zone will respond with one DNSKEY record.
|
||||
* The parent zone is `dnssec05.xa`.
|
||||
* It is served by two in-bailiwick NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* All responses will have the AA bit set.
|
||||
* All responses will have the [RCODE Name] "NoError".
|
||||
* The DNSKEY algorithm is 13 unless specified for the scenario.
|
||||
* The DNSKEY record can be technically invalid. Only the format is valid and
|
||||
only the algorithm value is checked.
|
||||
* The zone is not signed.
|
||||
|
||||
### ALGO-DEPRECATED-1
|
||||
The DNSKEY algo is 1
|
||||
|
||||
* Zone: "algo-deprecated-1.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 1.
|
||||
|
||||
### ALGO-DEPRECATED-3
|
||||
The DNSKEY algo is 3
|
||||
|
||||
* Zone: "algo-deprecated-3.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 3.
|
||||
|
||||
### ALGO-DEPRECATED-5
|
||||
The DNSKEY algo is 5
|
||||
|
||||
* Zone: "algo-deprecated-5.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 5.
|
||||
|
||||
### ALGO-DEPRECATED-6
|
||||
The DNSKEY algo is 6
|
||||
|
||||
* Zone: "algo-deprecated-6.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 6.
|
||||
|
||||
### ALGO-DEPRECATED-7
|
||||
The DNSKEY algo is 7
|
||||
|
||||
* Zone: "algo-deprecated-7.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 7.
|
||||
|
||||
### ALGO-DEPRECATED-12
|
||||
The DNSKEY algo is 12
|
||||
|
||||
* Zone: "algo-deprecated-12.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 12.
|
||||
|
||||
### ALGO-RESERVED-4
|
||||
The DNSKEY algo is 4
|
||||
|
||||
* Zone: "algo-reserved-4.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 4.
|
||||
|
||||
### ALGO-RESERVED-9
|
||||
The DNSKEY algo is 9
|
||||
|
||||
* Zone: "algo-reserved-9.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 9.
|
||||
|
||||
### ALGO-RESERVED-11
|
||||
The DNSKEY algo is 11
|
||||
|
||||
* Zone: "algo-reserved-11.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 11.
|
||||
|
||||
### ALGO-RESERVED-123
|
||||
The DNSKEY algo is 123
|
||||
|
||||
* Zone: "algo-reserved-123.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 123.
|
||||
|
||||
### ALGO-RESERVED-251
|
||||
The DNSKEY algo is 251
|
||||
|
||||
* Zone: "algo-reserved-251.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 251.
|
||||
|
||||
### ALGO-RESERVED-255
|
||||
The DNSKEY algo is 255
|
||||
|
||||
* Zone: "algo-reserved-255.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 255.
|
||||
|
||||
### ALGO-UNASSIGNED-20
|
||||
The DNSKEY algo is 20
|
||||
|
||||
* Zone: "algo-unassigned-17.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 17.
|
||||
|
||||
### ALGO-UNASSIGNED-122
|
||||
The DNSKEY algo is 122
|
||||
|
||||
* Zone: "algo-unassigned-122.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 122.
|
||||
|
||||
### ALGO-PRIVATE-253
|
||||
The DNSKEY algo is 253
|
||||
|
||||
* Zone: "algo-private-253.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 253.
|
||||
|
||||
### ALGO-PRIVATE-254
|
||||
The DNSKEY algo is 254
|
||||
|
||||
* Zone: "algo-private-254.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 254.
|
||||
|
||||
### ALGO-NOT-ZONE-SIGN-0
|
||||
The DNSKEY algo is 0
|
||||
|
||||
* Zone: "algo-not-zone-sign-0.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 0.
|
||||
|
||||
### ALGO-NOT-ZONE-SIGN-2
|
||||
The DNSKEY algo is 2
|
||||
|
||||
* Zone: "algo-not-zone-sign-2.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 2.
|
||||
|
||||
### ALGO-NOT-ZONE-SIGN-252
|
||||
The DNSKEY algo is 252
|
||||
|
||||
* Zone: "algo-not-zone-sign-252.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 252.
|
||||
|
||||
### ALGO-NOT-RECOMMENDED-10
|
||||
The DNSKEY algo is 10
|
||||
|
||||
* Zone: "algo-not-recommended-10.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 10.
|
||||
|
||||
### ALGO-OK-8
|
||||
The DNSKEY algo is 8
|
||||
|
||||
* Zone: "algo-ok-8.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 8.
|
||||
|
||||
### ALGO-OK-13
|
||||
The DNSKEY algo is 13
|
||||
|
||||
* Zone: "algo-ok-13.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 13.
|
||||
|
||||
### ALGO-OK-14
|
||||
The DNSKEY algo is 14
|
||||
|
||||
* Zone: "algo-ok-14.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 14.
|
||||
|
||||
### ALGO-OK-15
|
||||
The DNSKEY algo is 15
|
||||
|
||||
* Zone: "algo-ok-15.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 15.
|
||||
|
||||
### ALGO-OK-16
|
||||
The DNSKEY algo is 16
|
||||
|
||||
* Zone: "algo-ok-16.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 16.
|
||||
|
||||
### ALGO-OK-17
|
||||
The DNSKEY algo is 17
|
||||
|
||||
* Zone: "algorithm-ok-17.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 17.
|
||||
|
||||
### ALGO-OK-23
|
||||
The DNSKEY algo is 23
|
||||
|
||||
* Zone: "algorithm-ok-23.dnssec05.xa."
|
||||
* The algorithm of the DNSKEY in the response is 23.
|
||||
|
||||
## MIXED-ALGO-1
|
||||
Three DNSKEY with different algorithms.
|
||||
|
||||
* Zone: "mixed-algo-1.dnssec05.xa."
|
||||
* The response has three DNSKEY with different algorithms:
|
||||
* 7
|
||||
* 10
|
||||
* 13
|
||||
|
||||
### NO-RESPONSE-1
|
||||
No valid response from any of the servers.
|
||||
|
||||
* Zone: "no-response-1.dnssec05.xa."
|
||||
* No response at all from ns1.
|
||||
* Response from ns2 does not have the AA bit set.
|
||||
|
||||
### NO-RESPONSE-2
|
||||
No valid response from any of the servers.
|
||||
|
||||
* Zone: "no-response-2.dnssec05.xa."
|
||||
* Response from ns1 has RCODE SERVFAIL.
|
||||
* Response from ns2 has RCODE REFUSED.
|
||||
|
||||
### SERVER-NO-DNSSEC-1
|
||||
No DNSKEY from ns1.
|
||||
|
||||
* Zone: "server-no-dnssec-1.dnssec05.xa."
|
||||
* Response from ns1 is NODATA (no DNSKEY).
|
||||
* Response from ns2 is normal.
|
||||
|
||||
### SHARED-IP-1
|
||||
Two NS names, but only one IP. IPv4 only.
|
||||
|
||||
* Zone: "shared-ip-1.dnssec05.xa."
|
||||
* ns1a and ns1b are in bailiwick, but use the same IP.
|
||||
* IPv4 only.
|
||||
* The message should list both name server names, both with the same IP.
|
||||
|
||||
### ZONE-NO-DNSSEC-1
|
||||
No DNSKEY from neither ns1 nor ns2.
|
||||
|
||||
* Zone: "zone-no-dnssec-1.dnssec05.xa."
|
||||
* Responses from ns1 and ns2 are NODATA (no DNSKEY).
|
||||
|
||||
|
||||
[DNSSEC05]: ../../tests/DNSSEC-TP/dnssec05.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test scenario README file]: ../README.md
|
||||
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
|
||||
@@ -0,0 +1,204 @@
|
||||
# Specification of Test Scenarios for DNSSEC07
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test scenarios and setup of test zones]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
|
||||
This document specifies defined test scenarios for test case [DNSSEC07].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [DNSSEC07] is run on a test zone. The
|
||||
message tags are defined in the test case ([DNSSEC07]) and the scenarios are
|
||||
defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone or zones for each test scenario in this document is a subdomain
|
||||
(or lower zone) delegated from the base name (`dnssec07.xa`) and that subdomain
|
||||
having the same name as the scenario. The names of those zones are given in
|
||||
section "[Test scenarios and setup of test zones]" below.
|
||||
|
||||
|
||||
## All message tags
|
||||
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [DNSSEC07] for the specification of the tags.
|
||||
|
||||
* DS07_DS_FOR_SIGNED_ZONE
|
||||
* DS07_DS_ON_PARENT_SERVER
|
||||
* DS07_INCONSISTENT_DS
|
||||
* DS07_INCONSISTENT_SIGNED
|
||||
* DS07_NON_AUTH_RESPONSE_DNSKEY
|
||||
* DS07_NOT_SIGNED
|
||||
* DS07_NOT_SIGNED_ON_SERVER
|
||||
* DS07_NO_DS_ON_PARENT_SERVER
|
||||
* DS07_NO_DS_FOR_SIGNED_ZONE
|
||||
* DS07_NO_RESPONSE_DNSKEY
|
||||
* DS07_SIGNED
|
||||
* DS07_SIGNED_ON_SERVER
|
||||
* DS07_UNEXP_RCODE_RESP_DNSKEY
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
| Scenario name | Mandatory tags | Forbidden tags |
|
||||
|:---------------------------|:---------------------------------------------------------------------------------------------------------------------|:---------------|
|
||||
| SIGNED-AND-DS-1 | DS07_DS_FOR_SIGNED_ZONE, DS07_DS_ON_PARENT_SERVER, DS07_SIGNED, DS07_SIGNED_ON_SERVER | 2) |
|
||||
| SIGNED-NO-DS-1 | DS07_NO_DS_ON_PARENT_SERVER, DS07_NO_DS_FOR_SIGNED_ZONE, DS07_SIGNED, DS07_SIGNED_ON_SERVER | 2) |
|
||||
| INCONSIST-SIGNED-AND-DS-1 | DS07_DS_ON_PARENT_SERVER, DS07_INCONSISTENT_SIGNED, DS07_NOT_SIGNED_ON_SERVER, DS07_SIGNED_ON_SERVER | 2) |
|
||||
| INCONSIST-SIGNED-NO-DS-1 | DS07_INCONSISTENT_SIGNED, DS07_NOT_SIGNED_ON_SERVER, DS07_NO_DS_ON_PARENT_SERVER, DS07_SIGNED_ON_SERVER | 2) |
|
||||
| SIGNED-AND-INCONSIST-DS-1 | DS07_DS_ON_PARENT_SERVER, DS07_INCONSISTENT_DS, DS07_NO_DS_ON_PARENT_SERVER, DS07_SIGNED, DS07_SIGNED_ON_SERVER | 2) |
|
||||
| UNSIGNED-AND-DS-1 | DS07_NOT_SIGNED, DS07_NOT_SIGNED_ON_SERVER | 2) |
|
||||
| UNSIGNED-NO-DS-1 | DS07_NOT_SIGNED, DS07_NOT_SIGNED_ON_SERVER | 2) |
|
||||
| NON-AUTH-RESPONSE-DNSKEY-1 | DS07_NON_AUTH_RESPONSE_DNSKEY, DS07_SIGNED, DS07_SIGNED_ON_SERVER, DS07_DS_ON_PARENT_SERVER, DS07_DS_FOR_SIGNED_ZONE | 2) |
|
||||
| NO-RESPONSE-DNSKEY-1 | DS07_SIGNED, DS07_SIGNED_ON_SERVER, DS07_NO_RESPONSE_DNSKEY, DS07_DS_ON_PARENT_SERVER, DS07_DS_FOR_SIGNED_ZONE | 2) |
|
||||
| UNEXP-RCODE-RESP-DNSKEY-1 | DS07_SIGNED, DS07_SIGNED_ON_SERVER, DS07_UNEXP_RCODE_RESP_DNSKEY, DS07_DS_ON_PARENT_SERVER, DS07_DS_FOR_SIGNED_ZONE | 2) |
|
||||
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory tags"
|
||||
|
||||
## Test scenarios and setup of test zones
|
||||
|
||||
### Default zone configuration
|
||||
Unless otherwise specified in the specific scenario specification, the test zone
|
||||
or zones for the scenario will follow the default setup as stated below. The
|
||||
`child zone` is the zone to be tested for the scenario.
|
||||
|
||||
* The child zone is `SCENARIO.dnssec07.xa`.
|
||||
* It is delegated to two name servers, `ns1.SCENARIO.dnssec07.xa`
|
||||
and `ns2.SCENARIO.dnssec07.xa`.
|
||||
* The name server names have A and AAAA records to avoid non-relevant error
|
||||
messages.
|
||||
* The delegation of the child zone is to an IB NS.
|
||||
* There is a zone file for the child zone.
|
||||
* All child zone servers give the same response.
|
||||
* The only responses, with data queried for, to the child zone that can be assumed are queries for
|
||||
* NS
|
||||
* SOA
|
||||
* DNSKEY
|
||||
* Response on DNSKEY query will include RRSIG, others will not.
|
||||
* The parent zone is `dnssec07.xa`.
|
||||
* It is served by two in-bailiwick NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* The parent zone will respond with one DS record per child zone.
|
||||
* The only responses to the parent zone that can be assumed are queries for
|
||||
* NS
|
||||
* SOA
|
||||
* DNSKEY
|
||||
* delegation of the child
|
||||
* DS for child
|
||||
* Response on DS query will include RRSIG, others will not.
|
||||
* All responses will have the AA bit set.
|
||||
* All responses will have the [RCODE Name] "NoError".
|
||||
* The DS digest algorithm is 2.
|
||||
* The DS will not correctly match DNSKEY.
|
||||
* The zones are not signed.
|
||||
|
||||
### SIGNED-AND-DS-1
|
||||
All is good with signed zone and DS record in parent.
|
||||
|
||||
* Zone: signed-and-ds-1.dnssec07.xa.
|
||||
* All default settings.
|
||||
|
||||
### SIGNED-NO-DS-1
|
||||
The child zone is signed, but no DS in parent.
|
||||
|
||||
* Zone: signed-no-ds-1.dnssec07.xa.
|
||||
* The child zone has default settings.
|
||||
* The parent zone has no DS for the child zone.
|
||||
|
||||
### INCONSIST-SIGNED-AND-DS-1
|
||||
The child is signed on ns1 but not on ns2.
|
||||
|
||||
* Zone: inconsist-signed-and-ds-1.dnssec07.xa.
|
||||
* Response from ns1 with DNSKEY.
|
||||
* Response from ns2 without DNSKEY.
|
||||
|
||||
### INCONSIST-SIGNED-NO-DS-1
|
||||
The child is signed on ns1 but not on ns2.
|
||||
|
||||
* Zone: inconsist-signed-no-ds-1.dnssec07.xa.
|
||||
* Response from ns1 with DNSKEY.
|
||||
* Response from ns2 without DNSKEY.
|
||||
* Parent provides no DS.
|
||||
|
||||
### SIGNED-AND-INCONSIST-DS-1
|
||||
Parent provides DS on one server, but not the other.
|
||||
|
||||
* Zone: child.signed-and-inconsist-ds-1.dnssec07.xa.
|
||||
* Grandparent zone is dnssec07.xa.
|
||||
* Parent zone is signed-and-inconsist-ds-1.dnssec07.xa.
|
||||
* ns1 provides DS, ns2 does not.
|
||||
* Child zone is child.signed-and-inconsist-ds-1.dnssec07.xa.
|
||||
* Child zone is signed.
|
||||
|
||||
### UNSIGNED-AND-DS-1
|
||||
Both NS respond with no DNSKEY. Parent has NS but it is disregarded.
|
||||
|
||||
* Zone: unsigned-and-ds-1.dnssec07.xa.
|
||||
* ns1 and ns2 respond with NO DATA on DNSKEY query.
|
||||
* Parent provides DS record, but it is not expected to be queried for.
|
||||
|
||||
### UNSIGNED-NO-DS-1
|
||||
Both NS respond with no DNSKEY. Parent has NS but it is disregarded.
|
||||
|
||||
* Zone: unsigned-no-ds-1.dnssec07.xa.
|
||||
* ns1 and ns2 respond with NODATA on DNSKEY query.
|
||||
* Parent provides no DS record, but it is not expected to be queried for.
|
||||
|
||||
### NON-AUTH-RESPONSE-DNSKEY-1
|
||||
One server responds with non-authoritative DNSKEY response.
|
||||
|
||||
* Zone: non-auth-response-dnskey-1.dnssec07.xa.
|
||||
* ns1 responds with AA bit unset on DNSKEY query.
|
||||
* Other queries have normal responses.
|
||||
* Normal responses from ns2.
|
||||
|
||||
### NO-RESPONSE-DNSKEY-1
|
||||
One server does not respond on DNSKEY query.
|
||||
|
||||
* Zone: no-response-dnskey-1.dnssec07.xa.
|
||||
* ns1 does not respond on the DNSKEY query.
|
||||
* Other queries have normal responses.
|
||||
* Normal responses from ns2.
|
||||
|
||||
### UNEXP-RCODE-RESP-DNSKEY-1
|
||||
One server give unexpected RCODE in response on DNSKEY query.
|
||||
|
||||
* Zone: unexp-rcode-resp-dnskey-1.dnssec07.xa.
|
||||
* ns1 responds with RCODE REFUSED on the DNSKEY query.
|
||||
* Other queries have normal responses.
|
||||
* Normal responses from ns2.
|
||||
|
||||
|
||||
[DNSSEC07]: ../../tests/DNSSEC-TP/dnssec07.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test scenario README file]: ../README.md
|
||||
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
|
||||
@@ -0,0 +1,634 @@
|
||||
# Specification of Test Scenarios for DNSSEC10
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test scenarios and setup of test zones]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies defined test scenarios for test case [DNSSEC10].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [DNSSEC10] is run on a test zone.
|
||||
The message tags are defined in the test case ([DNSSEC10]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone or zones for each test scenario in this document is a subdomain
|
||||
(or lower zone) delegated from the base name (`dnssec10.xa`) and that subdomain
|
||||
having the same name as the scenario. The names of those zones are given in
|
||||
section "[Test scenarios and setup of test zones]" below.
|
||||
|
||||
|
||||
## All message tags
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [DNSSEC10] for the specification of the tags.
|
||||
|
||||
* DS10_ALGO_NOT_SUPPORTED_BY_ZM
|
||||
* DS10_ERR_MULT_NSEC
|
||||
* DS10_ERR_MULT_NSEC3
|
||||
* DS10_ERR_MULT_NSEC3PARAM
|
||||
* DS10_EXPECTED_NSEC_NSEC3_MISSING
|
||||
* DS10_HAS_NSEC
|
||||
* DS10_HAS_NSEC3
|
||||
* DS10_INCONSISTENT_NSEC
|
||||
* DS10_INCONSISTENT_NSEC3
|
||||
* DS10_INCONSISTENT_NSEC_NSEC3
|
||||
* DS10_MIXED_NSEC_NSEC3
|
||||
* DS10_NSEC3PARAM_GIVES_ERR_ANSWER
|
||||
* DS10_NSEC3PARAM_MISMATCHES_APEX
|
||||
* DS10_NSEC3PARAM_QUERY_RESPONSE_ERR
|
||||
* DS10_NSEC3_ERR_TYPE_LIST
|
||||
* DS10_NSEC3_MISMATCHES_APEX
|
||||
* DS10_NSEC3_MISSING_SIGNATURE
|
||||
* DS10_NSEC3_NODATA_MISSING_SOA
|
||||
* DS10_NSEC3_NODATA_WRONG_SOA
|
||||
* DS10_NSEC3_NO_VERIFIED_SIGNATURE
|
||||
* DS10_NSEC3_RRSIG_EXPIRED
|
||||
* DS10_NSEC3_RRSIG_NOT_YET_VALID
|
||||
* DS10_NSEC3_RRSIG_NO_DNSKEY
|
||||
* DS10_NSEC3_RRSIG_VERIFY_ERROR
|
||||
* DS10_NSEC_ERR_TYPE_LIST
|
||||
* DS10_NSEC_GIVES_ERR_ANSWER
|
||||
* DS10_NSEC_MISMATCHES_APEX
|
||||
* DS10_NSEC_MISSING_SIGNATURE
|
||||
* DS10_NSEC_NODATA_MISSING_SOA
|
||||
* DS10_NSEC_NODATA_WRONG_SOA
|
||||
* DS10_NSEC_NO_VERIFIED_SIGNATURE
|
||||
* DS10_NSEC_QUERY_RESPONSE_ERR
|
||||
* DS10_NSEC_RRSIG_EXPIRED
|
||||
* DS10_NSEC_RRSIG_NOT_YET_VALID
|
||||
* DS10_NSEC_RRSIG_NO_DNSKEY
|
||||
* DS10_NSEC_RRSIG_VERIFY_ERROR
|
||||
* DS10_SERVER_NO_DNSSEC
|
||||
* DS10_ZONE_NO_DNSSEC
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:------------------------------|:-----------------------------------------------------------------------------|:--------------------
|
||||
GOOD-NSEC-1 | DS10_HAS_NSEC | 2)
|
||||
GOOD-NSEC-2 | DS10_HAS_NSEC | 2)
|
||||
GOOD-NSEC-3 | DS10_HAS_NSEC | 2)
|
||||
GOOD-NSEC3-1 | DS10_HAS_NSEC3 | 2)
|
||||
GOOD-NSEC3-2 | DS10_HAS_NSEC3 | 2)
|
||||
GOOD-NSEC3-3 | DS10_HAS_NSEC3 | 2)
|
||||
ALGO-NOT-SUPP-BY-ZM-1 | DS10_ALGO_NOT_SUPPORTED_BY_ZM, DS10_HAS_NSEC | 2)
|
||||
ALGO-NOT-SUPP-BY-ZM-2 | DS10_ALGO_NOT_SUPPORTED_BY_ZM, DS10_HAS_NSEC3 | 2)
|
||||
BAD-SERVERS-BUT-GOOD-NSEC-1 | DS10_HAS_NSEC | 2)
|
||||
ERR-MULT-NSEC-1 | DS10_ERR_MULT_NSEC, DS10_HAS_NSEC | 2)
|
||||
ERR-MULT-NSEC-2 | DS10_ERR_MULT_NSEC, DS10_HAS_NSEC | 2)
|
||||
ERR-MULT-NSEC3-1 | DS10_ERR_MULT_NSEC3, DS10_HAS_NSEC3 | 2)
|
||||
ERR-MULT-NSEC3PARAM-1 | DS10_ERR_MULT_NSEC3PARAM, DS10_HAS_NSEC3 | 2)
|
||||
EXP-NSEC-NSEC3-MISS-1 | DS10_EXPECTED_NSEC_NSEC3_MISSING | 2)
|
||||
INCONSISTENT-NSEC-1 | DS10_INCONSISTENT_NSEC, DS10_HAS_NSEC | 2)
|
||||
INCONSISTENT-NSEC3-1 | DS10_INCONSISTENT_NSEC3, DS10_HAS_NSEC3 | 2)
|
||||
INCONSIST-NSEC-NSEC3-1 | DS10_INCONSISTENT_NSEC_NSEC3 | 2)
|
||||
INCONSIST-NSEC-NSEC3-2 | DS10_INCONSISTENT_NSEC_NSEC3, DS10_INCONSISTENT_NSEC, DS10_INCONSISTENT_NSEC3| 2)
|
||||
MIXED-NSEC-NSEC3-1 | DS10_MIXED_NSEC_NSEC3 | 2)
|
||||
MIXED-NSEC-NSEC3-2 | DS10_MIXED_NSEC_NSEC3 | 2)
|
||||
NSEC3PARAM-GIVES-ERR-ANSWER-1 | DS10_NSEC3PARAM_GIVES_ERR_ANSWER, DS10_HAS_NSEC3, DS10_INCONSISTENT_NSEC3 | 2)
|
||||
NSEC3PARAM-GIVES-ERR-ANSWER-2 | DS10_NSEC3PARAM_GIVES_ERR_ANSWER, DS10_EXPECTED_NSEC_NSEC3_MISSING, DS10_INCONSISTENT_NSEC3, DS10_HAS_NSEC3 | 2)
|
||||
NSEC3PARAM-MISMATCHES-APEX-1 | DS10_NSEC3PARAM_MISMATCHES_APEX, DS10_HAS_NSEC3 | 2)
|
||||
NSEC3PARAM-Q-RESPONSE-ERR-1 | DS10_NSEC3PARAM_QUERY_RESPONSE_ERR, DS10_HAS_NSEC3, DS10_INCONSISTENT_NSEC3 | 2)
|
||||
NSEC3PARAM-Q-RESPONSE-ERR-2 | DS10_NSEC3PARAM_QUERY_RESPONSE_ERR, DS10_HAS_NSEC3, DS10_INCONSISTENT_NSEC3 | 2)
|
||||
NSEC3PARAM-Q-RESPONSE-ERR-3 | DS10_NSEC3PARAM_QUERY_RESPONSE_ERR, DS10_EXPECTED_NSEC_NSEC3_MISSING, DS10_INCONSISTENT_NSEC3 | 2)
|
||||
NSEC3-ERR-TYPE-LIST-1 | DS10_NSEC3_ERR_TYPE_LIST, DS10_HAS_NSEC3 | 2)
|
||||
NSEC3-ERR-TYPE-LIST-2 | DS10_NSEC3_ERR_TYPE_LIST, DS10_HAS_NSEC3 | 2)
|
||||
NSEC3-MISMATCHES-APEX-1 | DS10_NSEC3_MISMATCHES_APEX, DS10_HAS_NSEC3 | 2)
|
||||
NSEC3-MISSING-SIGNATURE-1 | DS10_NSEC3_MISSING_SIGNATURE, DS10_HAS_NSEC3 | 2)
|
||||
NSEC3-NODATA-MISSING-SOA-1 | DS10_NSEC3_NODATA_MISSING_SOA, DS10_HAS_NSEC3 | 2)
|
||||
NSEC3-NODATA-WRONG-SOA-1 | DS10_NSEC3_NODATA_WRONG_SOA, DS10_HAS_NSEC3 | 2)
|
||||
NSEC3-NO-VERIFIED-SIGNATURE-1 | DS10_NSEC3_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC3, DS10_NSEC3_RRSIG_NO_DNSKEY | 2)
|
||||
NSEC3-NO-VERIFIED-SIGNATURE-2 | DS10_NSEC3_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC3, DS10_NSEC3_RRSIG_EXPIRED | 2)
|
||||
NSEC3-NO-VERIFIED-SIGNATURE-3 | DS10_NSEC3_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC3, DS10_NSEC3_RRSIG_NOT_YET_VALID | 2)
|
||||
NSEC3-NO-VERIFIED-SIGNATURE-4 | DS10_NSEC3_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC3, DS10_NSEC3_RRSIG_VERIFY_ERROR | 2)
|
||||
NSEC-ERR-TYPE-LIST-1 | DS10_NSEC_ERR_TYPE_LIST, DS10_HAS_NSEC | 2)
|
||||
NSEC-ERR-TYPE-LIST-2 | DS10_NSEC_ERR_TYPE_LIST, DS10_HAS_NSEC | 2)
|
||||
NSEC-GIVES-ERR-ANSWER-1 | DS10_NSEC_GIVES_ERR_ANSWER, DS10_HAS_NSEC, DS10_INCONSISTENT_NSEC | 2)
|
||||
NSEC-GIVES-ERR-ANSWER-2 | DS10_NSEC_GIVES_ERR_ANSWER, DS10_EXPECTED_NSEC_NSEC3_MISSING, DS10_INCONSISTENT_NSEC, DS10_HAS_NSEC | 2)
|
||||
NSEC-MISMATCHES-APEX-1 | DS10_NSEC_MISMATCHES_APEX, DS10_HAS_NSEC | 2)
|
||||
NSEC-MISMATCHES-APEX-2 | DS10_NSEC_MISMATCHES_APEX, DS10_HAS_NSEC | 2)
|
||||
NSEC-MISSING-SIGNATURE-1 | DS10_NSEC_MISSING_SIGNATURE, DS10_HAS_NSEC | 2)
|
||||
NSEC-NODATA-MISSING-SOA-1 | DS10_NSEC_NODATA_MISSING_SOA, DS10_HAS_NSEC | 2)
|
||||
NSEC-NODATA-WRONG-SOA-1 | DS10_NSEC_NODATA_WRONG_SOA, DS10_HAS_NSEC | 2)
|
||||
NSEC-NO-VERIFIED-SIGNATURE-1 | DS10_NSEC_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC, DS10_NSEC_RRSIG_NO_DNSKEY | 2)
|
||||
NSEC-NO-VERIFIED-SIGNATURE-2 | DS10_NSEC_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC, DS10_NSEC_RRSIG_EXPIRED | 2)
|
||||
NSEC-NO-VERIFIED-SIGNATURE-3 | DS10_NSEC_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC, DS10_NSEC_RRSIG_NOT_YET_VALID| 2)
|
||||
NSEC-NO-VERIFIED-SIGNATURE-4 | DS10_NSEC_NO_VERIFIED_SIGNATURE, DS10_HAS_NSEC, DS10_NSEC_RRSIG_VERIFY_ERROR | 2)
|
||||
NSEC-QUERY-RESPONSE-ERR-1 | DS10_NSEC_QUERY_RESPONSE_ERR, DS10_HAS_NSEC, DS10_INCONSISTENT_NSEC | 2)
|
||||
NSEC-QUERY-RESPONSE-ERR-2 | DS10_NSEC_QUERY_RESPONSE_ERR, DS10_HAS_NSEC, DS10_INCONSISTENT_NSEC | 2)
|
||||
NSEC-QUERY-RESPONSE-ERR-3 | DS10_NSEC_QUERY_RESPONSE_ERR, DS10_EXPECTED_NSEC_NSEC3_MISSING, DS10_INCONSISTENT_NSEC | 2)
|
||||
SERVER-NO-DNSSEC-1 | DS10_SERVER_NO_DNSSEC, DS10_HAS_NSEC | 2)
|
||||
SERVER-NO-DNSSEC-2 | DS10_SERVER_NO_DNSSEC, DS10_HAS_NSEC3 | 2)
|
||||
ZONE-NO-DNSSEC-1 | DS10_ZONE_NO_DNSSEC | 2)
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
|
||||
## Test scenarios and setup of test zones
|
||||
|
||||
### Default zone configuration
|
||||
Unless otherwise specified in the specific scenario specification, the test zone
|
||||
or zones for the scenario will follow the default setup as stated below. The
|
||||
`child zone` is the zone to be tested for the scenario.
|
||||
|
||||
* The child zone is `SCENARIO.dnssec10.xa`.
|
||||
* It is delegated to two name servers, `ns1.SCENARIO.dnssec10.xa`
|
||||
and `ns2.SCENARIO.dnssec10.xa`.
|
||||
* The name server names have A and AAAA records to avoid non-relevant error
|
||||
messages.
|
||||
* The delegation of the child zone is complete with glue records.
|
||||
* There is a zone file for the child zone.
|
||||
* All child zone servers give the same response.
|
||||
* The responses are either with NSEC record (NSEC zone) or NSEC3 record (NSEC3
|
||||
zone), not mixed.
|
||||
* The parent zone is `dnssec10.xa`.
|
||||
* It is served by two in-bailiwick NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* If the child zone is an NSEC zone:
|
||||
* Responds with an NSEC response on the NSEC3PARAM query.
|
||||
* Responds with an NSEC record in answer section on the NSEC query.
|
||||
* If the child zone is an NSEC3 zone:
|
||||
* Responds with an NSEC3 response on the NSEC query.
|
||||
* Responds with an NSEC3PARAM record in answer section on the NSEC3PARAM query.
|
||||
* All responses will have the AA bit set.
|
||||
* All responses will have the [RCODE Name] "NoError".
|
||||
|
||||
### GOOD-NSEC-1
|
||||
An NSEC zone and a "happy path". Everything is fine.
|
||||
|
||||
* Zone: good-nsec-1.dnssec10.xa
|
||||
|
||||
### GOOD-NSEC-2
|
||||
An NSEC zone and a "happy path". Everything is fine besides that the zone
|
||||
is served on NS names with the same IP addresses which is fine for this test
|
||||
case.
|
||||
|
||||
* Zone: good-nsec-2.dnssec10.xa
|
||||
* The zone is delegated to ns1a, ns1b and ns1c.
|
||||
* All three share the same IPv4 and IPv6 address, respectively.
|
||||
|
||||
### GOOD-NSEC-3
|
||||
An NSEC zone and a "happy path". Everything is fine besides that the NS names
|
||||
in delegation and zone are different. Fine for this test case.
|
||||
|
||||
* Zone: good-nsec-3.dnssec10.xa
|
||||
* Zone NS are to dns1 and dns2.
|
||||
* dns1 has the same IP addresses as ns1
|
||||
* dns2 has the same IP addresses as ns2
|
||||
|
||||
### GOOD-NSEC3-1
|
||||
An NSEC3 zone and a "happy path". Everything is fine.
|
||||
|
||||
* Zone: good-nsec3-1.dnssec10.xa
|
||||
|
||||
### GOOD-NSEC3-2
|
||||
An NSEC3 zone and a "happy path". Everything is fine besides that the zone
|
||||
is served on NS names with the same IP addresses which is fine for this test
|
||||
case.
|
||||
|
||||
* Zone: good-nsec3-2.dnssec10.xa
|
||||
* The zone is delegated to ns1a, ns1b and ns1c.
|
||||
* All three share the same IPv4 and IPv6 address, respectively.
|
||||
|
||||
### GOOD-NSEC3-3
|
||||
An NSEC3 zone and a "happy path". Everything is fine besides that the NS names
|
||||
in delegation and zone are different. Fine for this test case.
|
||||
|
||||
* Zone: good-nsec3-3.dnssec10.xa
|
||||
* Zone NS are to dns1 and dns2.
|
||||
* dns1 has the same IP addresses as ns1
|
||||
* dns2 has the same IP addresses as ns2
|
||||
|
||||
### ALGO-NOT-SUPP-BY-ZM-1
|
||||
An NSEC zone. Unknown algorithm of a DNSKEY.
|
||||
|
||||
* Zone: algo-not-supp-by-zm-1.dnssec10.xa
|
||||
* There is an extra RRSIG for the NSEC record (as the response to the
|
||||
NSEC3PARAM query).
|
||||
* That RRSIG has been created by [algorithm 255][IANA registry], which is
|
||||
an unsupported private algorithm.
|
||||
* A matching DNSKEY ([algorithm 255][IANA registry]) is available.
|
||||
* For this test scenario a fake signature and a fake public key are used.
|
||||
* The extra DNSKEY is in the DNSKEY RRset which is resigned by the valid
|
||||
KSK.
|
||||
|
||||
### ALGO-NOT-SUPP-BY-ZM-2
|
||||
An NSEC3 zone. Unknown algorithm of a DNSKEY.
|
||||
|
||||
* Zone: algo-not-supp-by-zm-2.dnssec10.xa
|
||||
* There is an extra RRSIG for the NSEC3 record (as the response to the
|
||||
NSEC query).
|
||||
* That RRSIG has been created by [algorithm 255][IANA registry], which is
|
||||
an unsupported private algorithm.
|
||||
* A matching DNSKEY ([algorithm 255][IANA registry]) is available.
|
||||
* For this test scenario a fake signature and a fake public key are used.
|
||||
* The extra DNSKEY is in the DNSKEY RRset which is resigned by the valid
|
||||
KSK.
|
||||
|
||||
### BAD-SERVERS-BUT-GOOD-NSEC-1
|
||||
An NSEC zone. Everything is fine except some non-responsive servers.
|
||||
|
||||
* Zone: bad-servers-but-good-nsec-1.dnssec10.xa
|
||||
* The child zone is delegated to ns1, ns2, ns3, ns4 and ns5, all
|
||||
in-bailiwick with correct glue.
|
||||
* ns1 and ns2 are correct and work as they should.
|
||||
* ns3 does not respond on DNSKEY query.
|
||||
* ns4 responds with REFUSED on DNSKEY query.
|
||||
* ns5 responds with AA unset on DNSKEY query.
|
||||
|
||||
### ERR-MULT-NSEC-1
|
||||
An NSEC zone. An extra NSEC record is returned on the NSEC3PARAM query.
|
||||
|
||||
* Zone: err-mult-nsec-1.dnssec10.xa
|
||||
* An extra NSEC record is returned in the response to the NSEC3PARAM query.
|
||||
* The extra NSEC record has the same owner name, but different value in
|
||||
"Next Domain Name" field.
|
||||
* RRSIG is recalculated.
|
||||
|
||||
### ERR-MULT-NSEC-2
|
||||
An NSEC zone. An extra NSEC record is returned on the NSEC query.
|
||||
|
||||
* Zone: err-mult-nsec-2.dnssec10.xa
|
||||
* An extra NSEC record is returned in the response to the NSEC query.
|
||||
* The extra NSEC record has the same owner name, but different value in
|
||||
"Type List" field.
|
||||
* RRSIG is recalculated.
|
||||
|
||||
### ERR-MULT-NSEC3-1
|
||||
An NSEC3 zone. An extra NSEC3 record is returned.
|
||||
|
||||
* Zone: err-mult-nsec3-1.dnssec10.xa
|
||||
* An extra NSEC3 record is returned in the response to the NSEC query.
|
||||
* The extra NSEC3 record has the same hash owner name, but different value in
|
||||
"Next Hashed Owner Name" field.
|
||||
* The NSEC3 RRset has been signed with a valid RRSIG.
|
||||
|
||||
### ERR-MULT-NSEC3PARAM-1
|
||||
An NSEC3 zone. An extra NSEC3PARAM record is returned.
|
||||
|
||||
* Zone: err-mult-nsec3param-1.dnssec10.xa
|
||||
* An extra NSEC3PARAM record is returned in the response to the NSEC query.
|
||||
* The extra NSEC3PARAM record has the same owner name, but different number
|
||||
of iterations.
|
||||
* The NSEC3PARAM RRset has been signed with a valid RRSIG.
|
||||
|
||||
### EXP-NSEC-NSEC3-MISS-1
|
||||
A zone without NSEC and NSEC3. There is no NSEC or NSEC3 function.
|
||||
|
||||
* Zone: exp-nsec-nsec3-miss-1.dnssec10.xa
|
||||
* The NSEC query gives a NODATA response with no NSEC or NSEC3 record.
|
||||
* The NSEC3PARAM query gives a NODATA response with no NSEC or NSEC3 record.
|
||||
|
||||
### INCONSISTENT-NSEC-1
|
||||
An NSEC zone. Some errors in NSEC handling.
|
||||
|
||||
* Zone: inconsistent-nsec-1.dnssec10.xa
|
||||
* ns1 includes no NSEC record in the NODATA response on the NSEC3PARAM query.
|
||||
* ns2 includes no NSEC record in the NODATA response on the NSEC query.
|
||||
|
||||
### INCONSISTENT-NSEC3-1
|
||||
An NSEC3 zone. Some errors in NSEC3 handling.
|
||||
|
||||
* Zone: inconsistent-nsec3-1.dnssec10.xa
|
||||
* ns1 includes no NSEC3 record in the NODATA response on the NSEC query.
|
||||
* ns2 includes no NSEC3PARAM or NSEC3 record in the NODATA response on the
|
||||
NSEC3PARAM query.
|
||||
|
||||
### INCONSIST-NSEC-NSEC3-1
|
||||
Mixing beteen NSEC and NSEC3.
|
||||
|
||||
* Zone: inconsist-nsec-nsec3-1.dnssec10.xa
|
||||
* ns1 holds an NSEC version of the zone.
|
||||
* ns2 holds an NSEC3 version of the zone.
|
||||
|
||||
### INCONSIST-NSEC-NSEC3-2
|
||||
NSEC on one server and NSEC3 on the other plus errors in NSEC and NSEC3 handling.
|
||||
|
||||
* Zone: inconsist-nsec-nsec3-2.dnssec10.xa
|
||||
* ns1 holds an NSEC version of the zone.
|
||||
* It responds with a NODATA respond without NSEC record on the NSEC3PARAM
|
||||
query.
|
||||
* It does respond with an NSEC record to the NSEC query.
|
||||
* ns2 holds an NSEC3 version of the zone.
|
||||
* It responds with a NODATA respond without NSEC3 record on the NSEC query.
|
||||
* It does respond with an NSEC3PARAM record to the NSEC3PARAM query.
|
||||
|
||||
### MIXED-NSEC-NSEC3-1
|
||||
Servers gives both NSEC and NSEC3
|
||||
|
||||
* Zone: mixed-nsec-nsec3-1.dnssec10.xa
|
||||
* The zone gives an NSEC record in response to NSEC query.
|
||||
* The zone gives an NSEC3PARAM record in response to the NSEC3PARAM query.
|
||||
|
||||
### MIXED-NSEC-NSEC3-2
|
||||
Servers gives both NSEC and NSEC3
|
||||
|
||||
* Zone: mixed-nsec-nsec3-2.dnssec10.xa
|
||||
* The zone gives a NODATA response with NSEC3 record in response to NSEC
|
||||
query.
|
||||
* The zone gives a NODATA response with NSEC record in response to the
|
||||
NSEC3PARAM query.
|
||||
|
||||
### NSEC3PARAM-GIVES-ERR-ANSWER-1
|
||||
An NSEC3 zone. Error in response to NSEC3PARAM query.
|
||||
|
||||
* Zone: nsec3param-gives-err-answer-1.dnssec10.xa
|
||||
* The zone gives a TXT record, but no NSEC3PARAM record, in response to the
|
||||
NSEC3PARAM query.
|
||||
|
||||
### NSEC3PARAM-GIVES-ERR-ANSWER-2
|
||||
An NSEC3 zone. Error in response to NSEC3PARAM query on ns1. No NSEC or NSEC3 on
|
||||
ns2.
|
||||
|
||||
* Zone: nsec3param-gives-err-answer-1.dnssec10.xa
|
||||
* On ns1, the zone gives a TXT record, but no NSEC3PARAM record, in response to
|
||||
the NSEC3PARAM query.
|
||||
* On ns2, the zone gives NODATA responses without NSEC or NSEC3 record for both
|
||||
the NSEC3PARAM query and the NSEC query.
|
||||
|
||||
### NSEC3PARAM-MISMATCHES-APEX-1
|
||||
An NSEC3 zone. The owner name of the NSEC3PARAM record is erroneous.
|
||||
|
||||
* Zone: nsec3param-mismatches-apex-1.dnssec10.xa
|
||||
* The owner name of the NSEC3PARAM record in response to the NSEC3PARAM query is
|
||||
erroneous and does not match apex.
|
||||
* The owner name is `sub.nsec3param-mismatches-apex-1.dnssec10.xa` instead of
|
||||
expected `nsec3param-mismatches-apex-1.dnssec10.xa`.
|
||||
|
||||
## NSEC3PARAM-Q-RESPONSE-ERR-1
|
||||
An NSEC3 zone. Error in response to NSEC3PARAM query.
|
||||
|
||||
* Zone: nsec3param-q-response-err-1.dnssec10.xa
|
||||
* No DNS response on the NSEC3PARAM query.
|
||||
|
||||
## NSEC3PARAM-Q-RESPONSE-ERR-2
|
||||
An NSEC3 zone. Error in response to NSEC3PARAM query.
|
||||
|
||||
* Zone: nsec3param-q-response-err-2.dnssec10.xa
|
||||
* The response on the NSEC3PARAM query has the [RCODE Name] "REFUSED".
|
||||
|
||||
## NSEC3PARAM-Q-RESPONSE-ERR-3
|
||||
An NSEC3 zone. Error in response to NSEC3PARAM query on ns1. No NSEC or NSEC3 on
|
||||
ns2.
|
||||
|
||||
* Zone: nsec3param-q-response-err-3.dnssec10.xa
|
||||
* The response from ns1 on the NSEC3PARAM query has the AA flag unset.
|
||||
* On ns2, the zone gives NODATA responses without NSEC or NSEC3 record for both
|
||||
the NSEC3PARAM query and the NSEC query.
|
||||
|
||||
### NSEC3-ERR-TYPE-LIST-1
|
||||
An NSEC3 zone. The type list of the NSEC3 record is erroneous.
|
||||
|
||||
* Zone: nsec3-err-type-list-1.dnssec10.xa
|
||||
* The type list of the NSEC3 record includes NSEC.
|
||||
|
||||
### NSEC3-ERR-TYPE-LIST-2
|
||||
An NSEC3 zone. The type list of the NSEC3 record is erroneous.
|
||||
|
||||
* Zone: nsec3-err-type-list-2.dnssec10.xa
|
||||
* The type list of the NSEC3 record misses RRSIG.
|
||||
|
||||
### NSEC3-MISMATCHES-APEX-1
|
||||
An NSEC3 zone. The hash owner name of the NSEC3 record is erroneous.
|
||||
|
||||
* Zone: nsec3-mismatches-apex-1.dnssec10.xa
|
||||
* The hash owner name of the NSEC3 record in response to the NSEC query is
|
||||
erroneous and does not match apex.
|
||||
|
||||
### NSEC3-MISSING-SIGNATURE-1
|
||||
An NSEC3 zone. The RRSIG is missing
|
||||
|
||||
* Zone: nsec3-missing-signature-1.dnssec10.xa
|
||||
* There is no RRSIG for the NSEC3 record in the response with NSEC3 record.
|
||||
|
||||
### NSEC3-NODATA-MISSING-SOA-1
|
||||
An NSEC3 zone. The SOA record is missing in the NODATA response.
|
||||
|
||||
* Zone: nsec3-nodata-missing-soa-1.dnssec10.xa
|
||||
* In the NODATA response to the NSEC query the SOA record is missing.
|
||||
|
||||
### NSEC3-NODATA-WRONG-SOA-1
|
||||
An NSEC3 zone. In the NODATA response the SOA record has the wrong owner name.
|
||||
|
||||
* Zone: nsec3-nodata-wrong-soa-1.dnssec10.xa
|
||||
* The owner name of the SOA record in the NODATA response to the NSEC query
|
||||
is `sub.nsec3-nodata-wrong-soa-1.dnssec10.xa` instead of expected
|
||||
`nsec3-nodata-wrong-soa-1.dnssec10.xa`.
|
||||
|
||||
### NSEC3-NO-VERIFIED-SIGNATURE-1
|
||||
An NSEC3 zone. The RRSIG for the NSEC3 record cannot be verified.
|
||||
|
||||
* Zone: nsec3-no-verified-signature-1.dnssec10.xa
|
||||
* The RRSIG record for the NSEC3 record in the NODATA response to the NSEC
|
||||
query cannot be verified.
|
||||
* There is no matching DNSKEY for the RRSIG for the NSEC3 record.
|
||||
|
||||
### NSEC3-NO-VERIFIED-SIGNATURE-2
|
||||
An NSEC3 zone. The RRSIG for the NSEC3 record cannot be verified.
|
||||
|
||||
* Zone: nsec3-no-verified-signature-2.dnssec10.xa
|
||||
* The RRSIG record for the NSEC3 record in the NODATA response to the NSEC
|
||||
query cannot be verified.
|
||||
* The RRSIG has expired, i.e. the current date-time is beyond the last valid
|
||||
date-time.
|
||||
|
||||
### NSEC3-NO-VERIFIED-SIGNATURE-3
|
||||
An NSEC3 zone. The RRSIG for the NSEC3 record cannot be verified.
|
||||
|
||||
* Zone: nsec3-no-verified-signature-3.dnssec10.xa
|
||||
* The RRSIG record for the NSEC3 record in the NODATA response to the NSEC
|
||||
query cannot be verified.
|
||||
* The RRSIG it not yet valid, i.e. the current date-time is before the first
|
||||
valid date-time.
|
||||
|
||||
### NSEC3-NO-VERIFIED-SIGNATURE-4
|
||||
An NSEC3 zone. The RRSIG for the NSEC3 record cannot be verified.
|
||||
|
||||
* Zone: nsec3-no-verified-signature-4.dnssec10.xa
|
||||
* The RRSIG record for the NSEC3 record in the NODATA response to the NSEC
|
||||
query cannot be verified.
|
||||
* The RRSIG signature does not match the NSEC record and appointed DNSKEY.
|
||||
|
||||
### NSEC-ERR-TYPE-LIST-1
|
||||
An NSEC zone. The type list of the NSEC record is erroneous.
|
||||
|
||||
* Zone: nsec-err-type-list-1.dnssec10.xa
|
||||
* The type list of the NSEC record includes NSEC3PARAM.
|
||||
|
||||
### NSEC-ERR-TYPE-LIST-2
|
||||
An NSEC zone. The type list of the NSEC record is erroneous.
|
||||
|
||||
* Zone: nsec-err-type-list-2.dnssec10.xa
|
||||
* The type list of the NSEC record misses RRSIG.
|
||||
|
||||
### NSEC-GIVES-ERR-ANSWER-1
|
||||
An NSEC zone. Error in response to NSEC query.
|
||||
|
||||
* Zone: nsec-gives-err-answer-1.dnssec10.xa
|
||||
* The zone gives a TXT record, but no NSEC record, in response to the NSEC
|
||||
query.
|
||||
|
||||
### NSEC-GIVES-ERR-ANSWER-2
|
||||
An NSEC zone. Error in response to NSEC query on ns1. No NSEC or NSEC3 on ns2.
|
||||
|
||||
* Zone: nsec-gives-err-answer-2.dnssec10.xa
|
||||
* On ns1, the zone gives a TXT record, but no NSEC record, in response to the
|
||||
NSEC query.
|
||||
* On ns2, the zone gives NODATA responses without NSEC or NSEC3 record for both
|
||||
the NSEC3PARAM query and the NSEC query.
|
||||
|
||||
### NSEC-MISMATCHES-APEX-1
|
||||
An NSEC zone. The owner name of the NSEC record is errouneous.
|
||||
|
||||
* Zone: nsec-mismatches-apex-1.dnssec10.xa
|
||||
* The owner name of the NSEC record in response to the NSEC3PARAM query is
|
||||
errouneous and does not match apex.
|
||||
* The owner name is `sub.nsec-mismatches-apex-1.dnssec10.xa` instead of
|
||||
expected `nsec-mismatches-apex-1.dnssec10.xa`.
|
||||
|
||||
### NSEC-MISMATCHES-APEX-2
|
||||
An NSEC zone. The owner name of the NSEC record is errouneous.
|
||||
|
||||
* Zone: nsec-mismatches-apex-2.dnssec10.xa
|
||||
* The owner name of the NSEC record in response to the NSEC query is
|
||||
errouneous and does not match apex.
|
||||
* The owner name is `sub.nsec-mismatches-apex-2.dnssec10.xa` instead of
|
||||
expected `nsec-mismatches-apex-2.dnssec10.xa`.
|
||||
|
||||
### NSEC-MISSING-SIGNATURE-1
|
||||
An NSEC zone. The RRSIG is missing.
|
||||
|
||||
* Zone: nsec-missing-signature-1.dnssec10.xa
|
||||
* There is no RRSIG for the NSEC record in the response with NSEC record on the
|
||||
NSEC3PARAM query.
|
||||
|
||||
### NSEC-NODATA-MISSING-SOA-1
|
||||
An NSEC zone. The SOA record is missing in the NODATA response.
|
||||
|
||||
* Zone: nsec-nodata-missing-soa-1.dnssec10.xa
|
||||
* In the NODATA response to the NSEC3PARAM query the SOA record is missing.
|
||||
|
||||
### NSEC-NODATA-WRONG-SOA-1
|
||||
An NSEC zone. In the NODATA response the SOA record has the wrong owner name.
|
||||
|
||||
* Zone: nsec-nodata-wrong-soa-1.dnssec10.xa
|
||||
* The owner name of the SOA record in the NODATA response to the NSEC3PARAM
|
||||
query is `sub.nsec-nodata-wrong-soa-1.dnssec10.xa` instead of expected
|
||||
`nsec-nodata-wrong-soa-1.dnssec10.xa`.
|
||||
|
||||
### NSEC-NO-VERIFIED-SIGNATURE-1
|
||||
An NSEC zone. The RRSIG for the NSEC record cannot be verified.
|
||||
|
||||
* Zone: nsec-no-verified-signature-1.dnssec10.xa
|
||||
* The RRSIG record for the NSEC record in the NODATA response to the NSEC3PARAM
|
||||
query cannot be verified.
|
||||
* There is no matching DNSKEY for the RRSIG for that NSEC record.
|
||||
|
||||
### NSEC-NO-VERIFIED-SIGNATURE-2
|
||||
An NSEC zone. The RRSIG for the NSEC record cannot be verified.
|
||||
|
||||
* Zone: nsec-no-verified-signature-2.dnssec10.xa
|
||||
* The RRSIG record for the NSEC record in the NODATA response to the NSEC3PARAM
|
||||
query cannot be verified.
|
||||
* The RRSIG has expired, i.e. the current date-time is beyond the last valid
|
||||
date-time.
|
||||
|
||||
### NSEC-NO-VERIFIED-SIGNATURE-3
|
||||
An NSEC zone. The RRSIG for the NSEC record cannot be verified.
|
||||
|
||||
* Zone: nsec-no-verified-signature-3.dnssec10.xa
|
||||
* The RRSIG record for the NSEC record in the NODATA response to the NSEC3PARAM
|
||||
query cannot be verified.
|
||||
* The RRSIG it not yet valid, i.e. the current date-time is before the first
|
||||
valid date-time.
|
||||
|
||||
### NSEC-NO-VERIFIED-SIGNATURE-4
|
||||
An NSEC zone. The RRSIG for the NSEC record cannot be verified.
|
||||
|
||||
* Zone: nsec-no-verified-signature-4.dnssec10.xa
|
||||
* The RRSIG record for the NSEC record in the NODATA response to the NSEC3PARAM
|
||||
query cannot be verified.
|
||||
* The RRSIG signature does not match the RRSIG record and appointed DNSKEY.
|
||||
|
||||
### NSEC-QUERY-RESPONSE-ERR-1
|
||||
An NSEC zone. Error in response to NSEC query.
|
||||
|
||||
* Zone: nsec-query-response-err-1.dnssec10.xa
|
||||
* No DNS response on the NSEC query.
|
||||
|
||||
### NSEC-QUERY-RESPONSE-ERR-2
|
||||
An NSEC zone. Error in response to NSEC query.
|
||||
|
||||
* Zone: nsec-query-response-err-2.dnssec10.xa
|
||||
* The response on the NSEC query has the [RCODE Name] "REFUSED".
|
||||
|
||||
### NSEC-QUERY-RESPONSE-ERR-3
|
||||
An NSEC zone. Error in response to NSEC query on ns1. No NSEC or NSEC3 in
|
||||
responses from ns2.
|
||||
|
||||
* Zone: nsec-query-response-err-3.dnssec10.xa
|
||||
* The response from ns1 on the NSEC query has the AA flag unset.
|
||||
* On ns2, the zone gives NODATA responses without NSEC or NSEC3 record for both
|
||||
the NSEC3PARAM query and the NSEC query.
|
||||
|
||||
### SERVER-NO-DNSSEC-1
|
||||
An NSEC zone. No DNSKEY in response from ns1. Normal response from ns2.
|
||||
|
||||
* Zone: server-no-dnssec-1.dnssec10.xa
|
||||
* The answer section in response from ns1 on the DNSKEY query is empty. Unsigned
|
||||
NODATA response without NSEC or NSEC3.
|
||||
* The NSEC and NSEC3PARAM queries are irrelevant, but they also give a Unsigned
|
||||
NODATA response without NSEC or NSEC3 on ns1.
|
||||
|
||||
### SERVER-NO-DNSSEC-2
|
||||
An NSEC3 zone. No DNSKEY in response from ns1. Normal response from ns2.
|
||||
|
||||
* Zone: server-no-dnssec-2.dnssec10.xa
|
||||
* The answer section in response from ns1 on the DNSKEY query is empty. Unsigned
|
||||
NODATA response without NSEC or NSEC3.
|
||||
* The NSEC and NSEC3PARAM queries are irrelevant, but they also give a Unsigned
|
||||
NODATA response without NSEC or NSEC3 on ns1.
|
||||
|
||||
### ZONE-NO-DNSSEC-1
|
||||
No DNSKEY in response.
|
||||
|
||||
* Zone: zone-no-dnssec-1.dnssec10.xa
|
||||
* The answer section in response on the DNSKEY query is empty. Unsigned NODATA
|
||||
response without NSEC or NSEC3.
|
||||
* The NSEC and NSEC3PARAM queries are irrelevant, but they also give a Unsigned
|
||||
NODATA response without NSEC or NSEC3.
|
||||
|
||||
|
||||
[DNSSEC10]: ../../tests/DNSSEC-TP/dnssec10.md
|
||||
[IANA registry]: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test scenario README file]: ../README.md
|
||||
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
|
||||
|
||||
@@ -0,0 +1,190 @@
|
||||
# Specification of test zones for DNSSEC16
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
* [Terminology](#terminology)
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
|
||||
This document specifies defined test zones for test case [DNSSEC16].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [DNSSEC16] is run on a test zone. The
|
||||
message tags are defined in the test case ([DNSSEC16]) and the scenarios are
|
||||
defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test zone README file].
|
||||
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`dnssec16.xa`) and that subdomain having the same name as the
|
||||
scenario except where the test domain must be the root zone, a TLD or a domain
|
||||
under `.arpa`. The names of those zones are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
|
||||
Scenario name | Mandatory message tags | Forbidden message tags
|
||||
:----------------------------|:--------------------------------------------------|:-------------------------------------------
|
||||
CDS-INVALID-RRSIG | DS16_CDS_INVALID_RRSIG | DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
CDS-MATCHES-NO-DNSKEY | DS16_CDS_MATCHES_NO_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
CDS-MATCHES-NON-SEP-DNSKEY | DS16_CDS_MATCHES_NON_SEP_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
CDS-MATCHES-NON-ZONE-DNSKEY | DS16_CDS_MATCHES_NON_ZONE_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
CDS-NOT-SIGNED_BY_CDS | DS16_CDS_NOT_SIGNED_BY_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
CDS-SIGNED-BY-UNKNOWN-DNSKEY | DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
CDS-UNSIGNED | DS16_CDS_UNSIGNED, DS16_CDS_NOT_SIGNED_BY_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
CDS-WITHOUT-DNSKEY | DS16_CDS_WITHOUT_DNSKEY | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
DELETE-CDS | DS16_DELETE_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
DNSKEY-NOT-SIGNED-BY-CDS | DS16_DNSKEY_NOT_SIGNED_BY_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_MIXED_DELETE_CDS
|
||||
MIXED-DELETE-CDS | DS16_MIXED_DELETE_CDS | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS
|
||||
NO-CDS | (none) | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
NOT-AA | (none) | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
VALID-CDS | (none) | DS16_CDS_INVALID_RRSIG, DS16_CDS_MATCHES_NON_SEP_DNSKEY, DS16_CDS_MATCHES_NON_ZONE_DNSKEY, DS16_CDS_MATCHES_NO_DNSKEY, DS16_CDS_NOT_SIGNED_BY_CDS, DS16_CDS_SIGNED_BY_UNKNOWN_DNSKEY, DS16_CDS_UNSIGNED, DS16_CDS_WITHOUT_DNSKEY, DS16_DELETE_CDS, DS16_DNSKEY_NOT_SIGNED_BY_CDS, DS16_MIXED_DELETE_CDS
|
||||
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the scenario specifications:
|
||||
* Only CDS or DNSKEY records in apex are considered.
|
||||
* Unless stated otherwise, all name servers respond authoritatively with
|
||||
[RCODE Name] "NoError" on all queries.
|
||||
* Unless stated otherwise, all name servers respond authoritatively with (or
|
||||
without) CDS records on CDS queries and DNSKEY records on DNSKEY queries,
|
||||
respectively.
|
||||
* Unless stated otherwise, all RRSIGs are present where expected and are valid.
|
||||
* Each zone is served by two nameservers and both respond consistently.
|
||||
* No DS record is published at parent zone (`dnssec16.xa`).
|
||||
|
||||
### CDS-INVALID-RRSIG
|
||||
* Zone: "cds-invalid-rrsig.dnssec16.xa."
|
||||
* The zone has a [Well Formed DNSKEY Record] (key 1).
|
||||
* The zone has one [Well Formed CDS Record], that matches key 1, but the RRSIG
|
||||
of the CDS RRset has expired.
|
||||
|
||||
### CDS-MATCHES-NO-DNSKEY
|
||||
* Zone: "cds-matches-no-dnskey.dnssec16.xa."
|
||||
* The zone has one [Well Formed DNSKEY Record] (key 1).
|
||||
* The zone has one [Well Formed CDS Record] that matches key 1.
|
||||
* The zone has a second [Well Formed CDS Record] that matches no key by key
|
||||
tag.
|
||||
|
||||
### CDS-MATCHES-NON-SEP-DNSKEY
|
||||
* Zone: "cds-matches-non-sep-dnskey.dnssec16.xa."
|
||||
* The zone has a [Well Formed DNSKEY Record], but flag bit 15 is unset (key
|
||||
1).
|
||||
* The zone has one [Well Formed CDS Record] that matches key 1.
|
||||
|
||||
### CDS-MATCHES-NON-ZONE-DNSKEY
|
||||
* Zone: "cds-matches-non-zone-dnskey.dnssec16.xa."
|
||||
* The zone has one [Well Formed DNSKEY Record] (key 1).
|
||||
* The zone has a second [Well Formed DNSKEY Record], but flag bit 7 is unset
|
||||
and the key has not signed the DNSKEY RRset (key 2).
|
||||
* The zone has one [Well Formed CDS Record] and matches key 1 (CDS 1).
|
||||
* The zone has a second [Well Formed CDS Record], matching key 2, but the key
|
||||
has not signed the CDS RRset.
|
||||
|
||||
### CDS-NOT-SIGNED-BY-CDS
|
||||
* Zone: "cds-not-signed-by-cds.dnssec16.xa."
|
||||
* The zone has two [Well Formed DNSKEY Record] (key 1 and 2).
|
||||
* The zone has one [Well Formed CDS Record] that matches key 1.
|
||||
* The zone has a second [Well Formed CDS Record] that matches key 2, but its
|
||||
DNSKEY has not signed the CDS RRset.
|
||||
|
||||
### CDS-SIGNED-BY-UNKNOWN-DNSKEY
|
||||
* Zone: "cds-signed-by-unknown-dnskey.dnssec16.xa."
|
||||
* The zone has a [Well Formed DNSKEY Record] (key 1).
|
||||
* The zone has one [Well Formed CDS Record], and it matches key 1.
|
||||
* The CDS RRset has an additional RRSIG that matches no DNSKEY by key tag.
|
||||
|
||||
### CDS-UNSIGNED
|
||||
* Zone: "cds-unsigned.dnssec16.xa."
|
||||
* The zone has a [Well Formed DNSKEY Record] (key 1).
|
||||
* The zone has one [Well Formed CDS Record], and it matches key 1, but the CDS
|
||||
RRset is not signed.
|
||||
|
||||
### CDS-WITHOUT-DNSKEY
|
||||
* Zone: "cds-without-dnskey.dnssec16.xa."
|
||||
* The zone has no DNSKEY.
|
||||
* The zone has one [Well Formed CDS Record] that matches no DNSKEY.
|
||||
|
||||
### DELETE-CDS
|
||||
* Zone: "delete-cds.dnssec16.xa."
|
||||
* The zone has a [Well Formed DNSKEY Record].
|
||||
* The zone has one CDS RR that is a Delete CDS.
|
||||
|
||||
### DNSKEY-NOT-SIGNED-BY-CDS
|
||||
* Zone: "dnskey-not-signed-by-cds.dnssec16.xa."
|
||||
* The zone has a [Well Formed DNSKEY Record] (key 1), but the key has not
|
||||
signed the DNSKEY RRset.
|
||||
* The zone has one [Well Formed CDS Record], and it matches key 1.
|
||||
|
||||
### MIXED-DELETE-CDS
|
||||
* Zone: "mixed-delete-cds.dnssec16.xa."
|
||||
* The zone has a [Well Formed DNSKEY Record] (key 1).
|
||||
* The zone has one [Well Formed CDS Record], and it matches key 1.
|
||||
* The zone has a second CDS RR that is a Delete CDS.
|
||||
|
||||
### NO-CDS
|
||||
* Zone: "no-cds.dnssec16.xa."
|
||||
* The name servers give no CDS RRset on CDS query (NODATA).
|
||||
|
||||
### NOT-AA
|
||||
* Zone: "not-aa.dnssec16.xa."
|
||||
* The name servers give non-AA response on CDS queries.
|
||||
|
||||
### VALID-CDS
|
||||
* Zone: "valid-cds.dnssec16.xa."
|
||||
* The zone has a [Well Formed DNSKEY Record] (key 1).
|
||||
* The zone has one [Well Formed CDS Record], and it matches key 1.
|
||||
|
||||
## Terminology
|
||||
|
||||
* "Well Formed DNSKEY Record" - The term is used, in this document, for a DNSKEY
|
||||
record that meets the following requirements:
|
||||
* It is a DNSKEY record in apex.
|
||||
* It uses algorithm 10 (RSA/SHA-512) with a 2048-bit key length, see
|
||||
[DNSSEC05] and [DNSSEC14].
|
||||
* Flag bit 7 (zone key) and bit 15 (SEP) are set.
|
||||
* The DNSKEY RRset has been signed by the key and the RRSIG is valid.
|
||||
|
||||
* "Well Formed CDS Record" - The term is used, in this document, for a CDS record
|
||||
that meets the following requirements:
|
||||
* It is a CDS record in apex.
|
||||
* It uses hash digest 2 (SHA-256), see [DNSSEC01].
|
||||
* Its digest is a digest of a [Well Formed DNSKEY Record].
|
||||
* The CDS RRset has been signed by the its DNSKEY and the RRSIG is valid.
|
||||
|
||||
|
||||
[DNSSEC01]: ../../tests/DNSSEC-TP/dnssec01.md
|
||||
[DNSSEC05]: ../../tests/DNSSEC-TP/dnssec05.md
|
||||
[DNSSEC14]: ../../tests/DNSSEC-TP/dnssec14.md
|
||||
[DNSSEC16]: ../../tests/DNSSEC-TP/dnssec16.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../README.md
|
||||
[Well Formed CDS Record]: #terminology
|
||||
[Well Formed DNSKEY Record]: #terminology
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
# Specification of test scenarios for Delegation-TP
|
||||
|
||||
|
||||
Test scenario specifications are available for:
|
||||
|
||||
* [Delegation01](delegation01.md)
|
||||
* [Delegation02](delegation02.md)
|
||||
* [Delegation03](delegation03.md)
|
||||
@@ -0,0 +1,245 @@
|
||||
# Specification of test Scenarios for Delegation01
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test zone setup]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
|
||||
This document specifies test scenarios for test case [Delegation01].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are output when [Delegation01] is run on a test zone.
|
||||
The message tags are defined in the test case ([Delegation01]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`delegation01.xa`) and that subdomain having the same name as
|
||||
the scenario. The names of those zones are given in section
|
||||
[Test zone setup] below.
|
||||
|
||||
## All message tags
|
||||
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [Delegation01] for the specification of the tags.
|
||||
|
||||
* ENOUGH_IPV4_NS_CHILD
|
||||
* ENOUGH_IPV4_NS_DEL
|
||||
* ENOUGH_IPV6_NS_CHILD
|
||||
* ENOUGH_IPV6_NS_DEL
|
||||
* ENOUGH_NS_CHILD
|
||||
* ENOUGH_NS_DEL
|
||||
* NOT_ENOUGH_IPV4_NS_CHILD
|
||||
* NOT_ENOUGH_IPV4_NS_DEL
|
||||
* NOT_ENOUGH_IPV6_NS_CHILD
|
||||
* NOT_ENOUGH_IPV6_NS_DEL
|
||||
* NOT_ENOUGH_NS_CHILD
|
||||
* NOT_ENOUGH_NS_DEL
|
||||
* NO_IPV4_NS_CHILD
|
||||
* NO_IPV4_NS_DEL
|
||||
* NO_IPV6_NS_CHILD
|
||||
* NO_IPV6_NS_DEL
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:-----------------------------|:---------------------------------------------------------|:-------------------------------------------
|
||||
ENOUGH-1 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
|
||||
ENOUGH-2 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
|
||||
ENOUGH-3 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
|
||||
ENOUGH-DEL-NOT-CHILD | ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_DEL, NOT_ENOUGH_IPV4_NS_CHILD, NOT_ENOUGH_IPV6_NS_CHILD, NOT_ENOUGH_NS_CHILD | 2)
|
||||
ENOUGH-CHILD-NOT-DEL | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV6_NS_CHILD, ENOUGH_NS_CHILD, NOT_ENOUGH_IPV4_NS_DEL, NOT_ENOUGH_IPV6_NS_DEL, NOT_ENOUGH_NS_DEL | 2)
|
||||
IPV6-AND-DEL-OK-NO-IPV4-CHILD | ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV4_NS_CHILD | 2)
|
||||
IPV4-AND-DEL-OK-NO-IPV6-CHILD | ENOUGH_IPV4_NS_DEL, ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV6_NS_CHILD | 2)
|
||||
NO-IPV4-1 | ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV4_NS_CHILD, NO_IPV4_NS_DEL | 2)
|
||||
NO-IPV4-2 | ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV4_NS_CHILD, NO_IPV4_NS_DEL | 2)
|
||||
NO-IPV4-3 | ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV4_NS_CHILD, NO_IPV4_NS_DEL | 2)
|
||||
NO-IPV6-1 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV6_NS_CHILD, NO_IPV6_NS_DEL | 2)
|
||||
NO-IPV6-2 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV6_NS_CHILD, NO_IPV6_NS_DEL | 2)
|
||||
NO-IPV6-3 | ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL, NO_IPV6_NS_CHILD, NO_IPV6_NS_DEL | 2)
|
||||
MISMATCH-DELEGATION-CHILD-1 | ENOUGH_IPV4_NS_CHILD, NOT_ENOUGH_IPV4_NS_DEL, ENOUGH_IPV6_NS_CHILD, NOT_ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
|
||||
MISMATCH-DELEGATION-CHILD-2 | NOT_ENOUGH_IPV4_NS_CHILD, ENOUGH_IPV4_NS_DEL, NOT_ENOUGH_IPV6_NS_CHILD, ENOUGH_IPV6_NS_DEL, ENOUGH_NS_CHILD, ENOUGH_NS_DEL | 2)
|
||||
|
||||
1\) All tags except for those specified as "Forbidden message tags" (no
|
||||
instances for these test scenarios)
|
||||
|
||||
2\) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
## Test zone setup
|
||||
|
||||
Assumptions for the scenario specifications unless otherwise specified for the
|
||||
specific scenario:
|
||||
* For each scenario zone there are two name servers configured.
|
||||
* Both name servers (ns1 and ns2) are equal in delegation and in zone.
|
||||
* Both name servers are in-bailiwick.
|
||||
* Both name servers have both IPv4 and IPv6 addresses.
|
||||
* All required glue records are present in the delegation.
|
||||
* All glue exactly match the authoritative address records in correct zone
|
||||
(not more and not less records).
|
||||
* All name server IP addresses respond with identical zone content.
|
||||
|
||||
### ENOUGH-1
|
||||
This is the main happy path.
|
||||
|
||||
* Zone: enough-1.delegation01.xa
|
||||
|
||||
### ENOUGH-2
|
||||
This is also a happy path. Out-of-bailiwick.
|
||||
|
||||
* Zone: enough-2.delegation01.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick.
|
||||
* ns1 is "ns1.enough-2.delegation01.xb"
|
||||
* ns2 is "ns2.enough-2.delegation01.xb"
|
||||
* Delegation is without glue.
|
||||
* The test zone ("child") has no address records for the name server names.
|
||||
* The "delegation01.xb" zone has the full set of address records.
|
||||
|
||||
### ENOUGH-3
|
||||
This is also a happy path. Also out-of-bailiwick, but with sibling glue.
|
||||
|
||||
* Zone: enough-3.delegation01.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick
|
||||
* ns1 is "ns1.enough-3.sibling.delegation01.xa"
|
||||
* ns2 is "ns2.enough-3.sibling.delegation01.xa"
|
||||
* Delegation is with glue.
|
||||
* The child zone has no address records for the name server names.
|
||||
* The two name servers are defined directly in the parent zone with full set of
|
||||
address records.
|
||||
|
||||
### ENOUGH-DEL-NOT-CHILD
|
||||
Only one name server in child zone.
|
||||
|
||||
* Zone: enough-del-not-child.delegation01.xa
|
||||
* The child zone defines only one name server, ns1.
|
||||
* Delegation is complete.
|
||||
|
||||
### ENOUGH-CHILD-NOT-DEL
|
||||
Only one name server in delegation.
|
||||
|
||||
* Zone: enough-child-not-del.delegation01.xa
|
||||
* The delegation has only one name server, for ns1.
|
||||
* The child has two name servers with full set of address records.
|
||||
|
||||
### IPV6-AND-DEL-OK-NO-IPV4-CHILD
|
||||
No IPv4 in zone.
|
||||
|
||||
* Zone: ipv6-and-del-ok-no-ipv4-child.delegation01.xa
|
||||
* No A records for ns1 and ns2 in zone.
|
||||
* Delegation is complete.
|
||||
|
||||
### IPV4-AND-DEL-OK-NO-IPV6-CHILD
|
||||
No IPv6 in zone.
|
||||
|
||||
* Zone: ipv4-and-del-ok-no-ipv6-child.delegation01.xa
|
||||
* No AAAA records for ns1 and ns2 in zone.
|
||||
* Delegation is complete.
|
||||
|
||||
### NO-IPV4-1
|
||||
No IPv4 in delegation or zone.
|
||||
|
||||
* Zone: no-ipv4-1.delegation01.xa
|
||||
* No A glue for ns1 and ns2.
|
||||
* No A records in zone for ns1 and ns2.
|
||||
|
||||
### NO-IPV4-2
|
||||
No IPv4 in delegation or zone. Out-of-bailiwick name servers and no glue.
|
||||
|
||||
* Zone: no-ipv4-2.delegation01.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick under the xb tree.
|
||||
* ns1 is "ns1.no-ipv4-2.delegation01.xb"
|
||||
* ns2 is "ns2.no-ipv4-2.delegation01.xb"
|
||||
* Delegation is without glue.
|
||||
* The test zone ("child") has no address records for the name server names
|
||||
* The "delegation01.xb" zone has full set of address records for this.
|
||||
* AAAA only, not A
|
||||
|
||||
### NO-IPV4-3
|
||||
No IPv4 in delegation or zone. Out-of-bailiwick name servers, but with sibling
|
||||
glue.
|
||||
|
||||
* Zone: no-ipv4-3.delegation01.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick
|
||||
* ns1 is "ns1.no-ipv4-3.sibling.delegation01.xa"
|
||||
* ns2 is "ns2.no-ipv4-3.sibling.delegation01.xa"
|
||||
* Delegation is with glue.
|
||||
* The child zone has no address records for the name server names
|
||||
* The sibling names have full sets of address records.
|
||||
* AAAA only, not A.
|
||||
|
||||
### NO-IPV6-1
|
||||
No IPv6 in delegation or zone.
|
||||
|
||||
* Zone: no-ipv6-1.delegation01.xa
|
||||
* No AAAA glue for ns1 and ns2.
|
||||
* No AAAA records in zone for ns1 and ns2.
|
||||
|
||||
### NO-IPV6-2
|
||||
No IPv6 in delegation or zone. Out-of-bailiwick name servers and no glue.
|
||||
|
||||
* Zone: no-ipv6-2.delegation01.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick under the xb tree.
|
||||
* ns1 is "ns1.no-ipv6-2.delegation01.xb"
|
||||
* ns2 is "ns2.no-ipv6-2.delegation01.xb"
|
||||
* Delegation is without glue.
|
||||
* The test zone ("child") has no address records for the name servers names
|
||||
* The "delegation01.xb" zone has full set of address records for this.
|
||||
* A only, not AAAA
|
||||
|
||||
### NO-IPV6-3
|
||||
No IPv6 in delegation or zone. Out-of-bailiwick name servers, but with sibling
|
||||
glue.
|
||||
|
||||
* Zone: no-ipv6-3.delegation01.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick
|
||||
* ns1 is "ns1.no-ipv6-3.sibling.delegation01.xa"
|
||||
* ns2 is "ns2.no-ipv6-3.sibling.delegation01.xa"
|
||||
* Delegation is with glue.
|
||||
* The child zone has no address records for the name server names
|
||||
* The sibling names has full set of address records.
|
||||
* A only, not AAAA.
|
||||
|
||||
### MISMATCH-DELEGATION-CHILD-1
|
||||
Missing glue, only IPv4 on ns1 and only IPv6 on ns2.
|
||||
|
||||
* Zone: mismatch-delegation-child-1.delegation01.xa
|
||||
* Only IPv4 glue on ns1.
|
||||
* Only IPv6 glue on ns2.
|
||||
* Full set in zone.
|
||||
|
||||
### MISMATCH-DELEGATION-CHILD-2
|
||||
The zone has only IPv4 on ns1 and only IPv6 on ns2.
|
||||
|
||||
* Zone: mismatch-delegation-child-2.delegation01.xa
|
||||
* Only IPv4 on ns1 in zone.
|
||||
* Only IPv6 on ns2 in zone.
|
||||
* Full set in delegation.
|
||||
|
||||
[Delegation01]: ../../tests/Delegation-TP/delegation01.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test scenario README file]: ../README.md
|
||||
[Test zone setup]: #test-zone-setup
|
||||
@@ -0,0 +1,214 @@
|
||||
# Specification of test Scenarios for Delegation02
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test zone setup]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies test scenarios for test case [Delegation02].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are output when [Delegation02] is run on a test zone.
|
||||
The message tags are defined in the test case ([Delegation02]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`delegation02.xa`) and that subdomain having the same name as
|
||||
the scenario. The names of those zones are given in section [Test zone setup]
|
||||
below.
|
||||
|
||||
## All message tags
|
||||
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [Delegation02] for the specification of the tags.
|
||||
|
||||
* DEL_DISTINCT_NS_IP
|
||||
* CHILD_DISTINCT_NS_IP
|
||||
* DEL_NS_SAME_IP
|
||||
* CHILD_NS_SAME_IP
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:-----------------------------|:-----------------------------------------|:-------------------------------------------
|
||||
ALL-DISTINCT-1 | DEL_DISTINCT_NS_IP, CHILD_DISTINCT_NS_IP | 2)
|
||||
ALL-DISTINCT-2 | DEL_DISTINCT_NS_IP, CHILD_DISTINCT_NS_IP | 2)
|
||||
ALL-DISTINCT-3 | DEL_DISTINCT_NS_IP, CHILD_DISTINCT_NS_IP | 2)
|
||||
DEL-NON-DISTINCT | DEL_NS_SAME_IP, CHILD_DISTINCT_NS_IP | 2)
|
||||
DEL-NON-DISTINCT-UND | DEL_NS_SAME_IP, CHILD_DISTINCT_NS_IP | 2)
|
||||
CHILD-NON-DISTINCT | DEL_DISTINCT_NS_IP, CHILD_NS_SAME_IP | 2)
|
||||
CHILD-NON-DISTINCT-UND | DEL_DISTINCT_NS_IP, CHILD_NS_SAME_IP | 2)
|
||||
NON-DISTINCT-1 | DEL_NS_SAME_IP, CHILD_NS_SAME_IP | 2)
|
||||
NON-DISTINCT-2 | DEL_NS_SAME_IP, CHILD_NS_SAME_IP | 2)
|
||||
NON-DISTINCT-3 | DEL_NS_SAME_IP, CHILD_NS_SAME_IP | 2)
|
||||
|
||||
1\) All tags except for those specified as "Forbidden message tags" (no
|
||||
instances for these test scenarios)
|
||||
|
||||
2\) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
## Test zone setup
|
||||
|
||||
Assumptions for the scenario specifications unless otherwise specified for the
|
||||
specific scenario:
|
||||
* For each scenario zone there are two name servers configured.
|
||||
* Both name servers (ns1 and ns2) are equal in delegation and in zone.
|
||||
* Both name servers are in-bailiwick.
|
||||
* Both name servers have both IPv4 and IPv6 addresses.
|
||||
* All addresses are distinct.
|
||||
* All required glue are present in the delegation.
|
||||
* All glue exactly matches the authoritative address records in correct zone
|
||||
(not more and not less records).
|
||||
* All name server IP addresses respond with identical zone content.
|
||||
|
||||
### ALL-DISTINCT-1
|
||||
This is the happy path.
|
||||
|
||||
* Zone: all-distinct-1.delegation02.xa
|
||||
|
||||
### ALL-DISTINCT-2
|
||||
This is also a happy path. Out-of-bailiwick.
|
||||
|
||||
* Zone: all-distinct-2.delegation02.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick under the xb tree.
|
||||
* ns1 is "ns1.all-distinct-2.delegation02.xb"
|
||||
* ns2 is "ns2.all-distinct-2.delegation02.xb"
|
||||
* Delegation is without glue.
|
||||
* The test zone has no address records for the name server names.
|
||||
* The "delegation02.xb" zone has full set of address records for this scenario.
|
||||
|
||||
### ALL-DISTINCT-3
|
||||
This is also a happy path. Also out-of-bailiwick, but with sibling glue.
|
||||
|
||||
* Zone: all-distinct-3.delegation02.xa
|
||||
* Both ns1 and ns2 are out-of-bailiwick
|
||||
* ns1 is "ns1.all-distinct-3.sibling.delegation02.xa"
|
||||
* ns2 is "ns2.all-distinct-3.sibling.delegation02.xa"
|
||||
* Delegation is with glue.
|
||||
* The test zone ("child") has no address records for the name server names.
|
||||
* The "delegation02.xa" zone has full set of address records for this scenario.
|
||||
|
||||
### DEL-NON-DISTINCT
|
||||
The glue records use the same IP addresses.
|
||||
|
||||
* Zone: del-non-distinct.delegation02.xa
|
||||
* The name servers are ns1a and ns1b
|
||||
* ns1a and ns1b in the delegation (glue) have the same IPv4 and IPv6
|
||||
addresses, respectively.
|
||||
* ns1a and ns1b have distinct addresses in the zone (IPv4 and IPv6,
|
||||
respectively).
|
||||
|
||||
### DEL-NON-DISTINCT-UND
|
||||
The glue records use the same IP addresses. The zone is undelegated.
|
||||
|
||||
* Zone: del-non-distinct-und.delegation02.xa
|
||||
* The zone is undelegated.
|
||||
* name servers are ns1a and ns1b
|
||||
* ns1a and ns1b in the delegation (glue) have the same IPv4 and IPv6
|
||||
addresses, respectively.
|
||||
* ns1a and ns1b have distinct addresses in the zone (IPv4 and IPv6,
|
||||
respectively).
|
||||
* Undelegated data:
|
||||
* ns1a.del-non-distinct-und.delegation02.xa/IPv4
|
||||
* ns1a.del-non-distinct-und.delegation02.xa/IPv6
|
||||
* ns1b.del-non-distinct-und.delegation02.xa/IPv4
|
||||
* ns1b.del-non-distinct-und.delegation02.xa/IPv6
|
||||
|
||||
### CHILD-NON-DISTINCT
|
||||
The address records in the zone use the same IP addresses.
|
||||
|
||||
* Zone: child-non-distinct.delegation02.xa
|
||||
* name servers are ns1a and ns1b
|
||||
* ns1a and ns1b in the delegation (glue) have distinct addresses (IPv4 and
|
||||
IPv6, respectively).
|
||||
* ns1a and ns1b have the same addresses in the zone, IPv4 and IPv6,
|
||||
respectively.
|
||||
|
||||
### CHILD-NON-DISTINCT-UND
|
||||
The address records in the zone use the same IP addresses.
|
||||
|
||||
* Zone: child-non-distinct-und.delegation02.xa
|
||||
* The zone is undelegated.
|
||||
* name servers are ns1a and ns1b
|
||||
* ns1a and ns1b in the delegation (glue) have distinct addresses (IPv4 and
|
||||
IPv6, respectively).
|
||||
* ns1a and ns1b have the same addresses in the zone, IPv4 and IPv6,
|
||||
respectively.
|
||||
* Undelegated data:
|
||||
* ns1a.child-non-distinct-und.delegation02.xa/IPv4
|
||||
* ns1a.child-non-distinct-und.delegation02.xa/IPv6
|
||||
* ns1b.child-non-distinct-und.delegation02.xa/IPv4
|
||||
* ns1b.child-non-distinct-und.delegation02.xa/IPv6
|
||||
|
||||
### NON-DISTINCT-1
|
||||
The address records in both delegation and zone use the same IP addresses.
|
||||
|
||||
* Zone: non-distinct-1.delegation02.xa
|
||||
* name servers are ns1a, ns1b and ns2
|
||||
* ns1a and ns1b in the delegation (glue) have the same IPv4 and IPv6
|
||||
addresses, respectively.
|
||||
* ns1a and ns1b have the same addresses in the zone, IPv4 and IPv6,
|
||||
respectively.
|
||||
* ns2 has a distinct address both in delegation and in zone.
|
||||
|
||||
### NON-DISTINCT-2
|
||||
The name servers in both delegation and zone refer to the same IP addresses. The
|
||||
names are out-of-bailiwick.
|
||||
|
||||
* Zone: non-distinct-2.delegation02.xa
|
||||
* name servers are ns1a, ns1b and ns2, and are out-of-bailiwick under the xb
|
||||
tree.
|
||||
* ns1a is "ns1a.non-distinct-2.delegation02.xb"
|
||||
* ns1b is "ns1a.non-distinct-2.delegation02.xb"
|
||||
* ns2 is "ns2.non-distinct-2.delegation02.xb"
|
||||
* Delegation is without glue.
|
||||
* ns1a and ns1b have the same addresses, IPv4 and IPv6, respectively.
|
||||
* ns2 has distinct addresses (IPv4 and IPv6).
|
||||
* The test zone has no address records for the name server names.
|
||||
* The "delegation02.xb" zone has full set of address records for this scenario.
|
||||
|
||||
### NON-DISTINCT-3
|
||||
The name servers in both delegation and zone refer to the same IP addresses. The
|
||||
names are out-of-bailiwick, but with sibling glue.
|
||||
|
||||
* Zone: non-distinct-3.delegation02.xa
|
||||
* name servers are ns1a, ns1b and ns2, and are out-of-bailiwick.
|
||||
* ns1a is "ns1a.non-distinct-3.sibling.delegation02.xa"
|
||||
* ns1b is "ns1a.non-distinct-3.sibling.delegation02.xa"
|
||||
* ns2 is "ns2.non-distinct-3.sibling.delegation02.xa"
|
||||
* Delegation has sibling glue.
|
||||
* ns1a and ns1b have the same addresses, IPv4 and IPv6, respectively.
|
||||
* ns2 has distinct addresses (IPv4 and IPv6).
|
||||
* The test zone has no address records for the name server names.
|
||||
* The "delegation02.xa" zone has full set of address records for this scenario.
|
||||
|
||||
|
||||
[Delegation02]: ../../tests/Delegation-TP/delegation02.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[test scenario README file]: ../README.md
|
||||
[Test zone setup]: #test-zone-setup
|
||||
|
||||
@@ -0,0 +1,124 @@
|
||||
# Specification of test Scenarios for Delegation03
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test zone setup]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies test scenarios for test case [Delegation03].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are output when [Delegation03] is run on a test zone.
|
||||
The message tags are defined in the test case ([Delegation03]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`delegation03.xa`) and that subdomain having the same name as the
|
||||
scenario. The names of those zones are given in section
|
||||
[Test zone setup] below.
|
||||
|
||||
## All message tags
|
||||
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [Delegation03] for the specification of the tags.
|
||||
|
||||
* REFERRAL_SIZE_OK
|
||||
* REFERRAL_SIZE_TOO_LARGE
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:-----------------------------|:-----------------------------------------|:-------------------------------------------
|
||||
REFERRAL-SIZE-OK-1 | REFERRAL_SIZE_OK | 2)
|
||||
REFERRAL-SIZE-OK-2 | REFERRAL_SIZE_OK | 2)
|
||||
REFERRAL-SIZE-TOO-LARGE-1 | REFERRAL_SIZE_TOO_LARGE | 2)
|
||||
REFERRAL-SIZE-TOO-LARGE-2 | REFERRAL_SIZE_TOO_LARGE | 2)
|
||||
|
||||
1\) All tags except for those specified as "Forbidden message tags" (no
|
||||
instances for these test scenarios)
|
||||
|
||||
2\) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
|
||||
## Test zone setup
|
||||
|
||||
Assumptions for the scenario specifications unless otherwise specified for the
|
||||
specific scenario:
|
||||
* For each scenario zone there are two name server configured.
|
||||
* Both name servers are in-bailiwick.
|
||||
* Both name servers have both IPv4 and IPv6 addresses.
|
||||
* All addresses are distinct.
|
||||
* All required glue are present in the delegation.
|
||||
* There is no actual zone or zone file, only a delegation.
|
||||
* For these scenarios only the delegation is needed.
|
||||
|
||||
### REFERRAL-SIZE-OK-1
|
||||
This is the happy path.
|
||||
|
||||
* Zone: referral-size-ok-1.delegation03.xa.
|
||||
|
||||
### REFERRAL-SIZE-OK-2
|
||||
Referral is large, but not too large. The name servers are in-bailiwick.
|
||||
|
||||
* Zone: referral-size-ok-2.delegation03.xa.
|
||||
* ns1 is "ns1.ipv4-large-but-not-too-large.referral-size-ok-2.delegation03.xa".
|
||||
* ns1 is "ns1.ipv6-large-but-not-too-large.referral-size-ok-2.delegation03.xa".
|
||||
* ns2 is "ns2.ipv4-large-but-not-too-large.referral-size-ok-2.delegation03.xa".
|
||||
* ns2 is "ns2.ipv6-large-but-not-too-large.referral-size-ok-2.delegation03.xa".
|
||||
|
||||
### REFERRAL-SIZE-TOO-LARGE-1
|
||||
Referral is too large and name servers are in-bailiwick.
|
||||
|
||||
* Zone: referral-size-too-large-1.delegation03.xa
|
||||
* Name server names are relative to the zone name:
|
||||
* ns1 is "ns1.1abcdefghijklmnopqrstuv.1defghijkl"
|
||||
* ns2 is "ns2.2abcdefghijklmnopqrstuv.2defghijkl"
|
||||
* ns3 is "ns3.2abcdefghijklmnopqrstuv.3defghijkl"
|
||||
* ns4 is "ns4.2abcdefghijklmnopqrstuv.4defghijkl"
|
||||
* ns5 is "ns5.2abcdefghijklmnopqrstuv.5defghijkl"
|
||||
|
||||
|
||||
### REFERRAL-SIZE-TOO-LARGE-2
|
||||
Referral is too large and name servers are out-of-bailiwick with no glue.
|
||||
|
||||
* Zone: referral-size-too-large-2.delegation03.xa
|
||||
* The zone is delegated to ns1, ns2, ns3 and ns4.
|
||||
* ns1 is "ns1.1abcdefghijklmnopqrstuvwxyz.1abcdefghijklmnopqrstuvwxy.1abcdefghijklmnopqrstuvw.referral-size-too-large-2.delegation03.xb"
|
||||
* ns2 is "ns2.2abcdefghijklmnopqrstuvwxyz.2abcdefghijklmnopqrstuvwxy.2abcdefghijklmnopqrstuvw.referral-size-too-large-2.delegation03.xb"
|
||||
* ns3 is "ns3.3abcdefghijklmnopqrstuvwxyz.3abcdefghijklmnopqrstuvwxy.3abcdefghijklmnopqrstuvw.referral-size-too-large-2.delegation03.xb"
|
||||
* ns4 is "ns4.4abcdefghijklmnopqrstuvwxyz.4abcdefghijklmnopqrstuvwxy.4abcdefghijklmnopqrstuvw.referral-size-too-large-2.delegation03.xb"
|
||||
* Delegation is without glue.
|
||||
* The test zone has no address records for the name server names.
|
||||
* The "delegation03.xb" zone has full set of address records (IPv4 and IPv6).
|
||||
|
||||
[Delegation03]: ../../tests/Delegation-TP/delegation03.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[test scenario README file]: ../README.md
|
||||
[Test zone setup]: #test-zone-setup
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
# Specification of test scenarios for Zonemaster-Engine Perl modules
|
||||
|
||||
This document structure contains test scenario specifications for
|
||||
Zonemaster-Engine Perl Modules, except for test scenarios for [Test Case]
|
||||
implementations and implementation of [MethodsV2], which are found in sibling
|
||||
structures.
|
||||
|
||||
The test scenarios found here are for various Perl modules. The specifications
|
||||
are split by Perl module, and sometimes further split by area.
|
||||
|
||||
The following specifications are available:
|
||||
|
||||
* [Recursor-PM](Recursor-PM/README.md)
|
||||
|
||||
|
||||
[Test Case]: ../../tests/README.md
|
||||
[MethodsV2]: ../../tests/MethodsV2.md
|
||||
|
||||
@@ -0,0 +1,320 @@
|
||||
# Specification of test zones for the CNAME functions in Recursor.pm
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file] which is for test case base test zones. Since
|
||||
this specifies test zones for code it is not fully applicable.
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
the code should be tested.
|
||||
|
||||
|
||||
## Test zone name
|
||||
|
||||
The test zone for these scenarios is `cname.recursor.engine.xa`. Subdomain and
|
||||
subzones are created. The names are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
Scenario name | Expected output
|
||||
:----------------------------|:---------------------------------------------------------------------------------------------
|
||||
GOOD-CNAME-1 | True and tags `CNAME_START`, `CNAME_FOLLOWED_IN_ZONE`
|
||||
GOOD-CNAME-2 | True and tags `CNAME_START`, `CNAME_FOLLOWED_IN_ZONE`
|
||||
GOOD-CNAME-CHAIN | True and tags `CNAME_START`, `CNAME_FOLLOWED_IN_ZONE`
|
||||
GOOD-CNAME-OUT-OF-ZONE | True and tags `CNAME_START`, `CNAME_FOLLOWED_OUT_OF_ZONE`
|
||||
NXDOMAIN-VIA-CNAME | True and tags `CNAME_START`, `CNAME_FOLLOWED_OUT_OF_ZONE`
|
||||
NODATA-VIA-CNAME | True and tags `CNAME_START`, `CNAME_FOLLOWED_OUT_OF_ZONE`
|
||||
MULT-CNAME | Undefined and tags `CNAME_START`, `CNAME_MULTIPLE_FOR_NAME`
|
||||
LOOPED-CNAME-IN-ZONE-1 | Undefined and tags `CNAME_START`, `CNAME_LOOP_INNER`
|
||||
LOOPED-CNAME-IN-ZONE-2 | Undefined and tags `CNAME_START`, `CNAME_LOOP_INNER`
|
||||
LOOPED-CNAME-IN-ZONE-3 | Undefined and tags `CNAME_START`, `CNAME_LOOP_INNER`
|
||||
LOOPED-CNAME-OUT-OF-ZONE | Undefined and tags `CNAME_START`, `CNAME_LOOP_OUTER`
|
||||
TOO-LONG-CNAME-CHAIN | Undefined and tags `CNAME_START`, `CNAME_RECORDS_TOO_MANY`
|
||||
TARGET-NO-MATCH-CNAME | Undefined and tags `CNAME_START`, `CNAME_NO_MATCH`
|
||||
BROKEN-CNAME-CHAIN | Undefined and tags `CNAME_START`, `CNAME_RECORDS_CHAIN_BROKEN`
|
||||
WRONG-CNAME-OWNER-NAME | False and no tags
|
||||
EXTRA-CNAME-IN-ANSWER | False and no tags
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the scenario specifications, unless stated otherwise for the
|
||||
specific scenario:
|
||||
|
||||
* The `cname.recursor.engine.xa` zone is used for all scenarios.
|
||||
* Relative names are under `cname.recursor.engine.xa.`.
|
||||
* The query name is given by the scenario.
|
||||
* Query type is assumed to be `A`.
|
||||
* In the zone, the query name always has a `CNAME` record.
|
||||
* The zone is set up on one NS, ns1.
|
||||
* The [RCODE Name] in the response is NoError.
|
||||
|
||||
### GOOD-CNAME-1
|
||||
The query name will resolve to one `A` record via one CNAME.
|
||||
|
||||
* Query name: "good-cname-1.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
good-cname-1 CNAME good-cname-1-target
|
||||
good-cname-1-target A 127.0.0.1
|
||||
```
|
||||
|
||||
### GOOD-CNAME-2
|
||||
The query name will resolve to two `A` record via one CNAME.
|
||||
|
||||
* Query name: "good-cname-2.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
good-cname-2 CNAME good-cname-2-target
|
||||
good-cname-2-target A 127.0.0.1
|
||||
good-cname-2-target A 127.0.0.2
|
||||
```
|
||||
|
||||
### GOOD-CNAME-CHAIN
|
||||
The query name will resolve to two `A` record via three CNAME.
|
||||
|
||||
* Query name: "good-cname-chain.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
good-cname-chain CNAME good-cname-chain-two
|
||||
good-cname-chain-two CNAME good-cname-chain-three
|
||||
good-cname-chain-three CNAME good-cname-chain-target
|
||||
good-cname-chain-target A 127.0.0.1
|
||||
```
|
||||
|
||||
### GOOD-CNAME-OUT-OF-ZONE
|
||||
The query name will resolve to an `A` record via a CNAME in the zone with a
|
||||
target that points at a subzone, and a delegation to that sub zone.
|
||||
|
||||
* For all queries
|
||||
* The two zones, `cname.recursor.engine.xa` and
|
||||
`goodsub.cname.recursor.engine.xa`, are hosted on different IP addresses.
|
||||
* "x", "y" and "z" in the IP addresses in the configuration below are to be
|
||||
set in the configuration of the test zones.
|
||||
|
||||
* Query name: "good-cname-out-of-zone.cname.recursor.engine.xa"
|
||||
* Servers: NS of `cname.recursor.engine.xa`.
|
||||
* Answer, authority and additional sections, respectively, to be found in the
|
||||
response:
|
||||
```
|
||||
;; ANSWER SECTION:
|
||||
good-cname-out-of-zone CNAME target.goodsub
|
||||
|
||||
;; AUTHORITY SECTION:
|
||||
goodsub NS ns1.goodsub
|
||||
|
||||
;; ADDITIONAL SECTION:
|
||||
ns1.goodsub A 127.x.y.z
|
||||
ns1.goodsub AAAA fda1:b2:c3::127:x:y:z
|
||||
```
|
||||
* Query name: "target.goodsub.cname.recursor.engine.xa"
|
||||
* Servers: NS of `goodsub.cname.recursor.engine.xa`.
|
||||
* To be found in the answer section:
|
||||
```
|
||||
target.goodsub A 127.0.0.1
|
||||
```
|
||||
|
||||
### NXDOMAIN-VIA-CNAME
|
||||
The query name exists, but as CNAME record. The target name of CNAME does not
|
||||
exist.
|
||||
|
||||
* Query name: "nxdomain-via-cname.cname.recursor.engine.xa"
|
||||
* The [RCODE Name] in the response is NxDomain.
|
||||
* The target of the CNAME, `nxdomain-via-cname-target` does not exist in the
|
||||
zone and is not delegated.
|
||||
* SOA of "cname.recursor.engine.xa" to be found in authority section.
|
||||
* To be found in the answer section:
|
||||
```
|
||||
nxdomain-via-cname CNAME nxdomain-via-cname-target
|
||||
```
|
||||
|
||||
### NODATA-VIA-CNAME
|
||||
The query name exists, but as CNAME record. The target name of CNAME exists, but
|
||||
not with any A record.
|
||||
|
||||
* Query name: "nodata-via-cname.cname.recursor.engine.xa"
|
||||
* The target of the CNAME, `nodata-via-cname-target`, exists in the zone but
|
||||
has neither `A` or `CNAME` record, and is not delegated.
|
||||
* SOA of "cname.recursor.engine.xa" to be found in authority section.
|
||||
* To be found in the answer section:
|
||||
```
|
||||
nodata-via-cname CNAME nodata-via-cname-target
|
||||
```
|
||||
|
||||
### MULT-CNAME
|
||||
The query name exists, but as CNAME, as two CNAME records.
|
||||
|
||||
* Query name: "mult-cname.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
mult-cname CNAME mult-cname-target-1
|
||||
mult-cname CNAME mult-cname-target-2
|
||||
mult-cname-target-1 A 127.0.0.1
|
||||
mult-cname-target-2 A 127.0.0.2
|
||||
```
|
||||
|
||||
## LOOPED-CNAME-IN-ZONE-1
|
||||
The query name will point at a CNAME record with the same target as owner name.
|
||||
|
||||
* Query name: "looped-cname-in-zone-1.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
looped-cname-in-zone-1 CNAME looped-cname-in-zone-1
|
||||
```
|
||||
|
||||
## LOOPED-CNAME-IN-ZONE-2
|
||||
The query name will point at a CNAME, which points at a second CNAME,
|
||||
which points to a third CNAME whose target name is the same as the
|
||||
owner name of the second CNAME.
|
||||
|
||||
* Query name: "looped-cname-in-zone-2.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
looped-cname-in-zone-2 CNAME looped-cname-in-zone-2-a
|
||||
looped-cname-in-zone-2-a CNAME looped-cname-in-zone-2-b
|
||||
looped-cname-in-zone-2-b CNAME looped-cname-in-zone-2-a
|
||||
```
|
||||
|
||||
## LOOPED-CNAME-IN-ZONE-3
|
||||
The query name will point at a CNAME, which points at a second CNAME whose target
|
||||
name is the same as the owner name of the first CNAME.
|
||||
|
||||
* Query name: "looped-cname-in-zone-3.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
looped-cname-in-zone-3 CNAME looped-cname-in-zone-3-next
|
||||
looped-cname-in-zone-3-next CNAME looped-cname-in-zone-3
|
||||
```
|
||||
|
||||
## LOOPED-CNAME-OUT-OF-ZONE
|
||||
The query name will point at a CNAME record, but in a sub zone, and the target
|
||||
name of the CNAME record will point at another CNAME record in another sub zone,
|
||||
and the target name of the second CNAME record will point at the first.
|
||||
|
||||
* For all four queries
|
||||
* The three zones `cname.recursor.engine.xa`, `sub2.cname.recursor.engine.xa`
|
||||
and `sub3.cname.recursor.engine.xa` are hosted on different IP addresses.
|
||||
* "x", "y" and "z" in the IP addresses in the configuration below are to be
|
||||
set in the configuration of the test zones.
|
||||
|
||||
* Query name: "looped-cname-out-of-zone.sub2.cname.recursor.engine.xa"
|
||||
* Servers: NS of `cname.recursor.engine.xa`.
|
||||
* Authority and additional sections, respectively, to be found in the
|
||||
response:
|
||||
```
|
||||
;; AUTHORITY SECTION:
|
||||
sub2 NS ns1.sub2
|
||||
|
||||
;; ADDITIONAL SECTION:
|
||||
ns1.sub2 A 127.x.y.z
|
||||
ns1.sub2 AAAA fda1:b2:c3::127:x:y:z
|
||||
```
|
||||
* Query name: "looped-cname-out-of-zone.sub2.cname.recursor.engine.xa"
|
||||
* Servers: NS of `sub2.cname.recursor.engine.xa`.
|
||||
* To be found in the answer section:
|
||||
```
|
||||
looped-cname-out-of-zone.sub2 CNAME looped-cname-out-of-zone.sub3
|
||||
```
|
||||
* Query name: "looped-cname-out-of-zone.sub3.cname.recursor.engine.xa"
|
||||
* Servers: NS of `cname.recursor.engine.xa`.
|
||||
* Relative names are under `cname.recursor.engine.xa.`.
|
||||
* Authority and additional sections, respectively, to be found in the
|
||||
response:
|
||||
```
|
||||
;; AUTHORITY SECTION:
|
||||
sub3 NS ns1.sub3
|
||||
|
||||
;; ADDITIONAL SECTION:
|
||||
ns1.sub3 A 127.x.y.z
|
||||
ns1.sub3 AAAA fda1:b2:c3::127:x:y:z
|
||||
```
|
||||
* Query name: "looped-cname-out-of-zone.sub3.cname.recursor.engine.xa"
|
||||
* Servers: NS of `sub3.cname.recursor.engine.xa`.
|
||||
* To be found in the answer section:
|
||||
```
|
||||
looped-cname-out-of-zone.sub3 CNAME looped-cname-out-of-zone.sub2
|
||||
```
|
||||
|
||||
### TOO-LONG-CNAME-CHAIN
|
||||
The query name will resolve to one `A` record via ten CNAME records which is
|
||||
above the limit.
|
||||
|
||||
* Query name: "too-long-cname-chain.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
too-long-cname-chain CNAME too-long-cname-chain-two
|
||||
too-long-cname-chain-two CNAME too-long-cname-chain-three
|
||||
too-long-cname-chain-three CNAME too-long-cname-chain-four
|
||||
too-long-cname-chain-four CNAME too-long-cname-chain-five
|
||||
too-long-cname-chain-five CNAME too-long-cname-chain-six
|
||||
too-long-cname-chain-six CNAME too-long-cname-chain-seven
|
||||
too-long-cname-chain-seven CNAME too-long-cname-chain-eight
|
||||
too-long-cname-chain-eight CNAME too-long-cname-chain-nine
|
||||
too-long-cname-chain-nine CNAME too-long-cname-chain-ten
|
||||
too-long-cname-chain-ten CNAME too-long-cname-chain-target
|
||||
too-long-cname-chain-target A 127.0.0.1
|
||||
```
|
||||
|
||||
### TARGET-NO-MATCH-CNAME
|
||||
The CNAME target name does not match the owner name of the `A` record.
|
||||
|
||||
* Query name: "target-no-match-cname.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
target-no-match-cname CNAME target-no-match-cname-two
|
||||
target-no-match-cname-target A 127.0.0.1
|
||||
```
|
||||
|
||||
### BROKEN-CNAME-CHAIN
|
||||
The CNAME chain is broken between first and second CNAME records.
|
||||
|
||||
* Query name: "broken-cname-chain.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
broken-cname-chain CNAME broken-cname-chain-two
|
||||
broken-cname-chain-three CNAME broken-cname-chain-target
|
||||
broken-cname-chain-target A 127.0.0.1
|
||||
```
|
||||
|
||||
|
||||
### WRONG-CNAME-OWNER-NAME
|
||||
The owner name of the CNAME in the response does not match query name.
|
||||
|
||||
* Query name: "wrong-cname-owner-name.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
wrong-cname-owner-name-1 CNAME wrong-cname-owner-name-target
|
||||
wrong-cname-owner-name-target A 127.0.0.1
|
||||
```
|
||||
|
||||
|
||||
### EXTRA-CNAME-IN-ANSWER
|
||||
There is an extra CNAME record with an owner name not matching the query name
|
||||
besides the `A` record matching query name.
|
||||
|
||||
* Query name: "extra-cname-in-answer.cname.recursor.engine.xa"
|
||||
* To be found in the answer section:
|
||||
```
|
||||
extra-cname-in-answer A 127.0.0.1
|
||||
extra-cname-in-answer-1 CNAME extra-cname-in-answer-2
|
||||
```
|
||||
|
||||
|
||||
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../../README.md
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
# Specification of test scenarios for Recursor.pm Perl module
|
||||
|
||||
The following specifications are available:
|
||||
|
||||
* [CNAME](CNAME.md)
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
# Specification of test scenarios for MethodsV2
|
||||
|
||||
This document structure contains test scenario specifications for [MethodsV2],
|
||||
which is not a Test Case module. Instead it is a collection of Method
|
||||
specifications referred to by the Test Case specifications and implemented by
|
||||
Perl methods used in the implementations of the Test Cases.
|
||||
|
||||
The purpose of the test scenarios for [MethodsV2] is to verify that the
|
||||
implementation of the methods matches the specifications.
|
||||
|
||||
Test scenarios specification for the following methods are available:
|
||||
|
||||
* [Get parent NS IP addresses]
|
||||
* [Get delegation NS names and IP addresses]
|
||||
* [Get zone NS names and IP addresses]
|
||||
|
||||
Test scenarios specification:
|
||||
|
||||
* [Specification of test scenarios for MethodsV2](methodsv2.md)
|
||||
|
||||
Test scenarios for [Test Case] implementations and test scenarios for Perl
|
||||
modules in Zonemaster-Engine are not in this structure. Instead they can
|
||||
be found in sibling structures.
|
||||
|
||||
[Get delegation NS names and IP addresses]: ../../tests/MethodsV2.md#method-get-delegation-ns-names-and-ip-addresses
|
||||
[Get parent NS IP addresses]: ../../tests/MethodsV2.md#method-get-parent-ns-ip-addresses
|
||||
[Get zone NS names and IP addresses]: ../../tests/MethodsV2.md#method-get-zone-ns-names-and-ip-addresses
|
||||
[MethodsV2]: ../../tests/MethodsV2.md
|
||||
[Test Case]: ../../tests/README.md
|
||||
@@ -0,0 +1,695 @@
|
||||
# Specification of test scenarios for MethodsV2
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Public methods](#public-methods)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and setup of test zones]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file] which is for test case base test zones. Since
|
||||
this document specifies test zones for a [MethodsV2] Method, it is not fully
|
||||
applicable.
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts for the
|
||||
Methods. See [the implementation of the scenarios] for the latest version of the
|
||||
implementation of the MethodsV2 scenarios.
|
||||
|
||||
|
||||
## Public methods
|
||||
|
||||
[MethodsV2] provides the following public methods:
|
||||
|
||||
* For parent zone:
|
||||
* Get parent NS names and IP addresses
|
||||
* Get parent NS IP addresses
|
||||
* For delegation:
|
||||
* Get delegation NS names and IP addresses
|
||||
* Get delegation NS IP addresses
|
||||
* Get delegation NS names
|
||||
* For zone information:
|
||||
* Get zone NS names and IP addresses
|
||||
* Get zone NS names
|
||||
* Get zone NS IP addresses
|
||||
|
||||
### Data type
|
||||
|
||||
All methods can return one of the following data types:
|
||||
* Empty set
|
||||
* Non-empty set
|
||||
* Undefined set
|
||||
|
||||
The non-empty set from the following methods consists of unique IP addresses,
|
||||
IPv4, IPv6 or both (e.g "127.40.4.21" and "fda1:b2:c3::21" are valid):
|
||||
* Get parent NS IP addresses
|
||||
* Get delegation NS IP addresses
|
||||
* Get zone NS IP addresses
|
||||
|
||||
The non-empty set from the following methods consists of unique name server
|
||||
names (e.g. "ns1.example.xa" and "ns2.example.xb" are valid):
|
||||
* Get delegation NS names
|
||||
* Get zone NS names
|
||||
|
||||
The non-empty set from the following methods consists of unique pairs of name
|
||||
server name and its IP address (IPv4 or IPv6). The IP address cannot be blank
|
||||
(e.g. "ns1.example.xa/127.40.4.21" and "ns1.example.xa/fda1:b2:c3::21" are
|
||||
valid but "ns1.example.xa" is not):
|
||||
* Get parent NS names and IP addresses
|
||||
|
||||
The non-empty set from the following methods consists of unique pairs of name
|
||||
server name and its IP address (IPv4 or IPv6). The IP address can be left blank
|
||||
(e.g. "ns1.example.xa/127.40.4.21", "ns1.example.xa/fda1:b2:c3::21" and
|
||||
"ns1.example.xa" are valid):
|
||||
* Get delegation NS names and IP addresses
|
||||
* Get zone NS names and IP addresses
|
||||
|
||||
### Data defined for the scenarios
|
||||
|
||||
Both *Get delegation NS IP addresses* and *Get delegation NS names* can be
|
||||
derived from *Get delegation NS names and IP addresses*.
|
||||
|
||||
Both *Get zone NS IP addresses* and *Get zone NS names* can be derived from
|
||||
*Get zone NS names and IP addresses*.
|
||||
|
||||
*Get parent NS IP addresses* can be derived from *Get parent NS names and IP
|
||||
addresses*.
|
||||
|
||||
Consequently, for the scenarios defined in this document the expected data is only
|
||||
defined for the following three methods:
|
||||
* Get parent NS names and IP addresses
|
||||
* Get delegation NS names and IP addresses
|
||||
* Get zone NS names and IP addresses
|
||||
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`methodsv2.xa`) and that subdomain having the same name as
|
||||
the specific scenario. The names of those zones are given in section
|
||||
"[Test scenarios and setup of test zones]" below.
|
||||
|
||||
|
||||
## Test scenarios and setup of test zones
|
||||
|
||||
### Default zone configuration
|
||||
|
||||
Assumptions for the scenario specifications unless otherwise specified for
|
||||
the specific scenario:
|
||||
|
||||
* The child zone is `child.parent.SCENARIO.methodsv2.xa`.
|
||||
* It is served by two IB (in-bailiwick) NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* The delegation from the parent has the same NS with complete glue.
|
||||
* The parent zone is `parent.SCENARIO.methodsv2.xa`.
|
||||
* It is served by two IB NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* The delegation from the grandparent has the same NS with complete glue.
|
||||
* The grandparent zone is `SCENARIO.methodsv2.xa`.
|
||||
* It is served by two IB NS (ns1 and ns2).
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* The delegation from the SCENARIO zoen has the same NS with complete glue.
|
||||
* Responds with a A record for the zone on query for A.
|
||||
* Responds with a AAAA record for the zone on query for AAAA.
|
||||
* All responses are authoritative with [RCODE Name] "NoError".
|
||||
* EDNS, version 0, is included in all responses on queries with EDNS.
|
||||
* EDNS is not included in responses on queries without EDNS.
|
||||
* Standard root is used.
|
||||
* In all cases, delegation and zone are consistent.
|
||||
* Same NS
|
||||
* Any required glue matches address records in zone. No extra address
|
||||
records.
|
||||
|
||||
### GOOD-1
|
||||
A "happy path". Everything is fine.
|
||||
|
||||
* Zone: child.parent.good-1.methodsv2.xa
|
||||
* Just defaults
|
||||
|
||||
### GOOD-2
|
||||
A "happy path". Everything is fine. Child has out-of-bailiwick name servers
|
||||
only.
|
||||
|
||||
* Zone: child.parent.good-2.methodsv2.xa
|
||||
* Child NS are out-of-bailiwick but not shared with grandparent zone.
|
||||
* ns5.good-2.methodsv2.xa
|
||||
* ns6.good-2.methodsv2.xa
|
||||
* No glue
|
||||
|
||||
### GOOD-3
|
||||
A "happy path". Everything is fine. Child has both in-bailiwick and
|
||||
out-of-bailiwick name servers.
|
||||
|
||||
* Zone: child.parent.good-3.methodsv2.xa
|
||||
* Child NS:
|
||||
* ns1.child.parent.good-3.methodsv2.xa
|
||||
* ns3.parent.good-3.methodsv2.xa
|
||||
* ns5.good-3.methodsv2.xa (not shared with grandparent zone).
|
||||
* Glue:
|
||||
* Address records (A and AAAA) for
|
||||
* ns1.child.parent.good-3.methodsv2.xa
|
||||
* ns3.parent.good-3.methodsv2.xa (optional)
|
||||
|
||||
### GOOD-4
|
||||
A "happy path". Everything is fine. Parent zone is also hosted on grandparent
|
||||
server.
|
||||
|
||||
* Zone: child.parent.good-4.methodsv2.xa
|
||||
* Parent NS:
|
||||
* ns1.parent.good-4.methodsv2.xa
|
||||
* ns2.parent.good-4.methodsv2.xa
|
||||
* ns1.good-4.methodsv2.xa (shared with grandparent zone).
|
||||
* Glue for parent:
|
||||
* Address records (A and AAAA) for
|
||||
* ns1.parent.good-4.methodsv2.xa
|
||||
* ns2.parent.good-4.methodsv2.xa
|
||||
* ns1.good-4.methodsv2.xa (optional)
|
||||
|
||||
### GOOD-5
|
||||
A "happy path". Everything is fine. Child zone is hosted also on grandparent
|
||||
server and parent server.
|
||||
|
||||
* Zone: child.parent.good-5.methodsv2.xa
|
||||
* Child NS:
|
||||
* ns1.child.parent.good-5.methodsv2.xa
|
||||
* ns2.child.parent.good-5.methodsv2.xa
|
||||
* ns1.good-5.methodsv2.xa (shared with grandparent zone).
|
||||
* ns1.parent.good-5.methodsv2.xa (shared with parent zone).
|
||||
* Glue:
|
||||
* Address records (A and AAAA) for
|
||||
* ns1.child.parent.good-5.methodsv2.xa
|
||||
* ns2.child.parent.good-5.methodsv2.xa
|
||||
* ns1.parent.good-5.methodsv2.xa (optional)
|
||||
|
||||
### GOOD-6
|
||||
A "happy path". Everything is fine. Child zone is only hosted on grandparent
|
||||
servers.
|
||||
|
||||
* Zone: child.parent.good-6.methodsv2.xa
|
||||
* Child NS (both shared with grandparent zone):
|
||||
* ns1.good-6.methodsv2.xa
|
||||
* ns2.good-6.methodsv2.xa
|
||||
* No glue.
|
||||
|
||||
### GOOD-7
|
||||
A "happy path". Everything is fine. Child zone is only hosted on parent
|
||||
servers.
|
||||
|
||||
* Zone: child.parent.good-7.methodsv2.xa
|
||||
* Child NS (both shared with parent zone):
|
||||
* ns1.parent.good-7.methodsv2.xa
|
||||
* ns2.parent.good-7.methodsv2.xa
|
||||
* Glue:
|
||||
* Address records (A and AAAA) for
|
||||
* ns1.parent.good-7.methodsv2.xa (optional)
|
||||
* ns2.parent.good-7.methodsv2.xa (optional)
|
||||
|
||||
|
||||
### GOOD-UNDEL-1
|
||||
A "happy path". Everything is fine. Child has both in-bailiwick and
|
||||
out-of-bailiwick name servers. Child is delegated but is tested
|
||||
undelegated.
|
||||
|
||||
* Zone: child.parent.good-undel-1.methodsv2.xa
|
||||
* Delegation:
|
||||
* Child NS:
|
||||
* ns1-2.child.parent.good-undel-1.methodsv2.xa
|
||||
* ns3.parent.good-undel-1.methodsv2.xa (not shared with parent zone)
|
||||
* ns5.good-undel-1.methodsv2.xa (not shared with grandparent zone)
|
||||
* Glue:
|
||||
* Adress records (A and AAAA) for
|
||||
* ns1-2.child.parent.good-undel-1.methodsv2.xa
|
||||
* ns3.parent.good-undel-1.methodsv2.xa (optional)
|
||||
* There is an undelegated version of the zone matching undelegated data.
|
||||
* `ns1-2` have different IP addresses for delegation and delegated zone, on one
|
||||
hand, and undelegated data and undelegated version of the zone, on the other.
|
||||
* `ns3.parent.good-undel-1.methodsv2.xa` is shared between delegated zone and
|
||||
undelegated version of zone, but holding the data of the undelegated version.
|
||||
* Undelegated data:
|
||||
* ns1-2.child.parent.good-undel-1.methodsv2.xa/IPv4
|
||||
* ns1-2.child.parent.good-undel-1.methodsv2.xa/IPv6
|
||||
* ns3.parent.good-undel-1.methodsv2.xa/IPv4
|
||||
* ns3.parent.good-undel-1.methodsv2.xa/IPv6
|
||||
* ns6.good-undel-1.methodsv2.xa
|
||||
|
||||
### GOOD-UNDEL-2
|
||||
A "happy path". Everything is fine. Child has both in-bailiwick and
|
||||
out-of-bailiwick name servers. Child is not delegated but is tested
|
||||
undelegated.
|
||||
|
||||
* Zone: child.parent.good-undel-2.methodsv2.xa
|
||||
* No delegation from parent.
|
||||
* To be tested with undelegated data:
|
||||
* There is an undelegated version of the zone matching undelegated data.
|
||||
* Undelegated data:
|
||||
* ns1.child.parent.good-undel-2.methodsv2.xa/IPv4
|
||||
* ns1.child.parent.good-undel-2.methodsv2.xa/IPv6
|
||||
* ns3.parent.good-undel-2.methodsv2.xa/IPv4
|
||||
* ns3.parent.good-undel-2.methodsv2.xa/IPv6
|
||||
* ns6.good-undel-2.methodsv2.xa
|
||||
|
||||
### DIFF-NS-1
|
||||
No match in name server names between delegation and zone. Same name server IP.
|
||||
|
||||
* Zone: child.parent.diff-ns-1.methodsv2.xa
|
||||
* Delegation to ns1 and ns2.
|
||||
* NS in zone ns1-2 and ns2-2.
|
||||
* ns1-2 and ns2-2 in zone, ns1 and ns2 not in zone.
|
||||
|
||||
### DIFF-NS-2
|
||||
No match in name server names between delegation and zone. Same name server IP on
|
||||
one server. Different on the other. No zone on servers from delegation except
|
||||
ns1.
|
||||
|
||||
* Zone: child.parent.diff-ns-2.methodsv2.xa
|
||||
* Delegation to ns1 and ns2.
|
||||
* NS in zone ns1-2, ns3.
|
||||
* ns1-2 and ns3 in zone, ns1 and ns2 not in zone.
|
||||
* No zone on ns2.
|
||||
* ns1 and ns1-2 have the same IP.
|
||||
|
||||
### IB-NOT-IN-ZONE-1
|
||||
Delegation has in-bailiwick NS, but the names are not defined in the zone.
|
||||
|
||||
* Zone: child.parent.ib-not-in-zone-1.methodsv2.xa
|
||||
* ns1 and ns2 not defined in zone.
|
||||
|
||||
### CHILD-NO-ZONE-1
|
||||
* Zone: child.parent.child-no-zone-1.methodsv2.xa
|
||||
* No child zone on ns1 and ns2.
|
||||
* Response SERVFAIL.
|
||||
|
||||
### CHILD-NO-ZONE-2
|
||||
* Zone: child.parent.child-no-zone-2.methodsv2.xa
|
||||
* No response from ns1 and ns2 of the child.
|
||||
|
||||
### GOOD-MIXED-UNDEL-1
|
||||
The child zone is delegated, but there is also an undelegated version which is
|
||||
the one tested. One grandparent server, in the delegated tree, also serves
|
||||
parent zone.
|
||||
|
||||
* Zone: child.parent.good-mixed-undel-1.methodsv2.xa
|
||||
* Grandparent zone `good-mixed-undel-1.methodsv2.xa` is served on `ns1` and
|
||||
`ns4`.
|
||||
* Parent zone `parent.good-mixed-undel-1.methodsv2.xa` is served by `ns1`,
|
||||
`ns2` and `ns4.good-mixed-undel-1.methodsv2.xa`.
|
||||
* Child zone is delegated, but there is also an undelegated version where
|
||||
the zone has the same data as the delegation.
|
||||
* Undelegated data:
|
||||
* ns3.child.parent.good-mixed-undel-1.methodsv2.xa/IPv4
|
||||
* ns3.child.parent.good-mixed-undel-1.methodsv2.xa/IPv6
|
||||
* ns4.child.parent.good-mixed-undel-1.methodsv2.xa/IPv4
|
||||
* ns4.child.parent.good-mixed-undel-1.methodsv2.xa/IPv6
|
||||
|
||||
### GOOD-MIXED-UNDEL-2
|
||||
The child zone is delegated, but there is also an undelegated version. One parent
|
||||
server also serves the delegated child zone.
|
||||
|
||||
* Zone: child.parent.good-mixed-undel-2.methodsv2.xa
|
||||
* Parent zone `parent.good-mixed-undel-2.methodsv2.xa` is served by `ns1` and
|
||||
`ns2`.
|
||||
* Child zone is served by `ns1`, `ns2` and
|
||||
`ns2.parent.good-mixed-undel-2.methodsv2.xa`.
|
||||
* Child zone is delegated, but there is also an undelegated version where the
|
||||
zone has the same data as the delegation.
|
||||
* Undelegated data:
|
||||
* ns3.child.parent.good-mixed-undel-2.methodsv2.xa/IPv4
|
||||
* ns3.child.parent.good-mixed-undel-2.methodsv2.xa/IPv6
|
||||
* ns4.child.parent.good-mixed-undel-2.methodsv2.xa/IPv4
|
||||
* ns4.child.parent.good-mixed-undel-2.methodsv2.xa/IPv6
|
||||
|
||||
### NO-DEL-MIXED-UNDEL-1
|
||||
The child zone is not delegated, but there is an undelegated version that is
|
||||
tested. One grandparent server also serves the parent zone.
|
||||
|
||||
* Zone: child.parent.no-del-mixed-undel-1.methodsv2.xa
|
||||
* Parent zone `parent.no-del-mixed-undel-1.methodsv2.xa` is served by `ns1`,
|
||||
`ns2` and on `ns2.no-del-mixed-undel-1.methodsv2.xa`.
|
||||
* Child zone is not delegated, but there is an undelegated version.
|
||||
* Undelegated data:
|
||||
* ns1.child.parent.no-del-mixed-undel-1.methodsv2.xa/IPv4
|
||||
* ns1.child.parent.no-del-mixed-undel-1.methodsv2.xa/IPv6
|
||||
* ns2.child.parent.no-del-mixed-undel-1.methodsv2.xa/IPv4
|
||||
* ns2.child.parent.no-del-mixed-undel-1.methodsv2.xa/IPv6
|
||||
|
||||
### NO-CHILD-1
|
||||
The child zone is not delegated. Parent zone returns NXDOMAIN.
|
||||
|
||||
* Zone: child.parent.no-child-1.methodsv2.xa
|
||||
* Child zone does not exist and is not served by any NS.
|
||||
|
||||
### NO-CHILD-2
|
||||
The child zone is not delegated. Parent zone returns NODATA.
|
||||
|
||||
* Zone: child.parent.no-child-2.methodsv2.xa
|
||||
* Child zone does not exist is not served by any NS.
|
||||
* The name child.parent.no-child-2.methodsv2.xa exists as a TXT record.
|
||||
|
||||
### NO-CHLD-PAR-UNDETER-1
|
||||
The child zone is not delegated. One grandparent NS lacks delegation of parent
|
||||
and return NXDOMAIN of child. The parent zone lacks delegation of child.
|
||||
|
||||
* Zone: child.parent.no-chld-par-undeter-1.methodsv2.xa
|
||||
* Child zone does not exist is not served by any NS.
|
||||
* Grandparent `ns1` lacks delegation of parent.
|
||||
* Grandparent `ns2` has delegation of parent (to both parent NS).
|
||||
* Parent zone lacks delegation of child.
|
||||
|
||||
### CHLD-FOUND-PAR-UNDET-1
|
||||
The child zone is delegated from one grandparent NS and from the parent zone.
|
||||
|
||||
* Zone: child.parent.chld-found-par-undet-1.methodsv2.xa
|
||||
* Grandparent `ns1` has delegation of child but lacks delegation of parent.
|
||||
* Grandparent `ns2` has delegation of parent (to both parent NS).
|
||||
* Parent zone has delegation of child.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-1
|
||||
The child is delegated from one parent NS. On the other there is an NXDOMAIN
|
||||
response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-1.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child (NXDOMAIN).
|
||||
|
||||
### CHLD-FOUND-INCONSIST-2
|
||||
The child is delegated from one parent NS. On the other there is an CNAME
|
||||
response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-2.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, and has a CNAME on that name,
|
||||
pointing at `no-child.parent.chld-found-inconsist-2.methodsv2.xa`, which has
|
||||
two address records (A and AAAA) with the IP addresses of child `ns2`.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-3
|
||||
The child is delegated from one parent NS. On the other there is a CNAME
|
||||
to another name, and that other name is delegated.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-3.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, and has a CNAME on the name,
|
||||
pointing at `sister.parent.chld-found-inconsist-3.methodsv2.xa`, which is
|
||||
delegated to `ns6-delegated-child.methodsv2.xa` and
|
||||
`ns7-delegated-child.methodsv2.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-4
|
||||
The child is delegated from one parent NS. On the other there is a DNAME to
|
||||
another name.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-4.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` has a DNAME on `child` pointing at
|
||||
`sister.parent.chld-found-inconsist-4.methodsv2.xa` which is delegated to
|
||||
`ns6-delegated-child.methodsv2.xa` and `ns7-delegated-child.methodsv2.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-5
|
||||
The child is delegated from one parent NS. On the other there is a NODATA
|
||||
response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-5.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, instead `child` has two address
|
||||
records (A and AAAA) with the IP addresses of child `ns2`.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-6
|
||||
The child is delegated from one parent NS, which is also NS for the child.
|
||||
On the other there is an NXDOMAIN response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-6.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to the two child NS.
|
||||
* Parent `ns2` lacks delegation of child (NXDOMAIN).
|
||||
* Child shares `ns1.parent.chld-found-inconsist-6.methodsv2.xa` with parent.
|
||||
* Child also uses child `ns1` and `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-7
|
||||
The child is delegated from one parent NS, which is also NS for the child. On the
|
||||
other there is an CNAME response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-7.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, and has a CNAME on that name,
|
||||
pointing at `no-child.parent.chld-found-inconsist-7.methodsv2.xa`, which has
|
||||
two address records (A and AAAA) with the IP addresses of child `ns2`.
|
||||
* Child shares `ns1.parent.chld-found-inconsist-7.methodsv2.xa` with parent.
|
||||
* Child also uses `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-8
|
||||
The child is delegated from one parent NS, which is also NS for the child. On
|
||||
the other there is a CNAME to another name, and that other name is delegated.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-8.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, and has a CNAME on the name,
|
||||
pointing at `sister.parent.chld-found-inconsist-8.methodsv2.xa`, which is
|
||||
`ns6-delegated-child.methodsv2.xa` and `ns7-delegated-child.methodsv2.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
* Child shares `ns1.parent.chld-found-inconsist-8.methodsv2.xa` with parent.
|
||||
* Child also uses `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-9
|
||||
The child is delegated from one parent NS, which is also NS for the child. On
|
||||
the other there is a DNAME to another name.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-9.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` has a DNAME on `child` pointing at
|
||||
`sister.parent.chld-found-inconsist-9.methodsv2.xa` which is delegated to
|
||||
`ns6-delegated-child.methodsv2.xa` and `ns7-delegated-child.methodsv2.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
* Child shares `ns1.parent.chld-found-inconsist-9.methodsv2.xa` with parent.
|
||||
* Child also uses `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### CHLD-FOUND-INCONSIST-10
|
||||
The child is delegated from one parent NS, which is also NS for the child. On the
|
||||
other there is a NODATA response.
|
||||
|
||||
* Zone: child.parent.chld-found-inconsist-10.methodsv2.xa
|
||||
* Parent `ns1` has normal delegation of child to two child NS, `ns1` and `ns2`.
|
||||
* Parent `ns2` lacks delegation of child, instead `child` has two address
|
||||
records (A and AAAA) with the IP addresses of child `ns2`.
|
||||
* Child shares `ns1.parent.chld-found-inconsist-10.methodsv2.xa` with parent.
|
||||
* Child also uses `ns2`.
|
||||
* Child exists with a zone.
|
||||
|
||||
### NO-DEL-UNDEL-NO-PAR-1
|
||||
The child is not delegated, but there is undelegated data to test. Both
|
||||
grandparent NS return SERVFAIL.
|
||||
|
||||
* Zone: child.parent.no-del-undel-no-par-1.methodsv2.xa
|
||||
* Grandparent `ns1` and `ns2` both return SERVFAIL.
|
||||
* No need of parent zone.
|
||||
* Child zone is not delegated, but there is an undelegated version.
|
||||
* Undelegated data:
|
||||
* ns1.child.parent.no-del-undel-no-par-1.methodsv2.xa/IPv4
|
||||
* ns1.child.parent.no-del-undel-no-par-1.methodsv2.xa/IPv6
|
||||
* ns2.child.parent.no-del-undel-no-par-1.methodsv2.xa/IPv4
|
||||
* ns2.child.parent.no-del-undel-no-par-1.methodsv2.xa/IPv6
|
||||
|
||||
### NO-DEL-UNDEL-PAR-UND-1
|
||||
The child is not delegated, but there is an undelegated data to test. One
|
||||
grandparent NS lacks delegation of parent and return NXDOMAIN of child. The
|
||||
parent zone lacks delegation of child.
|
||||
|
||||
* Zone: child.parent.no-del-undel-par-und-1.methodsv2.xa
|
||||
* Child zone does not exist is not served by any NS.
|
||||
* Grandparent `ns1` has delegation of parent (to both parent NS).
|
||||
* Grandparent `ns2` lacks delegation of parent.
|
||||
* Parent zone lacks delegation of child.
|
||||
* Child zone is not delegated, but there is an undelegated version.
|
||||
* Undelegated data:
|
||||
* ns1.child.no-del-undel-par-und-1.methodsv2.xa/IPv4
|
||||
* ns1.child.no-del-undel-par-und-1.methodsv2.xa/IPv6
|
||||
* ns2.child.no-del-undel-par-und-1.methodsv2.xa/IPv4
|
||||
* ns2.child.no-del-undel-par-und-1.methodsv2.xa/IPv6
|
||||
|
||||
### NO-CHLD-NO-PAR-1
|
||||
The child is not delegated. Both grandparent NS return SERVFAIL.
|
||||
|
||||
* Zone: child.parent.no-chld-no-par-1.methodsv2.xa
|
||||
* Grandparent `ns1` and `ns2` both return SERVFAIL.
|
||||
* No need of parent zone.
|
||||
* Child zone is not delegated, and there is no undelegated data.
|
||||
* No need of child zone.
|
||||
|
||||
### CHILD-ALIAS-1
|
||||
The child zone does not exist, instead there is a DNAME in the parent zone.
|
||||
|
||||
* Zone: child.parent.child-alias-1.methodsv2.xa
|
||||
* Parent has a DNAME on `child` pointing at
|
||||
`sister.parent.child-alias-1.methodsv2.xa` which is delegated to
|
||||
`ns6-delegated-child.methodsv2.xa` and `ns7-delegated-child.methodsv2.xa`.
|
||||
* Zone `sister` does not exist.
|
||||
|
||||
### ZONE-ERR-GRANDPARENT-1
|
||||
Grandparent `ns2` responds with AA bit unset on queries for grandparent zone.
|
||||
|
||||
* Zone: child.parent.zone-err-grandparent-1.methodsv2.xa
|
||||
* Normal response on grandparent `ns1`.
|
||||
* Grandparent `ns2` responds with AA bit unset on queries for the
|
||||
grandparent zone.
|
||||
|
||||
### ZONE-ERR-GRANDPARENT-2
|
||||
Grandparent `ns2` responds with NODATA on NS query for grandparent zone.
|
||||
|
||||
* Zone: child.parent.zone-err-grandparent-2.methodsv2.xa
|
||||
* Normal response on grandparent `ns1`.
|
||||
* Grandparent `ns2` responds with NODATA on NS query for the
|
||||
grandparent zone.
|
||||
|
||||
### ZONE-ERR-GRANDPARENT-3
|
||||
Grandparent `ns2` responds with wrong owner name on NS
|
||||
on query for grandparent zone NS.
|
||||
|
||||
* Zone: child.parent.zone-err-grandparent-3.methodsv2.xa
|
||||
* Normal response on grandparent `ns1`.
|
||||
* Grandparent `ns2` responds with other owner name on NS query for
|
||||
`zone-err-grandparent-3.methodsv2.xa`:
|
||||
* Owner name `oncle.zone-err-grandparent-3.methodsv2.xa` instead.
|
||||
|
||||
### DELEG-OOB-W-ERROR-1
|
||||
Zone is delegated to two OOB NS, of which one has no IP (NODATA).
|
||||
|
||||
* Zone: child.parent.deleg-oob-w-error-1.methodsv2.xa
|
||||
* Zone is delegated to `ns3.deleg-oob-w-error-1.methodsv2.xa` and
|
||||
`ns4-nodata.deleg-oob-w-error-1.methodsv2.xa`.
|
||||
* `ns3` is fully functional with the zone which matches the
|
||||
delegation.
|
||||
* `ns4-nodata` cannot be resolved (NODATA).
|
||||
|
||||
### DELEG-OOB-W-ERROR-2
|
||||
Zone is delegated to two OOB NS, of which one has no IP (NXDOMAIN).
|
||||
|
||||
* Zone: child.parent.deleg-oob-w-error-2.methodsv2.xa
|
||||
* Zone is delegated to `ns3.deleg-oob-w-error-2.methodsv2.xa` and
|
||||
`ns4-nxdomain.deleg-oob-w-error-2.methodsv2.xa`.
|
||||
* `ns3` is fully functional with the zone which matches the
|
||||
delegation.
|
||||
* `ns4-nxdomain` cannot be resolved (NXDOMAIN).
|
||||
|
||||
### DELEG-OOB-W-ERROR-3
|
||||
Zone is delegated to two OOB NS, where both have no IP (NODATA).
|
||||
|
||||
* Zone: child.parent.deleg-oob-w-error-3.methodsv2.xa
|
||||
* Zone is delegated to `ns3-nodata.deleg-oob-w-error-3.methodsv2.xa` and
|
||||
`ns4-nodata.deleg-oob-w-error-3.methodsv2.xa`.
|
||||
* `ns3-nodata` and `ns4-nodata` cannot be resolved (NODATA).
|
||||
* There is no child zone.
|
||||
|
||||
### DELEG-OOB-W-ERROR-4
|
||||
Zone is delegated to two OOB NS, where both have no IP (NXDOMAIN).
|
||||
|
||||
* Zone: child.parent.deleg-oob-w-error-4.methodsv2.xa
|
||||
* Zone is delegated to `ns3-nxdomain.deleg-oob-w-error-4.methodsv2.xa` and
|
||||
`ns4-nxdomain.deleg-oob-w-error-4.methodsv2.xa`.
|
||||
* `ns3-nxdomain` and `ns4-nxdomain` cannot be resolved (NXDOMAIN).
|
||||
* There is no child zone.
|
||||
|
||||
### CHILD-NS-CNAME-1
|
||||
Zone is delegated to two IB NS, where both NS names are aliases (CNAME)
|
||||
to other names in zone.
|
||||
|
||||
* Zone: child.parent.child-ns-cname-1.methodsv2.xa
|
||||
* Zone is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
|
||||
`ns1` and `ns2`, respectively.
|
||||
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
|
||||
|
||||
### CHILD-NS-CNAME-2
|
||||
Zone is delegated to two IB NS, where both NS names are aliases (CNAME)
|
||||
to other names out of zone.
|
||||
|
||||
* Zone: child.parent.child-ns-cname-2.methodsv2.xa
|
||||
* Zone is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
|
||||
`child-ns1.child-ns-cname-2.methodsv2.xa` and
|
||||
`child-ns2.child-ns-cname-2.methodsv2.xa`
|
||||
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
|
||||
|
||||
### CHILD-NS-CNAME-3
|
||||
Zone is delegated to two OOB NS, where both NS names are aliases (CNAME)
|
||||
to other names out of zone.
|
||||
|
||||
* Zone: child.parent.child-ns-cname-3.methodsv2.xa
|
||||
* Zone is delegated to `ns3-cname.child-ns-cname-3.methodsv2.xa` and
|
||||
`ns4-cname.child-ns-cname-3.methodsv2.xa` and both are aliases to `ns3`
|
||||
and `ns4`, respectively.
|
||||
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
|
||||
|
||||
### CHILD-NS-CNAME-4
|
||||
Zone is delegated to two IB NS, where both NS names are aliases (CNAME)
|
||||
to other names in zone.
|
||||
|
||||
* Zone: child.parent.child-ns-cname-4.methodsv2.xa
|
||||
* Zone is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
|
||||
`ns1` and `ns2`, respectively.
|
||||
* Both names can be resolved to A via CNAME and give correct IP.
|
||||
* Neither name can be resolved to AAAA via CNAME.
|
||||
* The parent zone has glue records for `ns1-cname`, but not for `ns2-cname`.
|
||||
|
||||
### PARENT-NS-CNAME-1
|
||||
Parent is delegated to two IB NS, where both NS names are aliases (CNAME)
|
||||
to other names in parent zone.
|
||||
|
||||
* Zone: child.parent.parent-ns-cname-1.methodsv2.xa
|
||||
* Parent is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
|
||||
`ns1` and `ns2`, respectively.
|
||||
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
|
||||
|
||||
### PARENT-NS-CNAME-2
|
||||
Parent is delegated to two IB NS, where both NS names are aliases (CNAME)
|
||||
to other names out of zone.
|
||||
|
||||
* Zone: child.parent.parent-ns-cname-2.methodsv2.xa
|
||||
* Parent is delegated to `ns1-cname` and `ns2-cname` and both are aliases to
|
||||
`parent-ns1.parent-ns-cname-2.methodsv2.xa` and
|
||||
`parent-ns2.parent-ns-cname-2.methodsv2.xa`
|
||||
* Both names can be resolved to A and AAAA via CNAME and give correct IP.
|
||||
|
||||
### PARENT-NS-SAME-IP-1
|
||||
Parent is delegated to three IB NS. The delegation lists two name server names
|
||||
resolving to the same IP.
|
||||
|
||||
* Zone: child.parent.parent-ns-same-ip-1.methodsv2.xa
|
||||
* Parent zone (parent.parent-ns-name-ip-1.methodsv2.xa) is delegated to
|
||||
`ns1a`, `ns1b` and `ns2`.
|
||||
* Both `ns1a` and `ns1b` have A and AAAA records pointing to the same IPv4
|
||||
and IPv6 address respectively.
|
||||
|
||||
### PARENT-NS-SAME-IP-2
|
||||
Parent is delegated to two IB NS. Two of the in-zone NS records resolve to the
|
||||
same IP. The grandparent zone’s delegation lists name server names that are
|
||||
different from the in-zone NS record’s, but the sets of IP addresses are equal.
|
||||
|
||||
* Zone: child.parent.parent-ns-same-ip-2.methodsv2.xa
|
||||
* Grandparent zone (parent-ns-name-ip-2.methodsv2.xa) delegates the parent
|
||||
zone (parent.parent-ns-name-ip-2.methodsv2.xa) to `ns1` and `ns2`.
|
||||
* Parent zone’s NS records list `ns1a`, `ns1b` and `ns2` instead of `ns1` and
|
||||
`ns2`.
|
||||
* Both `ns1a` and `ns1b` have A and AAAA records pointing to the same IPv4
|
||||
and IPv6 address respectively.
|
||||
|
||||
<!-- Links to documents in this repository but outside the public tree must be
|
||||
absolute -->
|
||||
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../../README.md
|
||||
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
|
||||
[MethodsV2]: ../../tests/MethodsV2.md
|
||||
[Get parent NS IP addresses]: ../../tests/MethodsV2.md#method-get-parent-ns-ip-addresses
|
||||
[the implementation of the scenarios]: https://github.com/zonemaster/zonemaster/blob/master/test-zone-data/MethodsV2/README.md
|
||||
@@ -0,0 +1,7 @@
|
||||
# Specification of test zones for Nameserver-TP
|
||||
|
||||
|
||||
Test zone specifications are available for:
|
||||
|
||||
* [NAMESERVER11](nameserver11.md)
|
||||
* [NAMESERVER15](nameserver15.md)
|
||||
@@ -0,0 +1,118 @@
|
||||
# Specification of test zones for NAMESERVER11
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies defined test zones for test case [NAMESERVER11].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [NAMESERVER11] is run on a test zone.
|
||||
The message tags are defined in the test case ([NAMESERVER11]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test zone README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`nameserver11.xa`) and that subdomain having the same name as the
|
||||
scenario. The names of those zones are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:-------------------------|:---------------------------------|:-------------------------------------------
|
||||
NO-EDNS-ON-UNKNOWN-OC | N11_NO_EDNS | N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
|
||||
NO-ERROR | (none) | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
|
||||
NO-RESPONSE-ON-EDNS | (none) | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
|
||||
NO-RESPONSE-ON-UNKNOWN-OC | N11_NO_RESPONSE | N11_NO_EDNS, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
|
||||
RETURNS-UNKNOWN-OC | N11_RETURNS_UNKNOWN_OPTION_CODE | N11_NO_EDNS, N11_NO_RESPONSE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE, N11_UNSET_AA
|
||||
UNEXPECTED-ANSWER-SECTION | N11_UNEXPECTED_ANSWER_SECTION | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_RCODE, N11_UNSET_AA
|
||||
UNEXPECTED-RCODE-FORMERR | N11_UNEXPECTED_RCODE | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNSET_AA
|
||||
UNEXPECTED-RCODE-REFUSED | N11_UNEXPECTED_RCODE | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNSET_AA
|
||||
UNSET-AA | N11_UNSET_AA | N11_NO_EDNS, N11_NO_RESPONSE, N11_RETURNS_UNKNOWN_OPTION_CODE, N11_UNEXPECTED_ANSWER_SECTION, N11_UNEXPECTED_RCODE
|
||||
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the scenario specifications:
|
||||
* For each scenario zone there is one name server configured.
|
||||
* Unless stated otherwise, all name servers respond as follows:
|
||||
* Responds with a SOA record for the zone on query for SOA.
|
||||
* All responses are authoritative with [RCODE Name] "NoError".
|
||||
* EDNS, version 0, is included in all responses on queries with EDNS.
|
||||
* EDNS is not included in responses on queries without EDNS.
|
||||
* Unknown EDNS option codes are not included in responses.
|
||||
|
||||
### NO-EDNS-ON-UNKNOWN-OC
|
||||
* Zone: "no-edns-on-unknown-oc.nameserver11.xa."
|
||||
* The name server will respond without EDNS if the query includes an unknown
|
||||
EDNS OPTION CODE.
|
||||
|
||||
### NO-ERROR
|
||||
* Zone: "no-error.nameserver11.xa."
|
||||
* The name server will respond as default (no error).
|
||||
|
||||
### NO-RESPONSE-ON-EDNS
|
||||
* Zone: "no-response-on-edns.nameserver11.xa."
|
||||
* The name server will not respond to any query with EDNS.
|
||||
|
||||
### NO-RESPONSE-ON-UNKNOWN-OC
|
||||
* Zone: "no-response-on-unknown-oc.nameserver11.xa."
|
||||
* The name server will not respond if the query includes an unknown EDNS OPTION
|
||||
CODE.
|
||||
|
||||
### RETURNS-UNKNOWN-OC
|
||||
* Zone: "returns-unknown-oc.nameserver11.xa."
|
||||
* The name server will respond with an unknown EDNS OPTION CODE if the query
|
||||
includes an unknown EDNS OPTION CODE.
|
||||
|
||||
### UNEXPECTED-ANSWER-SECTION
|
||||
* Zone: "unexpected-answer-section.nameserver11.xa."
|
||||
* The name server will respond without the SOA record if the query includes an
|
||||
unknown EDNS OPTION CODE.
|
||||
|
||||
### UNEXPECTED-RCODE-FORMERR
|
||||
* Zone: "unexpected-rcode-formerr.nameserver11.xa."
|
||||
* The name server will respond with [RCODE Name] "FormErr" if the query includes an
|
||||
unknown EDNS OPTION CODE.
|
||||
|
||||
### UNEXPECTED-RCODE-REFUSED
|
||||
* Zone: "unexpected-rcode-refused.nameserver11.xa."
|
||||
* The name server will respond with [RCODE Name] "Refused" if the query includes an
|
||||
unknown EDNS OPTION CODE.
|
||||
|
||||
### UNSET-AA
|
||||
* Zone: "unset-aa.nameserver11.xa."
|
||||
* The name server will respond with AA unset if the query includes an unknown
|
||||
EDNS OPTION CODE.
|
||||
|
||||
|
||||
[NAMESERVER11]: ../../tests/Nameserver-TP/nameserver11.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../README.md
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
|
||||
@@ -0,0 +1,178 @@
|
||||
# Specification of test zones for NAMESERVER15
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
This document specifies defined test zones for test case [NAMESERVER15].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [NAMESERVER15] is run on a test zone.
|
||||
The message tags are defined in the test case ([NAMESERVER15]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test zone README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`nameserver15.xa`) and that subdomain having the same name as the
|
||||
scenario. The names of those zones are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
Scenario name | Mandatory message tag | Forbidden message tags
|
||||
:-------------------------|:--------------------------------------|:-------------------------------------------
|
||||
NO-VERSION-REVEALED-1 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
|
||||
NO-VERSION-REVEALED-2 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
|
||||
NO-VERSION-REVEALED-3 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
|
||||
NO-VERSION-REVEALED-4 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
|
||||
NO-VERSION-REVEALED-5 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
|
||||
NO-VERSION-REVEALED-6 | N15_NO_VERSION_REVEALED | N15_ERROR_ON_VERSION_QUERY, N15_SOFTWARE_VERSION, N15_WRONG_CLASS
|
||||
ERROR-ON-VERSION-QUERY-1 | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED | N15_SOFTWARE_VERSION, N15_WRONG_CLASS
|
||||
ERROR-ON-VERSION-QUERY-2 | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED | N15_SOFTWARE_VERSION, N15_WRONG_CLASS
|
||||
SOFTWARE-VERSION-1 | N15_SOFTWARE_VERSION | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED, N15_WRONG_CLASS
|
||||
SOFTWARE-VERSION-2 | N15_SOFTWARE_VERSION | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED, N15_WRONG_CLASS
|
||||
WRONG-CLASS-1 | N15_SOFTWARE_VERSION, N15_WRONG_CLASS | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED
|
||||
WRONG-CLASS-2 | N15_SOFTWARE_VERSION, N15_WRONG_CLASS | N15_ERROR_ON_VERSION_QUERY, N15_NO_VERSION_REVEALED
|
||||
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the scenario specifications:
|
||||
* For each scenario zone there is one name server configured.
|
||||
* Unless stated otherwise, all name servers respond as follows:
|
||||
* Responds with a SOA record for the zone on query for SOA.
|
||||
* Responds with CH class on queries on CH class.
|
||||
* Software version query names are "version.bind" and "version.server".
|
||||
* All responses are [RCODE Name] "NoError".
|
||||
* EDNS, version 0, is included in all responses on queries with EDNS.
|
||||
* EDNS is not included in responses on queries without EDNS.
|
||||
|
||||
### NO-VERSION-REVEALED-1
|
||||
This is a happy path
|
||||
|
||||
* Zone: "no-version-revealed-1.nameserver15.xa."
|
||||
* The name server responds with empty answer section on both software version
|
||||
query names.
|
||||
|
||||
### NO-VERSION-REVEALED-2
|
||||
This is a happy path
|
||||
|
||||
* Zone: "no-version-revealed-2.nameserver15.xa."
|
||||
* The name server responds with empty answer section on both software version
|
||||
query names.
|
||||
* The name server responds with [RCODE Name] "NxDomain" on both software
|
||||
version query names.
|
||||
|
||||
### NO-VERSION-REVEALED-3
|
||||
This is a happy path
|
||||
|
||||
* Zone: "no-version-revealed-3.nameserver15.xa."
|
||||
* The name server responds with empty answer section on both software version
|
||||
query names.
|
||||
* The name server responds with [RCODE Name] "Refused" on both software
|
||||
version query names.
|
||||
|
||||
### NO-VERSION-REVEALED-4
|
||||
This is a happy path
|
||||
|
||||
* Zone: "no-version-revealed-4.nameserver15.xa."
|
||||
* The name server responds with a single CNAME record and no other record in
|
||||
answer section on both software version query names.
|
||||
* "version.bind. CNAME version.server." when query name is version.bind.
|
||||
* "version.server. CNAME version.bind." when query name is version.server.
|
||||
|
||||
### NO-VERSION-REVEALED-5
|
||||
This is a happy path
|
||||
|
||||
* Zone: "no-version-revealed-5.nameserver15.xa."
|
||||
* RDATA of the TXT records for both software version query names is the empty
|
||||
string.
|
||||
|
||||
### NO-VERSION-REVEALED-6
|
||||
This is a happy path
|
||||
|
||||
* Zone: "no-version-revealed-6.nameserver15.xa."
|
||||
* RDATA of the TXT records for both software version query names only consists
|
||||
of space characters.
|
||||
|
||||
### ERROR-ON-VERSION-QUERY-1
|
||||
Unexpected response from server
|
||||
|
||||
* Zone: "error-on-version-query-1.nameserver15.xa."
|
||||
* The name server responds with empty answer section on both software version
|
||||
query names.
|
||||
* The name server responds with [RCODE Name] "ServFail" on both software
|
||||
version query names.
|
||||
|
||||
### ERROR-ON-VERSION-QUERY-2
|
||||
Unexpected response from server
|
||||
|
||||
* Zone: "error-on-version-query-2.nameserver15.xa."
|
||||
* The name server does not respond at all to the queries with the software
|
||||
version query names.
|
||||
|
||||
### SOFTWARE-VERSION-1
|
||||
Normal version string
|
||||
|
||||
* Zone: "software-version-1.nameserver15.xa."
|
||||
* Empty response on software query name "version.bind".
|
||||
* TXT record with RDATA "v0" in response on software query name
|
||||
"version.server" in answer section.
|
||||
|
||||
### SOFTWARE-VERSION-2
|
||||
Normal version string
|
||||
|
||||
* Zone: "software-version-2.nameserver15.xa."
|
||||
* Empty response on software query name "version.server".
|
||||
* TXT record with RDATA "v0" in response on software query name
|
||||
"version.bind" in answer section.
|
||||
|
||||
### WRONG-CLASS-1
|
||||
Version string returned in wrong class
|
||||
|
||||
* Zone: "wrong-class-1.nameserver15.xa."
|
||||
* Empty response on software query name "version.bind".
|
||||
* TXT record with RDATA "v0" in response on software query name
|
||||
"version.server" in answer section.
|
||||
* TXT record is in IN class, not CH class.
|
||||
|
||||
### WRONG-CLASS-2
|
||||
Version string returned in wrong class
|
||||
|
||||
* Zone: "wrong-class-2.nameserver15.xa."
|
||||
* Empty response on software query name "version.server".
|
||||
* TXT record with RDATA "v0" in response on software query name
|
||||
"version.bind" in answer section.
|
||||
* TXT record is in IN class, not CH class.
|
||||
|
||||
|
||||
|
||||
|
||||
[NAMESERVER15]: ../../tests/Nameserver-TP/nameserver15.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../README.md
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
|
||||
180
zonemaster/docs/public/specifications/test-zones/README.md
Normal file
180
zonemaster/docs/public/specifications/test-zones/README.md
Normal file
@@ -0,0 +1,180 @@
|
||||
# Test scenarios for verification of test case implementation
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Objective](#objective)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test environment](#test-environment)
|
||||
* [Naming conventions](#naming-conventions)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Data outside the test zones](#data-outside-the-test-zones)
|
||||
* [Undelegated data](#undelegated-data)
|
||||
* [Terminology](#terminology)
|
||||
|
||||
|
||||
|
||||
## Objective
|
||||
|
||||
The purpose of the structure found here is to define test zones to be able to
|
||||
test the correctness of the implementation of the Zonemaster [test cases]. The
|
||||
main use case is to be the basis for the [unit tests] in the Zonemaster
|
||||
implementation. The second use case is to verify work in progress, e.g.
|
||||
implementation of new or updated test cases or updated test case
|
||||
implementation where the test case has not changed.
|
||||
|
||||
There can be other use cases, but only these two use cases are covered here
|
||||
and in the test zone specifications.
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The goal of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when a test case is run on test zones. The
|
||||
message tags are defined in the test case specifications found via "[test cases]"
|
||||
and the scenarios are defined in the test case specific specifications for test
|
||||
data found via the [test-zones] directory.
|
||||
|
||||
In the test zone specifications the scenarios are defined in two parts:
|
||||
|
||||
* What messages from test case that are expected to be outputted and what
|
||||
messages are expected not to be outputted when a test zone setup according to
|
||||
the scenario is tested by the test case.
|
||||
* Specification of the zone setup for the scenario.
|
||||
|
||||
One special aspect is the test scenario name. Since the name is to be part
|
||||
of the test zone name there are some requirements on it:
|
||||
* Under a specific test case there must not be two scenarios with the same name.
|
||||
Two closely related scenarios can, in their names, be separated with a
|
||||
relevant suffix.
|
||||
* The length of the scenario name must not exceed 32 characters to give room for
|
||||
additional parts and still make sure it can fit into a DNS label.
|
||||
* The character set of the name is limited to those of a host name, i.e.
|
||||
`A-Z0-9-` where `A-Z` will be downcased to `a-z` in the domain name.
|
||||
* The scenario name must not start or end with `-`.
|
||||
|
||||
|
||||
## Test environment
|
||||
|
||||
The tests against the test zones are assumed to be run in a closed environment
|
||||
with a private DNS tree to achieve full access to any zone. Configuration data
|
||||
and instructions to set this up are available in the [test-zone-data] directory
|
||||
in this repository.
|
||||
|
||||
## Naming conventions
|
||||
|
||||
In this document, domain names are given without trailing dot, except for the root
|
||||
zone (or node) given as a dot `.`.
|
||||
|
||||
The non-existing `.xa` TLD and its tree is used to host the target test
|
||||
zones, i.e. the zone name that will be given as *Child Zone* to the test case.
|
||||
All test zones are to be created under `.xa` except for a few cases elaborated
|
||||
below.
|
||||
|
||||
Unless specified in the test zone specification, DNS records that can be stored
|
||||
within the zone should also be stored there:
|
||||
* MX records should point at the relative name `mail` and that name should be
|
||||
added to the zone.
|
||||
* Name server names (NS record RDATA) should be [in-bailiwick]. "Prefixes" to be
|
||||
used are `ns1`, `ns2`, `ns3` etc.
|
||||
|
||||
|
||||
### Test zone names
|
||||
|
||||
The normal test zone name is built from the following parts:
|
||||
* `.xa`, the non-existing TLD used here.
|
||||
* The test case identifier in lower case, e.g. `zone09`.
|
||||
* The test scenario name in lower case, e.g. `no-response-mx-query`.
|
||||
|
||||
In the normal case, the test zone name is `<scenario name>.<test case name>.xa`,
|
||||
e.g. `no-response-mx-query.zone09.xa`. The normal case should be used as long as
|
||||
it is possible.
|
||||
|
||||
There are some exceptions to the name of the test zone that are identified here:
|
||||
1. If the test zone is the root, then the name is `.`.
|
||||
2. If the test zone is a TLD zone, then the name is
|
||||
`<scenario name>-<test case name>`. Note that hyphen "-" is used between the
|
||||
parts to create one label. E.g. `no-mx-tld-zone09`. In practice such a TLD
|
||||
can never be in conflict with real TLDs in the public DNS tree, especially
|
||||
since TLD names are not permitted to contain neither dash "-" nor digits.
|
||||
3. If the test zone must be in the ARPA tree, then the name is
|
||||
`<scenario name>.<test case name>.arpa`, e.g. `no-mx-arpa.zone09.arpa`. In
|
||||
practice such a name will never be in conflict with names in the public DNS
|
||||
tree since there no such names under public `.arpa`.
|
||||
4. If a scenario requires that the parent zone has different settings compared to
|
||||
other scenarios for the same test case, then the test zone name is
|
||||
`child.<scenario name>.<test case name>.xa`, e.g.
|
||||
`child.no-response-mx-query.zone09.xa`, where
|
||||
`no-response-mx-query.zone09.xa`, instead of `zone09.xa`, is the parent zone
|
||||
of the test zone.
|
||||
5. If a scenario requires that the grandparent zone has different settings
|
||||
compared to other scenarios for the same test case, then the test zone name is
|
||||
`child.parent.<scenario name>.<test case name>.xa`, e.g.
|
||||
`child.parent.no-response-mx-query.zone09.xa`, where
|
||||
`no-response-mx-query.zone09.xa`, instead of `zone09.xa`, is the grandparent
|
||||
zone of the test zone.
|
||||
|
||||
### Data outside the test zones
|
||||
|
||||
If a scenario requires that a certain name is outside its own zone, it should be
|
||||
stored within the `.xb` TLD (also a non-existing TLD) using the same name
|
||||
structure as under `.xa`, i.e. names for a scenario should be stored under
|
||||
`<scenario name>.<test case name>.xb`, e.g. `no-mx-arpa.zone09.xb`. If required
|
||||
test zones can be created in the same way under `.xc` and `.xd`.
|
||||
|
||||
What was stated above on data outside its own zone does not apply to reverse data
|
||||
since that must be stored in the `in-addr.arpa` or `ip6.arpa` tree, and the
|
||||
owner names of such data must follow the reverse data standards. There is no
|
||||
requirements for creating separate zones for `in-addr.arpa` or `ip6.arpa` or
|
||||
below.
|
||||
|
||||
### Undelegated data
|
||||
|
||||
Some test scenarios require that an [undelegated test] be carried out on it.
|
||||
In that case, the scenario specification will contain a small
|
||||
"undelegated data" structure with one line per name server. The format is one of
|
||||
the following
|
||||
* NAME-SERVER-NAME
|
||||
* NAME-SERVER-NAME/IPv4
|
||||
* NAME-SERVER-NAME/IPv6
|
||||
where "NAME-SERVER-NAME" is the actual name of the name server, e.g.
|
||||
`ns1a.del-non-distinct-und.delegation02.xa`, and "IPv4" and "IPv6",
|
||||
respectively, are literal strings indicating that in the test zone configuration
|
||||
an IP address of that type should be used. If there is no "/IPv4" or "/IPv6"
|
||||
then the name server is given without IP address.
|
||||
|
||||
In the undelegated structure for a specific scenario the name server name can be
|
||||
repeated multiple times with different IP addresses. If it appears without
|
||||
IP address specification it should only appear once.
|
||||
|
||||
Here is an example of an undelegated data section from a scenario specification:
|
||||
```
|
||||
* Undelegated data:
|
||||
* ns1a.del-non-distinct-und.delegation02.xa/IPv4
|
||||
* ns1a.del-non-distinct-und.delegation02.xa/IPv6
|
||||
* ns1b.del-non-distinct-und.delegation02.xa/IPv4
|
||||
* ns1b.del-non-distinct-und.delegation02.xa/IPv6
|
||||
```
|
||||
|
||||
|
||||
## Terminology
|
||||
|
||||
* "Glue Record" - The term is used as defined in [RFC 8499], section 7, pages
|
||||
24-25.
|
||||
|
||||
* "In-Bailiwick" - The term is used as defined in [RFC 8499], section 7,
|
||||
pages 24-25. In this document it is limited to the meaning "in domain" in the
|
||||
RFC.
|
||||
|
||||
* "Out-Of-Bailiwick" - The terms means, in this document, what is not
|
||||
"In-Bailiwick, in domain". [RFC 8499], section 7, pages 24-25.
|
||||
|
||||
|
||||
[Glue Records]: #terminology
|
||||
[In-Bailiwick]: #terminology
|
||||
[Out-Of-Bailiwick]: #terminology
|
||||
[RFC 8499]: https://datatracker.ietf.org/doc/html/rfc8499#section-7
|
||||
[Test cases]: ../tests/README.md
|
||||
[Test-zones]: .
|
||||
[undelegated test]: ../test-types/undelegated-test.md
|
||||
[Unit tests]: https://github.com/zonemaster/zonemaster-engine/tree/master/t
|
||||
[Test-zone-data]: https://github.com/zonemaster/zonemaster/tree/master/test-zone-data
|
||||
@@ -0,0 +1,7 @@
|
||||
# Specification of test zones for Zone-TP
|
||||
|
||||
|
||||
Test zone specifications are available for:
|
||||
|
||||
* [Zone09](zone09.md)
|
||||
* [Zone11](zone11.md)
|
||||
@@ -0,0 +1,158 @@
|
||||
# Specification of test zones for ZONE09
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Zone setup for test scenarios]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test zone README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
|
||||
This document specifies defined test zones for test case [Zone09].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [Zone09] is run on a test zone. The
|
||||
message tags are defined in the test case ([Zone09]) and the scenarios are
|
||||
defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test zone README file].
|
||||
|
||||
|
||||
## Test zone names
|
||||
|
||||
The test zone for each test scenario in this document is a subdomain delegated
|
||||
from the base name (`zone09.xa`) and that subdomain having the same name as the
|
||||
scenario except where the test domain must be the root zone, a TLD or a domain
|
||||
under `.arpa`. The names of those zones are given in section
|
||||
"[Zone setup for test scenarios]" below.
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
Scenario name | Mandatory message tags | Forbidden message tags
|
||||
:---------------------|:--------------------------------------------------|:-------------------------------------------
|
||||
NO-RESPONSE-MX-QUERY | Z09_NO_RESPONSE_MX_QUERY | (none)
|
||||
UNEXPECTED-RCODE-MX | Z09_UNEXPECTED_RCODE_MX | (none)
|
||||
NON-AUTH-MX-RESPONSE | Z09_NON_AUTH_MX_RESPONSE | (none)
|
||||
INCONSISTENT-MX | Z09_INCONSISTENT_MX, Z09_MX_FOUND Z09, NO_MX_FOUND, Z09_MX_DATA | Z09_MISSING_MAIL_TARGET
|
||||
INCONSISTENT-MX-DATA | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA | Z09_MISSING_MAIL_TARGET, Z09_NULL_MX_NON_ZERO_PREF, Z09_NULL_MX_WITH_OTHER_MX, Z09_ROOT_EMAIL_DOMAIN, Z09_TLD_EMAIL_DOMAIN
|
||||
NULL-MX-WITH-OTHER-MX | Z09_NULL_MX_WITH_OTHER_MX | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_ROOT_EMAIL_DOMAIN, Z09_TLD_EMAIL_DOMAIN
|
||||
NULL-MX-NON-ZERO-PREF | Z09_NULL_MX_NON_ZERO_PREF | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_ROOT_EMAIL_DOMAIN, Z09_TLD_EMAIL_DOMAIN
|
||||
TLD-EMAIL-DOMAIN | Z09_TLD_EMAIL_DOMAIN | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
|
||||
ROOT-EMAIL-DOMAIN | Z09_ROOT_EMAIL_DOMAIN | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
|
||||
MX-DATA | Z09_MX_DATA | Z09_INCONSISTENT_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
|
||||
NULL-MX | (none) | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
|
||||
NO-MX-SLD | Z09_MISSING_MAIL_TARGET | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
|
||||
NO-MX-TLD | (none) | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
|
||||
NO-MX-ARPA | (none) | Z09_INCONSISTENT_MX_DATA, Z09_MX_DATA, Z09_MISSING_MAIL_TARGET, Z09_TLD_EMAIL_DOMAIN, Z09_ROOT_EMAIL_DOMAIN, Z09_NULL_MX_WITH_OTHER_MX, Z09_NULL_MX_NON_ZERO_PREF
|
||||
|
||||
|
||||
## Zone setup for test scenarios
|
||||
|
||||
Assumptions for the zone setup for the test scenarios:
|
||||
* Only MX records in apex are considered.
|
||||
* Unless otherwise stated, all name servers respond authoritatively with the
|
||||
SOA record on SOA queries.
|
||||
* Unless otherwise stated, all name servers respond authoritatively with (or
|
||||
without) MX records on MX queries.
|
||||
* Unless otherwise stated, all responses are authoritative and with [RCODE Name]
|
||||
"NoError".
|
||||
|
||||
### NO-RESPONSE-MX-QUERY
|
||||
* Zone: "no-response-mx-query.zone09.xa."
|
||||
* The zone has two name servers.
|
||||
* Both name servers return an authoritative answer on SOA query.
|
||||
* One name server does not respond on MX query.
|
||||
|
||||
### UNEXPECTED-RCODE-MX
|
||||
* Zone: "unexpected-rcode-mx.zone09.xa."
|
||||
* The zone has two name servers.
|
||||
* Both name servers return an authoritative answer on SOA query.
|
||||
* One name server returns with any [RCODE Name] except "NoError".
|
||||
|
||||
### NON-AUTH-MX-RESPONSE
|
||||
* Zone: "non-auth-mx-response.zone09.xa."
|
||||
* The zone has two name servers.
|
||||
* Both name server return an authoritative answer on SOA query.
|
||||
* One name server returns with [RCODE Name] "NoError" and non-AA on MX query.
|
||||
|
||||
### INCONSISTENT-MX
|
||||
* Zone: "inconsistent-mx.zone09.xa."
|
||||
* The zone has two name servers.
|
||||
* One name server respond with a non-Null MX RRset.
|
||||
* The other responds without MX RRset (NODATA).
|
||||
|
||||
### INCONSISTENT-MX-DATA
|
||||
* Zone: "inconsistent-mx-data.zone09.xa."
|
||||
* The zone has two name servers.
|
||||
* Both name servers respond with an MX RRset.
|
||||
* The two MX RRsets are not equal.
|
||||
|
||||
### NULL-MX-WITH-OTHER-MX
|
||||
* Zone: "null-mx-with-other-mx.zone09.xa."
|
||||
* All name servers respond with the same MX RRset.
|
||||
* The MX RRset is a mix of Null MX and non-Null MX.
|
||||
|
||||
### NULL-MX-NON-ZERO-PREF
|
||||
* Zone: "null-mx-non-zero-pref.zone09.xa."
|
||||
* All name servers respond with the same MX RRset.
|
||||
* The MX RRset is a single MX record.
|
||||
* The MX record is a Null MX with a non-zero preference.
|
||||
|
||||
### TLD-EMAIL-DOMAIN
|
||||
* Zone: "tld-email-domain-zone09." (TLD, dash "-", not dot ".")
|
||||
* The test zone is a TLD zone.
|
||||
* All name servers respond with the same MX RRset.
|
||||
* All MX records are non-Null MX.
|
||||
|
||||
### ROOT-EMAIL-DOMAIN
|
||||
* Zone: "." (root zone)
|
||||
* The test zone is the root zone.
|
||||
* All name servers respond with the same MX RRset.
|
||||
* All MX records are non-Null MX.
|
||||
|
||||
### MX-DATA
|
||||
* Zone: "mx-data.zone09.xa."
|
||||
* All name servers respond with the same MX RRset.
|
||||
* All MX records are non-Null MX.
|
||||
|
||||
### NULL-MX
|
||||
* Zone: "null-mx.zone09.xa."
|
||||
* All name servers respond with the same MX RRset.
|
||||
* The MX RRset has a single, valid NULL MX.
|
||||
|
||||
### NO-MX-SLD
|
||||
* Zone: "no-mx-sld.zone09.xa."
|
||||
* The test zone is neither root, TLD or under .ARPA.
|
||||
* All name servers respond with no MX RRset (NODATA).
|
||||
|
||||
### NO-MX-TLD
|
||||
* Zone: "no-mx-tld-zone09." (TLD, dash "-", not dot ".")
|
||||
* The test zone is a TLD.
|
||||
* All name servers respond with no MX RRset (NODATA).
|
||||
|
||||
### NO-MX-ARPA
|
||||
* Zone: "no-mx-arpa.zone09.arpa."
|
||||
* The test zone is under .ARPA.
|
||||
* All name servers respond with no MX RRset (NODATA).
|
||||
|
||||
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Test zone README file]: ../README.md
|
||||
[Zone setup for test scenarios]: #zone-setup-for-test-scenarios
|
||||
[Zone09]: ../../tests/Zone-TP/zone09.md
|
||||
@@ -0,0 +1,340 @@
|
||||
# Specification of test scenarios for Zone11
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Background](#background)
|
||||
* [Test Case](#test-case)
|
||||
* [Test scenarios](#test-scenarios)
|
||||
* [Test zone names](#test-zone-names)
|
||||
* [All message tags](#all-message-tags)
|
||||
* [Test scenarios and message tags](#test-scenarios-and-message-tags)
|
||||
* [Test scenarios and setup of test zones]
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
See the [test scenario README file].
|
||||
|
||||
|
||||
## Test Case
|
||||
|
||||
This document specifies defined test scenarios for test case [Zone11].
|
||||
|
||||
|
||||
## Test scenarios
|
||||
|
||||
The purpose of the test scenarios is to cover all reasonable contexts where
|
||||
different message tags are outputted when [Zone11] is run on a test zone.
|
||||
The message tags are defined in the test case ([Zone11]) and the scenarios
|
||||
are defined below.
|
||||
|
||||
The test scenarios are structured as stated in the [test scenario README file].
|
||||
|
||||
## Test zone names
|
||||
|
||||
Unless specified otherwise, the test zone for each test scenario in this
|
||||
document is a subdomain delegated from the base name (`zone11.xa`) and that
|
||||
subdomain having the same name as the scenario. The names of those zones are
|
||||
given in section "[Test scenarios and setup of test zones]" below.
|
||||
|
||||
## All message tags
|
||||
|
||||
The test case can output any of these message tags, but not necessarily in any
|
||||
combination. See [Zone11] for the specification of the tags.
|
||||
|
||||
* Z11_DIFFERENT_SPF_POLICIES_FOUND
|
||||
* Z11_INCONSISTENT_SPF_POLICIES
|
||||
* Z11_NO_SPF_FOUND
|
||||
* Z11_NO_SPF_NON_MAIL_DOMAIN
|
||||
* Z11_NON_NULL_SPF_NON_MAIL_DOMAIN
|
||||
* Z11_NULL_SPF_NON_MAIL_DOMAIN
|
||||
* Z11_SPF_MULTIPLE_RECORDS
|
||||
* Z11_SPF_SYNTAX_ERROR
|
||||
* Z11_SPF_SYNTAX_OK
|
||||
* Z11_UNABLE_TO_CHECK_FOR_SPF
|
||||
|
||||
|
||||
## Test scenarios and message tags
|
||||
|
||||
If a message tag is not listed for the scenario, its presence or non-presence is
|
||||
irrelevant to the test scenario and must be ignored.
|
||||
|
||||
| Scenario name | Mandatory message tags | Forbidden message tags |
|
||||
|:-----------------------|:----------------------------------------------------------------|:-----------------------|
|
||||
| GOOD-SPF-1 | Z11_SPF_SYNTAX_OK | 2) |
|
||||
| GOOD-SPF-2 | Z11_SPF_SYNTAX_OK | 2) |
|
||||
| SAME-SPF-DIFFERENT-TXT | Z11_SPF_SYNTAX_OK | 2) |
|
||||
| NO-TXT | Z11_NO_SPF_FOUND | 2) |
|
||||
| NO-SPF-TXT | Z11_NO_SPF_FOUND | 2) |
|
||||
| NO-SPF-ROOT-ZONE | Z11_NO_SPF_NON_MAIL_DOMAIN | 2) |
|
||||
| NO-SPF-TLD-ZONE | Z11_NO_SPF_NON_MAIL_DOMAIN | 2) |
|
||||
| NO-SPF-ARPA-ZONE | Z11_NO_SPF_NON_MAIL_DOMAIN | 2) |
|
||||
| NULL-SPF-ROOT-ZONE | Z11_NULL_SPF_NON_MAIL_DOMAIN | 2) |
|
||||
| NULL-SPF-TLD-ZONE | Z11_NULL_SPF_NON_MAIL_DOMAIN | 2) |
|
||||
| NULL-SPF-ARPA-ZONE | Z11_NULL_SPF_NON_MAIL_DOMAIN | 2) |
|
||||
| NON-NULL-SPF-ROOT-ZONE | Z11_NON_NULL_SPF_NON_MAIL_DOMAIN | 2) |
|
||||
| NON-NULL-SPF-TLD-ZONE | Z11_NON_NULL_SPF_NON_MAIL_DOMAIN | 2) |
|
||||
| NON-NULL-SPF-ARPA-ZONE | Z11_NON_NULL_SPF_NON_MAIL_DOMAIN | 2) |
|
||||
| INVALID-SYNTAX-1 | Z11_SPF_SYNTAX_ERROR | 2) |
|
||||
| INVALID-SYNTAX-2 | Z11_SPF_SYNTAX_ERROR | 2) |
|
||||
| INVALID-SYNTAX-3 | Z11_SPF_SYNTAX_ERROR | 2) |
|
||||
| NON-AUTH-TXT | Z11_UNABLE_TO_CHECK_FOR_SPF | 2) |
|
||||
| SERVFAIL | Z11_UNABLE_TO_CHECK_FOR_SPF | 2) |
|
||||
| INCONSISTENT-SPF | Z11_INCONSISTENT_SPF_POLICIES, Z11_DIFFERENT_SPF_POLICIES_FOUND | 2) |
|
||||
| SPF-MISSING-ON-ONE | Z11_INCONSISTENT_SPF_POLICIES, Z11_DIFFERENT_SPF_POLICIES_FOUND | 2) |
|
||||
| ALL-DIFFERENT-SPF | Z11_INCONSISTENT_SPF_POLICIES, Z11_DIFFERENT_SPF_POLICIES_FOUND | 2) |
|
||||
| MULTIPLE-SPF-RECORDS | Z11_SPF_MULTIPLE_RECORDS | 2) |
|
||||
|
||||
|
||||
* (1) All tags except for those specified as "Forbidden message tags" (no instances for these test scenarios)
|
||||
* (2) All tags except for those specified as "Mandatory message tags"
|
||||
|
||||
## Test scenarios and setup of test zones
|
||||
|
||||
### Default zone configuration
|
||||
|
||||
Unless otherwise specified in the specific scenario specification, the test zone
|
||||
for the scenario will follow the default setup as stated below. The `child zone`
|
||||
is the zone to be tested for the scenario.
|
||||
|
||||
* The child zone is `SCENARIO.zone11.xa`.
|
||||
* There is a zone file for the child zone.
|
||||
* It is served by two name servers named ns1 and ns2.child.zone11.xa.
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 address records.
|
||||
* The parent zone is `zone11.xa`.
|
||||
* It is served by two in-bailiwick name servers named ns1 and ns2.zone11.xa.
|
||||
* ns1 and ns2 have the same zone content.
|
||||
* ns1 and ns2 have both IPv4 and IPv6 glue.
|
||||
* The records matching glue in the zone are complete.
|
||||
* All responses will have the AA bit set.
|
||||
* All responses will have the [RCODE Name] "NoError".
|
||||
|
||||
### GOOD-SPF-1
|
||||
|
||||
A zone whose SPF record is the shortest legal SPF record possible, namely the
|
||||
string `v=spf1`. It is valid syntax, albeit not very useful.
|
||||
|
||||
* Zone: good-spf-1.zone11.xa
|
||||
* The TXT RRset at the apex contains one TXT record with the text `v=spf1`.
|
||||
|
||||
### GOOD-SPF-2
|
||||
|
||||
A zone whose SPF record is well-formed and contains at least one term.
|
||||
|
||||
* Zone: good-spf-2.zone11.xa
|
||||
* The TXT RRset at the apex contains one TXT record starting with the text
|
||||
`v=spf1`, followed by a space, followed by one or more legal SPF terms.
|
||||
|
||||
### SAME-SPF-DIFFERENT-TXT
|
||||
|
||||
A zone whose SPF record is identical despite inconsistent TXT RRset records at
|
||||
the apex.
|
||||
|
||||
* Zone: same-spf-different-txt.zone11.xa
|
||||
* ns1 serves a TXT RRset containing one SPF record and one non-SPF record.
|
||||
* ns2 serves a different TXT RRset containing one SPF record and one non-SPF
|
||||
record. The SPF record served by ns2 is identical to the one served
|
||||
by ns1. The non-SPF record served by ns2 is different from the one served
|
||||
by ns1.
|
||||
|
||||
### NO-TXT
|
||||
|
||||
A zone containing no TXT record at the apex.
|
||||
|
||||
* Zone: no-txt.zone11.xa
|
||||
* The TXT RRset at the apex is empty.
|
||||
|
||||
### NO-SPF-TXT
|
||||
|
||||
A zone containing at least one TXT record, but none of the TXT after
|
||||
concatenating all strings, gives a string starting with `v=spf1`.
|
||||
|
||||
* Zone: no-spf-txt.zone11.xa
|
||||
* The TXT RRset at the apex is non-empty, but none of the TXT records are
|
||||
recognized as SPF records.
|
||||
|
||||
### NO-SPF-ROOT-ZONE
|
||||
|
||||
A root zone without SPF records.
|
||||
|
||||
* Zone: "." (root zone)
|
||||
* It is served by ns1 and ns2.no-spf.root-servers.zone11.xa.
|
||||
* The TXT RRset at the apex of the root zone is empty.
|
||||
|
||||
### NO-SPF-TLD-ZONE
|
||||
|
||||
A TLD zone without SPF records.
|
||||
|
||||
* Zone: no-spf-zone11
|
||||
* It is served by ns1 and ns2.zone11.xa.
|
||||
* The TXT RRset at the apex of the TLD zone is empty.
|
||||
|
||||
### NO-SPF-ARPA-ZONE
|
||||
|
||||
A zone in .arpa without SPF records.
|
||||
|
||||
* Zone: no-spf-arpa-zone.zone11.arpa
|
||||
* It is served by ns1 and ns2.child.zone11.xa.
|
||||
* The TXT RRset at the apex of the zone is empty.
|
||||
|
||||
### NULL-SPF-ROOT-ZONE
|
||||
|
||||
A root zone with a null SPF record.
|
||||
|
||||
* Zone: "." (root zone)
|
||||
* It is served by ns1 and ns2.null-spf.root-servers.zone11.xa.
|
||||
* The TXT RRset at the apex of the root zone contains one TXT record with the
|
||||
string `v=spf1 -all`.
|
||||
|
||||
### NULL-SPF-TLD-ZONE
|
||||
|
||||
A TLD zone with null SPF records.
|
||||
|
||||
* Zone: null-spf-zone11
|
||||
* It is served by ns1 and ns2.zone11.xa.
|
||||
* The TXT RRset at the apex of the TLD zone contains one TXT record with the
|
||||
string `v=spf1 -all`.
|
||||
|
||||
### NULL-SPF-ARPA-ZONE
|
||||
|
||||
A zone in .arpa with a null SPF record.
|
||||
|
||||
* Zone: null-spf-arpa-zone.zone11.arpa
|
||||
* It is served by ns1 and ns2.child.zone11.xa.
|
||||
* The TXT RRset at the apex of the zone contains one TXT record with the
|
||||
string `v=spf1 -all`.
|
||||
|
||||
### NON-NULL-SPF-ROOT-ZONE
|
||||
|
||||
A root zone with a non-null SPF record.
|
||||
|
||||
* Zone: "." (root zone)
|
||||
* It is served by ns1 and ns2.non-null-spf.root-servers.zone11.xa.
|
||||
* The TXT RRset at the apex of the root zone contains one TXT record with an
|
||||
SPF record that isn’t null (i.e. permits at least one IP address).
|
||||
|
||||
### NON-NULL-SPF-TLD-ZONE
|
||||
|
||||
A TLD zone with a non-null SPF record.
|
||||
|
||||
* Zone: non-null-spf-zone11
|
||||
* It is served by ns1 and ns2.zone11.xa.
|
||||
* The TXT RRset at the apex of the TLD zone contains one TXT record with an
|
||||
SPF record that isn’t null (i.e. permits at least one IP address).
|
||||
|
||||
### NON-NULL-SPF-ARPA-ZONE
|
||||
|
||||
A zone in .arpa with a non-null SPF record.
|
||||
|
||||
* Zone: non-null-spf-arpa-zone.zone11.arpa
|
||||
* It is served by ns1 and ns2.child.zone11.xa.
|
||||
* The TXT RRset at the apex of the zone contains one TXT record with an SPF
|
||||
record that isn’t null (i.e. permits at least one IP address).
|
||||
|
||||
### INVALID-SYNTAX-1
|
||||
|
||||
A zone whose SPF record is syntactically invalid.
|
||||
|
||||
* Zone: invalid-syntax-1.zone11.xa
|
||||
* The TXT RRset at the apex contains one SPF record with invalid syntax,
|
||||
i.e. beginning with `v=spf1` followed by whitespace but not compliant with
|
||||
the ABNF grammar described in [RFC 7208, Section 4.5][RFC 7208#4.5] and
|
||||
following sections.
|
||||
|
||||
### INVALID-SYNTAX-2
|
||||
|
||||
Like INVALID-SYNTAX-1, but two of the name server names in the delegation and in
|
||||
the zone point to the same IP address. This scenario is there to ensure that
|
||||
all name servers that serve an ill-formed SPF policy are reported, even if two
|
||||
of them have the same IP address.
|
||||
|
||||
* Zone: invalid-syntax-2.zone11.xa
|
||||
* It is served by ns1a, ns1b, and ns2.invalid-syntax.zone11.xa.
|
||||
* ns1a and ns1b resolve to the same IPv4 and IPv6 address as
|
||||
ns1.child.zone11.xa.
|
||||
* ns2 resolves to the same IPv4 and IPv6 address as ns2.child.zone11.xa.
|
||||
* The TXT RRset at the apex contains one SPF record with invalid syntax,
|
||||
i.e. beginning with `v=spf1` followed by whitespace but not compliant with
|
||||
the ABNF grammar described in [RFC 7208, Section 4.5][RFC 7208#4.5] and
|
||||
following sections.
|
||||
|
||||
### INVALID-SYNTAX-3
|
||||
|
||||
A zone whose SPF record contains a few random bytes, with a few non-ASCII
|
||||
bytes among those.
|
||||
|
||||
* Zone: invalid-syntax-3.zone11.xa
|
||||
* The TXT RRset at the apex contains one SPF record beginning with `v=spf1`,
|
||||
followed by some whitespace and containing some random bytes outside the
|
||||
printable ASCII range, which is not compliant with the ABNF grammar
|
||||
described in [RFC 7208, Section 4.5][RFC 7208#4.5] and following sections.
|
||||
|
||||
### NON-AUTH-TXT
|
||||
|
||||
A zone containing one SPF record in its TXT RRset, but served from name
|
||||
servers that fail to set the AA bit in their responses.
|
||||
|
||||
* Zone: non-auth-txt.zone11.xa
|
||||
* The TXT RRset at the apex contains one SPF record.
|
||||
* Both name servers serve the aforementioned TXT RRset with the AA bit unset
|
||||
in the response header.
|
||||
|
||||
### SERVFAIL
|
||||
|
||||
A zone where responses to queries for the TXT RRset have an RCODE different
|
||||
from NoError.
|
||||
|
||||
* Zone: servfail.zone11.xa
|
||||
* Responses to queries for the TXT RRset at the zone’s apex have the
|
||||
[RCODE Name] "ServFail".
|
||||
|
||||
### INCONSISTENT-SPF
|
||||
|
||||
A zone that serves different SPF records depending on the name server being
|
||||
queried.
|
||||
|
||||
* Zone: inconsistent-spf.zone11.xa
|
||||
* ns1 serves a TXT RRset at the apex containing one SPF record.
|
||||
* ns2 serves a different TXT RRset at the apex containing one SPF record
|
||||
that is also different from the SPF record served by ns1.
|
||||
|
||||
### SPF-MISSING-ON-ONE
|
||||
|
||||
A zone that serves identical SPF records, except on one of the name servers.
|
||||
|
||||
* Zone: spf-missing-on-one.zone11.xa
|
||||
* The zone is delegated to three name servers named ns1, ns2 and
|
||||
ns3.child.zone11.xa.
|
||||
* ns2 and ns3 serve an identical TXT RRset at the apex containing one SPF
|
||||
record.
|
||||
* ns1 serves a different TXT RRset at the apex without an SPF record.
|
||||
|
||||
### ALL-DIFFERENT-SPF
|
||||
|
||||
A zone that serves different SPF records on all of its name servers.
|
||||
|
||||
* Zone: all-different-spf.zone11.xa
|
||||
* The zone is delegated to three name servers named ns1, ns2 and
|
||||
ns3.child.zone11.xa.
|
||||
* ns1 serves a TXT RRset at the apex containing one SPF record
|
||||
* ns2 serves a different TXT RRset at the apex containing one SPF record
|
||||
that is also different.
|
||||
* ns3 serves another different TXT RRset at the apex containing one SPF
|
||||
record that is different from the two previous records.
|
||||
|
||||
### MULTIPLE-SPF-RECORDS
|
||||
|
||||
A zone whose TXT RRset at the apex contains more than one SPF record.
|
||||
|
||||
* Zone: multiple-spf-records.zone11.xa
|
||||
* The TXT RRset at the apex contains more than one SPF record.
|
||||
|
||||
|
||||
[Zone11]: ../../tests/Zone-TP/zone11.md
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[RFC 7208]: https://www.rfc-editor.org/rfc/rfc7208
|
||||
[RFC 7208#4.5]: https://www.rfc-editor.org/rfc/rfc7208#section-4.5
|
||||
[Test scenario README file]: ../README.md
|
||||
[Test scenarios and setup of test zones]: #test-scenarios-and-setup-of-test-zones
|
||||
@@ -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|
|
||||
@@ -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
|
||||
@@ -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.
|
||||
@@ -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).
|
||||
@@ -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
|
||||
@@ -0,0 +1,22 @@
|
||||
# Basic Test Plan
|
||||
|
||||
These are tests of a domain's most basic functionality. If these fail,
|
||||
it will be hard or impossible to perform any other tests at all. The
|
||||
test code should be constructed so that these tests are always run, even
|
||||
if a subset of tests is asked for that would not normally include them.
|
||||
|
||||
This document uses the terminology defined in the [Master Test Plan].
|
||||
|
||||
|
||||
[Master Test Plan]: ../MasterTestPlan.md
|
||||
[Test Case README]: ../README.md
|
||||
|
||||
<!-- Content until EOF generated by script updateTestPlanReadme.pl from Zonemaster/Zonemaster utils directory -->
|
||||
|
||||
## Test cases list
|
||||
|
||||
|Test Case |Test Case Description|
|
||||
|:---------|:--------------------|
|
||||
|[BASIC01](basic01.md)|Check for the parent zone and the zone itself|
|
||||
|[BASIC02](basic02.md)|The domain must have at least one working name server|
|
||||
|[BASIC03](basic03.md)|The _Broken but functional_ test|
|
||||
385
zonemaster/docs/public/specifications/tests/Basic-TP/basic01.md
Normal file
385
zonemaster/docs/public/specifications/tests/Basic-TP/basic01.md
Normal file
@@ -0,0 +1,385 @@
|
||||
# BASIC01: Check for the parent zone and the zone itself
|
||||
|
||||
## Test case identifier
|
||||
**BASIC01**
|
||||
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Objective](#objective)
|
||||
* [Scope](#scope)
|
||||
* [Inputs](#inputs)
|
||||
* [Summary](#summary)
|
||||
* [Test procedure]
|
||||
* [Outcome(s)](#outcomes)
|
||||
* [Special procedural requirements](#special-procedural-requirements)
|
||||
* [Intercase dependencies](#intercase-dependencies)
|
||||
* [Terminology](#terminology)
|
||||
|
||||
|
||||
## Objective
|
||||
|
||||
In order for a domain (zone) to work, it must be delegated from a
|
||||
zone higher up in the DNS hierarchy (a parent domain or zone).
|
||||
This Test Case will determine if parent zone and child zones,
|
||||
respectively, exist.
|
||||
|
||||
If the test is an [undelegated test], however, it can be tested even it is not
|
||||
delegated. Parent zone for [undelegated test] is disregarded.
|
||||
|
||||
If the zone to be tested is the root zone, it has no parent or
|
||||
delegation and will always pass this Test Case.
|
||||
|
||||
If no parent can be determined, there cannot be any delegation.
|
||||
|
||||
|
||||
## Scope
|
||||
|
||||
The algorithm in this test case should match the algorithm in method
|
||||
[Get parent zone].
|
||||
|
||||
If the child zone does not exist (is not delegated), the only
|
||||
test case to be run after this test case is [BASIC03]. However,
|
||||
if the test type is an [undelegated test], then all other test cases
|
||||
can be run even if the child zone is not delegated.
|
||||
|
||||
|
||||
## Inputs
|
||||
|
||||
Input for this Test Case:
|
||||
* "Child Zone" - The label of the domain name (zone) to be tested
|
||||
* "Root Name Servers" - The IANA [List of Root Servers]
|
||||
* "Test Type" - The test type with values "[undelegated test]" or
|
||||
"normal test".
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
Message Tag | Level | Arguments | Message ID for message tag
|
||||
:--------------------------|:------|:-----------------------------------|:--------------------------
|
||||
B01_CHILD_FOUND |INFO | domain | The zone "{domain}" is found.
|
||||
B01_CHILD_IS_ALIAS |NOTICE |domain_child, domain_target, ns_list| "{domain_child}" is not a zone. It is an alias for "{domain_target}". Run a test for "{domain_target}" instead. Returned from name servers "{ns_list}".
|
||||
B01_INCONSISTENT_ALIAS |ERROR | domain | The alias for "{domain}" is inconsistent between name servers.
|
||||
B01_INCONSISTENT_DELEGATION|ERROR |domain_child, domain_parent, ns_list| The name servers for parent zone "{domain_parent}" give inconsistent delegation of "{domain_child}". Returned from name servers "{ns_list}".
|
||||
B01_NO_CHILD |ERROR | domain_child, domain_super | "{domain_child}" does not exist as a DNS zone. Try to test "{domain_super}" instead.
|
||||
B01_PARENT_DISREGARDED |INFO | | This is a test of an undelegated domain so finding the parent zone is disregarded.
|
||||
B01_PARENT_FOUND |INFO | domain, ns_list | The parent zone is "{domain}" as returned from name servers "{ns_list}".
|
||||
B01_PARENT_NOT_FOUND |WARNING| | The parent zone cannot be found.
|
||||
B01_PARENT_UNDETERMINED |WARNING| ns_list | The parent zone cannot be determined on name servers "{ns_list}".
|
||||
B01_ROOT_HAS_NO_PARENT |INFO | | This is a test of the root zone which has no parent zone.
|
||||
B01_SERVER_ZONE_ERROR |DEBUG | query_name, rrtype, ns | Unexpected response on query for "{query_name}" with query type "{rrtype}" to "{ns}".
|
||||
|
||||
|
||||
The value in the Level column is the default severity level of the message. The
|
||||
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
|
||||
[Severity Level Definitions] document.
|
||||
|
||||
The argument names in the Arguments column lists the arguments used in the
|
||||
message. The argument names are defined in the [argument list].
|
||||
|
||||
The name server names are assumed to be available at the time when the msgid
|
||||
is created, if the argument name is "ns" or "ns_list" even when in the
|
||||
"[Test procedure]" below it is only referred to the IP address of the name
|
||||
servers.
|
||||
|
||||
|
||||
## Test procedure
|
||||
|
||||
In this section and unless otherwise specified below, the terms "[DNS Query]"
|
||||
follow the specification for DNS queries as specified in
|
||||
[DNS Query and Response Defaults]. The handling of the DNS responses on the
|
||||
DNS queries follow, unless otherwise specified below, what is specified for
|
||||
[DNS Response] in the same specification.
|
||||
|
||||
1. If the *Child Zone* is the root zone (".") then:
|
||||
1. Output *[B01_CHILD_FOUND]* with zone name (".").
|
||||
2. Output *[B01_ROOT_HAS_NO_PARENT]*.
|
||||
3. Exit the test case.
|
||||
|
||||
2. If *Test Type* is "[undelegated test]", then:
|
||||
1. Output *[B01_CHILD_FOUND]* with zone name equal to *Child Zone*.
|
||||
2. Output *[B01_PARENT_DISREGARDED]*.
|
||||
3. Exit the test case.
|
||||
|
||||
3. Create [DNS queries][DNS Query]:
|
||||
1. Query type DNAME and query name *Child Zone* ("DNAME Child Query").
|
||||
|
||||
4. Create the following empty sets:
|
||||
1. Name server IP and zone name ("Remaining Servers").
|
||||
2. Name server IP and query name ("Handled Servers").
|
||||
3. Parent name server IP and parent zone name ("Parent Found").
|
||||
4. Parent name server IP and parent zone name ("Delegation Found").
|
||||
5. Parent name server IP and parent zone name ("AA NXDomain Found").
|
||||
6. Parent name server IP and parent zone name ("AA SOA Found").
|
||||
7. Parent name server IP and parent zone name ("AA CNAME Found").
|
||||
8. Parent name server IP and parent zone name ("CNAME with Referral Found").
|
||||
9. Parent name server IP, parent zone name and DNAME target
|
||||
("AA DNAME Found").
|
||||
10. Parent name server IP and parent zone name ("AA NODATA Found").
|
||||
|
||||
5. Insert all addresses from *Root Name Servers* and the root zone name into the
|
||||
*Remaining Servers* set.
|
||||
|
||||
> In the loop below, the steps tries to capture the name of the parent zone of
|
||||
> **Child Zone** and the IP addresses of the name servers for that parent zone.
|
||||
> This is done using a modified version of the "QNAME minimization" technique
|
||||
> [RFC 9156]. SOA is the query type used for traversing the tree.
|
||||
|
||||
6. While the *Remaining Servers* is non-empty pick next name server IP address
|
||||
and zone name from the set ("Server Address" and "Zone Name") and do:
|
||||
|
||||
1. Extract and remove *Server Address* including its *Zone Name* from
|
||||
*Remaining Servers*.
|
||||
2. Insert *Server Address* and *Zone Name* into *Handled Servers*.
|
||||
3. Create [DNS queries][DNS Query]:
|
||||
1. Query type SOA and query name *Zone Name* ("Zone Name SOA Query").
|
||||
2. Query type NS and query name *Zone Name* ("Zone Name NS Query").
|
||||
4. [Send] *Zone Name SOA Query* to *Server Address*.
|
||||
5. Output [B01_SERVER_ZONE_ERROR] with query name *Zone Name*, [query type]
|
||||
SOA and name server IP *Server Address* and go to next server in
|
||||
*Remaining Servers* if one or more of the following matches:
|
||||
* No DNS response.
|
||||
* [RCODE Name] different from NoError in response.
|
||||
* AA bit not set in response.
|
||||
* Not exactly one SOA record in answer section
|
||||
* Owner name of SOA record is not *Zone Name*.
|
||||
6. [Send] *Zone Name NS Query* to *Server Address*.
|
||||
7. Output [B01_SERVER_ZONE_ERROR] with query name *Zone Name*, [query type]
|
||||
NS and name server IP *Server Address* and go to next server in
|
||||
*Remaining Servers* if one or more of the following matches:
|
||||
* No DNS response.
|
||||
* [RCODE Name] different from NoError in response.
|
||||
* AA bit not set in response.
|
||||
* No NS records in answer section
|
||||
* Owner name of any of the NS records is not *Zone Name*.
|
||||
8. Extract the name server names from the NS records and any address records
|
||||
in the additional section.
|
||||
9. Do [DNS Lookup] of name server names (A and AAAA) not already listed in the
|
||||
additional section of the response.
|
||||
1. For each IP address add the IP address and *Zone Name* to the
|
||||
*Remaining Servers* set unless the IP address is already listed in
|
||||
*Handled Servers* together with *Zone Name*.
|
||||
2. Ignore any failing lookups or lookups resulting in NODATA or NXDOMAIN.
|
||||
10. Create "Intermediate Query Name" by copying *Zone name* as start value.
|
||||
11. Run a loop processing *Server Address* (jumps back here from the steps
|
||||
below).
|
||||
1. Extend *Intermediate Query Name* by adding one more label to the left
|
||||
by copying the equivalent label from *Child Zone*. (See "Example 1"
|
||||
below.)
|
||||
2. Create a [DNS Query] with query name
|
||||
*Intermediate Query Name* and [query type] SOA
|
||||
("Intermediate SOA query").
|
||||
3. [Send] *Intermediate SOA Query* to *Server Address*. (See "Example 2"
|
||||
below.)
|
||||
4. Output [B01_SERVER_ZONE_ERROR] with query name *Intermediate Query Name*
|
||||
and [query type] SOA and name server IP *Server Address* and go to next
|
||||
server in *Remaining Servers* if there is no DNS response.
|
||||
5. If the response has exactly one SOA record with owner name
|
||||
*Intermediate Query Name* in the answer section, with the AA bit
|
||||
set and [RCODE Name] NoError then do:
|
||||
1. If *Intermediate Query Name* is equal to *Child Zone* then
|
||||
1. Save *Server Address* and *Zone Name* to the *Parent Found* set
|
||||
and to the *AA SOA Found* set.
|
||||
2. Go to next server in *Remaining Servers*.
|
||||
2. Else do:
|
||||
1. Create a [DNS query][DNS Query] with query name
|
||||
*Intermediate Query Name* and [query type] NS
|
||||
("Intermediate NS query").
|
||||
2. [Send] *Intermediate NS Query* to *Server Address*.
|
||||
3. Output [B01_SERVER_ZONE_ERROR] with query name
|
||||
*Intermediate NS Name* and [query type] NS and name server IP
|
||||
*Server Address* and go to next server in *Remaining Servers* if
|
||||
one or more of the following matches:
|
||||
* No DNS response.
|
||||
* [RCODE Name] different from NoError in response.
|
||||
* AA bit not set in response.
|
||||
* No NS records in answer section.
|
||||
* Owner name of any of the NS records is not *Intermediate Query Name*.
|
||||
4. Extract the name server names from the NS records and any address
|
||||
records in the additional section.
|
||||
5. Do [DNS Lookup] of name server names (A and AAAA) not already
|
||||
listed in the additional section of the response.
|
||||
6. For each IP address add the IP address and *Intermediate Query Name*
|
||||
to the *Remaining Servers* set unless the IP address is already
|
||||
listed in *Handled Servers* together with *Intermediate Query Name*.
|
||||
7. Set *Zone Name* to *Intermediate Query Name*.
|
||||
8. Go back to the start of the loop.
|
||||
6. Else, if the [RCODE Name] is NXDomain and the AA is set then do:
|
||||
1. Save *Server Address* and *Zone Name* to the *AA NXDomain Found* set
|
||||
and the *Parent Found* set.
|
||||
2. Go to next server in *Remaining Servers*.
|
||||
7. Else, if the response contains a [Referral] of *Intermediate Query Name*
|
||||
then do:
|
||||
1. If *Intermediate Query Name* is equal to *Child Zone* then do:
|
||||
1. Save *Server Address* and *Zone Name* to the *Parent Found* set
|
||||
and to the *Delegation Found* set.
|
||||
2. Else do:
|
||||
1. Extract the name server names from the NS records and any glue
|
||||
records.
|
||||
2. Do [DNS Lookup] of name server names (A and AAAA) not already
|
||||
listed as glue record or records.
|
||||
3. For each IP address add *Server Address* and
|
||||
*Intermediate Query Name* to the *Remaining Servers* set unless
|
||||
*Server Address* is already listed in *Handled Servers* together
|
||||
with *Intermediate Query Name*.
|
||||
3. Go to next server in *Remaining Servers*.
|
||||
8. Else, if the [RCODE Name] is NoError and the AA is set then do:
|
||||
1. If *Intermediate Query Name* is not equal to *Child Zone* then
|
||||
go back to the start of the loop.
|
||||
2. Else do:
|
||||
1. If the response has a CNAME record with *Child Zone* as owner
|
||||
name in the answer section, then do:
|
||||
1. Save *Server Address* and *Zone Name* to the *Parent Found*
|
||||
set and to the *AA CNAME Found* set.
|
||||
2. Go to next server in *Remaining Servers*.
|
||||
2. Else do:
|
||||
1. [Send] a *DNAME Child Query* to the name server IP address.
|
||||
2. If there is a response with the AA flag set, the [RCODE Name]
|
||||
NoError and a DNAME record with *Child Zone* as owner name in
|
||||
the answer section, then
|
||||
1. Save *Server Address* and *Zone Name* to the *Parent Found*
|
||||
set.
|
||||
2. Save *Server Address*, *Zone Name* and the DNAME target
|
||||
(RDATA value) to the *AA DNAME Found* set.
|
||||
3. Else (no response or some other response than above) save the
|
||||
*Server Address* and *Zone Name* to the *Parent Found* set
|
||||
and to the *AA NODATA Found* set.
|
||||
4. Go to next server in *Remaining Servers*.
|
||||
9. Else, if the response is a [Referral] with a CNAME record with
|
||||
*Child Zone* as owner name in the answer section, then
|
||||
1. Save *Server Address* and *Zone Name* to the *Parent Found* set and
|
||||
to the *CNAME with Referral Found* set.
|
||||
2. Go to next server in *Remaining Servers*.
|
||||
10. Else, output [B01_SERVER_ZONE_ERROR] with query name
|
||||
*Intermediate NS Name*, [query type] SOA and name server IP
|
||||
*Server Address* and go to next server in *Remaining Servers*.
|
||||
|
||||
|
||||
7. If the *Parent Found* set is non-empty, then
|
||||
1. For each parent zone name output *[B01_PARENT_FOUND]*, parent zone name
|
||||
and the set of name server IP addresses for that name.
|
||||
2. If not all members of the set have the same parent zone then output
|
||||
*[B01_PARENT_UNDETERMINED]* and the whole set of name server IP addresses.
|
||||
|
||||
8. If the *Parent Found* set is empty, then output *[B01_PARENT_NOT_FOUND]*.
|
||||
|
||||
9. If one or both of the *Delegation Found* and the *AA SOA Found* sets are
|
||||
non-empty, then do:
|
||||
1. Output *[B01_CHILD_FOUND]* with *Child Zone*.
|
||||
2. If one or more of the following five sets are also non-empty then output
|
||||
*[B01_INCONSISTENT_DELEGATION]* with *Child Zone*, parent zone name and
|
||||
the combined set of name server IP addresses from all five sets.
|
||||
* *AA NXDomain Found*
|
||||
* *AA CNAME Found*
|
||||
* *CNAME with Referral Found*
|
||||
* *AA DNAME Found*
|
||||
* *AA NODATA Found*
|
||||
|
||||
10. If both of the *Delegation Found* and the *AA SOA Found* sets are empty, then
|
||||
do:
|
||||
1. Create "Superdomain" as a copy of *Child Zone* with the first label
|
||||
removed.
|
||||
2. Output *[B01_NO_CHILD]* with *Child zone* and *Superdomain*.
|
||||
|
||||
11. If the *AA DNAME Found* set is non-empty then do:
|
||||
1. For each DNAME target in the set output *[B01_CHILD_IS_ALIAS]* with name
|
||||
server IP list, *Child Zone* and the DNAME target.
|
||||
2. If not all members of the set have the same DNAME target, output
|
||||
*[B01_INCONSISTENT_ALIAS]* with *Child Zone*.
|
||||
|
||||
> Examples referred to from the steps.
|
||||
>
|
||||
> Example 1: If *Child Zone* is "foo.bar.xa" and *Intermediate Query Name* is "."
|
||||
> (root zone) then *Intermediate Query Name* becomes "xa". If it is "xa", it
|
||||
> will become "bar.xa" instead.
|
||||
>
|
||||
> Example 2: An "bar.xa SOA" query to a name server for "xa".
|
||||
|
||||
|
||||
## Outcome(s)
|
||||
|
||||
The outcome of this Test Case is "fail" if there is at least one message with
|
||||
the severity level *[ERROR]* or *[CRITICAL]*.
|
||||
|
||||
The outcome of this Test Case is "warning" if there is at least one message
|
||||
with the severity level *[WARNING]*, but no message with severity level
|
||||
*ERROR* or *CRITICAL*.
|
||||
|
||||
In other cases, no message or only messages with severity level *[INFO]* or
|
||||
*[NOTICE]*, the outcome of this Test Case is "pass".
|
||||
|
||||
|
||||
## Special procedural requirements
|
||||
|
||||
If either IPv4 or IPv6 transport is disabled, skip [Sending][Send]
|
||||
queries over that transport protocol. A message will be outputted reporting that
|
||||
the transport protocol has been skipped.
|
||||
|
||||
The *Child Zone* must be a valid name meeting
|
||||
"[Requirements and normalization of domain names in input]".
|
||||
|
||||
|
||||
## Intercase dependencies
|
||||
|
||||
None.
|
||||
|
||||
|
||||
## Terminology
|
||||
|
||||
* "Direct Subdomain" - Domain A is considered to be a "direct Subdomain" to
|
||||
domain B if domain A is just the addition of one label at the least significant
|
||||
(left) side, e.g. "foo.domain.com" is a direct subdomain to "domain.com".
|
||||
|
||||
* "DNS Lookup" - The term is used when a recursive lookup is used, though
|
||||
any changes to the DNS tree introduced by an [undelegated test] must be
|
||||
respected. Compare with "[Send]".
|
||||
|
||||
* "Non-Referral" - See "[Referral]".
|
||||
|
||||
* "Referral" - A DNS response with [RCODE Name] NoError, AA flag unset and NS
|
||||
records in the authority section. The answer section is empty or with CNAME
|
||||
record or records. If the query type is CNAME, then the answer section must be
|
||||
empty (does not apply to this test case). The additional section may contain
|
||||
address records (A and AAAA) for the name server names from the NS (glue
|
||||
records).
|
||||
|
||||
* "Send" - The term "send" (to an IP address) is used when a DNS query is sent to
|
||||
a specific name server. Compare with "[DNS Lookup]".
|
||||
|
||||
|
||||
[Argument list]: ../ArgumentsForTestCaseMessages.md
|
||||
[B01_CHILD_FOUND]: #Summary
|
||||
[B01_CHILD_IS_ALIAS]: #Summary
|
||||
[B01_INCONSISTENT_ALIAS]: #Summary
|
||||
[B01_INCONSISTENT_DELEGATION]: #Summary
|
||||
[B01_NO_CHILD]: #Summary
|
||||
[B01_PARENT_DISREGARDED]: #Summary
|
||||
[B01_PARENT_FOUND]: #Summary
|
||||
[B01_PARENT_NOT_FOUND]: #Summary
|
||||
[B01_PARENT_UNDETERMINED]: #Summary
|
||||
[B01_ROOT_HAS_NO_PARENT]: #Summary
|
||||
[B01_SERVER_ZONE_ERROR]: #Summary
|
||||
[Basic03]: basic03.md
|
||||
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
|
||||
[Direct Subdomain]: #terminology
|
||||
[DNS Lookup]: #terminology
|
||||
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
|
||||
[DNS Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dns-query
|
||||
[DNS Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dns-response
|
||||
[ERROR]: ../SeverityLevelDefinitions.md#error
|
||||
[Get parent zone]: ../MethodsV2.md#method-get-parent-ns-names-and-ip-addresses
|
||||
[INFO]: ../SeverityLevelDefinitions.md#info
|
||||
[List of Root Servers]: https://www.iana.org/domains/root/servers
|
||||
[NOTICE]: ../SeverityLevelDefinitions.md#notice
|
||||
[Non-referral]: #terminology
|
||||
[Query type]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Referral]: #terminology
|
||||
[Requirements and normalization of domain names in input]: ../RequirementsAndNormalizationOfDomainNames.md
|
||||
[RFC 9156]: https://www.rfc-editor.org/rfc/rfc9156.html
|
||||
[Send]: #terminology
|
||||
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
|
||||
[Test procedure]: #test-procedure
|
||||
[Undelegated test]: ../../test-types/undelegated-test.md
|
||||
[WARNING]: ../SeverityLevelDefinitions.md#warning
|
||||
[Zonemaster-Engine profile]: ../../../configuration/profiles.md
|
||||
208
zonemaster/docs/public/specifications/tests/Basic-TP/basic02.md
Normal file
208
zonemaster/docs/public/specifications/tests/Basic-TP/basic02.md
Normal 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
|
||||
@@ -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.
|
||||
@@ -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|
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
@@ -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)
|
||||
@@ -0,0 +1,282 @@
|
||||
# CONNECTIVITY04: IP Prefix Diversity
|
||||
|
||||
## Test case identifier
|
||||
**CONNECTIVITY04**
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Objective](#objective)
|
||||
* [Scope](#scope)
|
||||
* [Inputs](#inputs)
|
||||
* [Summary](#summary)
|
||||
* [Test procedure](#test-procedure)
|
||||
* [Outcome(s)](#outcomes)
|
||||
* [Special procedural requirements](#special-procedural-requirements)
|
||||
* [Prefix lookup methods](#prefix-lookup-methods)
|
||||
* [Cymru prefix lookup](#cymru-prefix-lookup)
|
||||
* [RIPE prefix lookup](#ripe-prefix-lookup)
|
||||
* [Intercase dependencies](#intercase-dependencies)
|
||||
* [Terminology](#terminology)
|
||||
|
||||
## Objective
|
||||
|
||||
The objective in this Test Case is to verify that all IP addresses of the
|
||||
domain's authoritative name servers are not announced from the same IP prefix.
|
||||
|
||||
[RFC 2182, section 3.1][RFC 2182#3.1], clearly specifies that distinct authoritative
|
||||
name servers for a child domain should be placed in different topological and
|
||||
geographical locations. The objective is to minimise the likelihood of a single
|
||||
failure disabling all of them.
|
||||
|
||||
## Scope
|
||||
|
||||
It is assumed that *Child Zone* is also tested and reported by [Connectivity01].
|
||||
This Test Case will just ignore non-responsive name servers or name servers not
|
||||
giving a correct DNS response for an authoritative name server.
|
||||
|
||||
## Inputs
|
||||
|
||||
* "Child Zone" - The domain name to be tested.
|
||||
* "Prefix Database" - The database of IP Prefix data to be used. Possible values
|
||||
are "RIPE" and "Cymru" (the default value).
|
||||
* "Cymru Base Name" - If the *Prefix Database* is "Cymru", the default value
|
||||
is "asnlookup.zonemaster.net".
|
||||
* "RIS Whois Server" - If the *Prefix Database* is "RIPE", the default value
|
||||
is "riswhois.ripe.net".
|
||||
|
||||
## Summary
|
||||
|
||||
Message Tag | Level | Arguments | Message ID for message tag
|
||||
:---------------------------|:--------|:----------------------------|:------------------------------------------------------------------------------------------------
|
||||
CN04_EMPTY_PREFIX_SET | NOTICE | ns_ip | Prefix database returned no information for IP address {ns_ip}.
|
||||
CN04_ERROR_PREFIX_DATABASE | NOTICE | ns_ip | Prefix database error for IP address {ns_ip}.
|
||||
CN04_IPV4_DIFFERENT_PREFIX | INFO | ns_list | The following name server(s) are announced in unique IPv4 prefix(es): "{ns_list}"
|
||||
CN04_IPV4_SAME_PREFIX | NOTICE | ns_list, ip_prefix | The following name server(s) are announced in the same IPv4 prefix ({ip_prefix}): "{ns_list}"
|
||||
CN04_IPV4_SINGLE_PREFIX | WARNING | | All name server(s) IPv4 address(es) are announced in the same IPv4 prefix.
|
||||
CN04_IPV6_DIFFERENT_PREFIX | INFO | ns_list | The following name server(s) are announced in unique IPv6 prefix(es): "{ns_list}"
|
||||
CN04_IPV6_SAME_PREFIX | NOTICE | ns_list, ip_prefix | The following name server(s) are announced in the same IPv6 prefix ({ip_prefix}): "{ns_list}"
|
||||
CN04_IPV6_SINGLE_PREFIX | WARNING | | All name server(s) IPv6 address(es) are announced in the same IPv6 prefix.
|
||||
|
||||
The value in the Level column is the default severity level of the message. The
|
||||
severity level can be changed in the [Zonemaster-Engine Profile]. Also see the
|
||||
[Severity Level Definitions] document.
|
||||
|
||||
The argument names in the Arguments column lists the arguments used in the
|
||||
message. The argument names are defined in the [Argument List].
|
||||
|
||||
## Test procedure
|
||||
|
||||
1. Create the following empty sets:
|
||||
1. IP prefix, name server name and IP address ("IPv4 Prefix")
|
||||
2. IP prefix, name server name and IP address ("IPv6 Prefix")
|
||||
|
||||
2. Obtain the set of name server names and IP addresses using
|
||||
[Get-Del-NS-Names-and-IPs] and [Get-Zone-NS-Names-and-IPs] in [MethodsV2] and
|
||||
split those into IPv4 and IPv6 ("NS IPv4" and "NS IPv6", respectively).
|
||||
|
||||
3. For each IP address in *NS IPv4* and *NS IPv6* ("NS IP Address"),
|
||||
respectively, do:
|
||||
1. Determine the IP prefix in which *NS IP Address* is announced
|
||||
using *Prefix Database*. Go to [Prefix Lookup Methods] section below
|
||||
with the IP address as input.
|
||||
2. Add found IP prefix, if any, with *NS IP Address* and name server name
|
||||
to the *IPv4 Prefix* and *IPv6 Prefix* sets, respectively.
|
||||
|
||||
4. If the *IPv4 Prefix* set is non-empty, then do:
|
||||
1. For each IP prefix in the set that has two or more members, output
|
||||
*[CN04_IPV4_SAME_PREFIX]* with the prefix and list of all members (name
|
||||
server names and IP addresses) for that prefix.
|
||||
2. For all IP prefixes in the set that have exactly one member, output
|
||||
*[CN04_IPV4_DIFFERENT_PREFIX]* with the combined set of their associated
|
||||
members (name server names and IP addresses).
|
||||
3. If all members of *NS IPv4* are members of the same IP prefix in
|
||||
*IPv4 Prefix* then output *[CN04_IPV4_SINGLE_PREFIX]*.
|
||||
|
||||
5. If the *IPv6 Prefix* set is non-empty, then do:
|
||||
1. For each IP prefix in the set that has two or more members, output
|
||||
*[CN04_IPV6_SAME_PREFIX]* with the prefix and list of all members (name
|
||||
server names and IP addresses) for that prefix.
|
||||
2. For all IP prefixes in the set that have exactly one member, output
|
||||
*[CN04_IPV6_DIFFERENT_PREFIX]* with the combined set of their associated
|
||||
members (name server names and IP addresses).
|
||||
3. If all members of *NS IPv6* are members of the same IP prefix in
|
||||
*IPv6 Prefix* then output *[CN04_IPV6_SINGLE_PREFIX]*.
|
||||
|
||||
## Outcome(s)
|
||||
|
||||
The outcome of this Test Case is "fail" if there is at least one message
|
||||
with the severity level *[ERROR]* or *[CRITICAL]*.
|
||||
|
||||
The outcome of this Test Case is "warning" if there is at least one message
|
||||
with the severity level *[WARNING]*, but no message with severity level
|
||||
*ERROR* or *CRITICAL*.
|
||||
|
||||
In other cases, no message or only messages with severity level
|
||||
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".
|
||||
|
||||
## Special procedural requirements
|
||||
|
||||
This Test Case is dependent on one of two possible services that can provide
|
||||
ASN lookup (Cymru or RIPE RIS). The service must be available over the network.
|
||||
|
||||
The *Child Zone* must be a valid name meeting
|
||||
"[Requirements and normalization of domain names in input]".
|
||||
|
||||
## Prefix lookup methods
|
||||
|
||||
Use the prefix method set in *Prefix Database* and the IP address in the call to
|
||||
this section. Refer to the appropriate section below with the IP address as
|
||||
input.
|
||||
|
||||
### Cymru prefix lookup
|
||||
|
||||
The Cymru prefix lookup is described on the Team Cymru [IP to ASN Mapping]
|
||||
using DNS lookup, but the default data comes from [bgp.tools] (Port 179 Ltd
|
||||
in England and Wales) and is continuously being mapped into
|
||||
`asnlookup.zonemaster.net` by the Zonemaster project. Data is fetched from
|
||||
<https://bgp.tools/table.txt>. The Cymru source can also be used, if
|
||||
requested.
|
||||
|
||||
1. Input is the IP address in the call to this section ("Input IP").
|
||||
|
||||
2. Prepend the *Cymru Base Name* with the label "origin" (IPv4) or
|
||||
"origin6" (IPv6) ("Expanded Base Name"). Example of expanded basenames :
|
||||
|
||||
```
|
||||
origin.asnlookup.zonemaster.net
|
||||
origin6.asnlookup.zonemaster.net
|
||||
```
|
||||
|
||||
3. Reverse *Input IP* with the same method as is used for reverse lookup
|
||||
("Reverse IP"). For description see [RFC 1035][RFC 1035#3.5], section 3.5, for
|
||||
IPv4 and [RFC 3596][RFC 3596#2.5], section 2.5, for IPv6.
|
||||
|
||||
4. Prepend the *Expanded Base Name* with *Reverse IP* ("Query Name").
|
||||
See [IP to ASN Mapping] for details.
|
||||
|
||||
5. Create a [DNS Query] with query type TXT and query name *Query Name*.
|
||||
("TXT Query").
|
||||
|
||||
6. Do [DNS Lookup] of *TXT Query*.
|
||||
|
||||
7. If at least one of the following criteria is met, output
|
||||
*[CN04_EMPTY_PREFIX_SET]* and exit this lookup:
|
||||
1. The [DNS Response] has the [RCODE Name] NXDomain.
|
||||
2. The [DNS Response] has the [RCODE Name] NoError and an empty answer section.
|
||||
|
||||
8. If at least one of the following criteria is met, output
|
||||
*[CN04_ERROR_PREFIX_DATABASE]* and exit this lookup:
|
||||
1. There is no DNS response.
|
||||
2. The [DNS Response] does not have the [RCODE Name] NoError.
|
||||
3. The answer section has no TXT record.
|
||||
|
||||
9. Extract the TXT record(s) from the answer section (see [IP to ASN Mapping]
|
||||
for examples). Do for each TXT record:
|
||||
1. If the TXT record consists of multiple strings in RDATA, then [concatenate]
|
||||
the strings into one string.
|
||||
2. Using the format of such string parse the string into its parts and
|
||||
extract the subnet specification.
|
||||
1. If it was not possible to parse the string, ignore it and go to next TXT
|
||||
record.
|
||||
3. If *Input IP* does not match the extracted subnet, output
|
||||
*[CN04_ERROR_PREFIX_DATABASE]*, break the processing of TXT records and
|
||||
exit this loop without returning any prefix.
|
||||
4. Store the extracted prefix.
|
||||
|
||||
10. If more than one IP prefix was stored from the loop above, keep the most
|
||||
specific and discard the rest.
|
||||
|
||||
11. If no IP prefix was stored, output *[CN04_EMPTY_PREFIX_SET]*.
|
||||
|
||||
12. Return the IP prefix, or an empty string if no IP prefix was stored.
|
||||
|
||||
|
||||
### RIPE prefix lookup
|
||||
|
||||
The RIPE Prefix lookup is described on the RIPE [RISwhois] page.
|
||||
|
||||
1. Create a query string by prepending the IP address with
|
||||
" -F -M " ("WHOIS String"). E.g., using IP address "192.0.2.10":
|
||||
|
||||
```
|
||||
" -F -M 192.0.2.10"
|
||||
```
|
||||
|
||||
2. Create a WHOIS query (port 43 with the nicname ((whois)) protocol)
|
||||
using the *WHOIS String* ("WHOIS Query"). E.g., on Linux:
|
||||
|
||||
```
|
||||
whois -h riswhois.ripe.net " -F -M 192.0.2.10"
|
||||
```
|
||||
|
||||
3. [Send] *WHOIS Query* to the *RIS Whois Server*.
|
||||
|
||||
4. If there is no response, output *[CN04_ERROR_PREFIX_DATABASE]* and exit this lookup.
|
||||
|
||||
5. Extract the string (non-empty line not prepended with "%") from the response, and do:
|
||||
1. If there is no such string, output *[CN04_EMPTY_PREFIX_SET]* and exit this lookup.
|
||||
2. Extract the IP prefix from the second field of the string.
|
||||
3. If it was not possible to extract the IP prefix (i.e., malformed response),
|
||||
output *[CN04_ERROR_PREFIX_DATABASE]* and exit this lookup.
|
||||
|
||||
6. Return the IP prefix.
|
||||
|
||||
## Intercase dependencies
|
||||
|
||||
None
|
||||
|
||||
## Terminology
|
||||
|
||||
* "Concatenate" - The term is used to refer to the conversion of a TXT
|
||||
resource record’s data to a single contiguous string, as specified in [RFC
|
||||
7208, section 3.3][RFC7208#3.3].
|
||||
|
||||
* "DNS Lookup" - The term is used when a recursive lookup is used, though
|
||||
any changes to the DNS tree introduced by an [undelegated test] must be
|
||||
respected. Compare with "[Send]".
|
||||
|
||||
* "Send" - The term "send" (to an IP address) is used when a DNS query is sent to
|
||||
a specific name server IP address. Compare with "[DNS Lookup]".
|
||||
|
||||
|
||||
|
||||
[Argument List]: ../ArgumentsForTestCaseMessages.md
|
||||
[Bgp.tools]: https://bgp.tools/
|
||||
[CN04_EMPTY_PREFIX_SET]: #outcomes
|
||||
[CN04_ERROR_PREFIX_DATABASE]: #outcomes
|
||||
[CN04_IPV4_DIFFERENT_PREFIX]: #outcomes
|
||||
[CN04_IPV4_SAME_PREFIX]: #outcomes
|
||||
[CN04_IPV4_SINGLE_PREFIX]: #outcomes
|
||||
[CN04_IPV6_DIFFERENT_PREFIX]: #outcomes
|
||||
[CN04_IPV6_SAME_PREFIX]: #outcomes
|
||||
[CN04_IPV6_SINGLE_PREFIX]: #outcomes
|
||||
[Concatenate]: #terminology
|
||||
[Connectivity01]: connectivity01.md
|
||||
[CRITICAL]: ../SeverityLevelDefinitions.md#critical
|
||||
[Cymru Database]: #cymru-prefix-lookup
|
||||
[DEBUG]: ../SeverityLevelDefinitions.md#notice
|
||||
[DNS Lookup]: #terminology
|
||||
[DNS Query and Response Defaults]: ../DNSQueryAndResponseDefaults.md
|
||||
[DNS Query]: ../DNSQueryAndResponseDefaults.md#default-setting-in-dns-query
|
||||
[DNS Response]: ../DNSQueryAndResponseDefaults.md#default-handling-of-a-dns-response
|
||||
[ERROR]: ../SeverityLevelDefinitions.md#error
|
||||
[Get-Del-NS-Names-and-IPs]: ../MethodsV2.md#method-get-delegation-ns-names-and-ip-addresses
|
||||
[Get-Zone-NS-Names-and-IPs]: ../MethodsV2.md#method-get-zone-ns-names-and-ip-addresses
|
||||
[INFO]: ../SeverityLevelDefinitions.md#info
|
||||
[IP to ASN Mapping]: https://www.team-cymru.com/ip-asn-mapping
|
||||
[MethodsV2]: ../MethodsV2.md
|
||||
[NOTICE]: ../SeverityLevelDefinitions.md#notice
|
||||
[Prefix Lookup Methods]: #prefix-lookup-methods
|
||||
[RCODE Name]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
|
||||
[Requirements and normalization of domain names in input]: ../RequirementsAndNormalizationOfDomainNames.md
|
||||
[RFC 1035#3.5]: https://datatracker.ietf.org/doc/html/rfc1035#section-3.5
|
||||
[RFC 2182#3.1]: https://datatracker.ietf.org/doc/html/rfc2182#section-3.1
|
||||
[RFC 3596#2.5]: https://datatracker.ietf.org/doc/html/rfc3596#section-2.5
|
||||
[RFC7208#3.3]: https://datatracker.ietf.org/doc/html/rfc7208#section-3.3
|
||||
[RIPE Database]: #ripe-prefix-lookup
|
||||
[RISwhois]: https://www.ripe.net/analyse/archived-projects/ris-tools-web-interfaces/riswhois
|
||||
[Send]: #terminology
|
||||
[Severity Level Definitions]: ../SeverityLevelDefinitions.md
|
||||
[Undelegated test]: ../../test-types/undelegated-test.md
|
||||
[WARNING]: ../SeverityLevelDefinitions.md#warning
|
||||
[Zonemaster-Engine Profile]: ../../../configuration/profiles.md
|
||||
@@ -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|
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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|
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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.
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
@@ -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
|
||||
@@ -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
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user