OpenDNSSEC Development
OpenDNSSEC Project Wiki

Links

OpenDNSSEC Developer Wiki
OpenDNSSEC Documentation
SoftHSM Developer Wiki
SoftHSM Documentation

OpenDNSSEC Home

Current location:

OpenDNSSEC Developer Wiki

Child pages
  • Project Requirements
Skip to end of metadata
Go to start of metadata

1. Introduction 

1.1 Scope of the System 

As envisaged, the signing system sits between a private master nameserver and a public master. The system receives data from the public master, signs it, and sends the signed data to the public master.

The scope of this document covers the first phase of development, a system that will be able to sign whole zones. It does not cover the intended subsequent phase that will allow for incremental zone updates.

2. Requirements for 1.0.0 

2.1 Basic Requirements 

  1. The system MUST be able to deal with configurations containing zero or more zones.
  2. The system MUST be able to handle zone sizes ranging from a few RRs to millions of RRs.
  3. The system MUST accept zone data in the form of a zone file in standard presentation format
  4. The system MUST output signed zone data as a zone file in standard presentation format.
    1. The system SHOULD be able to send a notify command to the local nameserver upon changed output signed zones.
  5. The system MUST be able to accept input zone data via an AXFR:
    1. The system MUST be able to request an AXFR from an authoritative server.
    2. The system MUST be able to process NOTIFY messages received from an authoritative server.
  6. In the case of AXFR transfers, the system MUST support TSIG authentication with the upstream authoritative server.
  7. The system MUST NOT depend on the BIND tools for signing.

2.2 Normal Operations 

2.2.1 Startup/Shutdown? 

  1. A start-up script SHOULD be supplied that allows the software to be started when the system starts up.
  2. The system MUST be able to drop privileges upon start up.
  3. It MUST be possible to shutdown all long-running software cleanly.
  4. If the software is not cleanly shutdown, it MUST be possible to restart it with no loss of data.
    Note: if this provides difficult/impossible to implement automatically, it is allowable for written instructions to be supplied describing how to manually recover from a failure.

2.2.2 Configuration 

  1. It MUST be possible to specify a list of zones to be signed.
  2. It MUST be possible to specify a policy for each zone that specifies how the zone should be signed.
  3. Sensible default values MUST be provided for all configuration parameters.
    Note: This is likely to be in the form of a default policy.

2.2.3 Operation 

  1. For each zone, at intervals specified by the policy, the system MUST retrieve the zone data, sign it, and output signed zone.
  2. It MUST be possible for an operator to be able to manually sign a zone.
    Note: this may be done for various reasons, e.g. a zone has changed and the change must be propagated as soon as possible.
  3. It MUST be possible to update the polices and zone data, without taking the system down.

2.2.4 Reporting 

  1. syslog() MUST be used as the logging mechanism.
  2. The choice of which operations to log SHOULD be configurable.
  3. The syslog() facility under which messages are logged SHOULD be configurable
  4. Components of the system should use the following log levels:
    1. Info - for informational messages. (System has worked, this is possibly useful information.)
    2. Warning - for warning messages. (System has worked, but this condition was sufficiently unusual to remark upon.)
    3. Error - for error messages. (System has encountered a problem.)
    4. Alert - for messages where the operator needs to be notified immediately.
      Note: if something goes wrong, the system might log multiple error messages as a result. However, only one alert message is required.
  5. All errors MUST be logged.

2.3 Signing Process 

