Building Resilience: Why We Started with Secondary DNS

Every web request starts with a DNS lookup. When resolution is slow, your users feel it before your application even loads. When resolution fails, your application is unreachable regardless of how healthy your origin is or how fast your CDN answers. DNS is the layer where most teams still accept a single point of failure, and it sits in front of everything else that’s been made redundant.

The fix is well understood: add a second authoritative DNS provider. That is the first thing we shipped with Fastly DNS, and it is worth explaining why we started there.

Why Secondary, and Why First

Primary DNS is the bigger build, so we started with the piece that makes an existing setup more resilient on day one.

Adding a secondary provider is not a migration. Your primary stays exactly where it is. You keep creating and editing records in the system you use today, with the tooling and the change process you already have. Adding Fastly is a configuration change you can make in an afternoon and back out just as quickly, which matters when the thing you are changing is the layer in front of your entire application.

Running two authoritative providers is what a resilient DNS setup looks like, and that stays true no matter who your primary is. Even a customer who eventually runs primary DNS on Fastly should still want a second provider answering for their zone. 

A second provider addresses the failure that actually happens, depending on one authoritative provider. That is the problem worth solving first.

How it works

Fastly DNS is an authoritative DNS service. It holds the records for your domain and returns the final answer for queries against it. And it is managed, so you are not running nameserver software, patching it, or maintaining hardware.

Your primary stays the source of truth. The sync path is standard:

• A record changes on your primary.

• Your primary sends a NOTIFY to Fastly.

• Fastly requests the zone transfer, using AXFR for a full copy or IXFR for just the changes.

• Fastly's nameservers serve whatever you manage on your primary.

Fastly cannot create or edit records. That is read-only by design, and it keeps the question of where your records actually live unambiguous.

On the query side, both providers appear in your NS record set, and Fastly answers authoritative queries from its global network, so lookups resolve from a POP near your user rather than a single region.

One clarification, because the industry is loose about it. This is not a failover. Your NS record set carries no priority order, so resolvers distribute queries across your nameservers. With two providers, a share of your traffic is already resolving through each one, and losing one costs you capacity rather than resolution.

What it Takes

The requirements are short. You operate your own primary DNS, and your primary supports zone transfers. Not every provider does, and that is the one thing worth confirming before you plan this out.

What You Get

Resilience that doesn’t depend on one vendor. A single provider's bad day becomes a degraded condition instead of an outage. This is the cheapest redundancy available to most teams, because it requires no application change at all.

Answers from the Fastly network. Authoritative responses are served from Fastly's global footprint, close to your users, providing a faster and a better user experience.

Get Started

Reach out to your account manager to talk about adding Fastly as a secondary provider or talk to a Fastly expert.