In October 2016, a massive DDoS attack against the DNS provider Dyn took down a huge swath of the internet. Twitter, Reddit, Spotify, GitHub, Netflix, and countless other major sites became unreachable, not because their own infrastructure failed, but because the single DNS provider they all relied on was overwhelmed. Sites that used a second DNS provider stayed up. Sites that didn't went dark.
That event was a wake-up call for an uncomfortable truth: if all your DNS lives with one provider, that provider is a single point of failure for your entire online presence. No matter how resilient your own infrastructure is, a DNS provider outage takes you offline, and there's nothing you can do but wait for them to recover.
Multi-provider DNS, often implemented as secondary DNS, solves this. By serving your zone from two independent DNS providers, your domain stays resolvable even if one provider fails completely. This guide explains how it works, the different models, the tradeoffs, and how to set it up.
The Single-Provider Risk
When you use one DNS provider, your domain's resolution depends entirely on that provider's nameservers being available and answering correctly. This creates a dependency that sits above all your other infrastructure. Your servers can be perfectly healthy, your application flawless, your database replicated across regions, and none of it matters if the DNS that points to it stops resolving.
Single-provider failures happen for several reasons: large-scale DDoS attacks against the provider, provider infrastructure outages, BGP routing problems, or operational errors on the provider's side. These are outside your control, and when they happen, your only option with a single provider is to wait.
For many organizations, the risk is acceptable. Major providers are highly reliable, and occasional rare outages may be tolerable. But for businesses where downtime is costly, where DNS availability is mission-critical, multi-provider redundancy is the architectural answer.
How Multi-Provider DNS Works
The foundation of multi-provider DNS is that a domain can be served by nameservers from more than one provider simultaneously. Your nameserver delegation at the registrar lists nameservers from both providers. When a resolver looks up your domain, it can query any of the listed nameservers, and as long as one provider's nameservers respond correctly, resolution succeeds.
For this to work, both providers must serve the same records. If they disagree, resolvers get inconsistent answers depending on which provider they happen to query. Keeping the two providers synchronized is the central challenge of multi-provider DNS, and there are two main approaches.
Primary-Secondary (Zone Transfer) Model
This is the traditional model, and it's where the term "secondary DNS" comes from.
In this setup, one provider is the primary (also called the master / hidden primary), holding the authoritative copy of your zone where you make changes. The other provider is the secondary (or slave), which automatically pulls a copy of the zone from the primary.
The synchronization happens through zone transfers:
- AXFR (full zone transfer) copies the entire zone from primary to secondary.
- IXFR (incremental zone transfer) copies only the changes since the last transfer, which is more efficient.
- NOTIFY messages let the primary tell the secondary "the zone changed, come get the update," so changes propagate quickly rather than waiting for the secondary's refresh interval.
You make all your changes at the primary. The secondary detects the change (via NOTIFY or its refresh schedule), pulls the updated zone via zone transfer, and begins serving the new records. Both providers then answer queries with identical data.
The SOA record's serial number drives this: the secondary compares its serial against the primary's, and when the primary's is higher, it knows to transfer. This is one of the practical reasons the SOA serial matters, as we covered in our zone file guide.
Hidden Primary
A common variation is the "hidden primary," where the primary nameserver isn't listed in your delegation at all. It exists only to feed the secondaries via zone transfer. The publicly visible nameservers are all secondaries pulling from the hidden primary. This keeps your authoritative source private and lets you treat the public-facing providers uniformly.
Multi-Primary (Dual Provider) Model
The newer model, increasingly common with modern managed DNS providers, is multi-primary, where both providers are independently authoritative and you push the same configuration to both.
Instead of one provider pulling from another via zone transfer, you manage both providers directly, typically through automation. A change is pushed to both providers' APIs simultaneously, keeping them in sync. Each provider operates independently as a primary, with no zone transfer dependency between them.
This model has advantages: there's no zone transfer link that can break, no dependency of one provider on another, and each provider can use its own advanced features. The challenge is that you're responsible for keeping the two in sync through your own tooling, since they don't talk to each other. Configuration management and infrastructure-as-code tools (like Terraform with DNS providers) are commonly used to push identical records to both.
A complication: provider-specific features don't always translate. If one provider offers a proprietary record type or routing feature the other doesn't, you can't keep them perfectly identical. Multi-primary works best when you stick to standard record types that both providers support.
Comparing the Models
| Aspect | Primary-Secondary (AXFR) | Multi-Primary (Dual) |
|---|---|---|
| Sync method | Zone transfer (AXFR/IXFR) | Push to both via API/automation |
| Provider dependency | Secondary depends on primary | Fully independent |
| Where you make changes | Primary only | Both (via tooling) |
| Provider-specific features | Limited (standard records) | Limited (must support both) |
| Setup complexity | Moderate | Higher (needs automation) |
| Best for | Traditional redundancy | Modern IaC-driven setups |
The DNSSEC Complication
DNSSEC and multi-provider DNS interact in tricky ways, and it's the most common stumbling block.
The problem: DNSSEC signing involves private keys. In a multi-provider setup, both providers need to serve validly signed records, but they each have their own signing keys. There are a few approaches:
- One provider signs, transfers signed zone: In primary-secondary, the primary signs the zone and transfers the already-signed records to the secondary. The secondary serves the pre-signed data. This works but ties signing to the primary.
- Both providers sign with coordinated keys: A more complex multi-signer setup (defined in RFC 8901) where both providers sign independently but their keys are cross-published so validation works regardless of which provider answers. This is powerful but operationally complex.
- Disable DNSSEC: Some organizations forgo DNSSEC to simplify multi-provider setups, trading one security property for availability redundancy.
If you use both DNSSEC and multi-provider DNS, plan the signing strategy carefully. A misconfigured multi-provider DNSSEC setup can cause validation failures, the same fail-closed outage mode we've discussed. Both providers must present a coherent chain of trust.
How to Set Up Secondary DNS
- Choose your providers. Select two independent DNS providers. Independence matters: two providers that share underlying infrastructure don't give you true redundancy. Pick providers with separate networks and operations.
- Decide on a model. Primary-secondary (zone transfer) or multi-primary (dual push). Zone transfer is simpler if both providers support AXFR/IXFR; multi-primary suits automated, infrastructure-as-code environments.
- Configure the zone on both. For primary-secondary, set up the primary with your zone and configure the secondary to transfer from it (with NOTIFY and appropriate access controls on the transfer). For multi-primary, create the identical zone on both and establish your sync tooling.
- Secure zone transfers. If using AXFR/IXFR, restrict transfers to authorized secondaries (by IP and ideally TSIG authentication) so attackers can't pull your entire zone.
- Update your delegation. At your registrar, list the nameservers from both providers in your NS delegation. This is what makes resolvers able to query either provider.
- Verify both providers serve identical records. Query each provider's nameservers directly and confirm they return the same answers. Any discrepancy means inconsistent resolution.
- Test failover. Confirm that resolution still works if one provider is unavailable. This is the whole point, so verify it actually functions.
The Synchronization Risk
Multi-provider DNS introduces its own failure mode: the two providers drifting out of sync. If a change is made at one provider but not the other (a failed zone transfer, a sync tool error, a manual change at one provider), the two start serving different records. Resolvers then get different answers depending on which provider they query, causing inconsistent and confusing behavior that can be harder to diagnose than a simple outage.
This is why monitoring is essential in a multi-provider setup. You need to verify not just that your DNS resolves, but that both providers are serving the same, correct records. Drift between providers is a silent problem that monitoring catches and manual checking usually misses.
How DNS Assistant Helps With Multi-Provider DNS
Multi-provider DNS adds resilience but also adds the complexity of keeping providers synchronized and correct. DNS Assistant supports multi-provider setups by monitoring what's actually being served:
- Record monitoring verifies the records resolving for your domain are correct, catching drift or unexpected changes regardless of which provider serves them.
- NS delegation monitoring confirms your delegation correctly lists both providers' nameservers and alerts if it changes.
- DNSSEC validation checks that your chain of trust validates, which is especially important in multi-provider DNSSEC setups where signing coordination is complex and failure-prone.
- Change detection alerts you to any modification, helping you confirm that changes propagated correctly to your DNS and catching the case where one provider updated but another didn't.
- Multi-channel alerting via email, Slack, Microsoft Teams, webhooks, and SMS.
Multi-provider DNS is a powerful resilience measure, and pairing it with continuous monitoring ensures the redundancy actually delivers, both providers serving correct, consistent records, with any drift caught immediately. This complements the broader resilience strategy we outlined in our DNS disaster recovery guide.
Get Started
Check your current DNS setup with the DNS lookup tool at dnsassistant.com/tools to see your nameservers and records. Run a Free Domain Risk Report for a comprehensive view of your DNS configuration.
For continuous monitoring across all your DNS providers with real-time alerting, sign up at dnsassistant.com.
Top comments (0)