2.3.1 Signing Policy 

  1. The system MUST sign each zone according to a pre-defined policy. (This determines parameters such as signing interval, key length, signature lifetime etc.)
  2. It MUST be possible for each zone to have its own policy.
  3. The policy for the zone MUST allow values for the following signing parameters to be set:
    1. Inception offset. (This is the time before the present at which the signatures first become valid. It allows for clock skew, a difference in times between two systems on a network.)
    2. The signature re-sign interval. The period of which the Signer runs.
    3. The signature refresh interval. The Signer will reuse a signature until it has this amount of time remaining in its validity period. After this will a new signature be generated.
    4. The default signature validity period of RRSIGs. (Note: this is the time from signing for which the records are valid.)
    5. Jitter. (Note: This is a value, uniformly distributed between zero and some maximum, added to the signature validity period to prevent all records signature expiring at once.)
    6. The TTL for DNSKEY records. (Note: this is the TTL for the DNSKEY records generated by the system. It also overrides the TTL associated with any DNSKEY records in the input file (as all DNSKEY records in an RRset should have the TTL).)
    7. Signature scheme:
      1. RSA/SHA1 MUST be supported for signatures.
      2. RSA/SHA-256 MUST be supported for signatures.
      3. RSA/SHA-512 MUST be supported for signatures.
  4. The policy MUST allow a choice of authenticated denial scheme:
    1. NSEC MUST be supported.
    2. NSEC3 without opt-out MUST be supported.
    3. NSEC3 with opt-out MUST be supported.
  5. The policy for the zone SHOULD allow values for the following to be set:
    1. The signature lifetime of the RRSIG for NSEC/NSEC3 records.
      Note: If not specified, the signature lifetime of NSEC/NSEC3 records should be that of other RRSIG records in the zone.
    2. The parameters for the NSEC3PARAM record: hash algorithm, flags, iterations and salt.
    3. The parameters for the SOA record: serial, minimum, ttl.

2.3.2 Signing Process 

  1. The signer MUST discard all DNSSEC RRs (except DNSKEY RRs) from the input data.
    Note: DNSKEY RRs may be in the input zone file if the zone is in the process of moving between DNS operators.

2.4 Key Management 

2.4.1 Key Generation 

  1. The system MUST generate keys as required according to the policy for the zone.
  2. The system MUST allow additional keys to be manually generated by the operator.
  3. The policy for the zone MUST allow the following key parameters to be set:
    1. The key algorithm:
      1. RSA MUST be supported as a key algorithm.
    2. RSA key lengths between 1024 and 4096 bits MUST be supported.
  4. The MUST have an option that will system not allow keys to be used until they have been backed up.
    Note: this means that there must be some way of notifying to the system that the backup has been done.

2.4.2 Key Storage 

  1. All access to key material MUST be via the  PKCS#11 API
    Note: This requirement is to allow use of any compliant HSM.
  2. The system MUST be capable of working with multiple PKCS#11 providers simultaneously.
    Note: this is to allow migration to new HSMs as the old ones reach the end of their life.
  3. If multiple PKCS#11 providers are in use:
    1. It MUST be possible to select which provider to use for new KSKs.
    2. It MUST be possible to select which provider to use for new ZSKs.
    3. The system MUST be able to access all existing keys, regardless of which connected provider they are stored in.

2.4.3. Key Rollovers 

  1. The system MUST be able to roll ZSKs automatically with no operator intervention.
  2. The rolling of the keys MUST be done according to the algorithm in  draft-morris-dnsop-dnssec-key-timing (or its successor documents). In particular, it MUST be possible to roll a ZSK without requiring multiple signatures per RRset.
  3. It MUST be possible to manually roll the ZSK for a zone.
  4. It MUST be possible to manually roll the KSK for a zone.
  5. It MUST be able to supply a DS record or a DNSKEY RR for every KSK.
  6. Where the KSK rolling process removes a key from the zone, the system SHOULD cause the generation of a notification that the corresponding DS record be removed from the parent zone.
  7. The system MUST be able to supply the operator with an advance warning of the the production of a new KSK for a zone if such notifications are enabled.
    Note: this requirement aids installations where the generation of a KSK is a manual operation.
  8. The production of a new KSK for a zone SHOULD be notified to the operator if such notifications are enabled.
    Note: this requirement aids installations where the passing of trust anchor information to an external organisation is a manual operation.

2.5 Integrity Requirements 

