Zone Transfers Explained: How AXFR and NOTIFY Keep Secondary Nameservers in Sync

The SOA record tracks a zone's serial number specifically so secondary nameservers can tell when they're out of date. That covers when a secondary knows it needs an update. This article covers how the actual copy of the zone gets there: AXFR, IXFR, and NOTIFY, the three mechanisms that keep a domain's nameservers in sync with each other.

Why domains have more than one nameserver

A domain's NS records almost always list two or more nameservers, often on different networks entirely, and for good reason: if a domain only had one nameserver and it went down, the domain would become unresolvable. Running multiple copies means a single outage doesn't take the whole domain offline. One of these nameservers is typically the source of truth, sometimes called the primary, and the others are secondaries that hold a synced copy of the same zone data. In most managed DNS setups today this distinction is invisible, since the provider replicates changes across their own anycast network automatically, but the underlying mechanism, a zone transfer, is the same one used when a domain deliberately runs secondary DNS through a separate provider.

AXFR: the full zone transfer

AXFR (Authoritative Transfer) is the original mechanism: a secondary nameserver asks the primary for a complete copy of every record in the zone, sent over TCP rather than DNS's usual UDP, since a full zone can be far larger than a single UDP packet allows. The secondary gets every record in one transfer and replaces its own copy entirely. It's simple and reliable, but for a large zone, transferring the entire thing for even a single-record change is wasteful.

IXFR: the incremental version

IXFR (Incremental Transfer) solves that inefficiency. Instead of the whole zone, the secondary tells the primary the serial number it currently has, and the primary sends back only the changes needed to bring that serial up to the current one: which records were added, changed, or removed since then. For a large zone with frequent small edits, this is a meaningfully smaller transfer than a full AXFR. If a primary can't compute an efficient incremental diff for some reason, it can fall back to a full AXFR instead, so IXFR support is a performance optimization layered on top of AXFR, not a full replacement for it.

NOTIFY: skipping the wait

Without NOTIFY, a secondary only finds out about a change when its own refresh timer (the SOA record's refresh interval, covered in the SOA article above) next elapses, which could be minutes or hours after the actual edit. NOTIFY closes that gap: as soon as the primary's zone changes, it sends a NOTIFY message directly to its secondaries, which prompts them to check the serial number and pull an update immediately rather than waiting out the refresh interval. This is what makes a zone edit on most managed providers propagate to all their edge locations within seconds rather than on whatever schedule the refresh interval happens to specify.

Why open zone transfers are a real risk

An AXFR response contains the entire zone: every hostname, every record, all in one readable transfer. If a nameserver answers an AXFR request from anyone who asks, not just its own known secondaries, that's a straightforward way for an outside party to enumerate a domain's complete internal DNS layout: internal-sounding hostnames, staging environments, third-party services in use, anything that was ever added as a record. None of that is necessarily sensitive on its own, but handing it to anyone who asks removes a layer of reconnaissance effort for an attacker for no operational benefit to you. This is why zone transfers should be restricted, typically to a specific allowlist of secondary IP addresses, or authenticated with TSIG (a shared-secret signing mechanism for zone transfer requests), rather than left open to any requester.

Checking whether your domain allows an open transfer

dig @ns1.example.com example.com AXFR

A properly restricted nameserver refuses this unless the request comes from an authorized secondary, typically responding with a REFUSED status rather than the zone data. If this command actually returns your full zone from a nameserver you don't control, that's worth fixing. Most reputable managed DNS providers restrict this by default, but it's worth confirming rather than assuming, particularly for self-managed BIND setups where it's an explicit configuration choice.

Where this comes up in practice

Most people using a single managed DNS provider never think about zone transfers, since the provider handles replication internally and doesn't expose the mechanism at all. It becomes relevant in a few specific situations: running secondary DNS through a separate provider for redundancy against a primary provider's outage, migrating a zone by transferring it directly between two DNS servers instead of manually re-entering every record, or troubleshooting a report from a security scan flagging an open AXFR response.

How DNS monitoring fits in

Zone transfers govern how nameservers within your own setup stay in sync with each other, which is a layer beneath what most monitoring tools, including OneDollarDNS, are built to watch. What monitoring does catch is the downstream effect: if one of your nameservers is serving different records than another because a transfer failed or lagged, querying your authoritative nameservers directly, the same approach covered in DNS Basics, surfaces that inconsistency instead of only seeing whichever nameserver happened to answer first.