Skip to end of metadata
Go to start of metadata

1. Introduction

The OpenDNSSEC XML configuration files (conf.xml and kasp.xml) offer the user many options to configure the OpenDNSSEC signing system. Some syntactic constraints are placed on the configuration by the .rng definition (for example, whether an element is required or optional), but some semantic constraints cannot be defined this way (for example, if NSEC3 is used to secure the zone, then a consistent DNSKEY algorithm choice should be made). The Policy Configuration Checker is intended to check the user's configuration before the signing commences.

2. Operational Requirements

The tool may be run either by the user (to check recent changes to the configuration), or by the OpenDNSSEC system at startup (to check that the configuration is sane).

The tool should be able to report directly to the user through the console (as logging may have been incorrectly configured, and the user may be running the tool directly from the console).

3. Syntactic Checks

The Configuration Checker will validate the conf.xml and kasp.xml files against the .rng definitions.

4. Semantic Checks

A number of the checks here test the value against fixed limits. These seem sensible values, although it is recognised that there may be good reasons for breaching them. For this reasons, a failure of the check should only generate a warning, not an error.

It is suggested that the limits not be hard-coded into the policy checker, but specified in a separate file or as command line options

4.1 General Checks

  1. If 'm' is used in the XSDDuration, then warn the user that 31 days will be used instead of one month.
  2. If 'y' is used in the XSDDuration, then warn the user that 365 days will be used instead of one year.
  3. Check that any paths used exist. It would be good to check if paths will be writable after dropping privileges to the defined user/group.

4.2 conf.xml Checks

  1. If a user and/or group is defined in the conf.xml then check that it exists.
  2. If there are multiple repositories of the same type, each must have a unique TokenLabel
  3. If a repository specifies a capacity, the capacity must be greater than zero.
  4. Check that the shared library (Module) exists.
  5. Check if two repositories exist with the same name.

4.3 kasp.xml Checks

  1. Warn if a policy named "default" does not exist.
  2. Check if two policies exist with the same name.
  3. For all policies, check that the "Re-sign" interval is less than the "Refresh" interval.
  4. Ensure that the "Default" and "Denial" validity periods are greater than the "Refresh" interval.
  5. Warn if "Jitter" is greater than 50% of the maximum of the "default" and "Denial" period. (This is a bit arbitrary. The point is to get the user to realise that there will be a large spread in the signature lifetimes.)
  6. Warn if the InceptionOffset is greater than one hour. (Again arbitrary
    - but do we really expect the times on two systems to differ by more than this?
  7. Warn if the "PublishSafety" and "RetireSafety" margins are less than 0.1 * TTL or more than 5 * TTL.
  8. The algorithm should be checked to ensure it is consistent with the NSEC/NSEC3 choice for the zone.
  9. If datecounter is used for serial, then no more than 99 signings should be done per day (there are only two digits to play with in the version number).
  10. The key strength should be checked for sanity
    - warn if less than 1024 or error if more than 4096. Only do this check for RSA.
  11. Check that repositories listed in the KSK and ZSK sections are defined in conf.xml.
  12. Warn if for any zone, the KSK lifetime is less than the ZSK lifetime.
  13. Check that the value of the "Serial" tag is valid.
  14. Error if Jitter is greater than either the Default or Denial Validity.
  15. Warn if resalt is less than resign interval.
  • No labels