Secondary DNS Server: What It Is and How It Works

What Is a Secondary DNS Server?

A secondary DNS server is an authoritative nameserver that holds a read-only copy of a DNS zone and answers queries for it with the same authority as the primary. It does not have its own version of the zone: it receives the zone from the primary through a zone transfer and keeps that copy in sync.

From the outside, primary and secondary are indistinguishable. Both appear in the domain's NS records, both answer with the AA (authoritative answer) flag, and resolvers pick whichever responds faster. The difference is only in where the data is edited: you change records on the primary, and the secondary follows.

Older documentation and many configuration files still call the two roles master and slave. BIND, PowerDNS and most panels accept both names; the meaning is the same.

Every production domain is expected to have at least two authoritative nameservers, on different networks — RFC 2182 spells out why, and most registries refuse a delegation with fewer. A secondary DNS server is how a single-server setup meets that requirement without running a second full DNS installation by hand.

Primary vs Secondary DNS

Primary (master). Holds the editable copy of the zone — in zone files for BIND, in a database for PowerDNS, in the panel's storage for cPanel, Plesk, DirectAdmin or CyberPanel. Every change to a record happens here, and each change is supposed to bump the zone's SOA serial.

Secondary (slave). Holds a copy obtained by zone transfer. It never accepts edits; anything changed locally is overwritten by the next transfer. It answers queries authoritatively, sends no changes back, and drops the zone if it cannot reach the primary for longer than the SOA expire time.

What this means in practice:

- Adding a record means editing the primary only. The secondary picks the change up on its own. - If the primary is down, the secondary keeps answering — but new changes cannot be made until the primary is back. - If the secondary is down, the primary keeps answering and nothing is lost; resolvers simply use the remaining nameserver. - Both servers must be listed in the NS records at the registrar, or resolvers will never ask the secondary anything.

How a Secondary Gets the Zone

The mechanism is a zone transfer, defined by the DNS protocol itself, so any secondary can work with any primary regardless of software.

1. Authorisation. The primary must allow transfers to the secondary's IP address (allow-transfer in BIND, allow-axfr-ips in PowerDNS) or accept a shared TSIG key. Without this the secondary is refused. 2. First transfer. The secondary asks for the whole zone with an AXFR request over TCP port 53 and stores the result. From now on it is authoritative for the zone. 3. Staying in sync. The secondary re-checks the primary's SOA record on the schedule set by the zone's SOA refresh value. If the primary's serial is higher than its own, it transfers again — the full zone (AXFR) or only the changes (IXFR) when both sides support it. 4. NOTIFY. Instead of waiting for the refresh timer, a primary can send a NOTIFY message the moment the zone changes; the secondary then checks the serial immediately. With NOTIFY in place, changes reach the secondary in seconds. 5. Expiry. If the primary stays unreachable past the SOA expire value, the secondary stops answering for the zone rather than serve data that may be badly outdated.

Two details cause most failed setups. The serial must actually increase on every change — a secondary compares numbers, not content. And AXFR uses TCP, not UDP: a firewall that allows only UDP 53 lets normal queries through but silently blocks every zone transfer. The transfer protocol is covered in depth in Understanding AXFR Zone Transfers, and the timers in What Is a DNS SOA Record and Why It Matters for Your Domain.

Why You Need a Secondary DNS Server

Availability. A single authoritative nameserver is a single point of failure for every domain on it. A reboot for a kernel update, a hardware fault, a DDoS on the server — and the domains do not resolve at all: websites, mail and APIs stop together. With a secondary on a different network, resolvers get their answers from it and users notice nothing.

Registrar and registry rules. Most registries require at least two nameservers to delegate a domain, and some check that they are on different networks. Listing the same server under two names satisfies the form but not the purpose: both names fail together.

Caching does not save you. Resolvers cache records only for their TTL — minutes to hours. A primary that is down for longer than the TTL is a domain that has vanished from the internet, and mail servers that cannot resolve your MX will bounce or defer messages.

