Primary DNS vs Secondary DNS — Redundancy and Zone Transfers

Every domain on the internet depends on DNS to translate names into addresses. If a single nameserver is all that stands between your users and an outage, your domain has a single point of failure. Primary and secondary DNS servers solve this by distributing authoritative zone data across multiple machines so that queries keep getting answered even when one server goes down.

What Is Primary (Master) DNS?

The primary DNS server (historically called the "master") is the authoritative source of truth for a DNS zone. This is the server where all record changes are made — whether through a dashboard, an API, or a zone file edit. When you add an A record, update an MX record, or modify a TXT record, those changes happen on the primary.

Key characteristics of a primary DNS server:

• Holds the read-write copy of the zone
• All record edits originate here
• Sends zone data to secondary servers via zone transfers
• Manages the SOA record serial number, incrementing it on every change
• May or may not be publicly listed in NS records

The primary is the single place where zone data is edited. Every other server holding a copy of the zone gets it — directly or indirectly — from the primary.

What Is Secondary (Slave) DNS?

A secondary DNS server (historically called the "slave") holds a read-only copy of the zone. It receives its data from the primary through zone transfers and serves that data to resolvers just like the primary does. From a resolver's perspective, primary and secondary nameservers are indistinguishable — both return authoritative answers.

Key characteristics of a secondary DNS server:

• Holds a read-only copy of the zone
• Cannot modify zone data locally — all changes must go through the primary
• Receives updates via AXFR or IXFR zone transfers
• Checks the SOA serial number to detect changes
• Stops serving the zone if it cannot reach the primary for longer than the SOA expire interval

Most production domains run at least two nameservers. Many registrars and TLD registries enforce this as a minimum requirement.

How Zone Transfers Work

Zone transfers are the mechanism by which secondary servers get zone data from the primary. There are two transfer protocols, a notification mechanism, and the SOA record ties everything together.

AXFR — Full Zone Transfer

AXFR (Authoritative Transfer) sends the entire zone from primary to secondary. The secondary requests a complete copy, and the primary responds with every record in the zone. AXFR is used for:

• Initial synchronization when a new secondary is set up
• Recovery after data loss on the secondary
• Cases where the primary cannot determine the incremental difference

Secondary → Primary:  AXFR request for example.com
Primary → Secondary:  [SOA, then every record, then SOA again]

AXFR uses TCP on port 53. The entire zone must fit in the transfer, so for very large zones (hundreds of thousands of records) this can be bandwidth-intensive.

IXFR — Incremental Zone Transfer

IXFR (Incremental Zone Transfer) sends only the changes since the secondary's last known serial number. This is far more efficient for large zones with frequent small updates.

Secondary → Primary:  IXFR request for example.com (I have serial 2026031801)
Primary → Secondary:  [deleted records from serial 2026031801, added records up to serial 2026031802]

IXFR requires the primary to maintain a history of changes. If the primary cannot provide an incremental update (for example, because too many changes have occurred), it falls back to a full AXFR.

NOTIFY — Instant Change Alerts

Without NOTIFY, secondaries only learn about changes when their SOA refresh timer expires. DNS NOTIFY (RFC 1996) lets the primary immediately inform secondaries that the zone has changed:

1. An administrator changes a record on the primary
2. The primary increments the SOA serial number
3. The primary sends a NOTIFY message to each secondary listed in its configuration
4. Each secondary responds by checking the SOA serial and initiating a transfer if needed

NOTIFY dramatically reduces the propagation delay between a zone change and secondary synchronization — from potentially hours (waiting for the refresh interval) down to seconds.

NOTIFY messages are sent over UDP by default. If a secondary doesn't acknowledge, the primary retries several times before giving up. Make sure your firewall allows UDP port 53 between primary and secondary servers.

SOA Record and Transfer Timing

The SOA record contains five fields that directly control how secondaries behave:

The refresh and retry values work as a polling fallback when NOTIFY is not in use or fails. The expire value is a safety net — if the secondary cannot reach the primary for the entire expire period, it stops answering queries for the zone rather than serving dangerously stale data.

Why Use Secondary DNS?

Redundancy and Uptime

If your only nameserver goes offline, every service on your domain becomes unreachable — website, email, API, everything. Secondary DNS servers continue answering queries even when the primary is down. This is the most fundamental reason to deploy secondaries.

Registrar and TLD Requirements

Most domain registrars require at least two nameservers when delegating a domain. Many TLD registries (such as .com, .net, .org) enforce this at the registry level. You cannot operate a domain on the public internet with a single nameserver in most cases.

