From OpenDNSSEC to Knot DNS

This article is written to assist those considering Knot DNS as a replacement for OpenDNSSEC.

More specifically, in this article, we'll be showing how to:

• Make Knot use Hardware Security Modules (HSMs) via the PKCS11 interface.
• Seamlessly transition from OpenDNSSEC (ODS) to Knot.
• Transition from HSM to automatically managed in-memory keys.

If you've never interacted with Knot before, please familiarize yourself with the basics. Our documentation provides a great novice-friendly introduction.

Preparation

Let's assume ODS is currently running and taking its input data from .

First, we need to prepare a transient configuration. We won't be running Knot itself just yet, but we will be using the tools that come with it (especially ; the key management utility), which share its settings.

In the above example, we set up Knot to:

• Source its data from the same zonefile ODS uses as input.
• Sign the data, but leave the key administration to the operator.
• Keep the keys stored safely in an HSM.

The config option in the keystore section of knot.conf () is the PKCS11 token Uniform Resource Identifier (URI) combined with the HSM's module path - see the relevant documentation. The template provided above should work well enough. Both and should be specified in your existing ODS configuration (). The resulting URI could look like:

Finally, make sure that the Knot process has access rights to the zonefile and any necessary data linked to your HSM. Then, if you've set up everything correctly thus far, you should see something like the following:

If, in the Knot configuration, you used a different in the section, use that instead of .

Key importing

Before attempting any of this, you should make sure ODS isn't currently in the midst of a rollover or that there isn't a rollover planned in the near future. A more rigorous approach would be to disable automatic key generation and rollovers by issuing in and in .

We've configured Knot to be able to access our HSM storage. Next, we need to seamlessly phase out ODS while phasing in Knot.

To do that, we need to synchronize private keys between ODS and Knot. Knot has a separate utility for key management named , which allows us to do exactly that. HSMs don't provide keymgr with metadata about the key, so first we have to use ODS tooling to find that information:

And then we may:

Now, make sure everything went well, and the keys are actually imported:

To be clear, these commands only make Knot aware of the keys' parameters and existence inside your HSM. They do not extract the cryptographic secret.

If you haven't done so yet, now is a good time to actually start the Knot daemon. If you ran it previously, in its logs, you would have seen complaints about missing keys, and the zone wouldn't be signed. (Re)starting now, everything should work fine:

From adapters to remotes

Suppose we want our Knot signer to act as a hidden primary for one or more secondaries. This can be achieved with the following configuration options:

Of course, this has to be reciprocated on the secondaries' side.

Now, what if we wanted the source data to come from a zone transfer (XFR) instead of a zone file, similarly to ODS's input adapter? No problem on that front either!

Nothing prevents us from defining both and statements at the same time, providing multiple masters in a multisigner setup, or using the server as a validator ( option).

The options are vast, but they're out of scope for this article.

By default, communication with a happens in plain-text over TCP. We've previously discussed the mechanisms through which communication may be secured in a previous post, but in a nutshell, Knot DNS supports TSIG, TLS and QUIC in opportunistic, strict and mutual modes.

Keystore migration

The upcoming Knot v3.5 will bring support for multiple keystores, which is a feature useful for those of you who want to migrate away from HSM keystores to internally managed keys. You will also be able to keep your Key-Signing Keys (KSKs) in an HSM for security, with Zone-Signing Keys (ZSKs) staying in memory for efficient signing.

Some HSMs don't allow private key extraction, so the only way to migrate is to do a rollover to different keystores. The steps are:

1. In , define the destination keystore for the migration.
2. Perform the key rollover.
3. Remove the old keystore from the configuration.

Let's demonstrate with an example migration from SoftHSM to Knot's PEM keystore:

It's important to set the option so that it corresponds to the algorithm used by your HSM. Otherwise, in combination with automatic key management, Knot would automatically initiate an algorithm rollover.

Notice that the new is referenced first in the policy section. In this way, it is denoted as the default store for newly generated keys.

Now reload Knot's configuration:

Unless you've manually set key lifetimes in your , the default values apply - indefinite for KSKs and 30 days for ZSKs. We can't afford to wait that long, so let's move it along a little:

We've issued the command to schedule a ZSK rollover. This is reflected in the logs:

If that went well, repeat the same command, only this time with KSK. After a while, you should see a log:

Make sure the new delegation signer (DS) is submitted to the parent zone and then:

Alternatively, define a submission section and ksk-submission to handle DS checks automatically.

Now just sit back and watch the rollover happen:

Now you can safely remove any mention of from the configuration. If you wish, you can now also change the algorithm and perform an algorithm rollover.

This process could alternatively be left for Knot to deal with 'automatically', by adjusting the values of , , and . However, describing the various nuances and pitfalls would be out of scope for this article.

Wrapping up

Hopefully, this was helpful to get you started on your transition from OpenDNSSEC to Knot DNS. We aim for Knot to be a powerful, yet approachable and coherent software package, which we hope was apparent throughout this article.

We're always improving and always open to user feedback. If you're looking to report a bug, request a feature or simply say hi, feel free to join one of our communication channels - we hope to see you there.

Jan Doskočil is a developer of Knot DNS, a project supported by CZ.NIC Labs.

This post is adapted from the original at CZ.NIC.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.