Fetching contributors…
Cannot retrieve contributors at this time
169 lines (148 sloc) 13 KB

Test requirements


Zonemaster is based on Zonecheck and DNSCheck, and most of the current set of requirements are derived from those projects.

However, Zonemaster in its current form stands on its own, and this document describes the current set of requirements on the tests to implement for Zonemaster.

Any previous mapping detailing the inheritance on the requirements from Zonecheck and DNSCheck can be found inolder versions of this document.

Source documents

Most of the requirements are derived from these documents:

Type of document Document copied from Document
Source document for Zonecheck Previois Zonecheck site Features
Policy document for Zonecheck Previois Zonecheck site Test Policy
Source document for DNSCheck DNSCheck Github Wiki Detailes list of all messages

Tests to implement

Req Requirement description Level and Test Case
R01 UDP connectivity CONNECTIVITY
R02 TCP connectivity CONNECTIVITY
R03 Address in a private network ADDRESS
R04 Address should not be part of a bogon prefix ADDRESS
R05 Illegal symbols in domain name SYNTAX
R06 Dash ('-') at start or beginning of domain name SYNTAX
R07 Double dash in domain name SYNTAX
R08 The child domain has atleast one working name server BASIC
R09 At least two nameservers for the domain DELEGATION
R10 Identical addresses DELEGATION
R11 Nameserver addresses on same subnet CONNECTIVITY
R12 Nameserver addresses are all on the same subnet CONNECTIVITY
R13 Delegation response fit in a 512 byte UDP packet DELEGATION
R14 Delegation response with additional fit in a 512 byte UDP packet DELEGATION
R15 NS record present BASIC
R16 NS authoritative answer DELEGATION
R17 NS name has a valid domain/hostname syntax SYNTAX
R18 NS is not an alias DELEGATION
R19 NS can be resolved DELEGATION
R20 SOA record present DELEGATION
R21 SOA authoritative answer DELEGATION
R22 Missused '@' characters in SOA contact name SYNTAX
R23 Illegal characters in SOA contact name SYNTAX
R24 Illegal characters in SOA master nameserver SYNTAX
R25 Fully qualified master nameserver in SOA ZONE
R26 SOA 'refresh' at least 6 hours ZONE
R27 SOA 'retry' lower than 'refresh' ZONE
R28 SOA 'retry' at least 1 hour ZONE
R29 SOA 'expire' at least 7 days ZONE
R31 SOA 'minimum' less than 1 day ZONE
R32 SOA master is not an alias ZONE
R33 Coherence of serial number with primary nameserver CONSISTENCY
R34 Coherence of administrative contact with primary nameserver CONSISTENCY
R36 Coherence of SOA with primary nameserver CONSISTENCY
R40 Nameserver IP reverse ADDRESS
R41 Nameserver IP reverse matching nameserver name ADDRESS
R42 Check if server is really recursive NAMESERVER
R43 Nameserver doesn't allow recursion NAMESERVER
R46 Test if server is recursive NAMESERVER
R47 MX record present ZONE
R49 MX syntax is valid for an hostname SYNTAX
R50 MX is not an alias ZONE
R52 MX can be resolved ZONE
R53 Behaviour against AAAA query (RFC 4074) NAMESERVER
R54 Nameservers belong all to the same AS CONNECTIVITY
R58 Legal values for the DS hash digest algorithm DNSSEC
R59 DS must match a DNSKEY in the designated zone DNSSEC
R60 Check for too many NSEC3 iterations DNSSEC
R61 Check for too short or too long RRSIG lifetimes DNSSEC
R62 Check for invalid DNSKEY algorithms DNSSEC
R63 Verify DNSSEC additional processing DNSSEC
R64 If there exists DNSKEY at child, the parent should have a DS DNSSEC
R65 RRSIG(DNSKEY) must be valid and created by a valid DNSKEY DNSSEC
R66 RRSIG(SOA) must be valid and created by a valid DNSKEY DNSSEC
R67 There must be NS records for the zone being tested on the parent side BASIC
R68 The child domain must have at least one working nameserver BASIC
R69 NS records from parent exists, but the child does not have NS but answers for A BASIC
R70 Coherence of all other SOA-fields where SOA Serial is the same CONSISTENCY
R71 Total mismatch between child and parent NS records, delegation works due to same IP DELEGATION
R72 Test of EDNS0 support NAMESERVER
R73 Test availability of zone transfer (AXFR) NAMESERVER
R74 Answer from name server came from an IP address other than expected (wrong source IP) NAMESERVER
R76 Zone contains NSEC or NSEC3 records DNSSEC
R77 Perform input validation on the domain name BASIC
R78 All authoritative nameservers reply with same set CONSISTENCY
R79 If DS at parent, child zone must be signed DNSSEC
R80 Test QNAME case sensitivity NAMESERVER
R81 Test Upward referral NAMESERVER
R82 Test QNAME Case insensitivity NAMESERVER
R83 Consistency between glue and authoritative data CONSISTENCY
R84 Test for DNSSEC Algorithm Completeness (DS->DNSKEY->RRSIG) DNSSEC

Future tests

  • Case insensitivity in a name server, RFC 4343.
  • More tests of EDNS(0), RFC 6891 and
  • AXFR is complex, perhaps do more inspection of data coming from AXFR, RFC 5936.
  • Check for algorithm completeness (DS->DNSKEY->RRSIG) as per section 2.2 of RFC 4035.
  • ICMP answer
  • Test for referral to root (possible DDoS vector for authoritative name servers)
  • Check to see if removed authoritative name server is still authoritative (requires a new input parameter, "previous ns")
  • Test the preservation of qname case in DNS answers, RFC 1035 section 7.1. ("0x20" hack)

Discarded tests

  • loopback delegation (Section 4.1 of RFC 1912)
  • loopback is resolvable (Section 4.1 of RFC 1912)
  • serial number of the form YYYYMMDDnn (RFC 1912 is not normative)
  • SOA serial may not be zero

Requirements on writing test specifications

These are some requirements for writing specifications for "Zonemaster":

  1. Follow the framework of the IEEE 829-2008.
  2. The documents must be in Markdown Syntax.
  3. Keep the columns in the document below 80, preferrably shorter than 74 columns. (Much easier to see changes in documents using the tools available for diffing).
  4. Use normative language.
  5. Refer to any reference that is the rationale for implementing the test case. If there are no reference to any standards, describe the reason for implementing the test. For most references, we use RFCs from IETF.
  6. Use well defined terms. Terms such as FQDN and FQHN seems to have dual meanings.
  7. The name of the test case might be better than the name of the requirements. Feel free to improve the name of the test case if it is possible to improve on the wording to make the test case clearer for the reader and the user of the software. Text from the test cases probably will be reused in other contexts.
  8. Be very clear in what DNS queries are performed, and what answers are expected. If a specific DNS protocol flag has to be set in the query, specify this as well. In general, be closer to describing the DNS protocol actions than to use more generic language.
  9. Use the same headers and titles as in all other test cases. Try to use the same style as used in the other tests.
  10. Make sure to write the tests so that any implementer that implements the tests will have the same outcome as any other implementation.

Copyright (c) 2013-2018, IIS (The Internet Foundation in Sweden)
Copyright (c) 2013-2018, AFNIC
Creative Commons Attribution 4.0 International License

You should have received a copy of the license along with this work. If not, see