Support Library
Multi-DNS Provider Strategy
How to run two DNS providers at once: keeping zones in sync, DNSSEC with two signers, and the features that do not carry over.
The short answer
Using two DNS providers at once means listing name servers from both in your delegation, with both serving the same records. If one provider has an outage or is attacked, resolvers retry the other provider's servers and your domain keeps resolving. The hard part is not the delegation but keeping two copies of the zone identical, and handling the features that do not translate between providers: proprietary record types, traffic steering, and DNSSEC.
Ways to keep the providers in sync
| Approach | How it works | Trade-offs |
|---|---|---|
| Primary and secondary | One provider (or your own hidden primary) holds the zone; the other pulls it by zone transfer | Simple and exact. Both must support AXFR/IXFR, and only standard record types transfer. |
| Two primaries, pushed by automation | A tool such as OctoDNS or DNSControl writes the same records to both providers' APIs | Works with providers that do not do transfers, and can map some provider features. Changes must only go through the tool. |
| Manual | Edit both consoles | Drifts quickly; not recommended beyond a handful of records |
DNSSEC with two providers
A secondary can serve signatures transferred from a single signer. With independent signers, RFC 8901 defines Model 1 with a common owner-managed KSK set and Model 2 with separate provider KSKs and parent DS records for both sets. Both require coordinated DNSKEY publication and rollovers, including the providers' ZSKs. Check that each provider supports the chosen model before committing.
Other things to plan for
- Proprietary records. ALIAS/ANAME at the apex, geo-steering, and weighted or failover answers behave differently or not at all on the other side. Keep those on names you can afford to answer simply, or use the same steering on both.
- NS records in the zone. Both providers' zones must list all name servers from both, matching the delegation.
- TTL and SOA. Each provider may rewrite the SOA, so serials will not match across providers. Compare record data instead.
- Cost and limits. Budget for two plans, minimum fees and the combined query volume. Resolvers normally split queries among authoritative servers rather than duplicating every query; traffic distribution, retries and pricing determine the total. Check record and zone limits on both plans.
- Testing. Regularly query each provider's servers directly and diff the answers.
$ dig +norecurse +short @ns1.provider-a.example www.example.com A
$ dig +norecurse +short @ns1.provider-b.example www.example.com AHow DNS Panopticon helps
Domain Visualizer lists the NS records it finds and reports a single name server as a single point of failure, or several as redundant. It counts name servers only: it does not check whether they belong to different providers or networks, and it does not compare their zone contents. Use the per-provider queries above for that.