Demystifying DNS Zones and Zone Transfers

DNS often feels like a single global database, but behind the scenes it is a carefully divided system. Responsibility is split into zones, each zone is served by several authoritative servers, and those servers stay in sync through a mechanism called the zone transfer. Understanding these pieces helps you troubleshoot propagation delays, choose a reliable DNS setup and avoid one of the most common information leaks on the internet: an unrestricted zone transfer. This article walks through the concepts and finishes with practical configuration and testing examples.

Zones versus domains: not the same thing

A domain is a node in the DNS tree together with everything beneath it. example.com is a domain, and so is shop.example.com. A zone is an administrative boundary: the part of the namespace that is managed as one unit and published by one set of authoritative name servers.

Often a domain and its zone look identical. A small business might keep every record for example.com in one zone file. But when part of the tree is delegated, the boundaries diverge. If eu.example.com is handed to a different team with its own name servers, the parent zone keeps only NS records (and possibly glue addresses) pointing to them, and eu.example.com becomes a separate zone. The domain example.com still includes eu.example.com, but the zone does not.

The same logic applies at the top: the root zone delegates .com, the .com zone delegates example.com to the name servers registered by its owner, and so on. When you look up a domain with the TLDix WHOIS and RDAP lookup, the name servers you see are exactly that delegation from the registry.

What lives inside a zone

A zone is a collection of resource records. The most common are listed below.

Every zone has exactly one SOA record at its apex, and at least one, usually two or more, NS records.

The SOA record and its serial number

The Start of Authority record describes how the zone should be maintained. A typical SOA looks like this in a zone file:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
              2026100701 ; serial
              7200       ; refresh
              900        ; retry
              1209600    ; expire
              300 )      ; negative caching TTL

• MNAME (ns1.example.com.) names the primary server.
• RNAME (hostmaster.example.com.) is the administrator mailbox, with the first dot standing in for the @ sign.
• Serial is a version number for the zone. Secondaries compare it with their own copy; if the primary has a higher serial, they transfer the zone.
• Refresh is how often secondaries check the serial.
• Retry is how long they wait before trying again after a failed check.
• Expire is how long a secondary keeps answering if it cannot reach the primary at all. After that it stops serving the zone rather than give stale answers.
• Minimum is now used as the TTL for negative answers such as NXDOMAIN (RFC 2308).

A popular convention is a date-based serial in the form YYYYMMDDnn, such as 2026100701 for the first change on 7 October 2026. The most common mistake in hand-edited zones is forgetting to increase the serial: the primary serves the new data, but the secondaries never fetch it, so users get different answers depending on which server they reach. Serial numbers use sequence-space arithmetic (RFC 1982), so if you ever need to decrease one, it must be done in planned steps rather than by simply typing a smaller number.

Primary and secondary servers

Most zones are published by several authoritative servers for resilience and performance. One is the primary (historically called master), where the zone is edited or generated, for example from a database or a provider API. The others are secondaries (historically slaves), which hold read-only copies obtained from the primary.

From the point of view of a resolver, all authoritative servers listed in the NS records are equal. It may ask any of them. That is why consistency matters: if one secondary lags behind, part of your traffic sees outdated records. Many organisations use a hidden primary, a server that is not listed in the public NS records and only feeds the secondaries, which reduces its exposure to attacks.

Using secondaries from a different provider or network is also a classic way to survive outages, since a failure at one provider no longer takes the whole zone offline.

Full transfers (AXFR) and incremental transfers (IXFR)

When a secondary needs data, it requests a zone transfer over TCP.

AXFR: the whole zone

AXFR, standardised in RFC 5936, sends every record in the zone, beginning and ending with the SOA record. It is simple and robust, and it is always used when a secondary has no copy yet. For large zones, though, repeating a full copy after every small change wastes bandwidth and time.

IXFR: only what changed

IXFR, defined in RFC 1995, lets the secondary send its current serial and receive only the differences: records deleted and records added between versions. The primary needs to keep a journal of recent changes to do this. If it cannot produce the differences, for example because the journal was cleared, it falls back to sending a full zone.

NOTIFY: no more waiting for the refresh timer

Relying only on the refresh interval would mean changes can take hours to reach secondaries. The DNS NOTIFY mechanism, described in RFC 1996, solves this. When the zone changes, the primary sends a NOTIFY message to its secondaries. Each secondary then queries the SOA, sees the higher serial and starts an IXFR or AXFR immediately. In practice this brings secondary updates down to seconds. Refresh still acts as a safety net in case a NOTIFY is lost.

Keep in mind that this is different from what people call propagation. Once all authoritative servers are in sync, the remaining delay comes from resolvers around the world caching older records until their TTL expires.

Why open zone transfers are a problem

If a server allows AXFR to anyone, anyone can download the full contents of the zone. That may reveal internal host names, staging systems, VPN endpoints, mail infrastructure and naming patterns, information that makes reconnaissance trivial. This misconfiguration still appears on the internet, often left over from defaults or old setups. The rule is simple: only your own secondaries should be allowed to transfer the zone.

IP-based restrictions are a good first step, but IP addresses can change or be shared. TSIG adds authentication on top.

Securing transfers with ACLs and TSIG

TSIG (Transaction Signature, RFC 8945) uses a shared secret key and an HMAC algorithm such as HMAC-SHA256 to sign DNS messages. The primary only answers transfer requests signed with the right key, and the secondary can verify that the data really came from the primary and was not altered in transit. TSIG does not encrypt the zone; for confidentiality, newer standards such as XoT (zone transfer over TLS, RFC 9103) can be used where supported.

A key is typically generated with tsig-keygen in BIND. The resulting configuration on the primary might look like this:

key "xfer-key" {
    algorithm hmac-sha256;
    secret "REPLACE-WITH-GENERATED-SECRET";
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.db";
    allow-transfer { key "xfer-key"; };
    also-notify { 198.51.100.20; };
    notify yes;
};

And on the secondary:

key "xfer-key" {
    algorithm hmac-sha256;
    secret "REPLACE-WITH-GENERATED-SECRET";
};

server 192.0.2.10 { keys { "xfer-key"; }; };

zone "example.com" {
    type secondary;
    primaries { 192.0.2.10; };
    file "/var/cache/bind/example.com.db";
};

Store the secret securely, rotate it when staff or providers change, and use a separate key per secondary relationship where practical. Older BIND versions use the keywords master and slave instead of primary and secondary; both are accepted in current releases.

Testing zone transfers with dig

After configuring restrictions, verify them from a machine that should not have access:

dig @ns1.example.com example.com AXFR

A correctly locked server answers with Transfer failed or a REFUSED status. From an authorised secondary, test with the key:

dig @192.0.2.10 example.com AXFR -y hmac-sha256:xfer-key:REPLACE-WITH-SECRET
dig @192.0.2.10 example.com IXFR=2026100701

To confirm that all authoritative servers are in sync, compare the serials:

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

If one server reports an older serial, check NOTIFY delivery, firewall rules for TCP port 53 and the logs on both sides. Only test transfers against servers you operate or have permission to test.

Keeping the whole picture healthy

Zones and transfers are only part of keeping a domain reachable. Delegation at the registry must point to the right name servers, DNSSEC signatures must stay valid (secondaries can serve signed zones, but the keys and DS record must match, as explained in why DNSSEC is essential for domain security), and the domain itself must not expire. Keeping your domains and their renewal dates in the TLDix domain panel makes it easier to spot problems before users do. With a clear SOA strategy, NOTIFY enabled, transfers restricted by TSIG and regular checks with dig, your DNS becomes both consistent and much harder to map from the outside.