Summary

  • A DNS NOTIFY response says the secondary received the notification; RFC 1996 says the response carries no useful zone information.
  • Publication still depends on SOA serial comparison, IXFR or AXFR, successful loading, and authoritative answers from the intended serving paths.
  • Operators need a zone-publication receipt that preserves each stage instead of promoting a notification acknowledgment into a serving guarantee.

The retry queue is not the serving plane

RFC 1996 defines NOTIFY as an interrupt for DNS change propagation. Instead of waiting for the SOA refresh interval, a master can advise secondaries that data changed. The response has a deliberately narrow meaning: it shows that a named secondary received that NOTIFY, allowing the sender to remove the transaction from its retry queue.

The response contains no useful zone information. It does not say which SOA serial the receiver currently holds, whether it judged the master's serial newer, whether a transfer began, or whether new records reached a process answering authoritative queries. A green notification queue therefore proves delivery of the trigger, not completion of the work the trigger may initiate.

The distinction is structural. On receiving a valid SOA NOTIFY, the secondary behaves as if its refresh timer expired. It queries a known master for SOA, compares serials, and starts IXFR or AXFR if the remote serial has advanced. Those are later operations with their own results and failure modes.

A hint cannot become zone data

RFC 1996 permits a NOTIFY request to carry an answer section, but calls it an insecure hint. The secondary must not use it to update local zone data, order a transfer by itself, or alter refresh timers. This prevents the notification channel from silently becoming an unaudited publication channel.

The serial comparison also deserves preservation. RFC 1982 defines serial arithmetic rather than ordinary unsigned-integer ordering; one comparison interval is explicitly undefined. A useful record should retain the observed local and remote serials and the implementation's comparison result, not merely a generic “newer” label.

IXFR can transfer changes, while AXFR can transfer the complete zone. RFC 5936 places AXFR among the IETF mechanisms for maintaining coherence among authoritative servers. Transfer success is important evidence, but it remains evidence about a transfer session. A deployment can still fail to load the received version, leave one worker on an old generation, or expose inconsistent versions across an anycast fleet.

Sources