Geographic Distribution

Placing secondary servers in different geographic regions reduces query latency for users worldwide. A resolver in Tokyo will get faster answers from a secondary in Asia than from a primary in Europe. This is especially effective when combined with anycast routing.

DDoS Resilience

Distributing DNS across multiple servers makes it harder for attackers to take down your entire DNS infrastructure. Even if one server is overwhelmed by a DDoS attack, the others continue operating. More servers across more networks means a larger attack surface that an attacker must cover.

Load Distribution

Multiple authoritative servers share the query load. Resolvers pick nameservers based on response time, naturally distributing traffic across your primary and secondaries.

Primary vs Secondary Comparison

The Hidden Primary Pattern

In a hidden primary (also called a "stealth primary") setup, the primary server is not listed in the zone's public NS records. Only secondary servers are advertised to the internet:

; Public NS records — only secondaries
example.com.  86400  IN  NS  ns1.dnscale.eu.
example.com.  86400  IN  NS  ns2.dnscale.eu.
 
; Hidden primary (not in NS records)
; internal-dns.yourcompany.com — only secondaries can reach it

Benefits of a hidden primary:

• The primary is not exposed to direct queries or attacks from the internet
• You can run the primary on internal infrastructure behind a firewall
• Secondaries handle all public query load
• You maintain full control over your zone data on your own servers

This pattern is common in enterprise environments and is the standard approach for multi-provider DNS deployments.

Multi-Provider Secondary DNS

Running secondaries across multiple DNS providers eliminates provider-level single points of failure. If one provider has an outage, the other continues serving your zone.

A typical multi-provider setup:

Primary:    Your own server or DNScale (hidden or public)
Provider A: ns1.dnscale.eu, ns2.dnscale.eu
Provider B: ns1.anotherprovider.com, ns2.anotherprovider.com

Both providers receive zone data from the primary via AXFR/IXFR. Your registrar's NS records point to nameservers from both providers. Resolvers worldwide query whichever set responds fastest.

Multi-provider DNS requires careful TTL alignment across providers. Use identical TTL values on both sides to avoid inconsistent caching behavior.

For a step-by-step guide to deploying DNS across multiple providers, see Multi-Provider DNS Deployment.

TSIG Authentication for Zone Transfers

Unrestricted zone transfers expose your entire zone to anyone who asks. TSIG (Transaction Signature) authenticates zone transfer requests using a shared secret, ensuring only authorized secondaries can pull your zone data.

TSIG uses HMAC-based signatures with a shared key:

; TSIG key definition
key "transfer-key" {
    algorithm hmac-sha256;
    secret "dGhpcyBpcyBhIGJhc2U2NCBlbmNvZGVkIHNlY3JldA==";
};
 
; Primary: allow transfers only with this key
zone "example.com" {
    type master;
    allow-transfer { key "transfer-key"; };
    also-notify { 198.51.100.10; };
};
 
; Secondary: use this key when requesting transfers
zone "example.com" {
    type slave;
    masters { 203.0.113.5 key "transfer-key"; };
};

Always use hmac-sha256 or stronger for TSIG keys. Older algorithms like hmac-md5 are deprecated and should not be used.

TSIG is essential in multi-provider setups where zone transfers traverse the public internet. DNScale supports TSIG authentication for both inbound and outbound zone transfers.

Setting Up Secondary DNS

Step 1: Configure AXFR on the Primary

On your primary server, allow zone transfers to your secondary's IP addresses:

; BIND-style configuration on the primary
zone "example.com" {
    type master;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { 198.51.100.10; 198.51.100.11; };
    also-notify { 198.51.100.10; 198.51.100.11; };
};

For PowerDNS:

# pdns.conf
allow-axfr-ips=198.51.100.10,198.51.100.11
also-notify=198.51.100.10,198.51.100.11

Step 2: Configure the Secondary

On the secondary, point it to the primary:

; BIND-style configuration on the secondary
zone "example.com" {
    type slave;
    masters { 203.0.113.5; };
    file "/var/cache/bind/example.com.zone";
};

Step 3: Verify the Transfer

After configuring both sides, test the transfer manually:

# Request a full zone transfer
dig @203.0.113.5 example.com AXFR
 
# Check that the secondary has the zone
dig @198.51.100.10 example.com SOA +short

Both servers should return the same SOA serial number.

Verifying Zone Consistency with dig

Keeping primary and secondary in sync is critical. Use dig to verify:

Check SOA Serial Across All Nameservers

# Compare serial numbers
dig +short SOA example.com @ns1.dnscale.eu
dig +short SOA example.com @ns2.dnscale.eu
 
