Multi-signer DNSSEC without losing your weekend

I have spent more late nights than I would like cleaning up after Domain Name System Security Extensions (DNSSEC) misadventures, and the shape of the failure is almost always the same. A team enables DNSSEC on a customer-facing zone because a regulator — or an internal security team reading the same regulation — has decided it is overdue. Everything works for months. Then a Key Signing Key (KSK) rotation slides quietly out of its planned window, the Resource Record Signature (RRSIG) inception and expiration timestamps stop matching reality at validating resolvers, and a percentage of users — typically the ones whose Internet service provider runs strict validators — start receiving SERVFAIL responses. The application is up. The infrastructure is up. The chain of trust is broken, and the blast radius is exactly the population of users whose resolvers do the right thing.

That failure mode is the warning I give every team evaluating multi-signer DNSSEC: the protocol is not optional once it is on, and the operational discipline it demands is real. Done well, DNSSEC adds verifiable integrity to the steering layer this series covered in the previous article — clients no longer have to trust whatever the network hands them, because cryptographic signatures bind each answer to the zone owner. Done poorly, it is a self-inflicted resilience hole. The cases where you legitimately need more than one signing provider are described in RFC 8901, Multi-Signer DNSSEC Models, published September 2020. The cases where you do not are at least as common, and worth being honest about.

DNSSEC is defined across a small set of RFCs that have aged better than most. RFC 4034 establishes the DNSKEY, RRSIG, NSEC, and Delegation Signer (DS) records. RFC 5155 adds NSEC3 for hashed authenticated denial of existence. RFC 8624 codifies which signing algorithms must be implemented today and which are recommended for new deployments. The chain of trust runs from the root zone — whose KSK is administered by ICANN and last rolled in October 2018, the first such rollover in the history of the system — down through top-level domain operators to your own zone. Each level signs the keys of the level beneath it. A validating resolver follows that chain, and if any link fails — wrong algorithm, expired RRSIG, missing DS at the parent — the resolver returns SERVFAIL. The protocol is failure-closed by design.

What DNSSEC does not defend is data confidentiality. Queries and responses still travel in the clear; DNS-over-HTTPS and DNS-over-TLS solve that at a different layer. What DNSSEC does is bind each answer to the authoritative zone, which is the integrity property that matters most when your steering layer is also a security boundary.

Two reasons drive serious resilience designs toward more than one DNS provider. The first is operational: DNS is a control point that benefits from provider diversity in the same way a multi-Region application benefits from infrastructure diversity. The second is regulatory. Resilience regimes such as the European Union's Digital Operational Resilience Act, applicable since 17 January 2025, push regulated entities to think carefully about concentration risk at every layer of their information and communication technology stack, and DNS is one of those layers. Once the decision is made that two providers are required, the next question is whether the providers must be aware of each other, and how.

If neither provider validates DNSSEC — that is, if the zone is unsigned — multi-provider DNS is a configuration exercise. You publish identical zone data, keep your serial numbers and Start of Authority records aligned, and pick a disciplined process to push the same record set to both. The moment the zone is signed, the question gets harder. RRSIGs are produced by zone operators, not by the zone owner directly, and a validating resolver does not care which operator answered as long as the signatures verify against keys it can chain to a DS at the parent. RFC 8901 exists to describe how to make that work.

The RFC defines two arrangements, and both require that every participating provider share a common signing algorithm — usually ECDSA P-256 with SHA-256, algorithm 13 in the DNSSEC registry, which RFC 8624 identifies as the recommended default for new deployments and which is mandatory to implement for both signing and validation. With that prerequisite in mind, the two models split on how keys are owned.

In Model 1, the zone owner generates a single KSK and a single Zone Signing Key (ZSK) and shares them with every provider. Each provider serves an identical DNSKEY Resource Record Set and produces RRSIGs that verify against the same key material. The parent zone holds exactly one DS record. The model is operationally easy to reason about — only one set of keys to rotate — but it requires providers that can import and protect key material produced elsewhere, which is precisely what most managed services do not allow.

In Model 2, each provider holds its own KSK and its own ZSK. The DNSKEY RRset published at every provider must include every KSK and every ZSK across all participating providers, and the parent DS RRset includes one DS for each provider's KSK. A validating resolver that lands on any provider's name servers receives a DNSKEY RRset that lists the key the answer was actually signed under, so verification succeeds whichever provider responded. This is the model that fits managed services in spirit, because no provider has to import another's key material. The price is ongoing coordination: whenever any provider rolls a key, every other provider must update its DNSKEY RRset to match, or some resolvers will receive answers signed by a key the DNSKEY RRset they see does not advertise, and validation will fail.

This is where the article has to be specific about the current state of Amazon Route 53. DNSSEC signing has been generally available for public hosted zones since December 2020, and the design is opinionated. The KSK is a customer-managed asymmetric key in AWS Key Management Service, key spec ECC_NIST_P256, which maps to DNSSEC algorithm 13. The ZSK is managed by Route 53 and is not exposed. Private hosted zones cannot be signed, which is by design: private DNS lives behind an Amazon Virtual Private Cloud trust boundary, and DNSSEC's threat model is the public Internet. Route 53 uses NSEC for authenticated denial of existence, with a compact-denial pattern that prevents the zone-walking risk NSEC3 was originally created to address.

The line that matters most is the one Route 53's own documentation draws explicitly: multi-vendor DNSSEC configurations are not supported. There is no turnkey RFC 8901 mode in the console or the application programming interface today. Route 53 also does not automatically publish Child DS (CDS) or Child DNSKEY (CDNSKEY) records to bootstrap DS provisioning at the parent — that step remains manual against your registrar. None of that puts RFC 8901 out of reach on AWS, but it does mean that if you genuinely need two signing providers, you build the coordination yourself, you treat every key rollover and algorithm migration as a change that crosses a vendor boundary, and you accept that the runbook is yours to own.

The single-provider KSK rollover is also worth rehearsing on Route 53 alone before any conversation about two providers begins. Add the new KSK; publish the new DS at the registrar; wait at least the old DS time-to-live; deactivate and delete the old KSK. Each step has to land in the right order, and the only guardrail is the discipline of the team running the change.

Multi-signer DNSSEC is not a project to take on for fashion. The cases where it is the right answer are the ones where the steering layer truly cannot tolerate single-provider risk and where the team has the runbook maturity to coordinate keys across vendors as a matter of routine. For most workloads on AWS today, the right answer is single-provider DNSSEC on Route 53 with low time-to-live values on records that move during failover, KSK rollovers documented as deliberate data-plane changes, and DS updates at the registrar treated with the same change-management rigor as any other parent-zone change. The blast radius of getting any of those wrong is the entire validating-resolver population, which is no place to discover that a runbook was written from memory.

DNSSEC closes the integrity gap at the steering layer; the next article descends to the physical-connectivity layer beneath it. AWS Direct Connect ships in two formal resilience postures — High Resilience and Maximum Resilience — and choosing between them is rarely as simple as picking the bigger number. We will walk through the resilience-outcome arithmetic, the geographic-diversity requirements that make the published commitments honest, and where each posture earns its keep.