Skip to end of metadata
Go to start of metadata

1. Introduction

1.1 Background

A misconfiguration or fault in the OpenDNSSEC software can have serious consequences. At best, zone data (including DNSSEC information) will be unaffected, although signature expiration times may be earlier or later than desired. At worst, a zone may be improperly signed, or may be missing data.

The purpose of the KASP Auditor (KA) is to provide an integrity check on the OpenDNSSEC signing process. It checks the output zone data against the input zone data and KASP policy and returns an indication as to whether the data is correct. Depending on the way that the signing system is set up, this indication could be used to prevent the propagation of the signed data into the public nameservers.

1.2 Terminology

The following terminology is used in this document:

  • Input zone data
    - the data that is to be signed. Normally it will be unsigned data, but it may contain DNSSEC records.
  • Output zone data
    - the data output from OpenDNSSEC after a run of the signer. It will contain all the non-DNSSEC RRs from the input zone data and may contain some DNSSEC RRs from that source (if present in the input, and if the signer does not decide to remove or replace them). It will also contain DNSSEC RRs generated by the signing process.

1.3 Requirements Overview

The rest of the document contains the requirements for the KS. 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

OpenDNSSEC will be used both for systems with a small number of large zones and for systems with a large number of small zones. Although it is possible to perform a complete check on all data, it is may not be be feasible for millions of domain names. Accordingly, the system should be able to perform checks on a subset of the data.

  1. It must be possible to specify the zone or zones for which the KA is to perform checks.
  2. The KA should be able to accept the input zone data in the form of:
    a. A zone file.
    a. An AXFR.
  3. It must be possible to specify the source of input zone data to the KA.
  4. The KA must be able to accept the output zone data in the form of:
    a. A zone file.
    a. An AXFR.
  5. It must be possible to specify the source of output zone data to the KA.
  6. It must be possible to specify the policy information used to sign the data.
  7. It must be possible to specify whether:
    a. The entire zone data is checked.
    a. A sample of zone data is checked.
  8. In the case that only a sample of the zone data is checked, it must be possible to specify one of:
    a. What fraction of the zone data is checked.
    a. A minimum number of domains to check.
  9. The KA must log the following to the syslog stream:
    a. The start of checking run.
    a. The end of the checking run.
    a. All checks that fail, with enough detail to locate the source of the error.
  10. The KA must provide a way for the controlling process to be able to determine that a check has failed and that the remainder of signing process (i.e. the loading of the signed data into the zone) is to be abandoned.
  11. It must be possible to specify a way that a zone operator can be notified in the case of check failure. Possible options are:
    a. Send an email message.
  12. The policy must be read from the KASP given by the user (kasp.xml).
  13. The KA shall not get information from the KASP database.

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. All non-DNSSEC data (i.e. all RRs except NSEC, NSEC3, NSEC3PARAM, and RRSIG) in the input zone must be identical to that in the output zone E. The only exceptions are SOA, where it is permissible for the serial number to differ, and out-of-zone-data W. DNSSEC data in the input zone generates a warning W.
  2. No additional non-DNSSEC data is included in the output zone. E
  3. The KA will retain the SOA serial number for a zone between runs and warn if the zone serial number has decreased. E
  4. The KA will check the SOA against the policy
    - if the policy is to keep the serial, then the KA will error if the serial has changed. E Otherwise, an info message is generated when the SOA changes. I
  5. 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
  6. The KA checks that the SOA name is the same in the input and output zones. E
  7. The KA checks that the SOA is the first record in the output zone. E
  8. An error is generated if an invalid RR is found in either 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
  2. The protocol field contains a valid protocol number. E
  3. The algorithm field contains a valid algorithm number. E
  4. The TTL is as set in the policy for the zone. E
  5. There is at least one DNSKEY record in the zone with the SEP bit set. W
  6. There is at least one DNSKEY record in the zone with the SEP bit clear. W

(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

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

  1. 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
  2. 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
  3. The inception date of each RRSIG record is in the past by at least the interval specified by the policy for the zone. E
  4. The expiration date of each RRSIG record is in the future by at least the interval specified by the policy for the zone. E
  5. Signature lifetime checked by : inceptionoffset + validity
    - jitter ? (exception
    - inception) ? inceptionoffset + validity +jitter 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 domain has a corresponding NSEC record. E
  3. Each NSEC RR has the same TTL value as the SOA minimum TTL. E
  4. Following the "Next Domain" field, the NSEC records form a single closed loop, with each "Next Domain" being alphabetically greater than the last. (The exception is the last NSEC record, which should point to the domain name of the zone apex.) E
  5. 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
  2. An NSEC3-consistent algorithm is used to sign the zone. W
  3. 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
  4. 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
  5. Each NSEC3 record has bits correctly set to indicate the types of RRs associated with the domain. E
  6. Each NSEC3(PARAM) record has the values specified in the zone policy for salt, algorithm and iterations.
  7. The "Next Hashed Owner" name field contains the hash of another domain in the zone that has an NSEC3 record associated with it, and that the links form a closed loop. E
  8. If an NSEC3 record does not have the opt-out bit set, there are no domain names in the zone for which the hash lies between the hash of this domain name and the value in the "Next Hashed Owner" name field. 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.
  2. Give a warning if the KSK is active longer than (KSK->Lifetime + Enforcer->Interval + Signatures->Validity). W
  3. Give a warning if the ZSK is active longer than (ZSK->Lifetime + Enforcer->Interval + Signatures->Validity). W
  4. Give a warning if the number of pre-published ZSK:s are less than ZSK->Emergency. W
  5. 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 KSK TTL. E
  • No labels