# Expected output (serials should match):
# ns1.dnscale.eu. admin.example.com. 2026031802 3600 900 1209600 300
# ns1.dnscale.eu. admin.example.com. 2026031802 3600 900 1209600 300

Test AXFR Manually

# Request a full zone transfer (must be allowed by the primary)
dig @primary-server.example.com example.com AXFR
 
# If TSIG is required:
dig @primary-server.example.com example.com AXFR -y hmac-sha256:transfer-key:base64secret

Verify a Specific Record on All Servers

# Query each nameserver for the same record
dig +short A www.example.com @ns1.dnscale.eu
dig +short A www.example.com @ns2.dnscale.eu

If results differ, the secondary may not have received the latest transfer. Check the SOA serial and review transfer logs.

Common Mistakes

SOA Serial Not Incrementing

If you edit the zone file manually and forget to increment the serial number, secondaries will not detect the change. They compare their serial with the primary's — if the numbers match, no transfer occurs. DNScale handles serial management automatically, but this is a frequent issue with manually managed zones.

Firewall Blocking AXFR on TCP Port 53

Zone transfers use TCP on port 53, not UDP. A common misconfiguration is allowing UDP 53 (for normal queries) but blocking TCP 53 (needed for transfers). Ensure your firewall rules allow TCP 53 between primary and secondary servers.

# Test TCP connectivity to the primary
dig @203.0.113.5 example.com AXFR +tcp

If this times out but normal queries work, TCP port 53 is likely blocked.

TSIG Key Mismatch

Both primary and secondary must use the exact same key name, algorithm, and secret. A single character difference in the base64-encoded secret will cause every transfer to fail with a BADKEY or BADSIG response. Double-check the key on both sides.

Expire Timer Too Short

If the SOA expire value is too low and the primary goes down for maintenance, secondaries will stop serving the zone prematurely. A 2-week expire (1209600 seconds) gives you ample time to restore the primary. Setting expire to just a few hours means a brief outage could cascade into a complete DNS failure.

Not Using NOTIFY

Without NOTIFY, secondaries only check for changes at the refresh interval (typically 1 hour). This means a DNS change could take up to an hour to reach secondaries. Always configure NOTIFY for timely propagation.

How DNScale Handles Secondary DNS

DNScale takes a modern approach to zone replication that goes beyond traditional AXFR/IXFR:

• Internal replication uses PostgreSQL logical replication to synchronize zone data to all edge nodes in near real-time — no polling delays
• AXFR/IXFR support lets you use DNScale as a secondary (pulling from your primary) or configure external secondaries to pull from DNScale
• TSIG support secures zone transfers in multi-provider configurations
• Anycast network serves your zone from geographically distributed edge nodes, providing the redundancy benefits of multiple secondaries without manual configuration

When you create a zone on DNScale, it is automatically served from all edge nodes. Traditional secondary configuration is only needed if you want to integrate DNScale with another provider or your own infrastructure.

For multi-provider setups using infrastructure-as-code tools, see the Multi-Provider DNS Deployment guide.

Related Topics

• What Is DNS — how the Domain Name System works
• DNS Record Types — overview of all record types
• What Is an NS Record — NS records delegate authority to nameservers
• What Is a DNS Zone — zones and their structure
• What Is an SOA Record — SOA controls zone transfer timing
• What Is Secondary DNS — deep dive on secondary DNS concepts
• Multi-Provider DNS Deployment — redundancy across providers with Terraform and DNSControl
• Anycast DNS Network — geographic distribution and low-latency DNS
• DNS Propagation Explained — why DNS changes take time to spread
• DNS TTL Best Practices — choosing the right TTL values
• DNS Attacks and Threats — DDoS, cache poisoning, and other attacks
• Types of DNS Servers — recursive, authoritative, root, and TLD servers
• Zone Import Methods — migrating zones into DNScale
• DNSSEC Key Management — securing DNS with cryptographic signatures
• System Records — why SOA and apex NS records are protected

Conclusion

Primary and secondary DNS form the foundation of a reliable DNS infrastructure. The primary holds the editable copy of your zone; secondaries hold synchronized read-only copies and continue serving queries when the primary is unavailable. Zone transfers (AXFR for full copies, IXFR for incremental updates) keep everything in sync, while NOTIFY ensures changes propagate quickly. TSIG protects transfers from unauthorized access. Whether you run a simple two-server setup or a multi-provider deployment across continents, understanding the primary-secondary relationship is essential to keeping your domains online and responsive.