DNSSEC KSK & ZSK Rollover Simulator

Model cryptographic DNSSEC key rotation schedules based on RFC 6781 and RFC 7583. Calculate minimum safety intervals, parent DS propagation delays, and execute fail-safe Pre-Publish ZSK and Double-Signature KSK transitions.

Standard Framework RFC 6781 / 7583 DNSSEC operational practices

ZSK Rotation Rhythm 30 to 90 Days Pre-Publish scheme

KSK Rotation Rhythm 12 to 24 Months Parent DS synchronization

Root Cause of SERVFAIL Premature Key Deletion Cache TTL violation

⚙️ Zone Cryptographic Parameters

Rollover Architecture:

DNSKEY Record TTL:

Parent Zone DS TTL:

Safety Rule: Minimum wait times between phases must strictly equal maximum cache TTL plus zone propagation delay to ensure zero resolving clients experience cryptographic failure.

⏱️ Execution Phase Checklist Total Time: 8 Hours

Frequently Asked Questions

What is the operational difference between a ZSK rollover and a KSK rollover?

A Zone Signing Key (ZSK) signs the zone resource records and is rolled frequently (every 1 to 3 months) using automated Pre-Publish methods entirely within the authoritative zone. A Key Signing Key (KSK) signs only the DNSKEY RRset and requires updating the Delegation Signer (DS) record at the parent registry (e.g. .com or .org). KSK rollovers take longer (typically 1 to 2 years) and carry higher risk because parent zone cache delays must expire completely.

What causes global SERVFAIL outages during an improperly executed DNSSEC rollover?

If an operator deletes an old ZSK or KSK before all recursive resolver caches worldwide have expired (based on the original DNSKEY and parent DS TTLs), resolvers attempting to validate signatures will be unable to find the corresponding public key, resulting in immediate SERVFAIL and complete website downtime.

What is the Pre-Publish ZSK rollover scheme (RFC 6781)?

Under the Pre-Publish scheme, the operator publishes the new ZSK public key in the zone alongside the old ZSK for at least one full TTL cycle before generating any signatures with it. This ensures all validating resolvers have pre-cached the new public key before receiving records signed by it.

How does automated CDS / CDNSKEY signaling de-risk KSK rollovers?

Child DS (CDS) and Child DNSKEY (CDNSKEY) records (RFC 7344) allow the child zone to signal the parent registry to update the parent DS record automatically. The registry polls the child, verifies the signature, and updates the DS without requiring human intervention in the registrar dashboard.