zonemaster/zonemaster

The Zonemaster Project

Table of contents

• Introduction
• Background
• Purpose
• Documentation
• Prerequisites
• Support of DNSKEY algorithms 15 and 16
• Translation
• Zonemaster and its components
• Installation
• Versions
• Participation
• Bug reporting
• Notable bugs and issues
• Contact and mailing lists
• License

Introduction

Zonemaster is a software package that validates the quality of a DNS delegation. The ambition of the Zonemaster project is to develop and maintain an open source DNS validation tool, offering improved performance over existing tools and providing extensive documentation which could be re-used by similar projects in the future.

Zonemaster consists of several modules or components. The components will help different types of users to check domain servers for configuration errors and generate a report that will assist in fixing the errors.

Background

DNSCheck from IIS and Zonecheck from AFNIC are two old software packages that validate the quality of a DNS delegation. AFNIC and IIS came together to develop a new DNS validation tool from scratch under the name Zonemaster. Zonemaster intends to be a major rewrite of Zonecheck and DNSCheck, and aims to implement the best parts of both.

Purpose

The components developed as part of the Zonemaster project will help different types of users to check domain servers for configuration errors and generate a report that will assist in fixing the errors.

The ambition of the Zonemaster project is to develop and maintain an open source DNS validation tool, offering improved performance over existing tools and providing extensive documentation which could be re-used by similar projects in the future.

Documentation

This is the main project repository. In this repository, most documentation of Zonemaster is found.

In the public documentation you will find e.g. specifications of all Test Cases for the Zonemaster implementation, as well as installation instructions and user guides for each Zonemaster component.

In the internal tree you can find documentation regarding the design and requirements of the Zonemaster implementation.

The public documentation can be built using mdbook and the following commands:

cd docs/public
mdbook build
open book/index.html

Prerequisites

See Prerequisites document.

Support of DNSKEY algorithms 15 and 16

To be able to support and process DNSKEY algorithms 15 (Ed25519) and 16 (Ed448) for DNSSEC the underlying OS must have a recent version of OpenSSL installed, and LDNS being linked against that OpenSSL (see Zonemaster-LDNS-README for more details). Then information below on support of the algorithms assumes that the installation instructions given for Zonemaster have been followed. A test of the domains ed25519.nl and superdns.nl will reveal if the Zonemaster installation has the support or not for algorithms 15 and 16, respectively.

All supported OSs support algorithms 15 and 16 out of the box.

Translation

Zonemaster comes with translation to the following languages. Translation is available as methods in Zonemaster::Engine, zonemaster-cli (i.e. the Zonemaster-CLI interface to Zonemaster::Engine), Zonemaster-Backend RPCAPI interface to Zonemaster::Engine) and the Zonemaster-GUI interface to RPCAPI.

• Danish (da, da_DK.UTF-8)
• English (en, en_US.UTF-8)
• Finnish (fi, fi_FI.UTF-8)
• French (fr, fr_FR.UTF-8)
• Norwegian (nb, nb_NO.UTF-8)
• Spanish (es, es_ES.UTF-8)
• Swedish (sv, sv_SE.UTF-8)

Zonemaster and its components

The Zonemaster product consists of the main part and five components. The main part consists of specifications and documentation for the Zonemaster product, and is stored in the main Zonemaster Github repository.

All the software for the Zonemaster project belong to the five components, each component being stored in its own Github repository (listed below).

The software has not yet been packaged for any operating systems, and you have to install most of it from the source code. The recommended method is to install from CPAN (except for Zonemaster-GUI), but it is possible to install directly from clones of the Github repositories. Zonemaster-GUI has no Perl code, and is installed directly from its repository at Github.

The Zonemaster Product includes the following components:

• Zonemaster-LDNS - LDNS with a Perl frontend used by Zonemaster-Engine.
• Zonemaster-Engine - The Zonemaster test library.
• Zonemaster-CLI - A Command Line Interface (CLI) to the test library (Zonemaster-Engine).
• Zonemaster-Backend - A JSON/RPC interface with database to the test library (Zonemaster-Engine).
• Zonemaster-GUI - A web user interface to the test library via Zonemaster-Backend.

Installation

Zonemaster itself can be installed manually. It can also be run using Docker. For detailed instructions on both options, see the Installation document.

Versions

Go to the release list of this repository to find the latest version of Zonemaster and the versions of the specific components. Be sure to read the release note of each component before installing or upgrading.

