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

feat: add full Zonemaster stack with Docker and Spanish UI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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