DNS Replication: How It Works and How to Verify

DNS replication is the process of copying DNS zone data from one nameserver to another. When you update a DNS record on your primary nameserver, that change needs to reach all your secondary nameservers so they serve consistent answers. If replication fails, some nameservers serve stale data while others serve current data, leading to intermittent resolution failures and inconsistent behavior for your users.

Most DNS providers handle replication automatically and invisibly. But if you run your own nameservers, use multiple DNS providers, or need to troubleshoot why a DNS change is not taking effect everywhere, understanding how replication works is essential. For general DNS architecture, see DNS Resolution: How It Works.

Primary and Secondary Nameservers

The traditional DNS replication model uses a primary-secondary architecture (historically called master-slave, though modern documentation uses primary-secondary or leader-follower terminology).

Primary nameserver: The server where DNS records are created and modified. It holds the authoritative, editable copy of the zone.

Secondary nameserver: A server that receives a copy of the zone from the primary through zone transfers. It serves the same records as the primary but does not allow direct edits. Changes must be made on the primary and replicated to secondaries.

From the perspective of DNS resolvers querying your domain, primary and secondary nameservers are indistinguishable. Both serve authoritative answers. The primary/secondary distinction only matters for how the zone data is managed and distributed.

Zone Transfers: AXFR and IXFR

Zone transfers are the mechanism for replicating DNS data between servers.

AXFR (Full Zone Transfer)

AXFR transfers the entire zone file from the primary to the secondary. Every record in the zone is sent, regardless of what has changed.

# Requesting an AXFR (if permitted)
dig AXFR example.com @ns1.example.com

AXFR is simple and reliable. The secondary gets a complete, fresh copy of the zone. The downside is efficiency: for large zones with thousands of records, transferring the entire zone when only one record changed wastes bandwidth and processing time.

AXFR is defined in RFC 5936 (which updates the original specification in RFC 1035).

IXFR (Incremental Zone Transfer)

IXFR transfers only the records that have changed since the secondary's last update. The secondary tells the primary its current SOA serial number, and the primary responds with only the differences.

# Requesting an IXFR
dig IXFR=2024010101 example.com @ns1.example.com

IXFR is more efficient for large zones with frequent small changes. Instead of transferring 10,000 records because one A record changed, only the changed record is sent.

Not all DNS server software supports IXFR. If the primary cannot provide an incremental transfer (because it does not have the change history or does not support IXFR), it falls back to a full AXFR.

IXFR is defined in RFC 1995.

The SOA Record and Replication

The SOA (Start of Authority) record plays a central role in DNS replication. It contains fields that control how and when secondary nameservers check for updates.

example.com.    86400    IN    SOA    ns1.example.com. admin.example.com. (
    2024010101    ; serial
    3600          ; refresh
    900           ; retry
    1209600       ; expire
    300           ; minimum
)

Serial Number

The serial number is incremented every time the zone is updated. Secondary nameservers compare their serial number to the primary's serial number. If the primary has a higher serial, the secondary knows it needs to transfer the updated zone.

The convention is to use a date-based format (YYYYMMDDNN, where NN is a sequence number for multiple changes in a day), but the serial number can be any integer. The only requirement is that it increases with each change.

Refresh Interval

The refresh value (in seconds) tells secondary nameservers how often to check the primary for updates. A refresh of 3600 means secondaries check every hour. Lower values mean faster replication but more traffic to the primary.

Retry Interval

If a secondary fails to reach the primary during a refresh, the retry interval specifies how long to wait before trying again. This is typically shorter than the refresh interval.

Expire Time

If a secondary cannot reach the primary for the expire duration, it stops serving the zone entirely. This prevents secondaries from serving very stale data. The expire value is typically set to 1-2 weeks (604800-1209600 seconds).

Minimum TTL

This field sets the TTL for negative caching (NXDOMAIN responses). It does not directly affect replication.

DNS NOTIFY

The SOA refresh interval means there is always a delay between a change on the primary and the secondary checking for it. DNS NOTIFY (RFC 1996) reduces this delay by having the primary actively tell secondaries when the zone has changed.

When a zone is updated on the primary, it sends a NOTIFY message to all configured secondary nameservers. The secondaries immediately initiate a zone transfer rather than waiting for the next refresh interval.

NOTIFY does not replace the refresh mechanism. It supplements it. If a NOTIFY message is lost (UDP is unreliable), the secondary still picks up the change at the next refresh interval. NOTIFY just makes propagation faster in the common case.

