Putting DNSSEC signers to the test: Knot vs Bind

In 2010, it was an easy decision to use a commercial DNSSEC signer to deploy DNSSEC on APNIC’s reverse zones. Because much of the signer’s management was automated, we only had to worry about updating the parent delegation signer (DS) record separately.

So, even though we had to consider the scheduled Key Signing Key (KSK) rollover, updating the parent DS record on time was never an issue, since it would not roll-off the old key unless the new DS record had been updated in the parent zone.

In 2019, RFC 8624 (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) was released. The minimum recommended DNSKEY algorithm changed to RSASHA256, and there was a strong recommendation to use ECDSAP256SHA256 as it provides more cryptographic strength with a shorter signature length than either RSASHA256 or RSASHA512.

RSASHA1 was APNIC’s DNSKEY algorithm for almost 10 years, so the need to upgrade was it was inevitable. When it was time to upgrade, algorithm rollover was supported and well documented.

Following the recommendations in RFC 8624, we decided to migrate APNIC’s existing DNSKEY algorithm from RSASHA1 to ECDSAP256SHA256. The whole process took about a week to complete, without breaking the DNSSEC chain of trust.

Once we’d migrated, it was great to see the new (short) signatures from our zones.

What else could we ask for?

Cracks appear

Unfortunately, our run of good luck was hard to maintain and we started seeing performance penalties using ECDSAP256SHA256 with the commercial DNSSEC signer. While the DNS servers answering queries were fine, the CPU of our DNSSEC signer was struggling during its daily re-signing event. With no software update or solution from the vendor, the only options were to rollback or migrate to another DNSSEC signer.

A replacement is needed

APNIC needed to replace our DNSSEC signer, but there were very high expectations for any candidate replacement. We had a lot of requirements that we wanted to carry over from our old one, and we also had some new requirements we wanted as well.

Read: DNSSEC — the long and bumpy road of algorithm deployment

We knew that the RIPE NCC had made their own DNSSEC migration to Knot, so we put that on the list of candidates. We also put Bind on the list since we were familiar with it and had been following its development. We were also interested in PowerDNS but at the time of testing, the key rollover required the manual creation of keys, and manually retiring old keys.

The two candidates left remaining were:

• Bind-9.16
• Knot-2.9

We had our requirements, so we spun-up virtual machines to test Bind and Knot on DNS servers. Both DNS servers were configured in parallel with a production DNSSEC signer. This allowed us to load the same zones as production and apply the same monitoring tool and configuration management. Part of our new requirements was to use configuration management to deploy zone configuration, DNSSEC policy, monitoring, and metrics collection.

Game on: Knot vs Bind

It’s important to note that this contest was about the specific DNSSEC signing needs of APNIC and is not a reflection on the quality of either offering. Both Knot and Bind had already been identified as the most suitable out of many options, and both of them are constantly updated with new features.

So, with all those considerations, the time had come to put them to the test!

Automatic DNSSEC zone signing: Both score

A new DNSSEC signature must be issued before the existing signature expires. The process of keeping the DNSSEC signature up to date is automatic DNSSEC zone signing. This was well-handled by both candidates. Both DNS servers can be configured to set how long DNSSEC signatures remain valid, and the frequency of re-signing the DNS resource record.

Automatic DNSSEC key rollover: Knot wins

Automatic rollover of the key is one thing, rolling-off the old key after the parent DS has been updated is another thing entirely. Our existing DNSSEC signer had both these features, so we really wanted to keep that capability. At the time of testing, both candidates successfully rolled over the KSK and ZSK automatically. When it came to the KSK rollover, only Knot checks the parent zone for the updated DS record presence. If the KSK has changed without updating the corresponding DS record in the parent, it breaks the DNSSEC chain.

For this round, we picked Knot as the winner.

DNSSEC Key and Signing Policy (KASP): Both score

Depending on the top level domain and domain registrars, we need to have different sets of DNSKEY algorithms.

We also have some non-critical zones that don’t regularly need a KSK rollover. Having a DNSSEC policy that can be applied for each zone, or multiple zones, allows us to operate with some flexibility.

For Bind, versions prior to Bind-9.16.10 have the DNSSEC policy outside the configuration file named.conf, while Knot has the DNSSEC policy in its configuration file, knot.conf.

At the time of testing, Bind required the initial creation of keys manually, and running DNSSEC policy automation using the dnssec-keymgr command line tool. A cron job had to be created to run at least every hour, with dnssec-keymgr to apply the policy.

