Skip to content

During algorithm rollover, old KSK is retired and removed too early, breaking the chain of trust

Description

Last weekend I rolled over the DNSSEC KSKs and ZSKs of two of my domains from ecdsap384sha384 (alg 14) to ed25519 (alg 15). One of my domains is registered at a registry with CDS support, the other I have to manually update the DS RRset.

Some time during this rollover process, I noticed that one of my domains (the one I have to update the DS RRset for manually) did not resolve anymore, and investigation showed that the chain of trust was broken because the old KSK had been retired and removed from the zone before the corresponding DS record had been removed, as can be seen in this DNSViz screenshot:

dnsviz

me to s3lph.me: The DS RRset for the zone included algorithm 14 (ECDSAP384SHA384), but no DS RR matched a DNSKEY with algorithm 14 that signs the zone's DNSKEY RRset

Expected Behavior

  1. New KSK is created, added to the zone and used to additionally sign the zone
  2. CDS RRset is updated to include both the old and new KSKs (with different algorithms.
  3. DS RRset is updated, either manually or through a registry with CDS support
  4. Knot notices that the DS RRset has been updated, and removes the old KSK from the CDS RRset, but still keeps the old key published and uses it for signing alongside with the new KSK
  5. DS RRset is again updated, removing the old key's entry
  6. Knot notices that the DS RRset has been updated, and finally retires the old key.

Actual Behavior

  1. New KSK is created, added to the zone and used to additionally sign the zone
  2. CDS RRset is updated to include both the old and new KSKs (with different algorithms.
  3. DS RRset is updated, either manually or through a registry with CDS support
  4. Knot notices that the DS RRset has been updated, and removes the old KSK from the CDS RRset, but also eventually retires and removes the old key, even if the old key's DS record is still present.
  5. Until the DS RRset is again updated to remove the old key's entry, the chain of trust is now broken, because the zone must have an active KSK for each algorithm used in the DS RRset.

Steps to reproduce

  1. Set up a DNSSEC-signed zone including a submission stanza, and enter the DS records in the parent zone
  2. Kick off an algorithm rollover by changing the KSK algorithm
  3. Wait until Knot publishes a new CDS RRset containing both the old and new KSK
  4. Update the DS RRset to include both keys
  5. When Knot updates the CDS RRset a second time to remove the old KSK, do not update the DS RRset
  6. Observe Knots behavior, notice that the old key is eventually retired and removed even though it is still referred to by a DS record.

Environment

  • Debian 11
  • Knot 3.0.5 (installed via Debian package