Participation

You can submit code by forking this repository and creating pull requests. When you create a pull request, please select the "develop" branch in the relevant Zonemaster repository.

See our contact and mailing lists page for information on mailing lists.

Bug reporting

For bug reporting go to the relevant Zonemaster repository and create a GitHub issue there. Before creating the issue, please search for the problem in the issue tracker in the relevant repository. If you find an open issue covering your issue, please add a comment with any additional information.

• Issues in Zonemaster::LDNS
• Issues in Zonemaster::Engine
• Issues in Zonemaster::CLI
• Issues in Zonemaster::Backend
• Issues in Zonemaster::GUI

If you cannot determine which repository to create the issue in, please select the main Zonemaster repository (i.e. general issues in Zonemaster).

Notable bugs and issues

None.

Contact and mailing lists

See our contact and mailing lists page for contact information and information on mailing lists.

License

This is free software under a 2-clause BSD license. The full text of the license can be found in the LICENSE file included in this respository.

zonemaster's Issues

R15 - Basic

Relate the appropriate test specification to R15

R03 in "Address Level" or "Connectivity Level" ?

R03 "Nameserver address in a private network" is under "Address Level"
Whereas

• R11 "nameserver addresses on same subnet"
• R12 "nameserver addresses are all on the same subnet"

are under "Connectivity Level"

Should we move R03 to "Connectivity level" ?

delegation02 - only count name servers from parent

The current test in delegation02 counts all name servers from the child and the parent. The test case should only count parent name servers.

R75 - Delegation

Relate R75 to appropriate test specification

delegation02 - abort test process?

In delegation02 - is it really impossible to run all other tests if there is only one name server available? I think we should run all tests anyway.

Syntax-TP/syntax06 has wrong order of steps

syntax06 specifies to first un-escape dots and then convert the first dot to an @ sign. That would make escaping useless. The order should probably be to replace the first un-escaped dot with an @, then change all escaped dots to plain dots.

step 3 in the nameserver04 test is impossible

Step 3 is impossible to figure out? (firewalls etc etc)
Comments?

syntax03 wrongly reports DISCOURAGED_DOUBLE_DASH for domain XN--MGBERP4A5D4AR

The title pretty much sums it up.

Separate DO test from EDNS0 test - nameserver02

A comment from a reviewer states that we should separate the DO bit test from the EDNS0 test. Comments?

AS diversity testing for IPv6

connectivity04.md says "Obtain the AS (name) list for each IP address obtained from step2 using "asn.routeviews.org"." AFAIK, this service does not work for IPv6 addresses. I am not aware of an IPv6 equivalent. This limit should be documented.

Please review the Test Specification under "Connectivity"

R37, R38 in Address Level ?

Guys,

R37 & R38 are uncategorized in the document "Test Requirements". Should I include them in "Address Level" ?

• R37 : loopback delegation : test if loopback addresses (IPv4, IPv6) are published by nameserver
• R38 : loopback is resolvable.

FYI these 2 tests are run in ZoneCheck against a nameserver, in the case where the nameserver is recursive.

• Shall we include them in the new tool ?
• If yes, is "Address Level" the right destination ?

Please review the Test Specification under Delegation

To pass on the information and to check how it works.

DNSSEC tests use an AND when it should be an OR

dnssec08.md says "If any of the RRSIGs does not validate the DNSKEY RR set, this test
case fails." This is harsh and contradicts RFC 6840 which says "This document specifies that a resolver SHOULD accept any valid RRSIG
as sufficient, and only determine that an RRset is Bogus if all
RRSIGs fail validation.

If a resolver adopts a more restrictive policy, there's a danger that
properly signed data might unnecessarily fail validation due to cache
timing issues. Furthermore, certain zone management techniques, like
the Double Signature Zone Signing Key Rollover method described in
Section 4.2.1.2 of [RFC6781], will not work reliably. Such a
resolver is also vulnerable to malicious insertion of gibberish
signatures."

Clarification needed in Zone05 Test Specs

In the text, there are 3 references to a 7 days duration which is each time calculated as 25200 seconds. As 7 days is actually 604800 seconds, what is the correct duration to take into account : 25200 seconds or 604800 seconds ?

Connectivity 03.md moved to address04.md

Connectivity 03.md is moved to address04.md as per comment #36

