Fastly DNS Adds Secondary Authoritative DNS Without a Migration

Adding a second authoritative DNS provider is a relatively contained way to reduce dependence on one provider. Fastly’s first DNS product takes that approach: it serves a read-only copy of records managed elsewhere, so teams can add another source of authoritative answers without moving their existing DNS workflow.

That distinction matters because DNS sits in front of application delivery. A healthy origin and a responsive content delivery network cannot help a user whose domain fails to resolve. Yet an organization can have redundancy across application infrastructure and still rely on one authoritative DNS provider. Fastly’s case for starting with secondary DNS is that this gap can be addressed without first replacing the system teams already use.

A second provider, without a DNS migration

Moving a domain’s primary DNS service can involve changing how records are managed, reviewed, and published. Fastly’s secondary setup is designed to leave those processes in place. Teams continue editing records in their current provider, and Fastly receives copies through standard DNS zone transfer mechanisms.

That makes the initial change easier to contain: the existing provider remains the source of truth, and Fastly’s service is added as another authoritative provider. The article describes setup as a configuration change that can be made or reversed quickly. The actual effort will depend on the current provider and its zone transfer settings, but the design avoids requiring application changes or a wholesale move of record management.

The arrangement also reflects a broader operational principle. If the goal is to avoid dependence on a single DNS provider, changing the primary provider alone does not remove that dependency. A second provider remains relevant even for teams that later choose Fastly as their primary DNS service.

How records reach Fastly

Fastly DNS is an authoritative DNS service: it stores zone data and returns answers to queries for that domain. Fastly manages the service infrastructure, while the customer maintains records through their existing primary provider.

Synchronization follows a familiar sequence. When a record changes on the primary, that provider sends Fastly a NOTIFY message. Fastly then requests a zone transfer. AXFR transfers a complete copy of the zone; IXFR sends only the changes. Fastly’s nameservers can then answer using the records maintained on the primary.

• A record is changed at the existing primary provider.

• The primary sends a NOTIFY message to Fastly.

• Fastly requests an AXFR full zone copy or an IXFR containing updates.

• Fastly serves authoritative answers using the synchronized zone data.

Fastly cannot create or edit records in this arrangement. That read-only boundary keeps record ownership clear: teams make changes in one place, and the secondary provider serves a synchronized copy. It also means teams need to understand how quickly their primary sends updates and how they will monitor whether transfers are working. The source describes the transfer path, but does not specify synchronization timing or monitoring details.

It distributes queries; it does not wait for an outage

Once both providers appear in a domain’s NS record set, resolvers can query either provider. DNS does not assign a priority order to those nameservers, so the setup is not a standby service that begins answering only after the primary fails. Queries are already distributed across the listed nameservers.

That changes how to think about the resilience benefit. If one provider stops answering, the other can continue serving queries, but the remaining provider must handle the traffic that still reaches it. The design reduces dependence on one provider; it does not make capacity planning or operational monitoring irrelevant. Teams should consider the load their remaining service would need to absorb and confirm that both providers have current zone data.

Fastly says its nameservers answer from its global network, with points of presence near users. That can place authoritative responses closer to some query sources, though the article provides no latency measurements or comparative benchmarks. Any performance difference will depend on resolver behavior, user location, network conditions, and the providers involved.

Check zone transfer support first

The stated requirements are straightforward: teams need to operate their own primary DNS and that provider must support zone transfers. Fastly identifies provider support for transfers as the key prerequisite, and it is the first compatibility detail to confirm. Teams should also check the primary provider’s configuration requirements for NOTIFY messages and transfer access before planning a rollout.

For teams whose provider supports the necessary DNS mechanisms, the model offers a way to add another authoritative path while retaining familiar record management. For teams whose provider does not support zone transfers, the described design may not fit without changing the DNS setup.

What to assess before rollout

The practical value is clearest when a team wants another provider answering for its domain and can keep its existing record workflow. The tradeoff is that two providers introduce synchronization and operational details to manage: records must stay current, both services need suitable capacity, and teams need a way to detect transfer or query problems.

Fastly presents secondary DNS as a low-effort resilience measure that requires no application changes. That is plausible for compatible setups, but the source does not give pricing, service-level details, transfer timing, or performance data. Those details should shape a production decision alongside the provider’s support for zone transfers.

The useful next step is to verify transfer support and understand how the two providers will be monitored. If those conditions fit, secondary DNS can add another authoritative answer path without forcing teams to relocate the record system they already operate.