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.
Most of the requirements are derived from these documents:
- Source document for Zonecheck: features.shtml
- Policy document for Zonecheck: tests-policy-2.html
- Source document for DNSCheck: Detailes list of all possible DNSCheck messages
| 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 |
- Case insensitivity in a name server, RFC 4343.
- More tests of EDNS(0), RFC 6891 and http://ednscomp.isc.org/.
- 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)
- 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
These are some requirements for writing specifications for "Zonemaster":
- Follow the framework of the IEEE 829-2008.
- The documents must be in [Markdown Syntax] (http://daringfireball.net/projects/markdown/syntax).
- 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).
- Use [normative language] (http://en.wikipedia.org/wiki/Normative#Standards_documents).
- 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.
- Use well defined terms. Terms such as FQDN and FQHN seems to have dual meanings.
- 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.
- 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.
- Use the same headers and titles as in all other test cases. Try to use the same style as used in the other tests.
- 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, 2014, 2015, IIS (The Internet Infrastructure Foundation)
Copyright (c) 2013, 2014, 2015, AFNIC
Creative Commons Attribution 4.0 International License
You should have received a copy of the license along with this work. If not, see https://creativecommons.org/licenses/by/4.0/.