Choosing a DNS Provider — Redundancy for the Layer Everyone Forgets

Here's a dependency audit most teams have never run: if your DNS provider went dark right now, what still works? The answer is nothing. Not the website, not the API, not the app — and, delightfully, often not your email or the status page you'd use to tell people about it. DNS sits in front of every other dependency you have, and yet it's routinely chosen in thirty seconds, by default, because it came bundled with the registrar or the CDN.

The internet learned this lesson the hard way in October 2016, when a massive DDoS attack on Dyn — a major managed-DNS provider — took Twitter, Spotify, Reddit, GitHub and dozens of other household names offline for large parts of a day. Those companies' servers were fine. Their names were unreachable, which amounts to the same thing. Three years later, the fix — genuine DNS redundancy — is still rare. Here's how to choose DNS hosting like the critical infrastructure it is.

What separates a serious DNS provider

Not all authoritative DNS is created equal. The short checklist:

• An anycast network, and a big one. Anycast announces the same nameserver IP from many locations worldwide; queries land at the nearest one. That buys two things — speed (resolution latency drops for global users) and resilience (an attack or outage at one site is absorbed by the rest of the network). A provider serving your zone from two unicast boxes is a 2016-Dyn-incident waiting to happen with a smaller headline.
• DDoS posture. DNS providers are attacked because they're leverage — one target, thousands of victims. Ask about capacity and history; providers who've weathered large attacks tend to say so.
• API access. You'll want programmatic record management for automation — not least for ACME DNS-01 certificate challenges — and for scripted failover.
• Support for the records you actually need — CAA, proper apex handling (ALIAS/ANAME if you point apexes at CDNs), and reasonable minimum TTLs.

But here's the thing: even a superb provider is still one provider — one control plane, one attack target, one billing mishap away from your whole domain not resolving. Dyn was excellent. That's why the real subject of this post is the next section.

Secondary DNS — two providers, one zone

DNS was designed for multi-provider redundancy; we've just collectively stopped using the feature. The protocol lets any number of nameservers answer authoritatively for a zone, and resolvers automatically retry another listed nameserver when one fails. Two common arrangements:

• Primary/secondary. Provider A holds the zone you edit; provider B is configured as a secondary that pulls a copy automatically via zone transfer (AXFR/IXFR), refreshed on every change (NOTIFY). You edit in one place; both providers serve identical answers.
• Hidden master. You run the master nameserver yourself — often a small, locked-down box that appears in no NS records — and both commercial providers act as secondaries pulling from it. The public never queries your master; it exists purely as the source of truth. Maximum control, and the providers become interchangeable serving capacity.

Your delegation then lists nameservers from both providers:

; Zone: example.com — NS records spanning two providers
example.com.    86400  IN  NS  ns1.provider-a.net.
example.com.    86400  IN  NS  ns2.provider-a.net.
example.com.    86400  IN  NS  ns1.provider-b.org.
example.com.    86400  IN  NS  ns2.provider-b.org.

Set the same NS set at your registrar (the parent delegation) and inside the zone itself. From then on, resolvers spread queries across all four names — and if provider A vanishes, resolvers quietly fail over to provider B's servers. Users notice nothing. During the Dyn attack, the sites that stayed reachable were, disproportionately, the ones with a second provider in their NS set.

Two practical warnings: confirm both providers support zone transfers (some popular ones don't, or only on higher plans — features like proprietary ALIAS records may not transfer cleanly), and test the failover by watching resolution behave with one provider's nameservers blocked, before you need it to be true.

TTL strategy — two different games

The time-to-live on each record tells resolvers how long to cache it, and it's a dial with two distinct uses:

• Planned changes: lower TTL in advance. Migrating a server next Tuesday? Drop the record's TTL from 3600 to 300 a day or two ahead (at least one old TTL before the change), make the switch, watch traffic move within minutes, then raise it back.
• Unplanned failover: the TTL you have is the TTL you get. When a server dies unexpectedly, your DNS-based failover can't act faster than the caches expire. A 24-hour TTL on your main A record means some users see the dead server for up to a day. For records you might need to move in an emergency, 300–900 seconds is a sensible standing value — the extra query load is negligible for most sites.

Don't set everything to 60 seconds "just in case," though: very low TTLs increase your dependence on your DNS provider being reachable right now, which cuts against the redundancy story above. Long TTLs on stable records (NS, MX) are a feature — they let the internet keep resolving you from cache even during a provider wobble.

DNSSEC — worth it, with eyes open

DNSSEC cryptographically signs your zone so resolvers can verify answers weren't forged — real protection against cache poisoning and certain hijacks. The trade-offs deserve honesty:

• Operational sharpness. Signatures expire; keys must roll. A botched key rollover or a migration that forgets the DS record at the registrar doesn't degrade gracefully — validating resolvers treat your domain as bogus and it disappears for a large fraction of the internet.
• Multi-provider friction. Secondary setups need both providers serving the same signatures — pre-signed zones from a hidden master handle this cleanly; provider-managed signing across two vendors is often where the plan stalls.

A fair rule of thumb this year: sign if your provider automates DNSSEC well and your domain is a likely hijack target (finance, auth endpoints, anything with valuable email); if you do, monitor validation continuously, because DNSSEC failures are silent right up until they're total.

Monitor resolution like you monitor uptime

Whatever architecture you land on, verify it continuously — from outside, from multiple places:

• Do all listed nameservers answer, from every region? A dead secondary is silent redundancy loss; you paid for a spare tire that's been flat for months.
• Do they agree? A stale zone transfer means provider B is serving yesterday's records — arguably worse than serving none.
• Are the answers right? Hijacks and fat-fingered edits both look like "wrong answer," and both are invisible from inside your network.

The layer in front of everything

DNS failures are rare, which is exactly why they're worth engineering for — nobody has muscle memory for them, and when they happen, everything is down at once. CompleteStatus monitors DNS resolution alongside uptime and SSL in one dashboard — checking your records resolve correctly, from multiple locations, and alerting on the first wrong or missing answer. Create a free account and put a monitor on the layer the rest of your stack stands on — it's the one outage where your website, API and email all go down with a single root cause.