Test DNS › DNS guides

DNS zone hosting: primary, secondary and transfers

A single server hosting a zone is a single point of failure for a whole domain. Replication between primary and secondary servers relies on standardised mechanisms, AXFR, IXFR and NOTIFY, whose actual behaviour explains most of the inconsistencies observed in production.

Two server racks connected by network cables in a data centre — Primary and secondary share the same content: replication carries the zone, it does not correct it.

Primary and secondary: two roles, the same content

The primary server is the one on which the zone is written; secondary servers hold a copy obtained by transfer. The official terminology of RFC 8499 replaced the terms master and slave, but the principle has not changed: a single source of writing, several servers answering resolvers with the same content. A secondary is not a cut-down server: from a resolver's point of view, it is fully authoritative.

This architecture has a practical consequence that is often overlooked: any change applied to the primary eventually reaches the secondaries, including a mistake. Replication protects against the failure of a machine, not against a typing error. That is why checks are carried out on the primary before publication, and not on the copies afterwards.

The full transfer, AXFR

The full zone transfer, described in RFC 5936, takes place over TCP: a secondary opens a connection, requests the whole zone, and receives the records as a stream, framed by the SOA record at the beginning and at the end. The protocol mandates TCP because the response almost always exceeds the size of a datagram, and because the loss of a packet must not leave a partial copy.

AXFR carries the entirety of the zone every time. On a zone of a few dozen records the operation is painless; on a large zone replicated often, it becomes costly in bandwidth and processor time. It is this limit that motivated the incremental transfer, without making AXFR disappear, since it remains the fallback when no history is available.

The incremental transfer, IXFR

Described in RFC 1995, IXFR allows a secondary to request only the differences since the serial number it holds. The primary consults its change journal and returns the successive deletions and additions. The gain is real on zones modified often and a little at a time, which matches how zone hosting normally works.

The mechanism has one condition: the primary must keep a history covering the secondary's serial. If the secondary has been stopped for too long, or if the journal has been purged, the primary answers with a full transfer. A secondary that keeps falling back to AXFR points to a journal that is too short or a prolonged outage, and deserves examination rather than blind tuning.

NOTIFY: notifying instead of waiting

Without notification, a secondary discovers a change by querying the primary's SOA periodically, at the refresh interval. That delay is laid down by the standard and can amount to hours. RFC 1996 defines a notification message, sent by the primary to the secondaries as soon as it reloads the zone, which immediately triggers the serial check and the transfer if necessary.

NOTIFY does not replace periodic refresh: it speeds it up. A lost notification has no consequence, the normal rotation taking over again. On the other hand, a primary configured without notification targets gives the illusion of a zone replicated instantly, whereas the secondaries keep their own pace: a gap that becomes noticeable during urgent changes.

Authorising and authenticating transfers

A zone transfer exposes the entirety of the content, internal names included. Name server software allows the addresses permitted to request an AXFR to be restricted, and that restriction must be set explicitly: an open transfer is an inventory leak, not a feature. By default, recent distributions in fact refuse transfers, which produces empty secondaries if the rule is forgotten.

Shared-key authentication, described in RFC 8945, provides an additional guarantee: the transfer is accepted only if the request carries a valid signature. It also protects notifications and dynamic updates, and proves useful as soon as the servers communicate over an untrusted network. The key is distributed over a separate channel, never in the zone file.

Checking replication instead of assuming it

The basic check comes down to one question asked of each server: what is the serial number of the zone's SOA. All must return the same value. A lagging secondary shows a lower serial; a secondary without the zone answers with an error or with a delegation, depending on the parent's configuration. This simple reading, repeated after every change, detects most replication incidents.

The second check concerns freshness. A secondary stops answering for the zone when the SOA expiry time is exceeded without contact with the primary: the zone then disappears from the server, and resolvers fail over to the others. Monitoring the serial and the age of the last copy avoids discovering that failover at the moment it happens, that is to say during a failure.

References

To check a domain name live — root, TLD, name servers — use the DNS test tool. Demarcq.net runs DNS servers: managed DNS operations.

← Configuring an authoritative DNS server for a zone Setting up a secondary DNS server: value, limits and good practice →