Summary

  • The original DNS replication loop made secondaries poll after a zone-defined refresh interval. That conserved primary-server work, but it also made a period of disagreement among authoritative servers a designed operating condition.
  • DNS NOTIFY did not push a replacement zone. It told a configured secondary to check the SOA serial; IXFR then let that secondary request the ordered changes since the version it already held, with AXFR retained as the complete-copy fallback.
  • The faster path remained bounded by modular serial arithmetic, stable storage, complete processing, atomic activation and optional transaction authentication. A signal accelerated scrutiny; it did not acquire the authority to rewrite another server by itself.

The minutes when authority disagreed with itself

A DNS zone can have several authoritative servers precisely so that one machine, one link or one institution is not the only place from which the zone can be answered. Replication creates resilience, but it creates a less celebrated question: after the zone changes, how long may two authoritative answers describe different realities?

The original answer was deliberately temporal. RFC 1034 described a primary copy at one name server and secondary copies that periodically checked the primary. A secondary queried the zone’s Start of Authority record, compared its SERIAL with the primary’s, and transferred the zone if the primary’s version was newer. The zone itself carried REFRESH, RETRY and EXPIRE values. RFC 1035 fixed those fields as 32-bit quantities and assigned AXFR as the request for a complete zone transfer.

That mechanism was not careless. It avoided continuous chatter. A stable zone did not need to be copied repeatedly; most checks were small SOA queries. If a check failed, the secondary retried. If it could not refresh for the entire expire interval, it was supposed to stop acting as authoritative rather than serve an indefinitely old copy.

Yet the mechanism turned delay into policy. Between a change at the primary and the next successful refresh check, a secondary could answer from the prior version while remaining correctly configured and nominally healthy. A shorter refresh interval narrowed that interval by increasing queries to the primary. A longer interval protected the primary at the cost of longer incoherence.

This distinction matters because authoritative divergence is not the same as resolver caching. A recursive resolver may continue to use an old record until its TTL expires even after every authoritative server has converged. Conversely, before the authoritative set converges, two resolvers with empty caches may obtain different current answers merely because they ask different authoritative servers. The article’s subject is that first replication boundary, not the reader-facing TTL boundary downstream.

Polling made delay a policy choice

The polling design placed initiative with each secondary. It knew when it had last refreshed, which master it should ask and when its authority must expire. The primary did not need to remember a live connection to every replica. This was a strong property for a distributed system: loss of a notification channel could not become permanent blindness because the ordinary timer would eventually cause another check.

But by the mid-1990s, zones and expectations had changed. A small edit could require the transfer of an entire growing zone. Operators who wanted prompt propagation had to choose aggressive polling even when nothing changed. The cost of discovering change and the cost of moving change were coupled to the size and quietness of the zone.

RFC 1996 stated the tradeoff without euphemism. Long refresh times reduced load on masters but produced long intervals of incoherence when a zone was updated. DNS NOTIFY introduced an interrupt alongside the poll. Once a master loaded a change, it could advise a set of secondaries that something relevant had changed.

The word “advise” carries the architecture. NOTIFY did not contain a trusted replacement database. Its ordinary purpose was to make the secondary initiate an SOA query. The recipient checked a master it was configured to trust, inspected the serial, and began a transfer only if its version was behind. Optional data in the NOTIFY answer section was explicitly an insecure hint. The knock shortened the wait; it did not cross the threshold and rearrange the room.

A knock, not a package

The default notify set consisted of the servers named in the zone’s NS records, excluding the server named as the SOA master. Operators could override the set or include a stealth secondary that was known by configuration rather than publicly listed. This meant that the zone described part of the distribution structure, but local administration still decided the actual replication relationships.

RFC 1996 required those relationships to form a dependency graph without transfer loops. There was one primary master, but another server could be a secondary for its own copy and a master for downstream replicas. After it successfully updated, it could notify the next level. The design distributed transfer load without pretending that every server learned directly from one global source.

Best effort also required restraint. UDP notifications could be retransmitted until acknowledged or timed out, with backoff under operator control. A secondary might hear the same event from several upstream peers. It was expected to suppress duplicates while an update was already in progress so that several knocks did not produce several simultaneous transfers and pound the master.

The response to NOTIFY merely confirmed receipt; it did not certify successful convergence. A lost response could cause another knock. A forged source could provoke useless SOA checks and produce a modest denial of service. A server that did not implement the opcode could answer NOTIMP, after which the master treated that notification attempt as complete. Ordinary refresh polling remained the compatibility and recovery mechanism.

This is why “push DNS” is a misleading shorthand. The primary pushed urgency, not authority. Data still moved through a separate protocol, from a configured transfer peer, after a version comparison, and it became live only under the receiving server’s rules.

The serial that could wrap around

Faster checking only works if two servers can agree which version is newer. DNS had always placed a 32-bit serial in the SOA record, but ordinary integer intuition fails when the largest value wraps back to zero. RFC 1982, published in the same month as IXFR and NOTIFY, defined the missing arithmetic.

A serial is a position in finite sequence space, not a date. Addition is modular and bounded. Comparison treats a nearby value ahead in the sequence as newer even if its ordinary integer is numerically smaller after wraparound. Two values exactly half the 32-bit space apart have no defined order. An operator must not advance a serial by more than 2^31−1 within the SOA expire interval, or an old secondary can appear to hold the “newer” version.

This limitation is not an historical curiosity. The serial is the compact evidence upon which the secondary decides whether to do nothing, request differences or replace a full zone. Careless reuse, enormous jumps or broken wraparound comparison can leave valid new data stranded behind an apparently advanced old copy.

