Tag: DNSSEC

DNSSEC Automation with Knot - Automated KSK Rollover

en
This article is part of a series:
  1. Automated Bootstrapping
  2. Automated KSK Rollover

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.

Visualization of the DNSSEC chain of trust before beginning the KSK rollover process.
Figure 1: Visualization of the DNSSEC chain of trust before beginning the KSK rollover process, as rendered by the online tool DNSViz. Again, I've added the CDS nodes afterwards. The trust relationship between the zone and its parent is established, and there is one active KSK and one active ZSK.

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:

Visualization of the DNSSEC chain of trust after publishing the new key.
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'm doing here), 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.

Visualization of the DNSSEC chain of trust after publishing the new key.
Figure 3: Visualization of the DNSSEC chain of trust after publishing the new CDS record. The CDS records and the ZSK are now signed by both keys.

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:

Visualization of the DNSSEC chain of trust after Knot has removed the old CDS record.
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:

Visualization of the DNSSEC chain of trust after the old key has been retired.
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:

Visualization of the DNSSEC chain of trust after trust for the old key has been removed.
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:

Visualization of the DNSSEC chain of trust after the old key has been removed.
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: double-ds
    # 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?

DNSSEC Automation with Knot - Automated Bootstrapping

en
This article is part of a series:
  1. Automated Bootstrapping
  2. Automated KSK Rollover

Knot DNS is an authoritative DNS name server developed by CZ.NIC. One of the features that sets it apart from BIND and other nameserver software is its support for fully automated DNSSEC key management. In this blogpost I'll show how to achieve fully automated DNSSEC bootstrapping, assuming that the parent zone implements trust management via CDS/CDNSKEY records.

RFC 8078: CDS and CDNSKEY

Usually, in order to bootstrap a DNSSEC trust relationship, a series of steps is necessary:

  1. A KSK and ZSK or CSK must be created for the child zone (e.g. s3lph.ch.).
  2. The public keys must be published in the child zone as DNSKEY records.
  3. The zone's records must be signed with the ZSK, with the exception of the DNSKEY records, which must be signed by the KSK.
  4. A DS record matching the KSK must be created.
  5. The DS record must be published in the parent zone (e.g. ch.).

Most of these steps can be automated and contained within a single piece of software such as Knot, but the last step usually requires a human to sign into their domain registrar's web management interface and configure the DS record manually.

RFC 8087 describes a mechanism to automate this last step. In order to achieve this, two new DNS RR types were introduced: CDS and CDNSKEY. They serve as a way for the child zone to tell the parent zone "I want the parent zone to serve DS records for these KSKs". Both types serve the same purpose, the only difference is that the CDNSKEY records are copies of the DNSKEY records for which a DS record should be created in the parent zone, whereas the CDS records are already-prepared DS records for the parent zone to copy. This can not only be used for bootstrapping DNSSEC upon introduction, but also for maintaining the chain of trust when rolling over to a new KSK.

The procedure to bootstrap or update a trust relationship using CDS/CDNSKEY records boils down to:

  1. The CDNSKEY and/or CDS records are published in the child zone.
  2. The parent zone scans all its child zones for CDNSKEY/CDS changes on a regular basis (e.g. once a day). Usually this is done by the registry operating the zone.
  3. DS records are computed from the CDNSKEY/CDS records and inserted into the parent zone.

Usually this last step is bound to a set of policies defined by the registry. For example, the CDS policies of SWITCH, the registry for the ch. and li. TLDs, require among other things:

  • The set of CDS records must be valid and consistent across all of the zone's nameservers
  • The new DS records must not break the chain of trust
  • the CDS records are signed with an already trusted KSK

Note: From hereon, every mention of CDS will imply CDS and/or CDNSKEY unless otherwise noted.

DNSSEC Bootstrap Example

Let's look at an example and have DNSSEC automatically bootstrapped for the s3lph.ch. zone. At first, immediately after setting up Knot to enable DNSSEC, keys are generated, the zone is signed and the keys and CDS records are published in the zone:

