Visual RFC.
ALL RFCs / RFC 1996
Read the RFC ↗
RFC 1996 / DNS ZONE NOTIFICATION

Check the notifying master before transferring a zone

03

A notification prompts a normal SOA query. The secondary compares that answer’s zone serial number with its local copy before deciding whether it needs a transfer.

RFC 1996 · § 3.11 and related clausesEXAMPLE
4 / 4
Check the notifying master before transferring a zoneAfter a successful transfer, the secondary installs serial 11. Failed transfers do not establish that state. If the checked serial were unchanged, this branch would end without a transfer. The diagram does not implement AXFR/IXFR framing.Check, compare, then transferSecondaryMaster BMaster Alocal 11serial 10serial 11A sends NOTIFYNOTIFY acknowledgementSOA query to notifying known master ASOA answer: serial 1111 is newer than previous local 10AXFR or IXFR requestSuccessful transfer: zone dataNow install local serial 11RFC1996 · fictional zone · simplified illustrations
04
Install data after successful transfer

After a successful transfer, the secondary installs serial 11. Failed transfers do not establish that state. If the checked serial were unchanged, this branch would end without a transfer. The diagram does not implement AXFR/IXFR framing.

Source for this drawing: RFC 1996 · Read RFC source: § 3.11 and related clauses ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

What changed
Ordinary timer-driven refreshNotification-driven source choice

For this event, query the known master that sent NOTIFY. Other known masters may still hold old data. RFC1996 §3.11 explicitly distinguishes this from the ordinary refresh sequence.

Read the updated RFC section ↗
KEY POINT

For a valid SOA NOTIFY, the secondary should act as though the zone reached its refresh interval. Query the known master that sent the event; a different configured master may still hold old data.

  • For a valid SOA NOTIFY, the secondary should act as though the zone reached its refresh interval. Query the known master that sent the event; a different configured master may still hold old data.
  • If the SOA serial has advanced, a zone transfer, AXFR (full) or IXFR (incremental), should be initiated. RFC1982 supplies wrap-aware serial comparison; ordinary integer ordering is not sufficient.
  • Only successful transfer/update work changes the local zone copy. A NOTIFY acknowledgement or its optional Answer cannot do that. Equal serials do not require a new transfer; half-range serial ordering is undefined under RFC1982.
DETAILS

Fictional picnic.example zone and documentation-only addresses. Drawings are schematic; no DNS traffic, server configuration or zone transfer is performed.

Read the RFC section ↗

All chapters in RFC 1996

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