A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
updates
- rfc-1035 — Domain names - implementation and specification
Extracted elements (27)
DNS NOTIFY uses an interrupt model rather than a poll model to reduce zone propagation delay. Long SOA refresh intervals reduce master server load but cause incoherence among authority servers; NOTIFY signals slaves immediately when the zone changes.
Each slave is likely to receive multiple copies of the same NOTIFY—one from the primary master and one from each slave that subsequently transfers the zone. The protocol tolerates this because NOTIFY is sent only after a successful zone transfer, so the last NOTIFY received will reflect the latest change.
Recommended UDP retry defaults are a 60-second interval and a maximum of 5 retransmissions, with additive or exponential backoff considered reasonable. These are intended to be configurable per-zone by the name server administrator.
Slaves of a multihomed master must either know the master by its closest interface address or know all of its interface addresses; otherwise, valid NOTIFY requests arriving from a secondary interface will appear to come from an unknown master and be silently dropped.
When a slave issues its SOA query after receiving a NOTIFY, it should query the specific master that sent the NOTIFY—not all known masters in turn as RFC 1035 specifies for normal refresh—because other masters in a deep dependency graph may not yet have the updated zone.
A master may delay NOTIFY transmissions by a random interval to avoid triggering simultaneous outbound zone transfers from multiple slaves. The delay must not exceed the SOA REFRESH time.
A slave/master must send NOTIFY only AFTER it has successfully completed a zone transfer and updated its SOA RR (or determined no update was necessary). This ensures that NOTIFY propagation reflects committed data.
A slave that receives a NOTIFY request from a host that is not a known master for the zone containing the QNAME should ignore the request and log an error. This guards against unauthorized NOTIFY senders.
A slave that receives a valid NOTIFY should defer action on any subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has completed the transaction started by the first NOTIFY, to avoid pummeling the master with concurrent requests.
Conforming implementations must set AUCOUNT=0 and ADCOUNT=0 in NOTIFY requests. Current implementations must ignore (but not discard) the authority and additional sections if present, since future revisions may define backwards-compatible uses for them.
Fields in a NOTIFY message not otherwise described must be filled with binary zero. Implementations must ignore all messages for which this is not the case.
If a slave does not implement the NOTIFY opcode, it must respond with a NOTIMP error. A master receiving NOTIMP should treat the NOTIFY transaction as complete for that slave.
If ANCOUNT>0, the answer section provides an unsecure hint at the new RRset. A slave may treat equivalence with local data as 'no further work needed.' The answer section MUST NOT be used to directly update a slave's local data or trigger zone transfer.
If TCP is used, both master and slave must continue to offer name service during the NOTIFY transaction, even when the TCP transaction is not making progress.
If UDP is used, a master periodically retransmits NOTIFY requests until a timeout occurs, an ICMP port-unreachable is received, or a matching NOTIFY response is received. The response must match on query ID, QNAME, IP source address, and UDP source port.
The zone's servers must be organized into a dependency graph with a single primary master and no loops. All other servers must use AXFR or IXFR from the primary master or from a slave that is also a master.
Upon receiving a NOTIFY with QTYPE=SOA, the slave should behave as if the zone's SOA REFRESH interval has expired: query its masters for the SOA, check if the SERIAL has incremented, and if so initiate AXFR or IXFR.
A NOTIFY request uses the DNS message format with opcode NOTIFY (4), QR=0, AA flag set, QDCOUNT>0, and optionally ANCOUNT>=0. The QNAME is the zone name, QCLASS is the zone class, and QTYPE is T_SOA for the only currently defined NOTIFY event.
A Stealth server is like a slave server but is not listed in any NS RR for the zone. It sets the AA bit in responses and can act as a master, but is only known to other servers through static configuration.
The Notify Set is the set of servers to be notified of zone changes. The default is all servers named in the NS RRset, excluding any server also named in the SOA MNAME field. Administrators may override or extend this set, e.g., to include stealth servers.
The Primary Master is the authoritative server at the root of the zone transfer dependency graph, named in the zone's SOA MNAME field. There is by definition only one primary master per zone.
UDP is the default transport for NOTIFY transactions. TCP is used only when the master has reason to believe it is necessary, such as when a firewall blocks UDP or the changed RR is too large for a UDP/DNS datagram.
This document defines opcode value 4 (NOTIFY) for use in the DNS message header opcode field, extending the set of DNS opcodes originally defined in RFC 1035.
A NOTIFY request with a forged IP/UDP source address can cause a slave to send spurious SOA queries to its masters, resulting in a benign denial-of-service attack if forged requests arrive at high frequency.
TCP spoofing could be combined with NOTIFY to synchronize a crafted SOA query, and then UDP/DNS spoofing could be used to force a zone transfer from a slave. This attack requires both TCP and UDP spoofing capabilities against the slave.
NOTIFY transaction states: master sends NOTIFY request (QR=0) → slave acknowledges with NOTIFY response (QR=1, same query ID) → master removes slave from retry queue. On timeout or ICMP unreachable, master stops retrying. On NOTIMP, transaction is also considered complete.
NOTIFY request fields: query ID (new), op=NOTIFY (4), resp=NOERROR, flags=AA, qcount=1, qname=(zone name), qclass=(zone class), qtype=T_SOA. The response is identical except that QR is also set and the query ID matches the request.