> > Limit all lines to 80 characters with the possible exception of tables
> > such as the one in the summary section.

# TEMPLATE01: This is a test specification template

> > Replace "TEMPLATE01" with test case ID (in uppercase). Replace the text
> > with a short description

## Test case identifier
**TEMPLATE01**

> > Replace with correct test case ID as specified in the
> > [Test Case Identifier Specification].

## Table of contents

> > If the specification contains extra sections, or if some section is not
> > included, update the list. In the normal case, keep the following sections.

* [Objective](#objective)
* [Scope](#scope)
* [Inputs](#inputs)
* [Summary](#summary)
* [Test procedure](#test-procedure)
* [Outcome(s)](#outcomes)
* [Special procedural requirements](#special-procedural-requirements)
* [Intercase dependencies](#intercase-dependencies)
* [Terminology](#terminology)

## Objective

> > Write a description of what this test case tests, i.e. the details that are
> > considered to be right and wrong. Include references to RFCs and other
> > documents.
> >
> > Do not include full links here (in the source). Put them at the end of the
> > specification document instead, as in this template.
> >
> > Do have deep links, but keep the display text short if possible. E.g.:

...described in [RFC 4035][RFC 4035#section-3.1.3], section 3.1.3, ...

## Scope

> > If this test case assumes, but not depends on, another test case then specify
> > it. Dependency would mean that the test case is affected by the other test
> > case, or even cannot be run if the other has not been run. Assuming that
> > another test case has been run is just to make it possible to ignore certain
> > errors. E.g.:

It is assumed that *Child Zone* is also tested and reported by [Connectivity01].
This test case will just ignore non-responsive name servers or name servers not
giving a correct DNS response for an authoritative name server.


## Inputs

> > Input data to the test case. Always include the Child zone, but it can also
> > be other data units, such as current time, if that is relevant.
> >
> > The input data name is put in quote marks '""', then a hyphen '-' as a
> > separator, and finally a description.

* "Child Zone" - The domain name to be tested.

## Summary

> > First we can have bullets, if applicable, that state notable things about
> > the execution or the messages. E.g.
* If no CDS record is found, the test case will terminate early
  with no message tag outputted.
* If a CDS record is of "delete" type, then it can by definition not
  match or point at any DNSKEY record.

> > Here is a table of all message tags referred to in the steps. The table has
> > the following columns:
> > 1. The message tag outputted in the test procedure below.
> > 2. The default severity level.
> > 3. The arguments (if any) to be included in the message ID. Argument name
> >    must be selected from the defined names (see link below).
> > 4. Message ID to be outputted by the implementation with any arguments
> >    included (see example below).
> >
> > Always use the same table set-up, but with the correct tags. Keep the table
> > sorted by message tag. Here is an example:

Message Tag                   | Level   | Arguments            | Message ID for message tag
:-----------------------------|:--------|:---------------------|:--------------------------------------------
T01_ALGO_NOT_SUPPORTED_BY_ZM  | NOTICE  | algo_descr, algo_num | The algorithm used, {algo_descr} ({also_num}) is not supported by the Zonemaster implementation.
T01_BROKEN_DNSSEC             | ERROR   | ns_ip_list           | Replies do not follow the standard. Returned from name servers "{ns_ip_list}".
T01_HAS_NSEC                  | INFO    |                      | The *Child Zone* uses NSEC.
T01_HAS_NSEC3                 | INFO    |                      | The *Child Zone* uses NSEC3.
T01_INCONSISTENT_DNSSEC       | ERROR   | keytag               | The keytag "{keytag}" of the zone is inconsistent with respect to DNSSEC.

The value in the Level column is the default severity level of the message. The
severity level can be changed in the [Zonemaster-Engine profile]. Also see the
[Severity Level Definitions] document.

The argument names in the Arguments column lists the arguments used in the
message. The argument names are defined in the [argument list].


> > The message tags should be formed following the [Message Tag Specification].
> >
> > The default severity level is selected from the [Severity Level Definitions].

## Test procedure

> > This section contains the detailed steps to execute the test case. The steps
> > should be as explicit as possible to avoid that different implementations or
> > executions make different interpretations or assumptions.
> >
> > If the test procedure uses DNS queries (most test cases do), then add the
> > following paragraph (types of DNS queries that do no apply for the test case
> > can be removed):

In this section and unless otherwise specified below, the terms "[DNS Query]",
"[EDNS Query]" and "[DNSSEC Query]" follow the specification for DNS queries
as specified in [DNS Query and Response Defaults]. The handling of the DNS
responses on the DNS queries follow, unless otherwise specified below, what is
specified for [DNS Response], [EDNS Response], and [DNSSEC Response],
respectively, in the same specification.

> > How the term "[DNSSEC Query]" is used can be seen in the next example below.
> >
> > The steps should be written in such a way that it is reasonably possible to
> > use them to execute the test case manually using tools such as [`dig`][dig].
> > It can be assumed that the reader of the text has good understanding of DNS.
> >
> > The steps should state what messages (message tags) to be outputted when.
> > Only messages with default severity level DEBUG or higher can be included.
> >
> > All messages with level INFO or higher must be included. I.e. the
> > implementation should not include messages with default level INFO or higher
> > unless included in the specification.
> >
> > Messages DEBUG or lower can be added in the implementation as needed without
> > being included in the specification.
> >
> > Also include statement on what other information to be accompanied
> > with the message (included as parameter to the message tag). Example of such
> > information is IP addresses to name servers.
> >
> > When referring to the data defined in **Inputs** then use the name in
> > *italic*, e.g.:

2. Create a [DNSSEC Query] with query type DNSKEY and query name *Child Zone*
   ("DNSKEY Query").

> > If data sets are created, then defined them in quote marks. E.g.:

4. Create three empty sets, "NSEC-Zone", "NSEC3-Zone", and
   "No-DNSSEC-Zone".

> > When used (referred to) in the steps, make the name italic. E.g.:

6. Add the name server IP to the *NSEC-Zone* set (*NSEC3-Zone*
         set).

> > When a message is outputted in the steps, it is done by outputting
> > the message tag, "T01_HAS_NSEC3" in the example below. Make the tag as a link
> > name in italic. What the link name points at is to be defined at the bottom
> > of the document. E.g.:

8. If the NSEC (NSEC3) records do not "cover" the
   *Nonexistent Query Name*, then output *[T01_HAS_NSEC3]*

> > When referring to RCODE, such as "NoError", use the term [RCODE Name]
> > with a link to the IANA page. Also use the name forms on that page.



## Outcome(s)
> > First we have standard text that should normally be the same in all
> > test case specifications.

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, no message or only messages with severity level
*[INFO]* or *[NOTICE]*, the outcome of this Test Case is "pass".

> > Then there could be statements about data being outputted from the test case
> > for use as input data for other test cases.

## Special procedural requirements

> > First we have standard text that should normally be the same in all
> > test case specifications.

If either IPv4 or IPv6 transport is disabled, skip sending queries over that
transport protocol. A message will be outputted reporting that the transport
protocol has been skipped.

> > Then there could be some other limitations or specialties of how or when
> > this test case is run. E.g.:

The test case is only performed if some DNSKEY record is found in the
*Child Zone*.

> > This is a standard limitation for all test cases:

The *Child Zone* must be a valid name meeting
"[Requirements and normalization of domain names in input]".

## Intercase dependencies

> > Either the following text if there is no formal dependencies on other test
> > cases...

None.

> > ...or specification on the outcome that this test case depend on, e.g.:

Example of formal dependency to be added.

> > Also see the text under **Objective** about test cases that are assumed to be
> > run, but that this test case does not depend on. I.e. not dependencies in a
> > formal sense.


## Terminology

> > If there is no terminology to be explained, then this section should contain
> > the following text:

No special terminology for this test case.

> > Following are examples of terminology that are candidates to be included
> > in the section.

* "DNS Lookup" - The term is used when a recursive lookup is used, though
  any changes to the DNS tree introduced by an [undelegated test] must be
  respected.

* "in-bailiwick" - The term is used as defined in [RFC 8499][RFC 8499#page-25],
  section 7, page 25. In this document, the term "in-bailiwick" is limited to the
  meaning "in-domain" in [RFC 8499][RFC 8499#page-25].

* "glue records" - The term is defined in [RFC 8499][RFC 8499#page-24], section 7,
  page 24.

* "out-of-bailiwick" - The term is used in this document to mean what is not
  "in-bailiwick" (see definition above).

* "send" (to an IP address) - The term is used when a DNS query is sent to
  a specific name server.

* "using Method" - The term is used when data is fetched using the defined
  [Method][Methods].

> > ----
> > The links listed below are not visible when rendered by GitHub. In the
> > specification the different parts below should be combined into one link
> > collection and sorted. Always start the link label (the left side) with an
> > upper case letter (if it starts with a letter). The reference can from the
> > text is case independent.
> >
> > All link names are listed below to the left with the link target to the
> > right. They are only visible when viewing the source of this document.
> >
> > All message tags are linked to section **Summary**

[T01_ALGO_NOT_SUPPORTED_BY_ZM]:         #summary
[T01_HAS_NSEC]:                         #summary
[T01_HAS_NSEC3]:                        #summary
[T01_INCONSISTENT_DNSSEC]:              #summary

> > All links in the template are absolute except for links within this template
> > or to other documents in the template tree. All absolute links to documents
> > in the zonemaster/zonemaster directory are to the develop branch. In the
> > test case specification all links should be relative if the link target is
> > in the zonemaster/zonemaster repository.
> >
> > A few relative links in this template:

[Message Tag Specification]:            MessageTagSpecification.md
[Test Case Identifier Specification]:   TestCaseIdentifierSpecification.md

> > Absolute links to be converted to relative links in the test case
> > specification. Here grouped to be easier to copy, but sort them
> > them always in the specification.

> > Links to pages on Zonemaster/Zonemaster:

[Severity Level Definitions]:                                     ../../../../public/specifications/tests/SeverityLevelDefinitions.md
[DEBUG]:                                                          ../../../../public/specifications/tests/SeverityLevelDefinitions.md#notice
[INFO]:                                                           ../../../../public/specifications/tests/SeverityLevelDefinitions.md#info
[NOTICE]:                                                         ../../../../public/specifications/tests/SeverityLevelDefinitions.md#notice
[WARNING]:                                                        ../../../../public/specifications/tests/SeverityLevelDefinitions.md#warning
[ERROR]:                                                          ../../../../public/specifications/tests/SeverityLevelDefinitions.md#error
[CRITICAL]:                                                       ../../../../public/specifications/tests/SeverityLevelDefinitions.md#critical

[Connectivity01]:                                                 ../../../../public/specifications/tests/Connectivity-TP/connectivity01.md

[Argument list]:                                                  ../../../../public/specifications/tests/ArgumentsForTestCaseMessages.md
[DNS Query and Response Defaults]:                                ../../../../public/specifications/tests/DNSQueryAndResponseDefaults.md
[DNS Query]:                                                      ../../../../public/specifications/tests/DNSQueryAndResponseDefaults.md#default-setting-in-dns-query
[DNS Response]:                                                   ../../../../public/specifications/tests/DNSQueryAndResponseDefaults.md#default-handling-of-a-dns-response
[DNSSEC Query]:                                                   ../../../../public/specifications/tests/DNSQueryAndResponseDefaults.md#default-setting-in-dnssec-query
[DNSSEC Response]:                                                ../../../../public/specifications/tests/DNSQueryAndResponseDefaults.md#default-handling-of-a-dnssec-response
[EDNS Query]:                                                     ../../../../public/specifications/tests/DNSQueryAndResponseDefaults.md#default-setting-in-edns-query
[EDNS Response]:                                                  ../../../../public/specifications/tests/DNSQueryAndResponseDefaults.md#default-handling-of-an-edns-response

[Methods]:                                                        ../../../../public/specifications/tests/Methods.md
[MethodsV2]:                                                      ../../../../public/specifications/tests/MethodsV2.md
[Undelegated test]:                                               ../../../../public/specifications/test-types/undelegated-test.md

[Requirements and normalization of domain names in input]:        ../../../../public/specifications/tests/RequirementsAndNormalizationOfDomainNames.md

[Zonemaster-Engine profile]:                                      ../../../../public/configuration/profiles.md

> > External links:

[Dig]:                                                            https://en.wikipedia.org/wiki/Dig_(command)
[RCODE Name]:                                                     https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[RFC 4035#section-3.1.3]:                                         https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.3
[RFC 8499#page-25]:                                               https://datatracker.ietf.org/doc/html/rfc8499#page-25
[RFC 8499#page-24]:                                               https://datatracker.ietf.org/doc/html/rfc8499#page-24



> > Keep all links sorted, and make a straight column of the link targets in
> > the test case specification.