In order to apply DNSSEC policy for a zone in Bind, you need to include the list of zones, including the policy, in another configuration file called dnssec-policy.conf. However, from Bind-9.16.10 onwards, DNSSEC policy can now be included with the Bind configuration file, named.conf.

In contrast, Knot’s DNSSEC policy is part of its configuration file. Applying DNSSEC policy in Knot meant simply including the policy name within the zone configuration. Bind met this requirement just in time, so both of them passed this requirement.

Manual DNSSEC key rollover: Both score

While automated rollover is great, some circumstances require you to override the scheduled rollover.

A short command line tool to initiate key rollover is a must, to avoid manually manipulating DNSKEY metadata. This is critical if you need to do an emergency rollover of KSK or ZSK without waiting for the actual schedule rollover.

The latest release of Bind-9.16 includes rndc dnssec -rollover -key id to initiate a key rollover for a zone. The only requirement from Bind is that you have DNSSEC policy already configured. In comparison, Knot has knotc zone-key-rollover <zone> ksk|zsk which will also initiate a key rollover. While this is a manually initiated key rollover, keys are created automatically.

DNSKEY algorithm rollover: Knot wins

In DNSSEC, the key algorithm for both KSK and ZSK should be the same. This means that if the algorithm needs to change, both KSK and ZSK will also need to change. We hoped that the DNSKEY algorithm rollover could be similar to the key rollover process, but this depends on each vendor implementation.

The DNSSEC algorithm rollover in Knot involves simply changing the DNSSSEC policy name from the configuration file and following the manual key rollover command. This starts the normal process of rolling the keys without breaking the DNSSEC chain of trust.

In Bind, pointing the zone to another DNSSEC policy with different algorithm changes both KSK and ZSK right away, breaking the DNSSEC chain of trust. We were hoping for a simpler method of algorithm rollover, so Knot wins this round.

Dynamic zone configuration: Both score

In DNS, the process of updating resource records without a reloading zone is called ‘dynamic update’. In contract updating, the configuration file normally requires editing and reloading configuration for changes to take effect. It has now become a common feature to be able to update the zone configuration without reloading the configuration file. If the DNSSEC signer supports some form of dynamic zone configuring, it can be integrated easily into configuration management for automation.

Both Knot and Bind support dynamic zone configuration without restarting or reloading the configuration file. As a bonus, both support the ‘DNS catalogue zones’ which allow the server to automatically add or remove the zone based on changes from its catalogue or list of zones. Both scored a point this round.

Support for CDS/CDNSKEY: Both score

There’s no such thing as fully automated DNSSEC key rollover, unless it allows you to update the DS record in the parent zone. RFC 8078 outlined the use of CDS and CDNSKEY resource records as a basis for automatically updating the DS Record in the parent zone. This will be a good feature for APNIC to have as we operate parent Reverse DNS zones. Both Bind and Knot publish CDS and CDNSKEY resource records, so we’re calling this round even.

Support for importing and exporting DNSKEY: Knot wins

If you don’t have access to the private keys of your DNSSEC signer, one of the processes in replacing your production DNSSEC signer is to exchange the public key part of ZSK. This allows the independent DNSSEC signer to sign both aspects of ZSK with their own unique KSKs. At some point, the zone can be served from the new DNSSEC signer after the parent DS record has been updated.

Our deployment required that the signer was configured to sit between the primary and secondary DNS servers. The signer performs the zone transfer of an un-signed zone from the primary zone, and applies DNSSEC policy before passing the signed zone to the secondary DNS servers. With this architecture, we managed to exchange the public DNSKEY ZSK between the production signer and Knot for a test zone. For Bind, we failed to load the production public DNSKEY ZSK.

DNSSEC key backup and recovery: No points awarded

Automated backup and recovery are features our previous signer had, that we really wanted to keep. It would be beneficial if the backup supported encryption as well. Bind does not have a feature to backup DNSSEC keys, and while Knot supports DNSSEC key backup and recovery, it doesn’t have encryption support. As our existing signer had this feature from day one, we decided to use another solution to secure our backup.

Good game, everyone

Throughout the entire process, we leaned toward Bind because it’s a great DNSSEC signer, and we were familiar with it. In the end, Knot better met APNIC’s needs.

However, this could change depending on new developments. Updates can change the entire situation quickly. While we plan to use Knot as the primary signer, we will continue to Bind as a backup DNSSEC signer.

Rate this article

---

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.