If the KSK is also compromised, perform the emergency KSK rollover first.

As long as there is a valid KSK signature over the ZSK, the KSK can continue to be used to inject false zone data. If both keys are compromised, clients are exposed to attacks on that data until the maximum of the expiration of the KSK's RRSIG (created by the ZSK) and the parent's signature over the DS of that KSK. (These attacks include signatures over false data, replay attacks of the old KSK, and replay attacks of the old DS.) Short TTLs allow recursive servers to more quickly recover from key-compromise situations, allowing them to get new keys more quickly. Key compromise exposes the secure recursive server to replays of the old key until the signature expires. The emergency procedures described for key rollover use the rationale that injection of valid but false data (which can be generated using the compromised key) is more serious than discontinuity in the ability to validate true data. Thus, during emergency ZSK rollover, there will be a period (up to twice the maximum zone TTL) where the cached zone data may not validate against the new ZSK. Also, the steps below are only useful if the Published and Current keys are kept separate from each other and if the Published ZSK has not also been compromised. If both ZSKs are compromised follow the steps in Chapter 13, Emergency ZSK Rollover (Published and Current ZSK Compromise) If only the Published key is compromised follow the steps in Chapter 12, Emergency ZSK Rollover (Published ZSK Compromise).