Please review the tests under Syntax-TP

The Syntax test plan is the most complete from me right now. Please review and issue a new ticket for anything you find problematic in them here.

How to use the IANA registries

Currently, four Markdown specification documents refer to IANA registries. I suggest:

1. To refer to them by the XML name, because they will probably be converted to code automatically and the XML version is the best for that.

2. To document somewhere that they must not be hardwired but converted (at compile-time, probably not at run-time to avoid DoSing IANA) automatically.

CLI requirements tries to specify a new test

Point 2.7, "The user MUST be able to specify former name servers as input in order to test if these formerly used name servers are still authorative for the domain being tested" is not an interface requirement, it's a requirement for a new test that is not in the test requirements document.

Bogon IPv6 / IPv4

One of the comments from the reviewers is that we handle the IPv4 and IPv6 globally routable addresses test in one way, and the Bogon IPv4/IPv6 test in a separate way. Should we include the IPv4 bogon test in the connectivity03 test case?

And - perhaps connectivity03 belongs more in the address test level?

Config, policy and language data for third-party modules.

Figure out a good way of doing it and implement it.

R75 - SOA Serial Zero

Write test case for Test Requirement R75.

delegation 02

Delegation 02 updated as per the comment #35

Syntax-TP/syntax09 allows invalid dates

According to the steps given, the SOA serial "19010231" should pass.

Suggested changes:

1. If the serial number is not exactly ten digits long, the test fails.
2. The first eight digits of the serial number must form a valid ISO8601 calendar date. If they do not, the test fails.
3. (removed)

delegation04 does not check that it got a packet before seeing if it as authoritative

Facebook's nameservers do not respond to TCP queries, so delegation04 crashes when it tries to call ->aa on a undefined value.

CLI requirements is unclear about what it wants to debug

Point 3.3 "The output from the CLI MUST have several levels of verbosity for debugging purposes" is unclear. What is it that is supposed to be debugged, and who is it supposed to help?

Please review test spec category "Address"

Hello,
Could you please review the 5 test cases under the category "address".
There were 2 requirements in ZoneCheck R37 and R38 (see Master Test Plan) about loopback addresses which I have rewritten in addr04 and and addr05. The reason of this rewrite is explained in the "Comments" paragraph of "level.med" of this category.

Samia.

Resolver in Mastertestplan.md

The resolver section in the Mastertestplan.md should be either removed (or) in the section "System overview and key features" there should be explanation for why this test category is not mandatory.

Basic01 - Semantics

In the ordered description

1. says - "redirect directly to the requested domain"
2. mentions - "nameserver that authoritatively responds with NXDOMAIN for the child domain"

Either domain should be used (or) child domain should be used in both (1) and (2)

Separate DO test from EDNS0 test - nameserver02

The nameserver02 test space has been updated to remove the DO bit from the EDNS0 options. Please update test case.

delegation03 wrongly reports REFERRAL_SIZE_LARGE

The current delegation03 gives a failing result for .COM, which it shouldn't. It claims that a minimal correct referral packet must be 726 octets. The algorithm we have in DNSCheck gives 495. Apart from that, I doubt quite strongly that such a central domain would be allowed to have a minimum referral larger than 512 octets.

syntax09 - syntax of SOA serial is no requirement

RFC1912 is an informational RFC, and the document is not normative. So there is not requirement at all for the YYYYMMDDnn format of the SOA serial.

The only standard document for the SOA serial format is RFC1982, "Serial Number Arithmetic".

Basic02 = Delegation01

Basic02 is same as Delegation01. Should we remove Delegation01?

Missing requirements in DNSCheck-Batch-Requirements.txt

This document is missing all requirements from PDT, Hälsoläget and Domänkollen. It may also be missing any extra requirements from the known users at RIPE and SIDN.

Connectivity 03 - UPdated

The database for checking AS numbers is modified. Check the test specification to have the nex link

Syntax09 - Removed

Syntax09 is removed

Uniform URL for RFCs

Today, the URLs of RFCs in the Markdown files are often tools.ietf.org but sometimes www.ietf.org. It needs cleanup.

Classifying tests as "Optional" "Mandatory"?

Do we categorise tests as "mandatory" and "optional" ? .. and if needed another cateogry "Useful"

Add RFC references to delegation02 if possible

Please reference any RFC that specify that at least two name servers should or must be used. I found RFC 2182 which has some recommendations, but I am sure that there are others.

