DNSSEC Multi-Signer & Key Rollover Planner
Design zero-downtime dual-provider DNSSEC architectures. Implement RFC 8901 Model 2 multi-signing, inspect active CDS / CDNSKEY records, and coordinate multi-cloud resilience across Cloudflare, AWS Route 53, and NS1.
RFC 8901 Model 1: Shared Key Management
In Model 1, both authoritative DNS providers sign records with the identical private key. While simple for resolvers to validate, it requires exporting private cryptographic signing keys outside of a provider Hardware Security Module (HSM), creating significant supply-chain security and key custody risks.
RFC 8901 Model 2: Independent Key Sets
In Model 2, Provider 1 generates Keypair A, and Provider 2 generates Keypair B. Each provider signs its own zone data with its own private key. Crucially, Provider 1 cross-publishes Provider 2 public DNSKEY in its zone, and vice-versa.
Frequently Asked Questions
What is Multi-Signer DNSSEC (RFC 8901) and why was it developed?
Historically, enabling DNSSEC required an organization to use a single authoritative DNS provider because different providers sign zones with different cryptographic keys. If resolvers received records signed by Provider B that did not match Provider A DS record in the parent zone, resolution failed with SERVFAIL. RFC 8901 defines standardized multi-signer models allowing providers like Cloudflare, AWS Route 53, and NS1 to co-exist with full DNSSEC validation.
What is the difference between RFC 8901 Model 1 and Model 2?
In Model 1, both DNS providers share the same Zone Signing Keys (ZSKs) or Key Signing Keys (KSKs), requiring private key export between providers. In Model 2, each provider maintains its own independent key pair, and both providers cross-publish each other public DNSKEY records in the zone. Model 2 is the modern industry standard because private keys never leave each provider security perimeter.
How do CDS and CDNSKEY records automate parent zone DS delegation updates?
Defined in RFC 7344 and RFC 8078, Child DS (CDS) and Child DNSKEY (CDNSKEY) records are published in the child zone to signal to the parent registry (e.g. .com or .org) that the DS record at the parent should be updated automatically, eliminating manual registrar dashboard intervention during key rollovers.
What is the primary risk during a Multi-Signer DNSSEC migration?
Removing a provider public DNSKEY before the parent zone DS record caches have fully expired worldwide will break DNSSEC validation for all recursive resolvers caching the old DS, taking down the entire domain for affected users.