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:
@@ -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).
|
||||
Reference in New Issue
Block a user