Change test specification to IEEE lingo

The test cases for the Basic Tests has been written in a non-standard language.

The header for each test case begins with a Test Case identifier, a short id for the test (BASIC1) and a short description of the test case. This is ok.

However, change the following:

Rationale should be Objective.
Information Needed should be Inputs.
Evaluation Criteria should be "Ordered description of steps to be taken to execute the test case" and even a clear description of the different outcomes (under a header just called "Outcome(s)".
Notes can be split into "Special procedural requirements" and "Intercase dependencies" depending on the need.

The current notes in the Basic test plan, "If this test fails, it's impossible to continue and the whole testing process (except for the BASIC3 test) is aborted." could perhaps also be further described in the Master Test Plan.

We should perhaps split the "Basic Tests Test Plan" into different documents describing each Test Case, and move the above mention notes to the "Basic Tests Test Plan" which is a document that should describe the whole Basic Tests as a subject in itself, and belongs in the hierarchy just below the MTP and above each individual TC (test case).

Terminology to be defined -1

There are two usages - "Child domain" and "domain name". Can we fix to one terminology - I vote for "domain name"
@bortzmeyer @cdybedahl

Consistency of serial numbers when the zone changes often

consistency01.md should warn that modern zones, specially for large and busy TLD, can often have different serial numbers and it is not a problem.

Here is .com at a typical moment:

% check-soa  com
a.gtld-servers.net.
    2001:503:a83e::2:30: OK: 1398695287
    192.5.6.30: OK: 1398695287
b.gtld-servers.net.
    2001:503:231d::2:30: OK: 1398695287
    192.33.14.30: OK: 1398695272
c.gtld-servers.net.
    192.26.92.30: OK: 1398695287
d.gtld-servers.net.
    192.31.80.30: OK: 1398695287
e.gtld-servers.net.
    192.12.94.30: OK: 1398695287
f.gtld-servers.net.
    192.35.51.30: OK: 1398695272
g.gtld-servers.net.
    192.42.93.30: OK: 1398695287
h.gtld-servers.net.
    192.54.112.30: OK: 1398695287
i.gtld-servers.net.
    192.43.172.30: OK: 1398695287
j.gtld-servers.net.
    192.48.79.30: OK: 1398695287
k.gtld-servers.net.
    192.52.178.30: OK: 1398695287
l.gtld-servers.net.
    192.41.162.30: OK: 1398695287
m.gtld-servers.net.
    192.55.83.30: OK: 1398695287

Do note that B has two different serial for IPv4 and v6...

Add DNS query flag specification to each test level

There are hardly any description of which DNS query flags that are necessary to receive the correct DNS answers in the test cases. We should add the flags we are using as the default for the test cases to each test level document (level.md), and more explicit to each test case if there is a need for a different set of flags to perform the test case.

For example, the DNSSEC test level should probably have the DO bit set for all tests, this will not be necessary for the other test levels.

only count AS in connectivity04 - should on more than one AS

Only count the number of AS numbers used.

Only have "should" on more than one AS.

Additional references for AS numbers: RFC 1163 and RFC 904 - for the concept of AS routers.

Typos

https://github.com/dotse/new-dnscheck/blob/master/docs/specifications/tests/Syntax-TP/syntax09.md

Test Case identifier should be syntax09

Step 2 in syntax05 is not needed

There is no need to execute step 2 in this test case.

Please review the Test Specification under Zone

Errors in DNSCheck-Batch-Requirements.txt

Requirement 1.5 must clarify what it means by "handle". By most reasonable definitions, the current dnscheck-dispatcher.pl does not fulfill this requirement.

The current dnscheck-dispatcher.pl does not fulfill requirement 1.9.

Terminology to be defined -2

From Requirements on writing test specifications

Use well defined terms. Terms such as FQDN and FQHN seems to have dual meanings.

From RFC 2109

Fully-qualified host name (FQHN) means either the fully-qualified domain name (FQDN) of a host (i.e., a completely specified domain name ending in a top-level domain such as .com or .uk), or the numeric Internet Protocol (IP) address of a host. The fully qualified domain name is preferred; use of numeric IP addresses is strongly discouraged.

As FQDN is the preferred, does any of you think still not normative ?

@bortzmeyer @cdybedahl

Typos in requirments

Here is an incomplete list of typos (mostly editorial only) in the current specification.