Treat optional Answer data as an untrusted hint
04A NOTIFY request may include an Answer RRset, a set of resource records. That section can save a check only in one narrow case; it cannot replace the normal update process.
A different sender is not a configured master for the zone. The RFC recommends ignoring its NOTIFY and recording an operations error; the illustration stops before any SOA query. Configuring all intended multihomed-master addresses avoids rejecting a legitimate source.
Source for this drawing: RFC 1996 · Read RFC source: § 3.7 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.
No Answer or a different Answer should lead to querying known masters for the data. If an included Answer equals local data, the receiver is free to conclude that no further work is needed.
- No Answer or a different Answer should lead to querying known masters for the data. If an included Answer equals local data, the receiver is free to conclude that no further work is needed.
- The NOTIFY Answer must never directly update local data, decide that a transfer is needed, or change refresh timers. Only the data-present/data-same shortcut changes normal handling.
- A request from a host not known as a master for the QNAME’s zone should be ignored and logged as an operational error. Source-address familiarity alone is not cryptographic 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 ↗