DNSSEC Automation with Knot - Automated KSK Rolloveren
- 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
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:
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
(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
always, only a CDS record for the new key is
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:
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:
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:
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:
Finally, some time afterwards, Knot will remove the old key from the zone, and only the new chain of trust remains:
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-22.214.171.124 remote: - id: remote-126.96.36.199 address: 2606:4700:4700::1111 address: 188.8.131.52
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.
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?