Choosing a DNS Provider — Redundancy for the Layer Everyone Forgets

A dependency audit most teams have never run: if your DNS provider went dark right now, what would still work? Nothing. Not the website, not the API, not the app, and 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, yet it's usually chosen in thirty seconds, by default, because it came bundled with the registrar or the CDN.

The internet learned this in October 2016, when a large DDoS attack on Dyn, a major managed-DNS provider, made Twitter, Spotify, Reddit, GitHub and dozens of other big names unreachable for much of a day across large parts of the US and Europe. Their servers were fine. Their names didn't resolve, which amounts to the same thing. Three years on, genuine DNS redundancy is still rare. Here's how to choose DNS hosting as if it were critical infrastructure, because 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 speed (lower resolution latency 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 the 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 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.

Even an excellent provider is still one provider: one control plane, one attack target, one billing mishap away from your whole domain not resolving. Dyn was a good provider. 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; most of us have simply 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. You get full 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 they fail over to provider B's servers. Users mostly notice nothing. During the Dyn attack, companies that already had a second provider in their NS set fared far better, and plenty of those that didn't added one in the days that followed.

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

TTL strategy: two different games

The time-to-live on each record tells resolvers how long to cache it. It has 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 argument above. Long TTLs on stable records (NS, MX) are useful: they let the internet keep resolving you from cache during a provider wobble.

DNSSEC: worth it, with eyes open

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

• 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 for now: 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 and from multiple places:

• Do all listed nameservers answer, from every region? A dead secondary is silent redundancy loss, a spare tire that's been flat for months.
• Do they agree? A stale zone transfer means provider B is serving yesterday's records, which is arguably worse than serving none.
• Are the answers right? Hijacks and fat-fingered edits both show up as a 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 that your records resolve correctly 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.