Although under the hood a lot has changed in OpenDNSSEC 2.0, the architecture and workflow has more in common with OpenDNSSEC 1.4 than it differs. This 'HOWTO' will initially focus on procedures that have changed or are formerly not possible. In the future this should be more complete and include updated sections now only find found in the 1.4 Documentation.

Upgrade OpenDNSSEC 1.4.

...

10 to OpenDNSSEC 2.0

With the rewrite of the ods-enforcerd daemon the database layout has changed as well. Upgrade scripts for Sqlite3 and MySQL are provided in the source tarball in enforcer/utils/1.4-2.0_db_convert. See "Migration from 1.4 to 2.1" for more information. The text file README.md in that directory explains the process. Note: while 1.4 supplied scripts to convert from one database backend to the other, 2.0 does not have these yet. If you are planning to change database backend do that first before upgrading OpenDNSSEC.

...

A zone is tied to a policy, and policies are described in kasp.xml in /etc/opendnssec. The 2.0 enforcer will store policy timing information per key in its database. As a result all TTL values can safely be changed without running the risk of a zone become bogus during a current or future rollover. In contrast, if one would shorten a TTL in 1.4 the next rollover has a change to be performed to quickly as the records would still be in cache with the old, long TTL. After editing the policy in kasp.xml one should issue a policy import and urge the Enforcer to see if there is any work to do on the zones.

ods-enforcer policy import
ods-enforcer enforce

There is no need to restart the enforcer. In fact, the KASP is not being read on startup. Any new keys will use the new timings.

...

ods-enforcer policy import
ods-enforcer enforce

Soon the enforcer wil notice there are no keys with the newly chosen algorithm and will introduce new ones. Algorithm rollovers are a bit different than normal rollovers. During the process your zone will be signed with two keys. 

...

After this you must instruct the Enforcer to reread the policy and reevaluate the zones.

ods-enforcer policy import
ods-enforcer enforce

Use a single key as ZSK and KSK

New in OpenDNSSEC 2.0 is the support for CSK's (Combined Signing Key) Which take the role of KSK and ZSK. Its configuration is exactly like that of the other types but uses the <CSK> tag in the KASP.

<Keys>
	<TTL>PT3600S</TTL>
	<RetireSafety>PT3600S</RetireSafety>
	<PublishSafety>PT3600S</PublishSafety>
	<Purge>P14D</Purge>
	<CSK>
		<Algorithm length="2048">8</Algorithm>
		<Lifetime>P1Y</Lifetime>
		<Repository>SoftHSM</Repository>
	</CSK>
</Keys>

It is entirely possible to roll from a split key (KSK+ZSK) policy to a single key policy (CSK) and vice versa by changing the policy.

Get a parsable version of key list

The -p (or --parsable) is added to ods-enforcer key list to aid processing and monitoring of the key states by an external process. key list -v and key list -d accept this flag.

 The information outputted and order remains the same.

$ ods-enforcer key list -z example.com -d 2>/dev/null 
Keys:
Zone:          Key role:   DS:       DNSKEY:      RRSIGDNSKEY:  RRSIG:       Pub:  Act:  Id:
example.com    KSK         rumoured  omnipresent  omnipresent   NA           1     1     7a188b4177bed1a744c1bcb9aa4362cf
example.com    ZSK         NA        omnipresent  NA            omnipresent  1     1     1c86793b7b779d935756906ec7fd28f7

$ ods-enforcer key list -z example.com -d -p 2>/dev/null 
example.com;KSK;rumoured;omnipresent;omnipresent;NA;1;1;7a188b4177bed1a744c1bcb9aa4362cf
example.com;ZSK;NA;omnipresent;NA;omnipresent;1;1;1c86793b7b779d935756906ec7fd28f7

Passing zones through OpenDNSSEC unsigned

It is possible to pass zones through OpenDNSSEC without signing them. It's useful if you want to have the same work flow for OpenDNSSEC signed and unsigned (or externally signed) zones. To achieve this add the <Passthrough/> element to the policy like so:

<KASP>
    <Policy name="default">
		<Passthrough/>
        <Description>A default policy that will amaze you and your friends</Description>
        <Signatures>
			...
		...
	</Policy>
	...
</KASP>

Most of the following parameters such as TTLs and algorithms will not be used for this zone. They are still required to be present however, like in any other policy. Please also note that this is different than defining a policy without keys. A policy without keys will get its DNSSEC related records stripped.

Change Database Backend

If you are running OpenDNSSEC and want to change its used database backend there are three steps involved:

1. Change database settings in conf.xml
2. Create database
3. Convert the database

To accommodate step 3 we provided two scripts: convert_mysql_to_sqlite and convert_sqlite_to_mysql both located in enforcer/utils.

usage: ./convert_mysql_to_sqlite -i DATABASE_MYSQL -o DATABASE_SQLITE [-h HOST] [-u USER] [-p PASSWORD]
usage: ./convert_sqlite_to_mysql -i DATABASE_SQLITE -o DATABASE_MYSQL [-h HOST] [-u USER] [-p PASSWORD]

• DATBASE_MYSQL, Name of the MySQL database. Make sure you created the database beforehand.
• DATABASE_SQLITE, Path of SQLite database file. Will overwrite existing file
• HOST, USER, PASSWORD apply to the MySQL database. HOST will default to localhost.

When creating a SQLite database make sure the resulting file is readable and writable for the user OpenDNSSEC runs as.