What is secondary DNS and why should you use it?

Secondary DNS is a setup where one or more additional authoritative nameservers hold a read-only copy of your DNS zone, copied automatically from a primary server through zone transfers. Both the primary and the secondaries answer queries for your domain, so if the primary nameserver or the whole DNS provider goes offline, the secondaries keep answering and your website, email and APIs stay reachable. You use it to remove your DNS provider as a single point of failure, to spread query load, and to keep the master copy of your zone somewhere you control.

Every domain already needs at least two nameservers, but in most setups they're run by the same provider, on the same platform, with the same failure modes. Secondary DNS, especially with a second provider, adds genuine independence. In this article you'll learn how primary and secondary nameservers work together, how zone transfers and NOTIFY keep them in sync, the common architectures, how to configure BIND as both primary and secondary with TSIG, and what to check before you rely on it.

Primary and Secondary Nameservers

Every DNS zone has one source of truth: the primary nameserver (historically called the master). That's where you edit records. Secondary nameservers (historically called slaves) don't accept edits. They fetch the zone from the primary and serve that copy.

From the outside, there's no difference. When a resolver looks up your domain, it picks one of the nameservers listed in your NS records, roughly at random or based on which responds fastest, and accepts the answer. All of them are authoritative.

$ dig example.com NS +short
ns1.dns-provider-a.example.
ns2.dns-provider-a.example.
ns1.dns-provider-b.example.
ns2.dns-provider-b.example.

In this example, two nameservers belong to one provider and two to another. If provider A has an outage, resolvers that fail to get an answer from its servers will retry with provider B's servers, and your domain keeps resolving.

Why Use Secondary DNS?

Resilience Against Provider Outages

DNS providers are very reliable, but not perfect. Large DDoS attacks against DNS providers, configuration mistakes and software bugs have all caused widespread outages over the years, taking thousands of well-known sites offline at once, even though their web servers were perfectly healthy. Sites that used a second DNS provider were largely unaffected.

If your domain is important to your business, two independent DNS providers is one of the cheapest forms of insurance available.

Better Performance and Capacity

More nameservers in more locations means more capacity to absorb traffic and a better chance that a resolver has a fast nameserver nearby. Resolvers tend to learn which nameservers respond quickest and prefer them.

Control Over the Master Copy

A popular design is the hidden primary: you run the primary yourself, on a server that isn't listed in your NS records and isn't reachable by the public. It exists only to feed one or more managed secondary providers, which do all the public-facing work. You get full control over your zone (in files, version control or your own tooling) without having to expose your own server to the internet.

Easier Migrations

When moving between DNS providers, adding the new provider as a secondary first lets it serve an identical copy of the zone before you change the delegation. That avoids the risk of forgetting a record during a manual copy.

How Zone Transfers Work

Secondaries stay in sync using a few standard mechanisms.

The SOA Record Controls Timing

The zone's SOA record contains a serial number and timers that tell secondaries how often to check for changes:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                2026102201 ; serial
                3600       ; refresh: check for changes every hour
                600        ; retry: if a check fails, retry after 10 minutes
                1209600    ; expire: stop answering after 14 days without contact
                300 )      ; negative caching TTL

• Serial: Must increase every time the zone changes. A common format is YYYYMMDDnn.
• Refresh: How often a secondary asks the primary whether the serial has changed.
• Retry: How long to wait before trying again after a failed refresh.
• Expire: If the secondary can't reach the primary for this long, it stops answering for the zone rather than serve dangerously stale data.

NOTIFY for Instant Updates

Waiting up to an hour for a refresh is slow. With NOTIFY, the primary sends a message to its secondaries as soon as the zone changes. Each secondary then checks the serial straight away and pulls the update if it's higher. In practice, changes reach well-configured secondaries within seconds.

AXFR and IXFR

There are two types of zone transfer:

Type	What it sends	When it's used
AXFR	The entire zone	First transfer, or when an incremental transfer isn't possible
IXFR	Only the changes since a given serial	Routine updates, if both sides support it

Transfers run over TCP. Because a full transfer reveals every record in your zone, primaries should only allow transfers to known secondaries, ideally authenticated with TSIG keys rather than relying on IP addresses alone.

Common Secondary DNS Architectures

Architecture	How it works	Best for
Single provider, multiple nameservers	The provider runs all nameservers on its own network	Most small sites; easy, but one provider is a single point of failure
Primary provider plus secondary provider	Provider A is primary and sends transfers to provider B	Adding resilience without changing how you edit records
Hidden primary plus one or more secondary providers	Your own server is primary but not public; providers serve the zone	Organisations that want control and resilience
Multi-primary via API	Records are pushed to two providers separately by tooling, with no zone transfers	Providers that don't support transfers, or that rely on proprietary record types

The last option deserves a mention. Not every provider supports zone transfers. Amazon Route 53, for example, doesn't act as a primary or a secondary for standard zone transfers. In that case, people keep two providers in sync with DNS-as-code tools such as OctoDNS, DNSControl or Terraform, which push the same records to both through their APIs.

How to Set Up Secondary DNS with BIND

Here's a complete example with a primary at 192.0.2.53 and a secondary at 198.51.100.53, using a TSIG key to authenticate transfers.

Step 1: Create a TSIG Key

On the primary, generate a key:

tsig-keygen -a hmac-sha256 transfer-key > /etc/bind/transfer-key.conf
cat /etc/bind/transfer-key.conf

The output looks like this (the secret here is illustrative):

