Independent Secondary DNS

Authoritative DNS fails closed. If no name server answers for your zone, your service does not degrade - it ceases to exist for every client that does not already hold a cached answer. Application servers, databases, CDN and load balancers can all be perfectly healthy and entirely unreachable.

Most organisations have one authoritative DNS provider, which means one organisation's availability is a hard ceiling on their own. The NS record set names that provider's name servers and nothing else, so a resolver that cannot get an answer has nowhere else to ask.

Independent secondary DNS removes the ceiling by naming two providers in the NS set. Resolvers try them in no guaranteed order and will use whichever answers, so the zone survives the loss of either.

Why it matters

The failure is correlated and total, which is an unusual combination. Most dependencies degrade a feature; this one removes the whole estate at once, for everyone whose cache has expired - and organisations that tuned TTLs down for fast failover expire fastest.

It is also a dependency almost nobody tests. Internal monitoring stays green throughout, because nothing inside the company is broken, so the detection path is customer reports. And the exposure is set by the TTL: with records cached for 60 seconds, essentially the whole internet must successfully re-resolve your names every minute.

The cost asymmetry is stark. A second provider for an ordinary zone costs tens to low hundreds of dollars a month at typical query volumes. A day of total unreachability costs orders of magnitude more than that, and the design work is a few days.

Implementation patterns

• Primary-secondary by zone transfer. One provider is primary; the second pulls the zone by AXFR/IXFR and is notified of changes. Simple, and it depends on both vendors' transfer implementations and on TSIG key management.
• Dual push from your own automation. Your pipeline applies every change to both providers through their APIs. This removes the dependency on vendor transfer support and makes zone consistency your problem, which is the right trade when the zone is generated from code.
• Name both providers' name servers in the NS record set, and keep the parent delegation in step. A secondary that serves the zone but is not delegated is doing nothing.
• Continuously verify the two answer identically, for every record type, from an external vantage point. This is the control that matters most, because resolvers will happily use a stale secondary.
• Keep the zone inside the feature intersection of both providers - see the failure list below.
• Monitor resolution from outside, from several networks and resolvers, as a first-class signal with its own alert.
• Keep TTLs where failover needs them rather than compromising them for this; provider diversity and TTL solve different problems.

Industry example

On 21 October 2016 a large managed DNS provider was hit by waves of distributed denial-of-service traffic beginning around 11:10 UTC, which the provider and Flashpoint confirmed involved a Mirai botnet of compromised consumer devices. Widely used sites that named only that provider's name servers became unreachable for much of the day, while their own infrastructure was healthy throughout. The industry response was not better single-provider resilience; it was the normalisation of dual-provider authoritative DNS for consumer-facing zones.

Failure scenarios

• Feature divergence. The zone uses apex ALIAS or ANAME records, weighted answers or health-checked failover - all provider extensions. The secondary cannot serve them, so either the zone is redesigned or the second provider is quietly abandoned.
• Stale secondary. Transfers break, nobody notices for weeks because the primary answers most queries, and then a fraction of users is served last month's records. This is worse than having no secondary, since the wrong answer is authoritative and cached.
• Delegation drift. Records are added at the secondary but the parent delegation still names only the primary, so the secondary never receives a query.
• Shared fate that was not visible. The "second" provider resells the first, or both run on the same anycast infrastructure. Verify the autonomous systems, not the brand.
• DNSSEC key management. Signing with two providers requires either one signer with the other serving pre-signed data, or coordinated multi-signer key sets. Getting this wrong makes the zone fail validation, which is a harder outage than the one being prevented.

Trade-offs

The honest tension is that provider-specific traffic steering is genuinely useful, and giving it up to gain availability feels like a downgrade. The usual resolution is to put steering behind a hostname both providers can CNAME to, keeping the apex simple.

When not to use it

For an internal zone whose clients are all inside a network you operate, a resolution outage and an application outage are usually the same event, so the second provider buys nothing.

For a zone that exists only to serve a non-critical property - a marketing microsite, a redirect - the work is not proportionate.

And where the business genuinely depends on health-checked, latency-aware steering at the apex that only one provider offers, be explicit: accept the single provider, document it as a known single point of failure, and pair it with an exercised runbook for moving the zone, rather than pretending diversity exists.

Interview question

Q: Your consumer-facing zone is served by one managed DNS provider. The board asks whether a DNS outage could take the company offline. What do you tell them, and what would you implement?

What a strong answer covers: that authoritative DNS fails closed and the failure is total rather than partial · that short TTLs make it worse, not better · dual-provider authoritative DNS with both in the NS set, by zone transfer or dual push · continuous equality verification and external resolution monitoring as the controls that make it real · the genuine blocker, which is the provider feature intersection at the apex, and the CNAME-based workaround · DNSSEC multi-signer complexity named rather than skipped · and the cost comparison: a second provider at tens to low hundreds of dollars a month against a day of total unreachability.

Quick check

Quiz: Why is a stale secondary DNS provider worse than having no secondary at all? Because resolvers treat it as authoritative and cache its answers, so a fraction of users is served wrong records with no error anywhere - whereas with no secondary the failure is at least obvious.

Flashcard: What is the real blocker to running two authoritative DNS providers? - Not cost or transfers, but provider-specific features: apex ALIAS or ANAME records, weighted and geo-steered answers and health-checked failover, which force the zone into the intersection of what both support.