Zone transfer policy

This node is a transfer client. It never generates zone data and never edits a record it received. Everything below describes what it will and will not accept.

Direction

Direction	Allowed	Notes
Inbound AXFR from primary	yes	On NOTIFY, and on the refresh timer as a fallback.
Inbound IXFR from primary	yes	Falls back to AXFR when the primary cannot serve the delta.
Outbound transfer to third parties	no	Refused for every source, including our own other nodes.
NOTIFY from unknown sources	no	Dropped. Only the configured primary can trigger a transfer.

A secondary that serves AXFR to anyone who asks hands over a complete inventory of the network's names. Whether that inventory is sensitive is not for the secondary to decide, so the answer is always no.

Authentication

Transfers are authenticated with a shared key. An unsigned transfer request is refused even from the correct address.
Keys are per zone pair, not per host: compromising one does not expose the others.
Rotation is a two-sided change with an overlap window in which both keys are valid. Skipping the overlap is what caused the May 2026 entry in the status log.
Source address is checked in addition to the key, as a second condition rather than a substitute for one.

Serial handling

Serials are produced by the primary's generator and are strictly increasing. This node compares before it commits: a transfer whose serial is not higher than the copy in memory is discarded and logged, because the only ways to get one are a misconfigured primary or an attempt to roll a zone backwards.

If a transfer arrives and fails to parse, the previously served copy stays in memory. There is no state in which this node serves a partially applied zone; either the whole new copy replaces the old one or nothing changes.

Expiry

When the primary has been unreachable for longer than the zone's expiry interval, this node stops answering for that zone rather than serving data it can no longer vouch for. The response becomes SERVFAIL, not a stale answer.

That is the correct behaviour and it is also the reason expiry intervals should be measured in weeks, not hours: a short expiry converts a transient transfer outage into a resolution outage.

What we ask of zone owners

Send NOTIFY on every change. Relying on the refresh timer alone means the standby is routinely several hours behind for no reason.
Keep the expiry interval at seven days or more.
Tell us before rotating a transfer key, not after.
Do not put records in the zone that only make sense on one nameserver. A copy is a copy; per-node answers belong in separate zones.