How to Set Up a Secondary DNS Server

What Is a Secondary DNS Server?

Secondary DNS server setup — primary and secondary name servers connected

A secondary DNS server (also called a slave server) holds a read-only copy of your DNS zone data. It receives updates from the primary (master) server through a zone transfer — a full AXFR or an incremental IXFR.

When a resolver queries your domain, the request can be answered by the primary or by any secondary listed in your NS records. This gives you redundancy: if the primary goes offline, the secondaries keep serving the last known-good records and your domain stays resolvable. The roles of primary and secondary servers are defined in RFC 1034.

You keep editing your records in one place — the primary — while every secondary mirrors those changes automatically over the zone transfer. There is nothing to maintain day to day once it is set up, which makes a secondary the simplest, registrar-approved way to add resilience to your DNS.

Why You Need a Secondary DNS Server

Most domain registrars require at least two nameservers before they will delegate a zone. Beyond that minimum, a secondary DNS server gives you:

– Resilience against primary-server outages and maintenance windows – Lower query latency by placing nameservers in different geographic regions and networks – Protection against DDoS attacks aimed at a single server or a single network – Compliance with RFC 2182, which recommends at least three nameservers, on separate networks, for every zone

If you want the full reasoning behind running multiple nameservers, see our guide on DNS redundancy and failover.

Automatic DNS Zone Synchronization

Synchronization is driven by the zone's SOA record and by NOTIFY messages:

– After the first AXFR, the secondary re-checks the zone every refresh interval (the second timer in the SOA record). – If the primary sends a NOTIFY (RFC 1996) on every change, secondaries pull the update within seconds instead of waiting for the refresh timer. – A bumped SOA serial is the signal that tells the secondary new data is available — always increment it after editing a zone, or the secondary will never see your changes.

The mechanics of AXFR, IXFR, the SOA timers, and TSIG signing are covered in depth in Understanding AXFR zone transfers.

Secondary DNS Setup Requirements

Before you begin, make sure you have:

1. A primary DNS server running BIND, PowerDNS, Knot, NSD, or any software that supports AXFR 2. The public IP address of that primary server 3. AXFR (zone transfer) allowed on the primary for the secondary server's IP address 4. Access to your domain registrar to edit NS records

TCP port 53 must be reachable on the primary — AXFR runs over TCP, not UDP. A firewall that only permits UDP/53 will answer ordinary queries but silently break zone transfers.

Allow Zone Transfers on Primary DNS

On the primary, allow AXFR to the secondary server's IP address.

For BIND, add this to the zone definition (or to the global options):

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

For PowerDNS, allow AXFR and enable NOTIFY in pdns.conf:

allow-axfr-ips=192.0.2.1/32
also-notify=192.0.2.1

For Knot DNS or NSD, allow the secondary in the zone's transfer and notify settings — Knot uses acl rules (action: transfer and notify), NSD uses provide-xfr and notify. See the Knot DNS and NSD documentation for the exact syntax.

Replace 192.0.2.1 with the actual IP address of your secondary DNS service. For production zones, restrict transfers further with a TSIG key — covered in the security section of the AXFR guide.

Add Your Domain to Secondary DNS

If you use a managed secondary DNS service, add your domain through the dashboard or API. Provide the zone name and the primary server's IP address — the secondary does the rest.

The secondary immediately attempts an AXFR to pull the full zone. After that initial transfer it stays in sync using the SOA refresh interval, or instantly via NOTIFY when the primary is configured to send it. If your secondary is not listed in the zone's NS records (a stealth or hidden setup), add its IP to also-notify so it still receives change notifications.

With SecondDNS you can add your first zone on the free 3-month trial — no credit card required — and confirm transfers work before pointing any NS records at it. Create an account to get the secondary IP you need to whitelist in Allow Zone Transfers on Primary DNS.

Update NS Records at Your Registrar

Once the secondary is syncing, add it as a nameserver at your domain registrar.

If your primary is ns1.example.com and the secondary is ns1.seconddns.com, your delegation should list both:

example.com.  NS  ns1.example.com.
example.com.  NS  ns1.seconddns.com.

Keep the primary NS record in place — both servers answer queries. If the secondary's hostname lives under your own domain (for example ns2.example.com), you must also register glue records at the registrar so resolvers can find its IP. Using a provider hostname such as ns1.seconddns.com avoids the glue-record step entirely; see personalized nameservers if you want vanity NS names on your own domain.

Verify Secondary DNS Is Working

Test that both nameservers answer with the same data:

dig @ns1.example.com example.com SOA
dig @ns1.seconddns.com example.com SOA

Both should return the same SOA serial number. If the serial on the secondary is lower, the zone transfer hasn't completed yet — check firewall rules and the allow-transfer configuration from Allow Zone Transfers on Primary DNS.

Confirm the delegation lists both servers:

dig example.com NS

And request the full zone from the secondary to be sure AXFR is permitted for it. This should succeed from your authorized IP and be refused from anywhere else:

dig @ns1.seconddns.com example.com AXFR

How Long Does Propagation Take?

NS record changes are governed by the TTL on the parent zone's delegation, not by the TTLs inside your own zone. In practice, allow 24–48 hours for the new nameserver to become visible to every resolver worldwide, although most resolvers pick it up much sooner.

During this propagation window both the old and the new delegation are valid, so there is no downtime as long as every server listed in your NS records answers correctly. This is exactly why you verify the secondary in Verify Secondary DNS Is Working before changing the delegation at your registrar.

Troubleshooting Secondary DNS Setup

Common issues and how to fix them:

Zone transfer refused — the primary isn't allowing AXFR from the secondary's IP. Re-check allow-transfer (BIND) or allow-axfr-ips (PowerDNS) and any firewall rule on TCP port 53.

Stale records on the secondary — NOTIFY isn't reaching the secondary, or the SOA refresh interval is too long. Enable also-notify on the primary, or lower the refresh timer.

Serial not increasing — if you edit the zone by hand but forget to bump the SOA serial, the secondary will never pull the change. Always increment the serial; many operators use the YYYYMMDDnn format.

Secondary not listed in DNS — NS record changes can take 24–48 hours to propagate. Use dig against specific resolvers (for example dig @8.8.8.8 example.com NS) to check.

Connection timeout — TCP port 53 is blocked between primary and secondary. AXFR uses TCP; a firewall that only allows UDP/53 will pass queries but break transfers.

Setting this up inside a hosting control panel? Follow the step-by-step guides for cPanel/WHM, Plesk, DirectAdmin, or CyberPanel.