key "transfer-key" {
	algorithm hmac-sha256;
	secret "pN7kq2v0eXbS1oY9hJt6lA3mR8cW4uZ5fG0dE2iK1sQ=";
};

Copy this file securely to the secondary as well. Both servers need the same key.

Step 2: Configure the Primary

In the primary's named.conf.local:

include "/etc/bind/transfer-key.conf";

zone "example.com" {
    type primary;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { key transfer-key; };
    also-notify { 198.51.100.53; };
    notify yes;
};

allow-transfer restricts transfers to requests signed with the key. also-notify sends NOTIFY messages to the secondary even if it isn't listed in the zone's NS records, which is useful for hidden primary setups.

Step 3: Configure the Secondary

On the secondary:

include "/etc/bind/transfer-key.conf";

server 192.0.2.53 {
    keys { transfer-key; };
};

zone "example.com" {
    type secondary;
    file "/var/cache/bind/db.example.com";
    primaries { 192.0.2.53 key transfer-key; };
    allow-notify { 192.0.2.53; };
};

The secondary stores its copy in /var/cache/bind, a directory the named process can write to. Older BIND versions use type slave and masters instead of type secondary and primaries; current versions accept both, but the newer terms are preferred.

Step 4: Check and Reload Both Servers

sudo named-checkconf
sudo rndc reload

On the secondary, you should see the transfer in the logs:

sudo journalctl -u named --since "5 minutes ago" | grep -i transfer

transfer of 'example.com/IN' from 192.0.2.53#53: Transfer completed: 1 messages, 14 records, 512 bytes, 0.004 secs

On Debian and Ubuntu the service may be called bind9 rather than named.

Step 5: Add the Secondary to Your NS Records

Add the secondary's name to the zone's NS records on the primary, increase the serial, and reload. Then update the nameservers at your registrar so the parent zone delegates to all of them:

example.com.   3600  IN  NS  ns1.example.com.
example.com.   3600  IN  NS  ns2.example.net.

If the secondary's hostname is inside your own domain, such as ns2.example.com, you'll also need glue records at the registrar.

Using a Managed Secondary DNS Provider

Many managed providers offer secondary DNS, sometimes on all plans and sometimes as a paid add-on. Examples include Cloudflare, NS1, DNS Made Easy, Hurricane Electric's free DNS service, and many registrars and hosting companies. The process is usually the same:

1. Add the zone as a secondary in the provider's dashboard and enter your primary's IP address.
2. Allow transfers from the provider's transfer servers on your primary. The provider documents their IP addresses, and many support TSIG too.
3. Add the provider's addresses to also-notify so updates arrive straight away.
4. Confirm the zone has transferred by querying the provider's nameservers directly.
5. Add the provider's nameservers to your NS records and at your registrar.

Verifying Your Secondaries

The most important check is that every nameserver is serving the same version of the zone. dig +nssearch asks each listed nameserver for the SOA record and shows the serial:

$ dig example.com +nssearch
SOA ns1.example.com. hostmaster.example.com. 2026102201 3600 600 1209600 300 from server 192.0.2.53 in 12 ms.
SOA ns1.example.com. hostmaster.example.com. 2026102201 3600 600 1209600 300 from server 198.51.100.53 in 25 ms.

If the serials differ for more than a few seconds after a change, a transfer is failing. You can also query a specific record on each nameserver directly:

for ns in $(dig example.com NS +short); do
  echo "== $ns"
  dig @"$ns" www.example.com A +short
done

To test a transfer yourself, from a machine that's allowed to transfer, using the TSIG key:

dig @192.0.2.53 example.com AXFR -k /etc/bind/transfer-key.conf

And from any other machine, confirm that unauthenticated transfers are refused:

$ dig @192.0.2.53 example.com AXFR
; Transfer failed.

Things to Watch Out For

1. Proprietary record types don't transfer: Features such as ALIAS or ANAME records, CNAME flattening, GeoDNS and health-checked failover are computed by one provider's software. They either don't transfer at all or transfer as a static snapshot. Keep your zone to standard record types if you want both providers to answer identically.

2. DNSSEC needs planning: If you sign your zone, the secondary must serve the signed records unchanged, or both providers must sign with keys that are published in each other's DNSKEY sets (a multi-signer setup). Check that both providers support your chosen approach before enabling it.

3. The expire timer matters: If the primary is down for longer than the SOA expire value, secondaries stop answering. Set it long enough, such as one to four weeks, and monitor transfer failures so you notice well before then.

4. Keep serials increasing: If you edit the zone and forget to increase the serial, secondaries won't pick up the change. Most tools and managed providers handle this automatically.

5. Watch TTLs on NS records: Changes to your nameserver list take a while to propagate through the parent zone and resolver caches, so add new secondaries well before you need them.

6. Monitor every nameserver: An outage on one secondary is easy to miss because resolvers quietly retry the others. Check each nameserver individually, not just whether the domain resolves.

---

FAQ: Secondary DNS

---

Conclusion

Secondary DNS gives your domain additional authoritative nameservers that hold an automatically synchronised copy of your zone. The primary sends NOTIFY messages when something changes, the secondaries pull the update with IXFR or AXFR, and every nameserver answers queries. Used with a second provider or a hidden primary, it removes your DNS host as a single point of failure.

Setting it up is mostly a matter of allowing authenticated transfers from the primary, adding the zone on the secondary, and listing the new nameservers at your registrar. Stick to standard record types, plan DNSSEC carefully, and monitor serial numbers on every nameserver, and you'll have a DNS setup that keeps working even when one provider doesn't.