Running two

Two authoritative providers means one delegation naming servers at both, answering identically. The work is not in the delegation — it is in keeping them identical, and DNSSEC makes that considerably harder.

Two models

	Primary/secondary transfer	Independent push
How the second provider gets the zone	AXFR/IXFR from the first, driven by `NOTIFY`	Both are written to by your tooling from one source of truth
Setup	Simpler — one provider is told to pull	More work, needs an API on both sides
If provider A is down	B keeps serving its last copy, and stops receiving updates	B is unaffected and still writable
DNSSEC	Straightforward — A signs, B transfers signed records	Hard. Both must sign, or neither.

What must stay in sync

Every record. Obvious, and the one that drifts when somebody makes an emergency change in one provider’s console.
The NS RRset inside the zone, which must list every nameserver at both providers and must match the delegation at the parent.
The SOA serial, or secondaries will not know an update happened.
TTLs, so behaviour does not depend on which provider answered.

DNSSEC across two providers

A resolver may reach either provider for any query, so every answer from both must validate against the same published DS. There are two ways to arrange that.

Model 1 — one signer
  Provider A signs. Provider B receives signed records
  by zone transfer and serves them unchanged.
  Simple. B cannot serve anything A has not signed,
  including synthesised denial.

Model 2 — multi-signer (RFC 8901)
  Both providers sign, each with its own ZSK.
  The DNSKEY RRset at both must contain BOTH ZSKs.
  Every key rollover at either provider requires the
  other to be updated.
  Complex, and the only option when both providers
  insist on holding their own keys.

Model 1 is what most organisations should do. Model 2 exists because some managed providers will not serve records they did not sign, and it is a genuinely demanding arrangement to operate.

The failure mode is worse than no redundancy

Two providers that have drifted apart serve different answers to different users, and which answer you get depends on which nameserver a resolver happened to pick. Under DNSSEC, a record signed by a key the other provider does not publish is bogus rather than merely different — so a botched multi-signer setup produces intermittent SERVFAIL, which is harder to diagnose than an outage.

Knowledge check

You add a second DNS provider and configure it as a secondary receiving AXFR from the first. What still has to be updated?

The NS RRset inside the zone and the delegation at the parent — both must name the new provider’s servers.
Nothing — the transfer carries the NS records with it.
The SOA serial only.
The DS record, since a second provider changes the signing arrangement.

Correct — The NS RRset inside the zone and the delegation at the parent — both must name the new provider’s servers. Transferring the zone does not make resolvers ask the new servers. The parent delegation is what sends queries there, and the in-zone NS RRset must agree with it or the setup is inconsistent.

Not this — Nothing — the transfer carries the NS records with it. It carries the NS RRset as it stands, which does not yet name the new provider. And the parent delegation is not in the zone at all.

Not this — The SOA serial only. The serial drives transfers and does nothing about which servers resolvers are told to ask.

Not this — The DS record, since a second provider changes the signing arrangement. Under a single-signer model the signing is unchanged — the secondary serves records the primary signed.

Two models

What must stay in sync

DNSSEC across two providers

Try it on a real domain