Zones, authoritative servers & transfers

A zone is the part of the DNS tree that one set of servers is authoritative for: a domain, minus any subdomains that have been delegated away to someone else. Chapter 1 covers where those cuts fall. This chapter is about what happens inside one zone, starting with how it is written down.

The original format is the master file, defined in section 5 of RFC 1035 in 1987 and still read by BIND, NSD, Knot and PowerDNS today. People also call it a zone file. It is plain text, one record per line, and it is built for typing: anything you leave out is filled in from context. That makes zone files short. It also makes them the source of one of the oldest bugs in the DNS.

Here is a small zone, written the way an administrator would write it. It is simulated: every name and address on this page comes from the ranges reserved for documentation.

Five shortcuts are at work, and each one is a rule you can state exactly.

• $ORIGIN sets the domain that every relative name is completed with. The server sets it to the zone's name before reading the file, so most files never say it; the line above just makes it visible.
• Relative and absolute names. A name that ends in a dot is absolute and is used exactly as written. A name without the final dot is relative, and the current origin is appended to it. So ns1 means ns1.example.com. and ns2.example.net. means itself.
• @ on its own means the origin. Here it is example.com., the apex of the zone.
• Blank owner. A line that starts with a space or tab belongs to the same name as the record before it. The two NS lines and the MX line above all belong to the apex.
• $TTL gives the TTL for any record that does not state one. It was not in RFC 1035; RFC 2308 added it in 1998, and it should be the first line of every file. Units such as 1h and 2w are a widely supported BIND convention; the protocol itself only carries seconds.

Parentheses let one record run over several lines, and a semicolon starts a comment that runs to the end of the line. That is why the SOA above can carry a label on each of its numbers.

Every zone has exactly one SOA record, at its apex. It names the zone's source and carries the numbers that drive replication. Ask any of the zone's servers for it:

The first two fields are names and the last five are unsigned 32-bit numbers. Three of the timers, REFRESH, RETRY and EXPIRE, are only for secondaries; resolvers never look at them. The fourth, MINIMUM, is the one that changed meaning over the years, and it is the only one that reaches the wider internet.

RFC 1912, the old but still useful guide to common DNS errors, gives the reasoning for each value. REFRESH is how long you can live with a secondary serving out-of-date data. RETRY is usually a fraction of REFRESH. EXPIRE should be longer than any outage you expect, so a secondary survives a long one, and it must be longer than RETRY and MINIMUM. Once NOTIFY is in place, REFRESH matters much less, because changes no longer wait for it.

The serial is a version number, and the rule a secondary follows is simple: if the primary's serial is greater than mine, my copy is old, so fetch the new one. Change the zone without raising the serial and no secondary will ever fetch the change. That is the most common replication bug there is, and Instrument 2 lets you commit it.

"Greater than" needs care, because the serial is only 32 bits and it is allowed to wrap round. RFC 1982 defines serial number arithmetic for this. Picture the 4,294,967,296 possible serials around a circle. From any serial, the half of the circle ahead of it counts as newer and the half behind counts as older. A serial exactly half way round is neither: the comparison is undefined, and software may do anything.

Two conventions are common for choosing serials. Some people simply add 1 each time. Many use the date: YYYYMMDDnn, so 2026102201 is the first change on October 22, 2026 and 2026102202 is the second. Dates sort correctly, tell you when the zone last changed, and still fit in 32 bits until the year 4294. The scheme's one weakness is that it allows only 100 changes a day; zones changed by software often switch to a counter or to the Unix time in seconds.

The circle explains the classic accident. Someone means 2026102201 and types 2062102201. The secondaries copy it, because it is newer. Fixing the typo by loading 2026102202 does nothing: from 2062102201, the number 2026102202 is behind, so every secondary decides it already has a newer zone and ignores the fix. You cannot go backward. You go forward round the circle, in steps of less than half.

1. Add 2,147,483,647 (that is 2³¹ − 1) to the bad serial, wrapping past 4,294,967,295. Load that. Every secondary sees it as newer and copies it.
2. Wait until every secondary has it: RFC 1912 suggests two REFRESH periods; with NOTIFY, check each server with dig +nssearch.
3. If your target is now ahead of the serial you loaded, load the target. If not, repeat step 1. Instrument 3 does the arithmetic.

Every zone should have at least two authoritative servers, and usually has more. One of them, the primary, holds the zone as the administrator edits it, from a file, a database or a provider's API. The others are secondaries: they load the zone from the primary over the DNS protocol itself and answer from their copy. Older documents call them master and slave; RFC 9499, the current DNS terminology reference, uses primary and secondary. A secondary can also feed further secondaries, so the source a server copies from is just "its primary."

The original sync loop is polling, and it runs on the SOA timers. Every REFRESH seconds the secondary asks the primary a single small question, the SOA of the zone, and compares serials. Same serial: nothing to do, try again in REFRESH. Bigger serial: transfer the zone. No answer: try again in RETRY, and keep trying. If no refresh has succeeded for EXPIRE seconds, the copy is considered too old to be authoritative, and the secondary stops answering for the zone. Resolvers that ask it then get SERVFAIL, and fall back to other servers if they can.

