Skip to end of metadata
Go to start of metadata

1. Introduction

1.1 Background

This page contains the requirements for the auditor for opendnssecv1.1. The terminology used in the requirements for version 1.0 of the auditor will be re-used in this document.

For version 1.0, the auditor processed the entire zone file. To do this, the auditor needed to expand every line the file to its canonical form, and then sort the file. After this, the file could be processed a line at a time. If NSEC3 was used, more file were created (to store details about the NSEC3 records found) and then scanned. This technique succeeded in checking almost every aspect of the generated zone (which was extremely useful for testing purposes). However, for large zones (in excess of a million records), this technique takes too long (a problem exacerbated by the use of the Ruby language).

For version 1.1 of the OpenDNSSEC system, there should be a choice of auditors. Many zones will continue to use the full (v1.0) auditor, as they do not have performance requirements. Some sites (TLDs in particular) will wish to use the auditor-v1.1, and to be able to configure this auditor for use on their zone.

1.2 Requirements Overview

The rest of the document contains the requirements for auditor-v1.1. They fall into two categories:

  • Operational
    - concerned with the configuration and operation of the system.
  • Consistency Checking
    - concerned with checking that the zone data has been signed according to the KASP policy.

2 Operational Requirements

It must be possible for the user to choose between versions of the auditor. For OpenDNSSEC version 1.1, the partial auditor will not be configurable. Otherwise, the operational requirements of the two systems are the same.

3. Consistency Checking Requirements

For these checks, E signals that an error (LOG_ERR) is generated, W signals that a warning (LOG_WARNING) is generated and I signals that an informational message (LOG_INFO) is generated. The KA will exit with a code equal to the negative of the most severe level log message that was generated (e.g. -3 for LOG_ERR, -4 for LOG_WARNING, and 0 for OK or LOG_INFO).

3.1 Non-DNSSEC Data

1. The number of non-DNSSEC resource records in the unsigned zone should match the number of non-DNSSEC resource records in the signed zone.
1. Zone apex
- the non-DNSSEC resource records at the zone apex should be checked in both the signed and unsigned zones. The serial number in the SOA may differ.
1. The SOA serial number should be retained between runs, and a warning should be generated if it is seen to decrease.
1. The policy should be checked, and an error generated if the SOA serial has changed, when the policy is to keep the serial.
1. The KA will check that the SOA TTL in the output zone is the same as the SOA TTL in the input zone, unless the //Zone/SOA/TTL element in the zone policy overrides this value. E
1. The KA checks that the SOA name is the same in the input and output zones. E
1. The KA checks that the SOA is the first record in the output zone. E

3.2 DNSKEY checks

The KA should examine each DNSKEY record in the zone and check that:

1. The flags field contains an allowed combination of flags. E
1. The protocol field contains a valid protocol number. E
1. The algorithm field contains a valid algorithm number. E
1. The TTL is as set in the policy for the zone. E
1. There is at least one DNSKEY record in the zone with the SEP bit set. E
1. There is at least one DNSKEY record in the zone with the SEP bit clear. E
(The last two checks ensure that there is both a ZSK and KSK for the zone. This is not required by the DNSSEC protocol but, as it is considered good practice, the KA should check for this.)

3.3 Signature Checks

These signature checks should be performed for all records at the zone apex. The user should also be able to supply a list of domains, or specify a number of randomly chosen domains, to be checked.

For each signed domain chosen for verification (or, configurably, for all RRSIG records), the KA should check that:

1. The inception date of each RRSIG record is in the past by at least the interval specified by the policy for the zone. E
2. The expiration date of each RRSIG record is in the future by at least the interval specified by the policy for the zone. E
3. Signature lifetime checked by : inceptionoffset + validity
- jitter ? (exception
- inception) ? inceptionoffset + validity +jitter E

The following should be configurable for all signed domains chosen for verification (i.e. none, some or all of the chosen signed domains may be specified) :

3. The RRSIG record(s) validate the RRset(s) for the domain using one of the keys in the DNSKEY RRset. (Note: except for the zone apex, there should be no RRSIG for NS RRsets, glue records, unsigned delegations or out of zone data.) E
4. There is an RRSIG record for each algorithm for which there is a DNSKEY RR (unless the domain is glue, an unsigned delegation or out of zone) E

3.4 NSEC Checks

If the policy for the zone specifies that the NSEC authenticated denial scheme is being used, the KA should check that:

1. There are no NSEC3 or NSEC3PARAM records in the zone. E
2. Each NSEC RR has the same TTL value as the SOA minimum TTL. E

For each signed domain chosen for verification, the KA should check that :

3. The domain has a corresponding NSEC record. E
4. Each NSEC record has bits correctly set to indicate the types of RRs associated with the domain. E

3.5 NSEC3 Checks

If the policy for the zone specifies that the NSEC3 authenticated denial scheme is being used, the KA should check that:

1. There are no NSEC records in the zone. E
1. An NSEC3-consistent algorithm is used to sign the zone. W
1. If an NSEC3PARAM RR is found:
a. There is only one NSEC3PARAM record in the zone, and it is present at the apex of the zone E
a. The flags field of the record must be zero. E
a. Each NSEC3 record present in the zone has the same hash algorithm iterations and salt parameters. E
1. Each NSEC3 RR has the same TTL value as the SOA minimum TTL (unless overridden by the configured //Zone/SOA/Minimum in kasp.xml, when it should have that value) E
1. Each NSEC3(PARAM) record has the values specified in the zone policy for salt, algorithm and iterations. E
1. Following the next hashed owner name links form a single closed loop. E

For each signed domain chosen for verification, the KA should check that :

1. Each NSEC3 record has bits correctly set to indicate the types of RRs associated with the domain. E

3.6 Key rollover Checks

For each signed zone chosen for verification, the KA should:

1. Keep a record of what keys have been used in the zone, from the KA point-of-view.
a. When it was pre-published (added to the zone).
a. When it was made active.
a. When it was retired.
a. When it was made dead (removed from the zone).
a. The information about the key may be dropped once the key is dead.
1. Give a warning if the KSK is active longer than (KSK->Lifetime + Enforcer->Interval). W
1. Give a warning if the ZSK is active longer than (ZSK->Lifetime + Enforcer->Interval). W
1. Give a warning if the number of pre-published ZSK:s are less than ZSK->Emergency. W
1. Give an error if a key is seen in use without it having first been seen as prepublished for a time of at least the zone SOA TTL. E

  • No labels