These page capture the main differences between OpenDNSSEC 1.4 and OpenDNSSEC 2.0 in order to documented this for users during the development phase of 2.0.

Overview

The design of the enforcer daemon in 2.0 is fundamentally different to that in 1.4 in a number of ways:

• In 2.0 the command ods-ksmutil is replaced by ods-enforcer. A wrapper script will be provided in a future 2.0 release to re-direct commands issued to ods-ksmutil to ods-enforcer and issue a warning that ods-ksmutil is deprecated. This script will be removed in 2.1.
   
• The ods-enforcer executable is now located in {installdir}/sbin. (In 1.4 ods-ksmutil was located in {installdir}/bin.)
   
• In 2.0 all the command line utilities are now handled via the enforcer daemon. Therefore the enforcer daemon must be running in order to issue any command line instructions. (In 1.4 the command utilities could be executed in an offline mode using the ods-ksmutil command ).
   
• In 2.0 the enforcer daemon is task based and therefore may awake to execute tasks at any time. (In 1.4 the enforcer daemon ran periodically at intervals specified by the <Interval> tag in conf.xml)

Key states and rollovers

The logic of the enforcer in 2.0 centres around a generic engine which can perform flexible key rollover. This means it is possible to support:

• multiple rollover mechanisms
• algorithm rollover
• policy rollover
• a combined signing key

This logic is described in the paper "Flexible and Robust Key Rollover in DNSSEC". The key states used to model the rollover process with this logic are more granular than the familiar key states used in 1.4 (PUBLISH/READY/ACTIVE/RETIRE). However a mapping has been used in 2.0 to reproduced as much as possible the key state lifecycle users are familiar with from 1.4 in the 'key list' command. However users should be aware that this mapping is not exact. If they wish to observe the underlying key states this can be done by using the '--debug' option on 'ods-enforcer key list'.

More information on details of key states and the new rollover process are given on this page: New rollover options, logic and DS process.

Installation

Dependencies

2.0 introduces a dependency on Google's protocol buffer library. On Debian and derivatives you'll need the libprotobuf package. At compile time you additionally need protobuf-c-compiler and libprotobuf-dev. Some parts of 2.0 are written in C++.

Configure

There are a couple of new configure options:

• --with-protobuf=<path>
• --with-readline When enabled the client connecting to the enforcer daemon (ods-enforcer) keeps an history of typed commands when in interactive mode, much like for example the Bash shell would do. You will need the libreadline-dev library for this.

And a change to several configure options. The following options:

•  --with-dbname=DB_NAME   Database name/schema for unit tests
• --with-dbhost=DB_HOST   Database host for unit tests
• --with-dbport=DB_PORT   Database port for unit tests
• --with-dbuser=DB_USER   Database user for unit tests
• --with-dbpass=DB_PASS   Database password for unit tests
• --with-database-backend  Select database backend (sqlite3|mysql)

are replaced by:

• --with-enforcer-database=BACKEND Select database backend: sqlite3 (default), mysql 
• --with-enforcer-database-test-host=HOSTHost to use when testing the Enforcer database backend
• --with-enforcer-database-test-port=PORT Port to use when testing the Enforcer database backend
• --with-enforcer-database-test-database=DATABASE Database to use when testing the Enforcer database backend
• --with-enforcer-database-test-username=USERNAME  Username to use when testing the Enforcer database  backend
• --with-enforcer-database-test-password=PASSWORD Password to use when testing the Enforcer database backend
  

 A known issue on Debian Testing (jessie) when building with sqlite is the improper include of the pthread library. Please make sure the file enforcer-ng/Makefile contains the line "LDFLAGS = -pthread". Or configure with ./configure LDFLAGS="-lpthread"

Migration

The migration path to upgrade the enforcer database from 1.4 to 2.0 is only partially implemented and is not yet available to users. This will be completed in a later development release.

Configuration

Files

conf.xml: <Enforcer> section

