Zone14 (zone14)

Status: Draft

Purpose

• Check existence and RFC 8976 compliance of the ZONEMD RR at the zone apex.
• Detect cross-nameserver inconsistencies (mixed presence, divergent content).
• Detect intra-RRset structural defects (duplicate (Scheme, Hash) pairs).
• Detect ZONEMD Serial mismatches against the current SOA serial of the same nameserver.
• Detect ZONEMD records that publish a hash algorithm outside the IANA-assigned set verifiable by standard tooling (1 = SHA-384, 2 = SHA-512).

Preconditions And Inputs

• Preconditions:
  • A zone.Zone object is available.
• Required inputs:
  • Nameserver addresses from methods.Method4and5.
  • ZONEMD and SOA responses from authoritative nameservers at the zone apex.
• Profile/config knobs that affect behavior:
  • net.ipv4 and net.ipv6: disabled transports are skipped with transport debug tags.
  • resolver.defaults.parallel: parallel nameserver query fanout.

Algorithm And Decision Flow

1. Emit TEST_CASE_START.
2. Read nameserver list from Method4and5.
3. For each nameserver (parallelized, input-order merged logs):
   • If transport is disabled, emit IPV4_DISABLED or IPV6_DISABLED for rrtype ZONEMD, then skip.
   • Send ZONEMD query to the zone apex with default query options.
   • If no response, or response is not authoritative NOERROR, skip this nameserver silently.
   • Else collect the ZONEMD RRs from the answer section (zero or more records).
   • Send SOA query to the same nameserver and record the SOA serial for comparison (mark unavailable if the query fails or returns no SOA RR).
4. Post-processing (sequential, over all collected outcomes):
   • For each nameserver that returned an authoritative NOERROR response:
     • If the ZONEMD RRset is empty, collect the nameserver for consolidated Z14_NO_ZONEMD.
     • Else:
       • Build a (Scheme, Hash) multiset across the records on this nameserver. For every pair that appears more than once, emit Z14_DUPLICATE_SCHEME_HASH (ns, address, scheme, hash) once per distinct duplicated pair.
       • Build a hash-algorithm set across the records on this nameserver. For every distinct hash value that is not in {1, 2} (SHA-384, SHA-512), emit Z14_UNSUPPORTED_HASH (ns, address, hash) once per (ns, hash) pair.
       • For each ZONEMD record on this nameserver:
         • Group nameservers for consolidated Z14_ZONEMD_FOUND by record content (serial, scheme, hash, digest).
         • If the SOA serial was retrieved and record.Serial != soa.Serial, emit Z14_SERIAL_MISMATCH (ns, address, zonemd_serial, soa_serial).
       • Compute an NS-level consistency key from the canonical sorted concatenation of all (Serial, Scheme, Hash, Digest) tuples on this nameserver and add it to the cross-nameserver key set.
   • Emit consolidated Z14_ZONEMD_FOUND for each distinct ZONEMD record content group, with servers list, serial, scheme, hash, and digest.
   • Emit consolidated Z14_NO_ZONEMD once with the servers list of nameservers without ZONEMD.
   • If at least one nameserver has ZONEMD and at least one has no ZONEMD, emit Z14_MIXED_PRESENCE.
   • If more than one nameserver has ZONEMD and the NS-level consistency keys differ across them, emit Z14_INCONSISTENT_ZONEMD.
5. Emit TEST_CASE_END.

ZONEMD record identity (for Z14_ZONEMD_FOUND consolidation) is determined by the tuple (Serial, Scheme, Hash, Digest). Per-nameserver consistency identity (for Z14_INCONSISTENT_ZONEMD) is determined by the canonical sorted concatenation of all (Serial, Scheme, Hash, Digest) tuples on that nameserver.

Emitted Tags (Possible Set)

Tag Arguments

Severity Levels Per Tag

Differences From Upstream

• No upstream (Zonemaster) equivalent exists; this is a gonemaster-specific test case.
• References: RFC 8976
• Potential upstream report:
  • no

Edge Cases And Limitations

• ZONEMD is an optional zone apex record per RFC 8976; Z14_NO_ZONEMD is informational only and does not indicate a problem.
• Only authoritative NOERROR responses are evaluated. Nameservers returning non-NOERROR or non-AA responses are skipped silently.
• Multiple ZONEMD records with distinct (Scheme, Hash) pairs at the zone apex are valid per RFC 8976 §2.2.4 and emit one Z14_ZONEMD_FOUND per distinct record content; only repeated (Scheme, Hash) pairs produce Z14_DUPLICATE_SCHEME_HASH.
• Hash algorithm 1 (SHA-384) MUST be supported by verifiers; algorithm 2 (SHA-512) SHOULD be supported. Any other value (reserved 0 and 255, unassigned 3-239, private-use 240-254) emits Z14_UNSUPPORTED_HASH once per (ns, hash) pair; the underlying records are still surfaced via Z14_ZONEMD_FOUND so the digest content remains visible. Scheme values outside {1 = SIMPLE} are not flagged separately; only the hash algorithm is gated, since Scheme only affects canonicalization and the digest itself is not verified by this testcase.
• Digest content is not verified. Only structural fields (Serial, Scheme, Hash, presence) and cross-nameserver content equality are evaluated. Full digest verification would require performing an AXFR and recomputing the digest over the canonical zone, which is out of scope for this testcase.
• Z14_SERIAL_MISMATCH is only evaluated when the SOA query to the same nameserver succeeds and returns a SOA record. If the SOA query fails, no mismatch is reported for that nameserver.
• The cross-nameserver consistency key includes every ZONEMD record on a nameserver (including duplicates), so a nameserver carrying duplicated (Scheme, Hash) pairs will appear inconsistent with peers that publish a clean RRset of the same logical content.
• Distinct nameserver names sharing one IP are grouped per (ns, address) pair in servers outputs, matching the convention of the rest of the Zone module.