About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
When the primary name server disappears, the zone does not disappear with it. The secondary servers are authoritative too. They keep answering from the copy they already have. RFC 1034 then sets a clock. If a secondary cannot check the zone's serial with the primary for the whole expiry interval, it must treat its copy as obsolete and discard it. After that interval, affected secondaries stop serving the expired zone authoritatively. A saved disk copy may remain, and recursive caches can continue answering records until their own TTLs expire.
A replacement primary has a second clock, the serial number. In the normal SOA-check workflow, a secondary transfers a copy when its serial is newer under DNS serial-number arithmetic, not simply a larger unsigned integer. Restoring last month's zone file, with last month's serial, does not become the new authority. The secondaries already have something newer, or they will refuse to move.
This article is the recovery plan for those two rules. It is not a set of commands to promote a server. No name server was changed.
Why it matters
Resolvers do not know which authoritative server is the primary. BIND 9.20.30 says a primary reads the zone from a file, a secondary gets it by zone transfer, and both answer authoritatively. A resolver keeps a round-trip time for each listed server and prefers the fastest. It cannot tell, and is not supposed to tell, whether the answer came from the primary or a secondary. So the day the primary dies, lookups that hit a secondary still work. The monitoring that only asks "does the name resolve?" stays green.
What stops is everything that only the primary did. Edits to the zone file. A serial that moves forward. The place secondaries are configured to ask. BIND's sample secondary stores each transfer in a file so that a restart can answer immediately without waiting for a new transfer. That file is a saved copy of the last transfer. It is not a second place where you edit the zone. The guide says the zone file is not required on the secondary, because the secondary obtains it from the primary.
The quiet period lasts until expiry. RFC 1034 is blunt about the end of it. The secondary waits the refresh interval, retries if the check fails, and if it cannot complete a serial check for the expire interval it discards the zone. After that, "the secondary still serves authoritative data" is no longer true. Expiry does not itself establish that the saved zone file has been erased. The recovery has to finish before that discard, or it has to be built from a copy that is not the secondary's memory.
What the secondary is actually doing
RFC 1034, section 4.3.5, describes one master, which it also calls the primary, where changes are coordinated, usually by editing a master file. The other servers for the zone are secondaries. They poll. The poll is a query for the SOA record. If the serial matches, nothing transfers and the refresh timer starts again. If the serial on the primary is newer, the secondary requests a full zone transfer, AXFR, and the transfer has to use TCP because the copy has to be accurate. A secondary is required to do this against the primary, and it may also do it against another secondary. That optional path matters when the primary is down and another secondary is easier to reach. It does not create a new place to edit. It copies whatever serial is already out there.
The timers live in the SOA record. Refresh is how long a secondary waits after loading a zone before it checks. Retry is how often it tries again if the check fails. Expire is how long it will keep a zone it cannot check. BIND 9.20.30's base example uses a two-day default TTL, a refresh of 12 hours, a retry of 15 minutes, an expiry of 4 days and a minimum of 2 hours. Those numbers are an example, not a recommendation. The expiry field describes a maximum refresh-failure interval, not a recovery point or a guarantee of a full week from incident discovery. Each secondary has its own last successful refresh time and may refresh through another configured source. A zone with a one-hour expiry gives you almost no time at all.
BIND adds NOTIFY, which it says is configured automatically, citing RFC 1996. This article did not open RFC 1996. What BIND 9.20.30 itself says is that when the primary loads or reloads a zone it sends a NOTIFY to the configured secondaries, and it can be told to notify other hosts as well. The secondary then checks the SOA immediately instead of waiting for refresh. NOTIFY does not help while the primary is dead. It helps after a replacement primary starts, if the replacement is the server the secondaries are willing to be notified by, and if the serial is actually greater. A NOTIFY of an older serial does not move the zone. The serial check still decides.
The transfer itself, in the BIND guide, is AXFR or IXFR over TCP port 53, if both sides support the chosen form. AXFR is the complete copy. A new primary that has a zone file and no journal should be expected to serve a full transfer. This article does not describe how to build an IXFR journal.
The serial is the order of the copies
RFC 1034 says the serial is advanced whenever the zone changes, so that two copies can be compared. The comparison is sequence-space arithmetic on a 32-bit number, not ordinary "larger integer" arithmetic across the whole range. There is a limit to how fast the number may move: old copies have to die out before the serial covers half of the 32-bit space. In practice the warning is about the boundary, where a number looks smaller and is newer, or looks larger and is older. Jumping the serial by a billion to "be safe" can put secondaries on the wrong side of that comparison. RFC 1982 defines serial arithmetic modulo 2^32. A difference of exactly 2^31 has undefined ordering. Find a serial that is newer relative to every relevant surviving copy under those rules; do not choose the numerically largest value or assume an arbitrary jump is safe.
BIND 9.20.30 states the operational test directly. The secondary compares the serial it receives with the serial in its current data. If the received serial is arithmetically greater, it transfers. If you restore a primary whose file has a lower serial than the secondaries, they will not take it. They ordinarily retain their current content rather than replacing it with an older serial. Do not infer expiry merely from that mismatch: a reachable source and successful SOA responses can affect refresh/expiry handling. Check the installed implementation and reconcile the differing contents explicitly. If you restore a primary whose file is older in content but you set the serial higher than the secondaries, they will take the older content because the serial says it is newer. The serial does not know that the content is a rollback. You do.
That is the decision before anyone is promoted. Find the serial on each server that still has the zone. The replacement serial must advance from the surviving state under RFC 1982, and the intended content must be independently accepted. Republishing older content also needs an appropriate newer serial; it is an explicit data rollback, not an exception to serial arithmetic. Do not take the serial from the backup alone. The backup's serial was current when the backup was taken. The secondaries may have moved on.
What is left to promote
A secondary's saved file, in the BIND sample, exists so the secondary can restart and answer without waiting for a transfer. Promoting that file means making some server a primary that reads it from disk. BIND's definition of a primary is that read. Confirm the saved file’s actual format and journal relationship before treating it as a primary master file; a secondary’s on-disk representation is not necessarily editable text. The recovered authoritative content needs SOA, NS records and the remainder of the zone. RFC 1034 says a zone's data is the authoritative records, the data at the top of the zone, the cuts that delegate subzones, and the glue that lets resolvers reach the servers for those subzones. A saved transfer should contain those, because the transfer carries the zone. It will not contain later edits that never transferred, and it will not contain the primary's journals or keys unless those were in the zone. This article did not open a DNSSEC guide. A signed zone has records and timing that a casual promotion can break. A signed or dynamically updated zone needs its own validated recovery procedure, covering keys, signature validity, journals and parent trust records. This article does not supply that procedure. Do not strip signatures to make a file load.
The parent's delegation is not inside the child's zone in a way that updates itself. The zone you recover publishes its own NS records. The parent publishes the delegation that tells the world which servers to ask. If those servers are the dead primary and a secondary you are about to renumber, the recovered zone is authoritative only for resolvers that already know a server which still answers. Everyone else follows the parent's NS and glue. RFC 1034 describes glue as the data that allows access to the name servers for a subzone. Changing it is a change at the parent, on the parent's timing, not a change that a new primary can make by editing its own file. The recovery plan names who can change the parent, and what the TTL on that delegation means for how long the old servers will still be cached. This article does not pick a TTL.
RFC 1034 also says a whole zone can be moved by transferring the records, or by copying a master file, which is the textual form. A file copy of a known-good master file is a legitimate source in the protocol's own terms. It is still subject to the serial rule once secondaries compare it. A file copy from a laptop, with a serial of 1, is how you create a primary that nobody will transfer from.
What to decide while the secondaries are still answering
Write down the expire value in the live SOA, and the time the primary was last known to answer a serial check. Estimate remaining expiry separately for each secondary from its last successful refresh and effective timers. This is an availability window, not an obligation or guarantee that every server will remain up until then. It is not the refresh interval. Refresh is how often they look. Expire is how long they may fail to look before they discard.
Write down the serial on every remaining authoritative server, and the serial in every backup you might load. The serial chosen for the file must be newer under RFC 1982 relative to surviving copies; ordinary numerical maximum is insufficient around wraparound. If all authoritative serving has stopped, still inventory saved copies, journals and servers that may later rejoin. An expired copy can retain a serial on disk; do not assume the comparison history disappeared. Say which of those two situations you are in before you edit a number.
Decide which host will be the primary, meaning the host that reads the file, and which hosts will transfer from it. BIND says secondaries list the primary addresses they transfer from. A secondary that still points at the dead address will retry until it expires, even if a perfectly good primary exists somewhere else. Updating that list is part of the recovery, not a later tidy.
Decide whether the saved secondary file is the best content you have. It is the last successful transfer, not the last edit that failed to go out, and not a backup from before a mistake you have since corrected. A newer master file may be preferable if its content and provenance are sound and its serial can be reconciled; recency alone does not establish correctness. If it does not, the secondary's saved copy is the content the world has been using. Publishing something older, with a higher serial, is a choice to roll the data back. Make it explicitly.
Decide the parent. The NS and glue that resolvers use have to name servers that answer. A hidden primary can legitimately be absent from the parent delegation while feeding publicly delegated secondaries. The requirement is that delegated authoritative servers are reachable and serve the intended zone, not that the primary itself be public. A delegation that names only the dead host is a zone that expires out of the remaining servers and then has nowhere to go.
Do not reload a secondary in a way that drops its saved file during the window, unless you already have another copy. The BIND guide's reason for the file statement on a secondary is that a restart can answer immediately. A restart with no file and no primary waits, and then has nothing.
Risks and limits
RFC 1034 and RFC 1035 are dated November 1987. They use master and primary, and secondary, for the roles BIND now calls primary and secondary. BIND 9.20.30 says it treats primary and master, and secondary and slave, as synonyms. The behaviour cited here is the serial check, the expire discard, AXFR over TCP, and the contents of a zone. Later DNS has more record types than the 1987 list. The comparison rules for the serial are what the recovery depends on.
BIND's statement that a zone must have at least two authoritative servers is that guide's statement. A zone you built with one server does not gain a secondary because the guide prefers two. If you have one server and it is gone, there is no secondary copy to promote. The backup file is the only copy, and expiry is not your window, because nothing is answering.
NOTIFY is described from the BIND 9.20.30 chapter, not from a reading of RFC 1996. IXFR is named and not specified here. DNSSEC signing, key timing and trust anchors were not opened. Dynamic update was not opened. A zone that is updated by DHCP is a different recovery, because the lease system and the zone file can disagree. That is a sequencing problem of its own.
No zone was transferred, no serial was changed, and no server was promoted. The example timers in the BIND chapter are the chapter's example.
Research and verification
Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No equipment was configured, no article commands were executed and no lab behaviour is claimed. This is educational source research, not an approved production recovery procedure.
Sources
-
RFC 1982, Serial Number Arithmetic, August 1996: https://www.rfc-editor.org/rfc/rfc1982.txt. Independently reopened 13 November 2026; modular comparison and undefined half-range ordering.
-
RFC 1034, Domain Names — Concepts and Facilities, P. Mockapetris, November 1987. https://www.rfc-editor.org/rfc/rfc1034.txt — section 4.2.1 on zone contents and glue; section 4.3.5 on primary and secondary maintenance, SOA serial, refresh, retry, expire and discard, AXFR over a reliable transport, and transfers from another secondary. Independently reopened 13 November 2026.
- RFC 1035, Domain Names — Implementation and Specification, P. Mockapetris, November 1987. https://www.rfc-editor.org/rfc/rfc1035.txt — master file format, cited by BIND as the base of the zone file. Independently reopened 13 November 2026. The operational rules used above are in RFC 1034.
- ISC, Configurations and Zone Files, BIND 9.20.30 documentation, chapter 3. https://bind9.readthedocs.io/en/stable/chapter3.html — primary reads from the file system; secondary transfers; both answer authoritatively; resolvers do not distinguish them; serial comparison; AXFR and IXFR over TCP port 53; NOTIFY and also-notify; the secondary file statement that saves a transfer for restart; the example SOA timers. Independently reopened 13 November 2026.
This article was originally published on .