Since the loading of incorrect DNSSEC data into a zone could have serious consequences, e.g. a zone being perceived as bogus, the system must take steps to verify that the data it is outputting is correct.

  1. The system SHOULD have an independent check that the output zone data is correct.
    Note: This is handled by the KASP Auditor, which has its own set of requirements.

2.6 Performance Requirements 

For large zones, or for large numbers of small zones, it is important that the signing is completed in a reasonable time. The figures given here are an estimate of acceptable performance, and need to be refined.

  1. With appropriate hardware, it SHOULD be possible to sign a one-million name zone in one hour.
    Note: Verification is not included in this time period

2.7 Standards Conformance 

  1. The signatures created by the system and operation of the system MUST conform to the following standards:
    1.  RFC 4033
    2.  RFC 4034
    3.  RFC 4035
    4.  RFC 5155
    5.  RFC 5702

2. Requirements for 1.1.0 

2.1 Performance 

  1. The Signer SHOULD be able to sign RRs with multiple threads.
  2. With appropriate hardware, it MUST be possible to sign a zone in 30 minutes. 5M name zone, 10M NS, 25000 glue. Using NSEC3 with opt-out. With 8GB RAM.
  3. The system MUST handle 50.000 zones. (Please add more information)
  4. A newly added zone MUST be signed as soon as possible.
    Note: A newly added zone must be prioritized.

2.2 Hooks and commands 

  1. It MUST be possible to select an auditor program that will be used by the Signer.
  2. It MUST be possible to configure a command that will accept the zone name and the current set of keys that should be at the parent. Used for sending DS and/or DNSKEY RR to the parent.
  3. There MUST be a way of notifying the system that the current set of KSKs has been sent to the parent.
  4. There MUST be a way of notifying the system that a particular DS RR has been seen at the parent.

2.3 ods-auditor 

  1. It MUST possible to configure the auditing level.

2.4 PKCS#11 

  1. The system MUST only save the private key object in order to save space in the provider (and improves performance).
  2. The system SHOULD have a per provider flag, indicating whether the security module needs to be activated before starting the system.

3. Requirements for 2.0.0 

3.1 Basic Requirements 

  1. The system SHOULD be able to output signed zone data via an AXFR:
    1. The system SHOULD be able to send the data as an AXFR in response to a request from a slave server.
    2. The system SHOULD be able to send NOTIFY messages to all configured slave servers when new zone data is available.
  2. In the case of AXFR transfers, the system MUST support TSIG authentication with the downstream authoritative server.

3.2 Normal Operations 

3.2.2 Configuration 

  1. A utility to check the policy for consistency SHOULD be provided:
    1. It MUST be possible to run the utility independently of the rest of the system.
    2. The utility (or a variant) MUST be run automatically before the policy is loaded into the database.
    3. The utility SHOULD compare parameter values against the limits for that parameter and warn when the value lies outside the allowable range.
    4. The utility SHOULD check the values of all the parameters and warn if the combination is inconsistent.
    5. The utility SHOULD check the values of all the parameters and check that they form a policy that conforms to accepted practice.
      Note: In practice, this means checking that the policy is not obviously absurd.
  2. The system SHOULD have a GUI that simplifies the configuration process.
    Note: the GUI will be specified in a separate document.

3.2.4 Reporting 

  1. The system SHOULD have an alternative method (e.g. email) of notifying the operator of urgent conditions.

3.5 PKCS#11 

  1. The signer MUST channel all traffic to providers through a session proxy, which keeps open a single session.
  2. The signer MUST support PKCS#11 standard external authentication pads, to replace a filesystem-stored PIN.

3.6 Performance 

  1. The Signer MUST be able to sign RRs with multiple threads.

3.7 Standards Conformance 

  1. The signatures created by the system and operation of the system MUST conform to the following standards:
    1.  RFC 5011
  • No labels

      

www.opendnssec.org

Report a bug

Mailing list