Most modern DNS server software supports NOTIFY by default. BIND, PowerDNS, Knot DNS, and NSD all support sending and receiving NOTIFY messages.

Verifying Replication

When you make a DNS change and it does not seem to take effect, the issue is often replication. Here is how to verify that all your nameservers have consistent data.

Query Each Nameserver Directly

# Find all nameservers
dig NS example.com +short

# Query each one for the record in question
dig A www.example.com @ns1.dnsprovider.com +short
dig A www.example.com @ns2.dnsprovider.com +short
dig A www.example.com @ns3.dnsprovider.com +short

If all nameservers return the same value, replication is working. If one returns a different value, that server has stale data.

Check SOA Serial Numbers

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

The serial number should be identical across all nameservers. A lower serial on a secondary means it has not picked up the latest zone update.

Using DNS Propagation Checkers

Online tools like DNS propagation checkers query your domain from multiple locations around the world. While they primarily test caching at recursive resolvers, they can also reveal replication issues if your authoritative nameservers are serving different data.

For more on propagation vs replication, see DNS Propagation Explained and Check DNS Propagation.

Replication vs Propagation

These terms are often confused but refer to different things.

Replication is the copying of zone data from primary to secondary authoritative nameservers. This is a direct server-to-server process that you configure and control.

Propagation is the process of updated records spreading through the global DNS cache system. After your authoritative nameservers have the new data (replication is complete), recursive resolvers around the world still need to expire their cached copies and fetch the new records. Propagation depends on TTL values and is not something you directly control.

A change can replicate to all your nameservers in seconds but take hours to propagate through global caches. Conversely, if replication fails, propagation cannot deliver the update no matter how long you wait.

Modern DNS Replication Approaches

Managed DNS Providers

Most managed DNS providers (Cloudflare, Route 53, Google Cloud DNS, Dnsimple) use their own internal replication mechanisms, not traditional AXFR/IXFR zone transfers. When you update a record through their API or dashboard, the change propagates to their globally distributed nameserver network through proprietary replication systems.

These providers typically replicate changes within seconds to all their points of presence worldwide. The replication is handled entirely by the provider, and you do not need to configure primary/secondary relationships.

Multi-Provider Replication

For high-availability setups, some organizations use nameservers from two or more DNS providers simultaneously. Keeping the zone data synchronized across providers requires either:

• AXFR/IXFR between providers: Configure one provider as the primary and the other as a secondary that receives zone transfers. Not all managed DNS providers support being a secondary via zone transfer.
• API-based synchronization: Use a script or tool that updates both providers through their APIs whenever a change is made.
• DNS automation tools: Tools like OctoDNS, DNSControl, and Terraform can manage DNS records across multiple providers from a single source of truth.

For the strategy behind multi-provider DNS, see Multi-DNS Provider Strategy.

Securing Zone Transfers

Zone transfers expose your entire DNS zone, including every record and its value. Unsecured zone transfers allow anyone to enumerate your subdomains, discover internal services, and map your infrastructure.

Restricting AXFR by IP

Configure your nameserver to only allow zone transfers from known secondary nameserver IP addresses:

# BIND example
zone "example.com" {
    type master;
    allow-transfer { 192.0.2.1; 198.51.100.1; };
};

TSIG (Transaction Signatures)

TSIG (RFC 8945) adds cryptographic authentication to zone transfers. Both the primary and secondary share a secret key, and each zone transfer message is signed. This prevents unauthorized servers from requesting zone transfers even if they can reach the primary.

Testing Zone Transfer Restrictions

# Try an AXFR from an unauthorized IP
dig AXFR example.com @ns1.example.com

If zone transfers are properly restricted, this command should return a "Transfer failed" or "REFUSED" response when run from an unauthorized IP.

References

1. RFC 5936, "DNS Zone Transfer Protocol (AXFR)," June 2010. https://datatracker.ietf.org/doc/html/rfc5936
2. RFC 1995, "Incremental Zone Transfer in DNS," August 1996. https://datatracker.ietf.org/doc/html/rfc1995
3. RFC 1996, "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)," August 1996. https://datatracker.ietf.org/doc/html/rfc1996
4. RFC 8945, "Secret Key Transaction Authentication for DNS (TSIG)," November 2020. https://datatracker.ietf.org/doc/html/rfc8945