• <Interval>: The <Interval> tag is no longer used in 2.0. If present in the conf.xml it will generate a warning on startup and when the file is checked by kaspcheck. It will be deprecated in 2.1.
• <AutomaticKeyGenerationPeriod>: By default the enforcer will generate enough keys for 1 year in advance when it runs. The <AutomaticKeyGenerationPeriod> modifies this interval. (The ability to have keys generated on demand as in 1.4 will be added in a future 2.0 development release.)
• <PidFile>: Just like the signer the enforcer now specifies <PidFile> 
• <WorkerThreads>: In a similar manner to the signer, this configures the number of worker threads for the enforcer daemon to use. (Note that this option existed in 1.4 but was ignored).
• <WorkingDirectory>: Just like the signer the enforcer now specifies <WorkingDirectory>. Default is var/opendnssec/enforcer. It is recommended the enforcer and signer do not share their working directories. 
• <DelegationSignerRetractCommand>: A new <DelegationSignerRetractCommand> element is added. It serves a similar purpose to the <DelegationSignerSubmitCommand>. The reason for introduction is that in the 2.0 implementation different kinds of key roll-overs are possible where the introduction of a DS record does not imply the decommissioning of the old DS record (yet).

conf.xml: <Signer> section

•  <WorkingDirectory>: The default working directory for the signer is changed to var/opendnssec/signer (was var/opendnssec/tmp).

kasp.xml: <Signatures> section

• <MaxZoneTTL>: To facilitate a perfectly safe rollover the enforcer needs to know the value of the largest TTL in the zone. By design the enforcer does not read the actual zone files and depends on the <MaxZoneTTL> element. This value will influence the time it takes to complete a ZSK rollover. When the signer encounters a TTL larger than MaxZoneTTL it will cap that TTL to MaxZoneTTL and print a warning.

kasp.xml: <Keys> section

• The <KSK> section takes an optional <KskRollType>. This indicates the preferred way of rolling a key signing key. Possible values are: KskDoubleRRset, KskDoubleDS, KskDoubleSignature. The last being the same as the 1.x rollover and is the default.
• The <ZSK> section takes an optional <ZskRollType>. This indicates the preferred way of rolling a zone signing key. Possible values are: ZskDoubleSignature, ZskDoubleRRsig, ZskPrePublication. The last being the same as the 1.x rollover and is the default.
• New <CSK> section. Additionally 2.0 supports a <CSK> section where one key acts as both the KSK and ZSK thus shaving a record of from the DNSKEY section in the zonefile. It takes an optional <CskRollType>: CskDoubleRRset, CskSingleSignature, CskDoubleDS, CskDoubleSignature, CskPrePublication. The last being the same as a regular ZSK+KSK 1.x rollover and is the default.

Running OpenDNSSEC

Policy Management

A notable change in OpenDNSSEC 2.0 is that the Enforcer has a much better understanding of how a valid DNSSEC signed zone should look. Another key feature is the decoupling of state from policy. In practice this means you can change the policy for a zone without negative side effects. Whenever algorithms or timings are changed, the Enforcer will deal with this gracefully i.e. it should never do an automated action which could render (a part of) the zone bogus. 

Daemon lifecycle

Some minor changes have been made to the specific information re-read by the enforcer daemon over restart/reload/enforce actions.

Zone management

See Changes to zone management

Logging

The logging in 2.0 is still a work in progress. It is significantly different in some aspects to 1.4 and providing improved logging is on the roadmap!

Command utilities

ods-enforcer

The majority of the backwards compatible set of  'ods-enforcer' command utilities are implemented, however some commands are missing some options. The following commands are not yet implemented:

• database backup
• key purge/delete
• key import
• repository list

Note that in 1.4 the commands returned a status code. The 2.0.0a4 release does not support this yet but it will be added in the next development release. 

ods-hsmutil dnskey

In 1.4 the "ods-hsmutil dnskey" command uses a fixed algorithm and key type; it is hard coded to ZSK and algorithm 5. In 2.0 the user is forced to select key type and algorithm.

Future development releases

Some changes which are in the pipeline but not in this particular release:

• Exit codes for the ods-enforcer client utility.
• Differentiate between stdout and stderr for the ods-enforcer client utility.
• Choose alternative socket file for the ods-enforcer client utility.
• Improved automation of KSK rollover steps for 'vanilla' workflows
• Just-in-time key generation (no pre-generation).
  
  

Further away in the future:

• Rewrite of the database backend
  • Remove dependency on Protocol Buffers
  • Remove dependency on C++
  • Allow to be compiled with support for multiple back-ends simultaneously.