# Zone transfers and NOTIFY: how secondary name servers stay in step

> Every DNS zone has to be served by at least two authoritative servers, and their copies have to agree. After reading you will be able to read the timers in a zone's SOA record and predict when a secondary polls, recognise an AXFR, IXFR or NOTIFY exchange in a packet capture, explain why transfers are restricted and encrypted, and check with dig whether a zone's servers carry the same serial.

Source: https://ronutz.com/en/learn/dns-zone-transfers-and-notify  
Updated: 2026-10-13  
Related tools: https://ronutz.com/en/tools/dig-command-builder, https://ronutz.com/en/tools/dig-output-explainer

---

The Domain Name System (DNS) requires every zone to live on more than one authoritative server, and the copies have to agree. A **zone transfer** is "The act of a client requesting a copy of a zone and an authoritative server sending the needed information" ([RFC 9499, section 6](https://www.rfc-editor.org/rfc/rfc9499#section-6)), whole (AXFR, "Authoritative Transfer") or incremental (IXFR, "Incremental Transfer"); NOTIFY announces that a change has happened. Their goal is "to enable a set of DNS name servers to remain coherently authoritative for a given zone" ([RFC 5936, section 1](https://www.rfc-editor.org/rfc/rfc5936#section-1)). After reading, you will be able to read the timers of an SOA (start of zone authority) record, recognise a transfer or a NOTIFY in a capture, explain why transfers are restricted and encrypted, and compare serials with dig.

## Why a zone is copied, and what the copies are called

RFC 1034: "we require every zone to be available on at least two servers", so that it survives "host or communication link failure" ([RFC 1034, section 4.1](https://www.rfc-editor.org/rfc/rfc1034#section-4.1)). RFC 2182, a Best Current Practice (BCP 16), recommends "that three servers be provided for most organisation level zones, with at least one which must be well removed from the others" ([RFC 2182, section 5](https://www.rfc-editor.org/rfc/rfc2182#section-5)).

The copies are not equals: "one of the name servers is the master or primary for the zone", and "The other non-master or secondary servers for the zone periodically check for changes" ([RFC 1034, section 4.3.5](https://www.rfc-editor.org/rfc/rfc1034#section-4.3.5)). The **primary** is "the server where the data is entered into the DNS from some source outside the DNS" ([RFC 2182, section 3](https://www.rfc-editor.org/rfc/rfc2182#section-3)).

A common belief is wrong: RFC 1034 and RFC 1035 never use the word "slave". RFC 1035 says "a primary name server" and "Designated secondary servers" ([RFC 1035, section 2.2](https://www.rfc-editor.org/rfc/rfc1035#section-2.2)). Master and Slave were defined by RFC 1996 in 1996 ([RFC 1996, section 2](https://www.rfc-editor.org/rfc/rfc1996#section-2)); RFC 2182 lists them as alternatives, "Sometimes known as a Master server" ([RFC 2182, section 2](https://www.rfc-editor.org/rfc/rfc2182#section-2)); RFC 9499 (2024) records that "the current common usage has shifted to calling it a "secondary"" ([RFC 9499, section 6](https://www.rfc-editor.org/rfc/rfc9499#section-6)); BIND accepts both, "primary (or master), secondary (or slave)" ([BIND 9 Administrator Reference Manual (ARM), Configuration Reference](https://bind9.readthedocs.io/en/latest/reference.html)).

## The SOA record, field by field

The zone's SOA record holds the schedule; RFC 1035 defines its seven RDATA fields, the last a TTL (time-to-live), and says "All times are in units of seconds" ([RFC 1035, section 3.3.13](https://www.rfc-editor.org/rfc/rfc1035#section-3.3.13)).

| Field | Size | Meaning (RFC 1035, section 3.3.13) |
|---|---|---|
| MNAME | domain name | The name server that was "the original or primary source of data for this zone" |
| RNAME | domain name | "the mailbox of the person responsible for this zone" |
| SERIAL | 32 bits, unsigned | The "version number of the original copy of the zone"; "Zone transfers preserve this value" |
| REFRESH | 32 bits | "time interval before the zone should be refreshed" |
| RETRY | 32 bits | Interval "before a failed refresh should be retried" |
| EXPIRE | 32 bits | "upper limit on the time interval that can elapse before the zone is no longer authoritative" |
| MINIMUM | 32 bits, unsigned | "minimum TTL field that should be exported with any RR from this zone" (the 1987 meaning) |

MINIMUM changed meaning twice. RFC 1035: "a lower bound on the TTL field for all RRs in a zone" (same section). RFC 1912 (1996): "servers seem to always implement this as the default value" ([RFC 1912, section 2.2](https://www.rfc-editor.org/rfc/rfc1912#section-2.2)). RFC 2308 (1998): the lower-bound meaning "is hereby deprecated", the default TTL moved to a new `$TTL` directive, and "the TTL to be used for negative responses" became the field's "new defined meaning" ([RFC 2308, section 4](https://www.rfc-editor.org/rfc/rfc2308#section-4)). That meaning is in force: a negative answer carries the SOA in its authority section with a TTL "set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself" ([RFC 2308, section 3](https://www.rfc-editor.org/rfc/rfc2308#section-3)).

## The refresh cycle as a secondary runs it

RFC 1034 sets the loop: the secondary "waits REFRESH seconds before checking with the primary for a new serial", with "a simple query to the primary for the SOA RR of the zone"; equal serials restart the wait; "If this check cannot be completed, new checks are started every RETRY seconds"; and after EXPIRE seconds without a check "it must assume that its copy of the zone is obsolete an discard it" (sic) ([RFC 1034, section 4.3.5](https://www.rfc-editor.org/rfc/rfc1034#section-4.3.5)). An expired copy answers "as if it were not supposed to possess the zone" ([RFC 1035, section 6.3](https://www.rfc-editor.org/rfc/rfc1035#section-6.3)).

The serial "is always advanced whenever any change is made to the zone", by "a simple increment" or from "the write date and time of the master file" ([RFC 1034, section 4.3.5](https://www.rfc-editor.org/rfc/rfc1034#section-4.3.5)); RFC 1912's "recommended syntax is YYYYMMDDnn" is a convention, not a rule ([RFC 1912, section 2.2](https://www.rfc-editor.org/rfc/rfc1912#section-2.2)). RFC 1035's "sequence space arithmetic" "is not defined in either RFC1034 or RFC1035" ([RFC 1982, section 1](https://www.rfc-editor.org/rfc/rfc1982#section-1)), so RFC 1982 defined serial number arithmetic: addition, where "The maximum defined increment is 2147483647 (2^31 - 1)" ([RFC 1982, section 7](https://www.rfc-editor.org/rfc/rfc1982#section-7)), and comparison, where s1 is less than s2 when `(i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))` ([RFC 1982, section 3.2](https://www.rfc-editor.org/rfc/rfc1982#section-3.2)). In the 8-bit example "0 > 255": "Incrementing a serial number can cause it to become "smaller"" ([RFC 1982, section 5.2](https://www.rfc-editor.org/rfc/rfc1982#section-5.2)), and that is the only way down: "Never simply decrease the serial number. Secondary servers will ignore that change" ([RFC 2182, section 7](https://www.rfc-editor.org/rfc/rfc2182#section-7)).

## AXFR: the whole zone over TCP

AXFR, query type 252, "A request for a transfer of an entire zone", dates from RFC 1035 ([RFC 1035, section 3.2.3](https://www.rfc-editor.org/rfc/rfc1035#section-3.2.3)); RFC 5936 (2010) re-specified it ([RFC 5936, section 1](https://www.rfc-editor.org/rfc/rfc5936#section-1)). Transport is TCP (Transmission Control Protocol) "on server port 53" ([RFC 1035, section 4.2](https://www.rfc-editor.org/rfc/rfc1035#section-4.2)): "Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests" ([RFC 1034, section 4.3.5](https://www.rfc-editor.org/rfc/rfc1034#section-4.3.5)).

| Part | Fields | AXFR query (RFC 5936, sections 2.1.1, 2.1.2 and 2.1.5) |
|---|---|---|
| Header | QR, OPCODE, RCODE | "MUST be 0 (Query)", "MUST be 0 (Standard Query)", "MUST be 0 (No error)" |
| Header | QDCOUNT, ANCOUNT, NSCOUNT | "MUST be 1", "MUST be 0", "MUST be 0" |
| Question | QNAME, QTYPE, QCLASS | "the name of the zone requested", "AXFR (= 252), the pseudo-RR type for zone transfer", "the class of the zone requested" |
| Additional | OPT, TSIG or SIG(0) | Optional: "The client MAY include one OPT resource record" and "one transaction integrity and authentication resource record" |

The response is "a series (which could be a series of length 1) of DNS messages. In such a series, the first message MUST begin with the SOA resource record of the zone, and the last message MUST conclude with the same SOA resource record. Intermediate messages MUST NOT contain the SOA resource record" ([RFC 5936, section 2.2](https://www.rfc-editor.org/rfc/rfc5936#section-2.2)). Implementations "SHOULD provide means to restrict AXFR sessions to specific clients", by address, TSIG ("Secret Key Transaction Authentication for DNS") or SIG(0), and "SHOULD NOT have a default policy for AXFR requests to be "open to all"" ([RFC 5936, section 5](https://www.rfc-editor.org/rfc/rfc5936#section-5)). RFC 5936 never cites RFC 1982 for the serial comparison; RFC 9103 does: "If the primary serial is higher than the secondary's serial (using Serial Number Arithmetic [RFC1982]), the secondary makes an AXFR request (over TCP) to the primary" ([RFC 9103, section 5.1](https://www.rfc-editor.org/rfc/rfc9103#section-5.1)).

## IXFR: only the records that changed

AXFR "is not an efficient means to propagate changes to a small part of a zone", so RFC 1995 (1996) defined IXFR, query type 251 ([RFC 1995, section 1](https://www.rfc-editor.org/rfc/rfc1995#section-1)). The query carries "the SOA record of client's version of the zone" in its authority section ([RFC 1995, section 3](https://www.rfc-editor.org/rfc/rfc1995#section-3)); the server sends "only the differences required to make that version current" ([RFC 1995, section 2](https://www.rfc-editor.org/rfc/rfc1995#section-2)). The answer is "preceded and followed by a copy of the server's current version of the SOA", and in each difference sequence "The first RR of the deleted RRs is the older SOA RR and the first RR of the added RRs is the newer SOA RR" ([RFC 1995, section 4](https://www.rfc-editor.org/rfc/rfc1995#section-4)). RFC 1995's example, client at serial 1, server at serial 3 ([RFC 1995, section 7](https://www.rfc-editor.org/rfc/rfc1995#section-7)):

| Answer section, in order | Role |
|---|---|
| JAIN.AD.JP. IN SOA serial=3 | opening bracket |
| JAIN.AD.JP. IN SOA serial=1 | older SOA, first change |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 | deleted |
| JAIN.AD.JP. IN SOA serial=2 | newer SOA, first change |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | added |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | added |
| JAIN.AD.JP. IN SOA serial=2 | older SOA, second change |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | deleted |
| JAIN.AD.JP. IN SOA serial=3 | newer SOA, second change |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | added |
| JAIN.AD.JP. IN SOA serial=3 | closing bracket |

Without history, the server should "attempt to perform a full zone transfer" ([RFC 1995, section 6](https://www.rfc-editor.org/rfc/rfc1995#section-6)). RFC 1995 says "a client should first make an IXFR query using UDP" (User Datagram Protocol; section 2), while RFC 9103 records that "most of the widely used open-source implementations of authoritative name servers (including both [BIND] and [NSD]) do IXFR using TCP by default in their latest releases" ([RFC 9103, section 5.2](https://www.rfc-editor.org/rfc/rfc9103#section-5.2)).

## NOTIFY: a hint, not a transfer

RFC 1996 (1996) added "an interrupt as opposed to poll model" ([RFC 1996, section 1](https://www.rfc-editor.org/rfc/rfc1996#section-1)) with a new opcode, "NOTIFY (4)". "The only defined NOTIFY event at this time is that the SOA RR has changed" ([RFC 1996, section 3](https://www.rfc-editor.org/rfc/rfc1996#section-3)).

| Field | Request (RFC 1996, section 4.5) | Response (RFC 1996, section 4.7) |
|---|---|---|
| query ID | "(new)" | "(same)" |
| op | "NOTIFY (4)" | "NOTIFY (4)" |
| resp | "NOERROR" | "NOERROR" |
| flags | "AA" | "QR AA" |
| qcount | "1" | "1" |
| qname, qclass, qtype | "(zone name)", "(zone class)", "T_SOA" | identical to the request |

The **Notify Set** is by default "all servers named in the NS RRset, except for any server also named in the SOA MNAME" ([RFC 1996, section 2](https://www.rfc-editor.org/rfc/rfc1996#section-2)).

A NOTIFY is a hint, never the data: "In no case shall the answer section of a NOTIFY request be used to update a slave's local data, or to indicate that a zone transfer needs to be undertaken, or to change the slave's zone refresh timers" ([RFC 1996, section 3](https://www.rfc-editor.org/rfc/rfc1996#section-3)). The recipient "should behave as though the zone given in the QNAME had reached its REFRESH interval" and, after comparing serials, start "a zone transfer (either AXFR or IXFR)" (same section). On whom to ask, the RFC and BIND differ: RFC 1996 directs the SOA query "at the known master who was the source of the NOTIFY event" (section 3), while in BIND "named does not first query the sender of the notify. It will continue with the next server in the list that transferred the zone" ([BIND 9 ARM, Configuration Reference, "type secondary"](https://bind9.readthedocs.io/en/latest/reference.html)).

## XoT: why a cleartext transfer leaks the zone

"DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections", and TSIG "does not add confidentiality" ([RFC 9103, Abstract](https://www.rfc-editor.org/rfc/rfc9103)). RFC 9103 (2021) answers with **XoT**, XFR (zone transfer) over TLS (Transport Layer Security) ([RFC 9103, section 2](https://www.rfc-editor.org/rfc/rfc9103#section-2)). Implementations "MUST use only TLS 1.3 [RFC8446] or later" ([RFC 9103, section 7.2](https://www.rfc-editor.org/rfc/rfc9103#section-7.2)); the connection "SHOULD be established using port 853, as specified in [RFC7858]" ([RFC 9103, section 7.3](https://www.rfc-editor.org/rfc/rfc9103#section-7.3)). "The client MUST authenticate the server by use of an authentication domain name using a Strict Privacy profile", and "The server MUST validate the client is authorized" by mutual TLS (mTLS) or by "an IP-based ACL (which can be either per message or per connection) combined with a valid TSIG/SIG(0) signature on the XFR request"; "If only one method is selected, then mTLS is preferred" ([RFC 9103, section 7.5](https://www.rfc-editor.org/rfc/rfc9103#section-7.5)). XoT is not DNS over TLS for authoritative servers: answering "all queries received over TLS just because it has enabled XoT would be equivalent to defining a form of authoritative DoT. This specification does not propose that" ([RFC 9103, section 7.7](https://www.rfc-editor.org/rfc/rfc9103#section-7.7)).

## Configuring, restricting and checking transfers

In BIND the mechanisms become a few statements, here from the ARM for the 9.21.28-dev development build, read 2026-10-13 ([BIND 9 ARM, Configuration Reference](https://bind9.readthedocs.io/en/latest/reference.html)).

| Statement | What it does (BIND 9 ARM, Configuration Reference) |
|---|---|
| `primaries` | "Defines one or more servers that zone transfer can be requested from", each with an optional TSIG `key` and `tls` configuration |
| `allow-transfer` | Hosts "allowed to transfer the zone information from this server"; default "none; outgoing zone transfers are disabled"; for example `allow-transfer port 853 transport tls { any; };` |
| `notify`, `also-notify` | "Controls whether NOTIFY(SOA) messages are sent on zone changes"; default `yes`, to the NS servers "except the primary server identified in the SOA MNAME field" plus the `also-notify` list |

The default of `none` makes RFC 5936's "SHOULD NOT have a default policy for AXFR requests to be "open to all"" concrete. And since "incoming TLS connections are not authenticated at the TLS level by default" (same page), TSIG or mutual TLS is still needed.

To check by hand, repeat the secondary's check: `dig +norecurse SOA` for the zone at each server in its NS set (see the [dig command builder](https://ronutz.com/en/tools/dig-command-builder) and [dig output explainer](https://ronutz.com/en/tools/dig-output-explainer)), then compare the SERIALs. Equal: in step. Smaller on a secondary: not yet polled or notified, or a transfer that failed ("The AXFR may cause an error, such as refused", [RFC 1034, section 4.3.5](https://www.rfc-editor.org/rfc/rfc1034#section-4.3.5)). "greater" than the primary's: the RFC 1982 trap. In a capture ([header and flags](https://ronutz.com/en/learn/dns-message-header-and-flags)), AXFR is TCP to port 53, QTYPE 252, an answer from one SOA to the same SOA; IXFR is QTYPE 251, the client's SOA in the query's authority section, two SOAs opening the answer; NOTIFY is opcode 4, QTYPE SOA, flag AA, normally UDP ([RFC 1996, section 3](https://www.rfc-editor.org/rfc/rfc1996#section-3)), answered with QR set and the same ID.

## What to remember

- Every zone must be on at least two servers; RFC 2182 recommends three, one well removed from the others.
- The primary is where data enters the DNS; secondaries copy it, and the words master and slave came from RFC 1996, not from RFC 1034 or RFC 1035.
- A secondary polls the primary's SOA every REFRESH seconds, retries every RETRY seconds after a failure, and drops the zone after EXPIRE seconds; serials follow RFC 1982 arithmetic and never decrease.
- AXFR runs over TCP and its answer begins and ends with the zone's SOA; IXFR sends deletion and addition blocks, each introduced by an SOA, and falls back to AXFR without history.
- NOTIFY (opcode 4) only tells a secondary to check the SOA now; XoT wraps the transfer in TLS 1.3 on port 853 with both ends authenticated.

## Sources

- [RFC 1034, Domain names - concepts and facilities, November 1987: sections 4.1 and 4.3.5 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc1034)
- [RFC 1035, Domain names - implementation and specification, November 1987: sections 2.2, 3.2.3, 3.3.13, 4.2 and 6.3 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc1035)
- [RFC 1912, Common DNS Operational and Configuration Errors, February 1996, Informational: section 2.2 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc1912)
- [RFC 1982, Serial Number Arithmetic, August 1996: sections 1, 3.2, 5.2 and 7 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc1982)
- [RFC 1995, Incremental Zone Transfer in DNS, August 1996: sections 1 to 7 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc1995)
- [RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY), August 1996: sections 1 to 4 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc1996)
- [RFC 2182, Selection and Operation of Secondary DNS Servers, July 1997, BCP 16: sections 2, 3, 5 and 7 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc2182)
- [RFC 2308, Negative Caching of DNS Queries (DNS NCACHE), March 1998: sections 3 and 4 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc2308)
- [RFC 5936, DNS Zone Transfer Protocol (AXFR), June 2010: sections 1, 2.1, 2.2 and 5 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc5936)
- [RFC 9103, DNS Zone Transfer over TLS, August 2021: Abstract and sections 2, 5.1, 5.2 and 7 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc9103)
- [RFC 9499, DNS Terminology, March 2024, BCP 219: section 6 (read 2026-10-13)](https://www.rfc-editor.org/rfc/rfc9499)
- [BIND 9 Administrator Reference Manual, 9.21.28-dev documentation, chapter 8, Configuration Reference: type, primaries, allow-transfer, notify, also-notify (vendor documentation, read 2026-10-13)](https://bind9.readthedocs.io/en/latest/reference.html)