Pace notifications and propagate only after checking
06A zone’s authoritative servers can receive duplicate events and notify their own peers. Coordination prevents notifications from multiplying expensive simultaneous work.
A forged but plausible source can trigger extra SOA queries, and spoofed follow-up traffic creates further risk. Known-master filtering and retry limits are not cryptographic proof of identity. This tutorial sends no traffic and does not implement authentication or safe transfer policy.
Source for this drawing: RFC 1996 · Read RFC source: § 4.2 and related clauses ↗
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.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A secondary/master sends NOTIFY only after updating its SOA or determining that no update is needed. It must not advertise work that has not completed.
- A secondary/master sends NOTIFY only after updating its SOA or determining that no update is needed. It must not advertise work that has not completed.
- After a valid notification, subsequent events with the same QNAME, QCLASS and QTYPE should be deferred until the first transaction’s work is complete. Duplicates do not require parallel refresh jobs.
- A master may delay notifications to spread transfer load, but the delay must not exceed SOA REFRESH. Suggested random30–60 second delays are examples. Forged source addresses can still cause unnecessary queries; RFC1996 supplies no cryptographic sender authentication.
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 ↗