; KSK and ZSK
s3lph.ch.   300 IN  DNSKEY  257 3 14 zjmE...AnD5 ; KSK ; key id = 46451
s3lph.ch.   300 IN  DNSKEY  256 3 14 fSZj...d+gU ; ZSK ; key id = 19881
; ZSK signature, signed with KSK
s3lph.ch.   300 IN  RRSIG   DNSKEY ... 46451 ...
; CDS referencing the KSK
s3lph.ch.     0 IN  CDS     46451 14 2 C129...DDC0
; CDS signature, signed with KSK
s3lph.ch.     0 IN  RRSIG   CDS ... 46451 ...
; AAAA record, signed with ZSK
s3lph.ch.   300 IN  AAAA    2a01:4f8:1c1c:1ae7::1
s3lph.ch.   300 IN  RRSIG   AAAA ... 19881

However, the ch. zone does not yet know about DNSSEC in the s3lph.ch. zone:

s3lph.ch.   3600    IN  NS  ns1.s3lph.me.
s3lph.ch.   3600    IN  NS  ns2.s3lph.me.
S8BEAUIIVUO5RD59BCLAL4MK7MDKBIOC.ch. 900 IN NSEC ... NS DS RRSIG
S8BEAUIIVUO5RD59BCLAL4MK7MDKBIOC.ch. 900 IN RRSIG NSEC3 ...

You can also see the chain of trust visualized in Figure 1. The foundation for this image has been created using the the online tool DNSViz resp. it's eponymous backend tool. I've added the CDS node manually afterwards, since DNSViz does not (yet) support CDS.

Visualization of the DNSSEC chain of trust before CDS bootstrapping.
Figure 1: Visualization of the DNSSEC chain of trust before CDS bootstrapping. Note the black arrow between ch. and s3lph.ch. indicating insecure delegation, as well as the NSEC3 record indicating the absence of a DS record.

One day later, we can see that SWITCH has successfully picked up the CDS record:

SWITCH CDS Status Check tool reporting "pending" status after the first successful validation.
Figure 2: SWITCH's CDS Status Check tool reporting "pending" status after the first successful validation.

However, SWITCH requires the CDS RRset to remain unchanged for 3 days when bootstrapping DNSSEC on a zone, so they haven't published the matching DS record yet.

Let's fast-forward to 3 days later: There now is a DS record in the ch. zone:

s3lph.ch.   3600    IN  NS      ns1.s3lph.me.
s3lph.ch.   3600    IN  NS      ns2.s3lph.me.
s3lph.ch.   3600    IN  DS      46451 14 2 C129...DDC0
s3lph.ch.   3600    IN  RRSIG   DS ...
Visualization of the DNSSEC chain of trust after CDS bootstrapping.
Figure 3: Visualization of the DNSSEC chain of trust after CDS bootstrapping, as rendered by DNSViz. Again, the CDS record was added afterwards. Note the arrow between ch. and s3lph.ch. has turned blue, indicating secure delegation, as well as the new DS record in the ch. zone.

And there we have it: The DNSSEC trust relationship between ch. and s3lph.ch. has been established without any manual interaction.

Now let's look into how to set up Knot for this.

Set Up Knot for Fully Automated DNSSEC Key Management

Let's have a look at my /etc/knot/knot.conf. I've boiled it down to the relevant pieces:

zone:
  - domain: s3lph.ch.
    # This option tells Knot to enable automatic zone signing ...
    dnssec-signing: on
    # ... and this tells Knot HOW to sign the zone.
    dnssec-policy: dnssec-s3lph.ch.

policy:
  # This is the Knot DNSSEC signing policy for s3lph.ch.
  - id: dnssec-s3lph.ch.
    # SWITCH doesn't yet support ed25519/ed448, so let's use some other
    # recommended algorithm, ECDSA using the P-384 curve, plus SHA384.
    algorithm: ecdsap384sha384
    # Automatically create NSEC3PARAMs as well, and respond with NSEC3
    # instead of regular NSEC.
    nsec3: on
    # This is the magic bit to turn on CDS and CDNSKEY record generation
    # "double-ds" means that during a KSK rollover, records for both the
    # old and the new key are published simultaneously to mitigate
    # caching artifacts.
    cds-cdnskey-publish: double-ds

And that's already it; those few lines are enough to have Knot automatically sign zones and generate CDS and CDNSKEY records on the fly.

There are other options available for the cds-cdnskey-publish option, you can look up the list in the Knot Configuration Reference.

Conclusion

If your registry supports CDS or CDNSKEY, this is a really simple method to bootstrap DNSSEC without any manual intervention. Even more, this still works if the registrar through which you bought your domain doesn't offer a way to configure DS records.

This procedure can also be used to make KSK rollovers fully automatic, which I'll be covering in the next blogpost.