The field therefore proves less than its everyday name suggests. It does not tell when the edit occurred, who authorised it, whether the content is correct or whether every replica has installed it. It orders permitted transitions between copies. That narrow statement is enough for replication—provided operators preserve its arithmetic meaning.

Sending the edit instead of the archive

NOTIFY reduced the time needed to discover a change. RFC 1995 reduced the cost of obtaining it. Under the original AXFR model, one changed address could require a secondary to fetch the entire zone. IXFR let the client include the serial of the copy it already held and ask for the differences needed to reach the server’s current serial.

An incremental response is a history of delete-and-add sequences. Each sequence begins with the older SOA and then the newer SOA, and the sequences run from the client’s version toward the current one. A modified record is expressed as removal of its old form followed by addition of its new form. Only the changed member of an RRset need travel when the rest is unchanged.

This is more than compression. It makes the receiver’s starting state explicit. The server is not saying “here is an update” in the abstract; it is saying “given that you hold serial X, these ordered changes produce serial Y.” The secondary applies the entire chain before replacing its older version. An incomplete difference stream cannot legitimately become half a new zone.

The primary or another IXFR server has to retain enough history to answer. RFC 1995 refused to turn that history into an eternal ledger. Old versions could be purged, and a server was encouraged to use AXFR when the differential response would be larger than a full copy. It could condense several versions into one difference, sacrificing intermediate history. If another server did not recognise the client’s particular starting serial, it could also fall back to a full transfer.

Efficiency remained contingent. A quiet, large zone with one edit benefits greatly from IXFR. A heavily rewritten zone, a newly provisioned secondary or a server whose change journal has been purged may not. The protocol preserved success by making the optimisation optional and the complete state transferable.

Why the old full copy stayed necessary

Fallback is often described as an embarrassment: the modern mechanism failed, so the system returned to the old one. Here it is part of the safety design. A differential is meaningful only relative to a known starting version and a retained path of changes. AXFR reconstructs a complete current zone when that shared history is absent.

RFC 5936 later respecified deployed AXFR with an important integrity rule. The client must not expose a partially transferred zone. It should receive the data into a separate file or store, perform sanity checks, and make the completed version available atomically. If the transfer fails, the previous valid version remains in service.

RFC 1995 imposed the matching obligation at the source. A new zone version should be written to stable storage before it is used to answer IXFR or AXFR. Otherwise a master could distribute data, crash, and restart without the version that secondaries had already accepted. Prompt propagation without durable origin state would create exactly the persistent inconsistency the protocol was meant to reduce.

The receiving server therefore has a real decision boundary. A notification can trigger work. A serial can show that work is needed. An IXFR or AXFR stream can supply candidate state. Only completed processing and atomic activation decide what the server will answer as authoritative.

Faster does not mean less accountable

Zone transfers can reveal the contents of a zone and can replace the data from which an authoritative server answers. RFC 5936 recommends restricting transfer access according to policy and points to transaction-signature mechanisms for authorisation and integrity. The present Internet Standard is RFC 8945, which specifies TSIG using shared-secret message authentication codes.

For a multi-message TCP transfer, TSIG can chain integrity across the stream so that the receiver can detect alteration. It can authenticate that a message came from a party possessing the agreed secret. Those are consequential protections, but they remain point-to-point. Key distribution occurs out of band; shared keys become cumbersome across many peers; compromise lets a party impersonate another holder of the same secret.

TSIG also does not encrypt the transfer. More fundamentally, it authenticates the transaction, not the truth of the zone. A correctly signed master can still serve an erroneous or malicious edit. A secondary must not turn “the MAC verified” into “the institution named in this data authorised every claim” or “the record establishes legal ownership.” Transport integrity preserves what one peer sent; it cannot improve the source’s judgment.

This separation makes the 1996 design more durable. Speed was added without deleting configuration, version evidence, fallback, stable storage or receiver-side activation. The mechanism did not ask every secondary to trust the network merely because a packet arrived sooner.

The quiet constitutional lesson

DNS NOTIFY and IXFR are rarely presented as a constitutional change. They introduced no new governing body and declared no new class of owner. Yet they solved a governance problem in miniature: how may one operational authority cause another to change quickly without acquiring direct control over it?

The answer was a chain of limited statements. “Something changed” caused a check. “My serial is Y” could be compared with X. “Here are the differences from X to Y” could be processed, or replaced by a complete copy. “This transaction carries the agreed authenticator” could protect the path. None of those statements alone became live authority.

That chain has costs. Operators must maintain correct serials, notify relationships, journals, transfer permissions, durable data and alarms. A topology hidden in local configuration can drift. A secondary can expire. An aggressive notifier can produce load. A wrong change can converge faster than before. Acceleration shortens both the life of a correction and the time available to notice a mistake.

The alternative, however, is not responsibility without complexity. It is authority that remains stale because nobody told it to look. The historical achievement was to make coherence prompt while preserving independent verification. The zone learned to knock. The secondary kept the right—and the burden—to open the door carefully.

Sources and evidence limits

RFC 1034 and RFC 1035 establish polling, SOA timers, serial comparison and full transfer. RFC 1982 defines serial arithmetic. RFC 1995 defines incremental differences and full-transfer fallback. RFC 1996 defines the best-effort notification and configured dependency graph. RFC 5936 clarifies complete, atomic AXFR activation. RFC 8945 defines point-to-point transaction authentication and its limits.

These specifications establish protocol design and requirements, not a universal deployment chronology or measured global convergence time. They do not prove that every implementation used the same defaults, retained the same journal depth, authenticated transfers or installed the extensions in August 1996. The claim is architectural: the standards separated trigger, version evidence, transfer and activation, making faster replication possible without making a notification self-executing.