Polling alone means a change can take up to a whole REFRESH interval to reach a secondary. RFC 1996 fixed that in 1996 with NOTIFY: when the zone changes, the primary sends each secondary a short message saying the zone may have changed. The secondary then does exactly what it would have done when its timer fired, asks for the SOA and compares, so a forged or stale NOTIFY can at worst cause an unnecessary check. The primary may wait a short random time before notifying, so a hundred secondaries do not all ask at once. Polling stays on underneath as the safety net for lost messages.

AXFR copies everything. The response is the zone's SOA, then every other record, then the SOA again so the receiver knows it has the end. RFC 5936 pinned down the details that RFC 1035 left loose: AXFR runs over TCP, and the response may be split across many messages. IXFR sends only what changed. The secondary includes the serial it has; the primary replies with the deletions and additions that lead from that serial to the current one, or, if it no longer remembers that far back, falls back to a full transfer. For a zone with a million records and ten changes a day, the difference is enormous.

A popular design is the hidden primary. The primary sits somewhere private and is not in the zone's NS records, so no resolver ever queries it. It exists only to feed the secondaries, which are the public face of the zone. Signing keys, admin tools and the database stay off the internet, and an attack on the public servers cannot reach the source of truth. RFC 1996 calls a server like this a stealth server; RFC 2182 discusses the same idea.

The original DNS assumed that anyone could copy any zone. A zone transfer was a convenience for operators, and the data was public anyway, since anyone can look up any single name. The difference is scale. One lookup answers one question; one AXFR hands over the complete inventory of the zone: every host name, every internal-sounding label, every mail server and test machine, without any guessing. RFC 5936 says plainly that administrators may restrict AXFR, to keep the bulk zone private or to protect the server from the load.

The defensive picture is simple. An authoritative server should refuse AXFR and IXFR from everyone except the secondaries that need them, and every server software's default is now to refuse or to require configuration. Checking your own zone is one command, run from a network that is not one of your secondaries: the answer you want is a refusal.

There are two layers of protection, and good setups use both.

• Address lists. The primary allows transfers only to the secondaries' addresses, and each secondary accepts NOTIFY only from its primary. Easy and useful, but an address alone is weak proof: on some networks it can be spoofed or borrowed, and it says nothing about whether the data was altered on the way.
• TSIG. Transaction signatures, RFC 8945. Primary and secondary share a secret key, and each signs its messages with an HMAC computed over the message and the current time. The receiver recomputes the HMAC; if the message was changed, sent by someone without the key, or is too old, it fails. RFC 8945 makes hmac-sha256 mandatory to implement and recommends a 300-second window for clock differences, so the two servers' clocks must agree to within a few minutes. TSIG also protects NOTIFY and dynamic update.

TSIG proves who is talking and that nothing was changed, but it does not hide the zone from someone watching the network path. RFC 9103 (2021) adds zone transfer over TLS, known as XoT, for zones where the contents themselves are sensitive. DNSSEC is a different tool for a different problem: it lets resolvers verify the records they receive, but it does not decide who may copy the zone.

Secondaries exist so that one failure does not take the zone off the internet. That only works if they do not share the failure. RFC 2182, written in 1997 to guide the choice of secondaries, puts it directly: secondary servers must be placed at both topologically and geographically dispersed locations, to minimise the likelihood of a single failure disabling all of them. It specifically warns against putting all of a zone's servers on the same LAN segment in the same room, and it applies the same logic to a single network provider. Two servers behind one router, one power feed or one upstream provider are, for this purpose, one server.

The modern version of the same mistake is putting every NS record with one DNS provider. Many large organizations now list name servers from two independent providers, which works with the primary-and-secondary model in this chapter as long as both providers can transfer the zone from a common source, or are both fed by the same automation. Chapter 9 covers anycast, which lets one server name stand for many machines; it helps, but one provider's anycast cloud is still one provider.

Then there is the delegation itself. A zone's name servers are listed twice: once in the parent zone, as the delegation NS records (plus glue addresses when needed), and once in the zone's own apex, the child NS set. Resolvers follow the parent's list to find the zone and then often prefer the child's. The two lists are meant to match, and when they drift apart, failures become intermittent and hard to reproduce: it depends which list a given resolver happens to have cached.

A lame delegation is a server that is listed as authoritative for a zone but does not actually serve it. Ask it and it answers with a refusal, a referral elsewhere, an answer without the authoritative flag, or nothing at all. It usually happens quietly: a zone moves to a new provider and the old servers are never removed from the parent, a secondary is decommissioned but still listed, or a typo in an NS record points at a machine that has never heard of the zone. Resolvers waste time on the lame server and fall back to the others, so the zone limps along slowly until the day the working servers fail too.