Distance. A secondary in a second location answers users closer to it, and the two servers share the query load. That is a side benefit, not the main reason: the main reason is that one server eventually goes down, and a secondary is what keeps the domain online when it does.

DNS Redundancy: Why It Matters and How to Achieve It goes deeper into what actually breaks and how to design against it.

Running Your Own Secondary vs Using a Hosted One

Your own second server. A second BIND or PowerDNS installation on another machine, ideally in a different data centre, configured as a secondary for each zone. It gives you full control and costs only the server. The cost is operational: a second host to patch and monitor, firewall rules on both sides, and every new zone registered on the secondary by hand — or automated with scripts you maintain. Many single-server setups never get to it for exactly that reason.

A hosted secondary DNS service. A provider runs the secondary nameservers; you allow zone transfers from their IP and point your NS records at their hostname (or at your own hostname with a glue record — see What Are DNS Glue Records and When Do You Need Them). Your server stays the primary, nothing about how you edit DNS changes, and the provider's job is to stay up when yours is not. The trade-off is that you depend on a third party for half of your DNS, so its uptime and its network separation from yours matter.

Hosting panels. On cPanel, Plesk, DirectAdmin and CyberPanel the manual route is harder than it looks: the panel regenerates the DNS server's configuration, so hand edits are overwritten, and each new domain needs registering on the secondary. Integrations that hook the panel's domain events exist for exactly this; the panel guides below show both the manual and the automated way.

Whichever you choose, the checklist is the same: transfers allowed from the secondary's address, NOTIFY enabled, TCP 53 open, both nameservers in the delegation, and the serial incremented on every change.

Checking That a Secondary Is Working

Ask each authoritative server for the zone's SOA record directly. Replace example.com with your domain and the two hostnames with your nameservers:

dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +short

Both must answer, and the serial number (the third field) must be identical. A secondary that answers with a lower serial has not picked up the latest change; one that answers SERVFAIL or REFUSED has never loaded the zone or has expired it.

Check the delegation as the world sees it:

dig NS example.com +short

Both nameservers must be listed. A secondary that is in perfect sync but missing from the NS records receives no queries and protects nothing.

Finally, confirm the zone transfer itself is possible from the secondary's network — from the secondary host, or from any host whose IP the primary allows:

dig AXFR example.com @ns1.example.com

A full zone listing means transfers work; a transfer failed or REFUSED means the primary's allow-transfer rules or a firewall on TCP 53 are blocking the secondary.

Common Mistakes

- Forgetting to increment the SOA serial. The primary answers with new data, the secondary sees the same serial and never transfers. The most common cause of "works on ns1, not on ns2". - Opening UDP 53 but not TCP 53. Queries work, transfers do not. Every zone on the secondary quietly expires. - Not listing the secondary in the NS records. The secondary syncs perfectly and is never asked anything. - Both nameservers on the same host or network. Satisfies the registrar's form, not the failure it is meant to survive. - A short SOA expire. One day is common in panel defaults; a weekend outage of the primary then takes the secondary down with it. Two weeks is the usual value. - Editing records on the secondary. They vanish at the next transfer. - Forgetting the secondary when a new domain is added. Every new zone has to be registered on the secondary, by hand or by automation; a zone that exists only on the primary has no redundancy at all.

Related Guides

Setup and the underlying mechanisms:

- How to Set Up a Secondary DNS Server - Understanding AXFR Zone Transfers - What Is a DNS SOA Record and Why It Matters for Your Domain - DNS Redundancy: Why It Matters and How to Achieve It - What Are DNS Glue Records and When Do You Need Them

Hosting panels:

- How to Add Secondary DNS to cPanel/WHM Hosting Panel - How to Add Secondary DNS to Plesk Hosting Panel - How to Add Secondary DNS to DirectAdmin Hosting Panel - How to Add Secondary DNS to CyberPanel Hosting Panel