Procedure: Emergency ZSK/KSK rollover

Written by Rick van Rein in category: Procedures, Security, Timing

This is a nasty procedure that must only be performed if private key material of ZSK and/or KSK is (or may have been) compromised. It always leads to temporary unsatisfactory performance, which is why the chances for this are virtually eliminated with our architecture: either the domain drops out of validating resolvers, or it becomes insecure.


  • The suspicious key material will no longer be a basis of trust in the zones it used to sign.
  • After the procedure, all domains are back to secure mode.

This theoretic case implies a tough decision. The contact person for a zone must decide which is worse: being invisible to a part of the internet, or being insecure. Note that the Kaminsky attack is the only widely known form of attack that makes DNSSEC a necessity, and it is known to always succeed, but only if it is given weeks of time. The weighing act between the two forms of badness is a human decision, and it is important to know who takes it, or to work out procedures matching your organisation’s security goals.


ZSK problem.

  1. Request a ZSK rollover from OpenDNSSEC.
  2. Push for immediate publication of the new records.
  3. Wait for the ZSK signatures to have expired from caches before fully trusting the affected zones.

KSK problem — temporarily dropping from the internet.

  1. Without delays between steps, remove the affected DS from the parent, remove the affected KSK DNSKEY record from the zone, generate a new KSK, upload the new DS to the parent using their emergency procedure if they have one. Do not wait for the registry, cache expirations or anything else.
  2. Sign the domain with the new KSK.
  3. Publish the domain as soon as possible, actively reloading authoritatives and flushing caches where possible.
  4. Wait for the old DS TTL to expire from caches before fully trusting the affected zones.

KSK problem — temporarily going to insecure mode.

  1. Perform a regular KSK rollover, but force it to happen right away.
  2. Update the parent, removing the DS as soon as possible.
  3. Wait until the old DS has expired out of caches before fully trusting the zone’s security again.

ZSK and KSK problem combined.

  • Handle the ZSK problem as explained above.
  • Handle the KSK problem with one of the procedures detaled above.