DNSSEC Automation with Knot - Automated KSK Rollover

2021-11-16, 00:00 en

This article is part of a series:

Automated Bootstrapping
Automated KSK Rollover

UPDATE: Due to how KSK algorithm rollovers work, cds-cdnskey-publish: double-ds should not be used. The configuration example below has been updated to use cds-cdnskey-publish: always instead.

In the previous post I've shown how to bootstrap DNSSEC in a fully automated fashion using the Knot DNS server and a CDS-enabled domain registry. (Again, when I'm saying CDS, this is meant to include CDNSKEY as well.)

Now I'm going to take this a step further and show how to have all the tasks required for a KSK rollover performed automatically by Knot.

The KSK Rollover Process

We start out with an already established trust relationship between a zone and its parent. Same as before, I'll use my s3lph.ch. domain as an example.

When the current KSK is about to expire, Knot will automatically generate a new KSK and publish it in the zone. It is signed by the current KSK:

Figure 2: Visualization of the DNSSEC chain of trust after publishing the new key. The new KSK (42001) is signed by the current key (46451).

Once Knot can assume that all other nameservers in the zone have replicated the new DNSKEY set (after the zone TTL has expired), a corresponding CDS record is published. The DNSKEY and CDS records are signed by both the old and the new key.

The exact behavior regarding the creation of CDS records depends on the config option cds-cdnskey-publish: If you chose double-ds (which I did here, please check the update at the top of the page), then records for both the old and the new KSK will be published simultaneously during the rollover process. If you chose rollover or always, only a CDS record for the new key is published.

Knot will wait for the parent registry to publish the new DS record. Now we have reached a "symmetry" in the rollover process where both keys are equally trusted and used for ZSK signing:

Visualization of the DNSSEC chain of trust after the new DS has been published. — Figure 4: Visualization of the DNSSEC chain of trust after the new DS record has been published. The ZSK is still signed by both KSKs, both of which are now trusted.

Knot will periodically check for existence of the DS record. Once it has been found, the CDS records are updated to only refer to the new key:

Figure 5: Visualization of the DNSSEC chain of trust after Knot has removed the old CDS record. Both keys are still being used for ZSK signing, however, only the new CDS record is published.

A short while after (again after having waited until all other nameservers have had time to replicate the changes) Knot will retire the old key, meaning it's no longer being used for ZSK signing. The zone gets resigned using only the new KSK:

Figure 6: Visualization of the DNSSEC chain of trust after the old key has been retired. Now only the new key (42001) is used for ZSK signing.

Sometime afterwards the parent registry will scrape for CDS records again and discover the new CDS RRset, which now only contains the new CDS record. This will cause the old DS record to be removed from the parent zone, only the new DS record remains:

Figure 7: Visualization of the DNSSEC chain of trust after trust for the old key has been removed.

Finally, some time afterwards, Knot will remove the old key from the zone, and only the new chain of trust remains:

Figure 8: Visualization of the DNSSEC chain of trust after the old key has been removed.

Set Up Knot for Fully Automated KSK Rollovers

Let's have a look at /etc/knot/knot.conf again, once more reduced to the relevant bits:

zone:
  - domain: s3lph.ch.
    dnssec-signing: on
    dnssec-policy: dnssec-s3lph.ch.

policy:

  - id: dnssec-s3lph.ch.
    # These options are explained in the previous blogpost. 
    algorithm: ecdsap384sha384
    nsec3: on
    cds-cdnskey-publish: always
    # ZSKs are valid for 30 days by default, KSKs are valid indefinitely
    # This instructs knot to initiate a KSK rollover every 180 days.
    ksk-lifetime: 180d
    # This will add an additional backoff time to account for cache ttl.
    # Choose this appropriately to your zone's TTL.  Defaults to 1h.
    propagation-delay: 1h
    # This tells Knot how to check for new DS records after the key has
    # been published.
    ksk-submission: submission-s3lph.ch.

submission:

 - id: submission-s3lph.ch.
   # How often to check for new DS records.
   check-interval: 1h
   # Nameservers to check for new DS records, must be configure in the
   # "remote" section below. Using an external, DNSSEC-validating
   # resolver makes sure the old DS records aren't cached anymore.
   parent: remote-1.1.1.1

remote:

- id: remote-1.1.1.1
  address: 2606:4700:4700::1111
  address: 1.1.1.1

This is all that's required to get fully automated KSK rollover running. A bit more config than for the last blogpost, but still manageable. Again the config options are documented in detail in the Knot Configuration Reference.

Conclusion

I don't think KSK rollovers have ever been this easy; this is basically a "fire and forget" operation and everything's taken care off afterwards.

You can even make use of these features if your domain registry is not CDS-enabled. In this case there's one manual step involved though: You have to manually submit the new DS record to your registry, usually through your registrar's config interface. Everything else, including the auto-detection of the new DS record in the parent zone will still work automatically. You'll of course have to rely on your monitoring to know when a KSK rollover is due.

You're monitoring your DNS, right? ... Right?

s3lph made

The KSK Rollover Process

Set Up Knot for Fully Automated KSK Rollovers

Conclusion