Summary

  • RFC 8901 is an IETF-consensus Informational document, not a Standards Track mandate or proof that a named provider supports multi-signer DNSSEC.
  • In both models it describes, every provider's DNSKEY RRset must contain every participating provider's active ZSK. Otherwise a resolver can cache Provider A's keys, receive Provider B's signature during failover and reject the response.
  • The zone owner must coordinate key exchange, the KSK-to-parent-DS model, common algorithms and rollover timing before a failure. A second supplier is only a potential path until that evidence exists.

The server survived; the chain did not

Consider a zone served by two independent managed-DNS providers. A validating resolver follows the secure delegation, asks Provider A for the apex DNSKEY RRset, authenticates it through the parent DS and caches it. Later, while that cache entry remains usable, Provider A becomes unreachable. The resolver selects Provider B and receives the requested record with a valid-looking RRSIG made by B's zone-signing key.

Provider B has answered. The response can still be unusable. If the DNSKEY RRset cached from A does not include B's active ZSK, the resolver has no authenticated public key with which to verify B's signature. It may try another nameserver and eventually reach A again. It may also exhaust retries, exceed its delay budget or lose the downstream client to a timeout. RFC 8901 does not change that resolver behaviour. It changes what the signers must coordinate so ordinary validation keeps working.

This is the narrow mechanism the phrase “multi-provider DNS” can hide. NS diversity, separate networks and two healthy control planes are evidence of possible authoritative reachability. They do not prove that a DNSSEC-authenticated answer can cross from one provider's cached key view to the other's signature. Redundancy becomes real only when the verification path survives the switch.

One invariant, two custody models

RFC 8901 presents two models for providers that independently sign and serve the same zone. Their custody arrangements differ, but the shared invariant does not: every provider must publish the active ZSKs of all participating providers in its apex DNSKEY RRset.

In Model 1, the zone owner holds a common KSK set and manages the parent DS. Each provider keeps its own ZSK. The owner collects every provider's public ZSK, builds one combined DNSKEY RRset, signs it with the common KSK and distributes that signed set to every provider. Even if no key changes, the owner must refresh and redistribute the DNSKEY signature before it expires.

This concentrates the secure entry point. The parent needs a DS for the owner-held KSK, and resolvers can authenticate the same signed key set wherever they retrieve it. The operational price is equally concentrated: KSK custody, periodic re-signing, provider API access and distribution are one common control surface. A stale copy at one provider can turn a successful key ceremony into split reality.

In Model 2, every provider holds its own KSK and ZSK. Each provider imports the other providers' public ZSKs into its DNSKEY RRset and signs that set with its own KSK. The parent DS RRset contains an entry for each provider KSK. A resolver may therefore authenticate the DNSKEY RRset obtained from either provider through the matching parent DS.

This preserves provider-specific KSK custody, but it creates more synchronized state. The parent has multiple secure entry points, while every signer still needs the same cross-provider ZSK coverage. A provider's KSK rollover changes its parent DS path. Its ZSK rollover changes the key view that every other provider must publish. Independence of private keys does not remove dependence on shared public state.

A rollover is a distributed transaction

The dangerous moment is not only an outage. It is the interval in which one provider has generated, activated or retired a key while another provider and resolver caches still reflect the previous set.

Under Model 1, a new ZSK cannot simply begin signing at Provider A. The zone owner must obtain it, add it to the combined DNSKEY set, sign that set and deploy it to all providers. Activation waits for propagation plus the DNSKEY TTL. Retirement waits until data signed by the old key and the longest relevant zone TTL no longer require it. A KSK rollover also crosses the parent DS and its cache horizon.

Under Model 2, Provider A can sign its own DNSKEY set with its KSK, but it still must give the new ZSK to the zone owner. The owner imports that key into Provider B and any other signer. A should not sign ordinary zone data with the new key until the import, authoritative propagation and DNSKEY TTL have completed everywhere. Removing the old ZSK repeats the coordination in reverse.

The completion receipt is therefore not “key created”, “API returned 200” or “one DNSKEY query looked right”. It is an ordered record of export, owner acceptance, import at every provider, publication at every authoritative surface, TTL passage, independent validation using each provider's answers and only then activation or retirement.

Algorithms and negative answers are part of the contract

RFC 8901 also requires participating providers to use a common DNSSEC signing algorithm, or the same supported algorithm set. When a DNSKEY RRset advertises multiple algorithms, DNSSEC's signing rules apply across zone RRsets. One provider cannot choose an incompatible algorithm and rely on the second provider's presence to fill the gap.

Authenticated denial needs separate attention. NSEC or NSEC3 proof travels with the negative response, so different providers can technically use different denial methods. But mixing NSEC with NSEC3 defeats NSEC3's resistance to easy zone enumeration, while permanently mixed configurations can make negative-cache behaviour less efficient. The document prefers one method and recommends minimizing differences when uniformity is impossible.

These are not cosmetic settings. During an incident, a positive answer may validate while a negative name or type answer exposes a different signing and caching path. A continuity test that queries only the homepage's A or AAAA record is not a DNSSEC continuity test.

What RFC 8901 does not establish

The document is Informational and records IETF consensus about deployment models. It does not report that any named provider exposes the required API, imports external ZSKs correctly, shares a signing algorithm or completes coordinated rollovers. It reports no measured outage, latency distribution or availability gain. Its examples are mechanisms, not market claims.

Nor does successful DNSSEC validation prove that the authoritative service was continuously reachable, that traffic failed over, that an application worked or that the provider was authorized by the domain owner. Validation proves a cryptographic relationship for the data, key and chain observed. Operational continuity remains a longer evidence path.

The practical conclusion is therefore deliberately modest. Buying a second provider can reduce one failure dependency. It becomes DNSSEC redundancy only when the zone owner can reproduce the shared key view, the parent entry points, the algorithm choice and the rollover timeline before the first provider disappears.

Sources