A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
Lets a DNS master tell its secondaries that a zone has changed.
Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.
@misc{rfc1996,
series = {Request for Comments},
number = 1996,
howpublished = {RFC 1996},
publisher = {RFC Editor},
doi = {10.17487/RFC1996},
url = {https://www.rfc-editor.org/info/rfc1996},
author = {P. Vixie},
title = {{A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)}},
pagetotal = 7,
year = 1996,
month = aug,
} RFC text
Contents
Network Working Group P. Vixie
Request for Comments: 1996 ISC
Updates: 1035 August 1996
Category: Standards Track
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo describes the NOTIFY opcode for DNS, by which a master
server advises a set of slave servers that the master's data has been
changed and that a query should be initiated to discover the new
data.
1. Rationale and Scope
1.1. Slow propagation of new and changed data in a DNS zone can be
due to a zone's relatively long refresh times. Longer refresh times
are beneficial in that they reduce load on the master servers, but
that benefit comes at the cost of long intervals of incoherence among
authority servers whenever the zone is updated.
1.2. The DNS NOTIFY transaction allows master servers to inform slave
servers when the zone has changed -- an interrupt as opposed to poll
model -- which it is hoped will reduce propagation delay while not
unduly increasing the masters' load. This specification only allows
slaves to be notified of SOA RR changes, but the architechture of
NOTIFY is intended to be extensible to other RR types.
1.3. This document intentionally gives more definition to the roles
of "Master," "Slave" and "Stealth" servers, their enumeration in NS
RRs, and the SOA MNAME field. In that sense, this document can be
considered an addendum to [RFC1035].
2. Definitions and Invariants
2.1. The following definitions are used in this document:
Slave an authoritative server which uses zone transfer to
retrieve the zone. All slave servers are named in
the NS RRs for the zone.
Master any authoritative server configured to be the source
of zone transfer for one or more slave servers.
Primary Master master server at the root of the zone transfer
dependency graph. The primary master is named in the
zone's SOA MNAME field and optionally by an NS RR.
There is by definition only one primary master server
per zone.
Stealth like a slave server except not listed in an NS RR for
the zone. A stealth server, unless explicitly
configured to do otherwise, will set the AA bit in
responses and be capable of acting as a master. A
stealth server will only be known by other servers if
they are given static configuration data indicating
its existence.
Notify Set set of servers to be notified of changes to some
zone. Default is all servers named in the NS RRset,
except for any server also named in the SOA MNAME.
Some implementations will permit the name server
administrator to override this set or add elements to
it (such as, for example, stealth servers).
2.2. The zone's servers must be organized into a dependency graph
such that there is a primary master, and all other servers must use
AXFR or IXFR either from the primary master or from some slave which
is also a master. No loops are permitted in the AXFR dependency
graph.
3. NOTIFY Message
3.1. When a master has updated one or more RRs in which slave servers
may be interested, the master may send the changed RR's name, class,
type, and optionally, new RDATA(s), to each known slave server using
a best efforts protocol based on the NOTIFY opcode.
3.2. NOTIFY uses the DNS Message Format, although it uses only a
subset of the available fields. Fields not otherwise described
herein are to be filled with binary zero (0), and implementations
must ignore all messages for which this is not the case.
3.3. NOTIFY is similar to QUERY in that it has a request message with
the header QR flag "clear" and a response message with QR "set". The
response message contains no useful information, but its reception by
the master is an indication that the slave has received the NOTIFY
and that the master can remove the slave from any retry queue for
this NOTIFY event.
3.4. The transport protocol used for a NOTIFY transaction will be UDP
unless the master has reason to believe that TCP is necessary; for
example, if a firewall has been installed between master and slave,
and only TCP has been allowed; or, if the changed RR is too large to
fit in a UDP/DNS datagram.
3.5. If TCP is used, both master and slave must continue to offer
name service during the transaction, even when the TCP transaction is
not making progress. The NOTIFY request is sent once, and a
"timeout" is said to have occurred if no NOTIFY response is received
within a reasonable interval.
3.6. If UDP is used, a master periodically sends a NOTIFY request to
a slave until either too many copies have been sent (a "timeout"), an
ICMP message indicating that the port is unreachable, or until a
NOTIFY response is received from the slave with a matching query ID,
QNAME, IP source address, and UDP source port number.
Note:
The interval between transmissions, and the total number of
retransmissions, should be operational parameters specifiable by
the name server administrator, perhaps on a per-zone basis.
Reasonable defaults are a 60 second interval (or timeout if
using TCP), and a maximum of 5 retransmissions (for UDP). It is
considered reasonable to use additive or exponential backoff for
the retry interval.
3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an
unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A
slave receiving such a hint is free to treat equivilence of this
answer section with its local data as a "no further work needs to be
done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section
differs from the slave's local data, then the slave should query its
known masters to retrieve the new data.
3.8. In no case shall the answer section of a NOTIFY request be used
to update a slave's local data, or to indicate that a zone transfer
needs to be undertaken, or to change the slave's zone refresh timers.
Only a "data present; data same" condition can lead a slave to act
differently if ANCOUNT>0 than it would if ANCOUNT=0.
3.9. This version of the NOTIFY specification makes no use of the
authority or additional data sections, and so conforming
implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
requests. Since a future revision of this specification may define a
backwards compatible use for either or both of these sections,
current implementations must ignore these sections, but not the
entire message, if AUCOUNT>0 and/or ADCOUNT>0.
3.10. If a slave receives a NOTIFY request from a host that is not a
known master for the zone containing the QNAME, it should ignore the
request and produce an error message in its operations log.
Note:
This implies that slaves of a multihomed master must either know
their master by the "closest" of the master's interface
addresses, or must know all of the master's interface addresses.
Otherwise, a valid NOTIFY request might come from an address
that is not on the slave's state list of masters for the zone,
which would be an error.
3.11. The only defined NOTIFY event at this time is that the SOA RR
has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA,
the slave should behave as though the zone given in the QNAME had
reached its REFRESH interval (see [RFC1035]), i.e., it should query
its masters for the SOA of the zone given in the NOTIFY QNAME, and
check the answer to see if the SOA SERIAL has been incremented since
the last time the zone was fetched. If so, a zone transfer (either
AXFR or IXFR) should be initiated.
Note:
Because a deep server dependency graph may have multiple paths
from the primary master to any given slave, it is possible that
a slave will receive a NOTIFY from one of its known masters even
though the rest of its known masters have not yet updated their
copies of the zone. Therefore, when issuing a QUERY for the
zone's SOA, the query should be directed at the known master who
was the source of the NOTIFY event, and not at any of the other
known masters. This represents a departure from [RFC1035],
which specifies that upon expiry of the SOA REFRESH interval,
all known masters should be queried in turn.
3.12. If a NOTIFY request is received by a slave who does not
implement the NOTIFY opcode, it will respond with a NOTIMP
(unimplemented feature error) message. A master server who receives
such a NOTIMP should consider the NOTIFY transaction complete for
that slave.
4. Details and Examples
4.1. Retaining query state information across host reboots is
optional, but it is reasonable to simply execute an SOA NOTIFY
transaction on each authority zone when a server first starts.
4.2. Each slave is likely to receive several copies of the same
NOTIFY request: One from the primary master, and one from each other
slave as that slave transfers the new zone and notifies its potential
peers. The NOTIFY protocol supports this multiplicity by requiring
that NOTIFY be sent by a slave/master only AFTER it has updated the
SOA RR or has determined that no update is necessary, which in
practice means after a successful zone transfer. Thus, barring
delivery reordering, the last NOTIFY any slave receives will be the
one indicating the latest change. Since a slave always requests SOAs
and AXFR/IXFRs only from its known masters, it will have an
opportunity to retry its QUERY for the SOA after each of its masters
have completed each zone update.
4.3. If a master server seeks to avoid causing a large number of
simultaneous outbound zone transfers, it may delay for an arbitrary
length of time before sending a NOTIFY message to any given slave.
It is expected that the time will be chosen at random, so that each
slave will begin its transfer at a unique time. The delay shall not
in any case be longer than the SOA REFRESH time.
Note:
This delay should be a parameter that each primary master name
server can specify, perhaps on a per-zone basis. Random delays
of between 30 and 60 seconds would seem adequate if the servers
share a LAN and the zones are of moderate size.
4.4. A slave which receives a valid NOTIFY should defer action on any
subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
completed the transaction begun by the first NOTIFY. This duplicate
rejection is necessary to avoid having multiple notifications lead to
pummeling the master server.
4.5 Zone has Updated on Primary Master
Primary master sends a NOTIFY request to all servers named in Notify
Set. The NOTIFY request has the following characteristics:
query ID: (new)
op: NOTIFY (4)
resp: NOERROR
flags: AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
4.6 Zone has Updated on a Slave that is also a Master
As above in 4.5, except that this server's Notify Set may be
different from the Primary Master's due to optional static
specification of local stealth servers.
4.7 Slave Receives a NOTIFY Request from a Master
When a slave server receives a NOTIFY request from one of its locally
designated masters for the zone enclosing the given QNAME, with
QTYPE=SOA and QR=0, it should enter the state it would if the zone's
refresh timer had expired. It will also send a NOTIFY response back
to the NOTIFY request's source, with the following characteristics:
query ID: (same)
op: NOTIFY (4)
resp: NOERROR
flags: QR AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
This is intended to be identical to the NOTIFY request, except that
the QR bit is also set. The query ID of the response must be the
same as was received in the request.
4.8 Master Receives a NOTIFY Response from Slave
When a master server receives a NOTIFY response, it deletes this
query from the retry queue, thus completing the "notification
process" of "this" RRset change to "that" server.
5. Security Considerations
We believe that the NOTIFY operation's only security considerations
are:
1. That a NOTIFY request with a forged IP/UDP source address can
cause a slave to send spurious SOA queries to its masters,
leading to a benign denial of service attack if the forged
requests are sent very often.
2. That TCP spoofing could be used against a slave server given
NOTIFY as a means of synchronizing an SOA query and UDP/DNS
spoofing as a means of forcing a zone transfer.
6. References
[RFC1035]
Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[IXFR]
Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
7. Author's Address
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
Phone: +1 415 747 0204
EMail: paul@vix.com
ISO Plain Language
On this page
§1Why Notify Instead of Poll
Slow propagation of new and changed data in a DNS zone can be due to a zone's relatively long refresh times. Longer refresh times are beneficial because they reduce the load on the master servers, but that benefit comes at the cost of long intervals of incoherence among authoritative servers whenever the zone is updated.
The DNS NOTIFY transaction allows master servers to inform slave servers when the zone has changed, an interrupt as opposed to a poll model, which is hoped to reduce propagation delay while not unduly increasing the masters' load. This specification only allows slaves to be notified of SOA record changes, but the architecture of NOTIFY is intended to be extensible to other record types.
The document also gives more definition to the roles of master, slave and stealth servers, their enumeration in NS records, and the SOA MNAME field. In that sense it can be considered an addendum to RFC 1035.
Waiting on a timer keeps the server quiet but makes the data stale for longer. NOTIFY lets the master say changed right away, and the secondaries then do the work of fetching the new copy.
§2The Server Roles
The document defines the roles precisely. A slave is an authoritative server that uses zone transfer to retrieve the zone, and all slave servers are named in the NS records for the zone. A master is any authoritative server configured to be the source of zone transfer for one or more slaves. The primary master is the master server at the root of the zone transfer dependency graph, is named in the zone's SOA MNAME field and optionally by an NS record, and by definition there is only one per zone. A stealth server is like a slave except that it is not listed in an NS record; unless explicitly configured otherwise it sets the AA bit in responses and is capable of acting as a master, and other servers will only know of it if given static configuration data indicating its existence.
The Notify Set is the set of servers to be notified of changes to a zone. The default is all the servers named in the NS record set, except any server also named in the SOA MNAME. Some implementations let the administrator override this set or add elements to it, for example stealth servers.
The zone's servers must be organised into a dependency graph with a primary master, and all other servers must use AXFR or IXFR either from the primary master or from some slave that is also a master. No loops are permitted in the AXFR dependency graph.
There is one head server for a zone, and a set of servers that copy from it. NOTIFY goes to the ones in that set.
§3The NOTIFY Message
When a master has updated one or more records that slave servers may be interested in, it may send the changed record's name, class, type and optionally new data to each known slave using a best-efforts protocol based on the NOTIFY opcode.
NOTIFY uses the DNS message format, although it uses only a subset of the available fields. Fields not otherwise described are to be filled with binary zero, and implementations must ignore all messages for which this is not the case.
NOTIFY is similar to a query in that it has a request message with the QR flag clear and a response message with QR set. The response contains no useful information, but its reception by the master indicates that the slave received the NOTIFY, so the master can remove the slave from any retry queue for that event.
The transport is UDP unless the master has reason to believe TCP is necessary, for example if a firewall between master and slave allows only TCP, or if the changed record is too large to fit in a UDP datagram. If TCP is used, both sides must continue to offer name service during the transaction even when it is not making progress. The NOTIFY request is sent once, and a timeout is said to have occurred if no response arrives within a reasonable interval.
If UDP is used, a master periodically sends a NOTIFY request to a slave until too many copies have been sent, an ICMP message indicates that the port is unreachable, or a NOTIFY response arrives with a matching query ID, QNAME, source IP address and source UDP port number. The interval between transmissions and the total number of retransmissions should be operational parameters that the administrator can set, perhaps per zone. Reasonable defaults are a 60 second interval, or a timeout if using TCP, and a maximum of 5 retransmissions for UDP, with additive or exponential backoff considered reasonable for the retry interval.
A NOTIFY request has QDCOUNT greater than zero and the other counts at least zero. If ANCOUNT is greater than zero, the answer section is an insecure hint at the new record set for that name, class and type, and a slave that receives such a hint is free to treat equivalence with its local data as a sign that no further work is needed. If ANCOUNT is zero, or the answer differs from the slave's local data, the slave should query its known masters to retrieve the new data. In no case may the answer section be used to update a slave's local data, to indicate that a zone transfer needs to be undertaken, or to change the slave's zone refresh timers. This version of the specification makes no use of the authority or additional data sections, so conforming implementations should set those counts to zero when transmitting requests, and current implementations must ignore those sections if they are present, but not the entire message.
It is an ordinary DNS message with a new operation number, sent over UDP and repeated a few times until the other side answers. The answer the other side sends back carries no data; it only says the message arrived.
- 4Opcode — The NOTIFY operation code.
- T_SOAQTYPE — The only defined NOTIFY event is a change to the SOA record.
- AAFlags in the request — The authoritative answer bit is set in the request.
- QRFlags in the response — Clear in a request, set in the response.
- 1QDCOUNT — A NOTIFY request carries one question entry.
- 60 secondsDefault retry interval — Also the timeout when TCP is used.
- 5Maximum retransmissions — For UDP.
§3.11What a Slave Does on Receipt
The only defined NOTIFY event at this time is that the SOA record has changed. When the transaction for QTYPE=SOA completes, the slave should behave as though the zone had reached its REFRESH interval: it should query its masters for the SOA of the zone named in the NOTIFY, and check the answer to see whether the SOA serial has been incremented since the zone was last fetched. If so, a zone transfer, either AXFR or IXFR, should be initiated.
Because a deep dependency graph may have several paths from the primary master to a given slave, a slave may receive a NOTIFY from one of its known masters even though the others have not yet updated their copies. The query for the zone's SOA should therefore be directed at the known master that was the source of the NOTIFY, and not at the other known masters. This is a departure from RFC 1035, which specifies that when the SOA REFRESH interval expires, all known masters should be queried in turn.
If a slave receives a NOTIFY request from a host that is not a known master for the zone containing the name in the question, it should ignore the request and record an error in its operations log. This implies that slaves of a multihomed master must either know their master by the closest of the master's interface addresses, or know all of the master's interface addresses, or a valid request might come from an address that is not on the slave's list of masters for the zone, which would be an error.
On receiving the message the second copy checks the zone's serial number with the server that sent it, and if the number has gone up it fetches the new zone.
- NOTIFY requestQTYPE=SOA, sent over UDP and repeated until answered.
- NOTIFY responseQR set, carrying no useful information. It tells the master the message arrived.
- SOA queryDirected at the master that sent the NOTIFY.
- Zone transferStarted if the SOA serial has been incremented.
§4Details and Examples
Retaining query state across host reboots is optional, but it is reasonable to execute an SOA NOTIFY transaction on each authority zone when a server first starts.
Each slave is likely to receive several copies of the same NOTIFY request: one from the primary master, and one from each other slave as that slave transfers the new zone and notifies its potential peers. The protocol supports this multiplicity by requiring that NOTIFY be sent by a slave or master only after it has updated the SOA record or has determined that no update is necessary, which in practice means after a successful zone transfer. Thus, barring delivery reordering, the last NOTIFY any slave receives is the one indicating the latest change.
If a master wants to avoid causing a large number of simultaneous outbound zone transfers, it may delay for an arbitrary length of time before sending a NOTIFY to any given slave. The time is expected to be chosen at random, so that each slave begins its transfer at a unique time, and the delay shall not in any case be longer than the SOA REFRESH time. The RFC suggests random delays of between 30 and 60 seconds would be adequate if the servers share a LAN and the zones are of moderate size.
A slave that receives a valid NOTIFY should defer action on any subsequent NOTIFY with the same name, class and type until it has completed the transaction begun by the first one, since this duplicate rejection avoids having multiple notifications lead to pummelling the master server.
The message details are given as field lists. When the zone has updated on the primary master, it sends a NOTIFY request to all servers named in the Notify Set, with a new query ID, op NOTIFY (4), resp NOERROR, the AA flag, qcount 1, the zone name as qname, the zone class as qclass and T_SOA as qtype. When a slave that is also a master updates the zone, the same applies, except that its Notify Set may differ because of optional static specification of local stealth servers. When a slave receives a NOTIFY request from one of its designated masters with QTYPE=SOA and QR clear, it enters the state it would if the refresh timer had expired, and sends a NOTIFY response back to the source with the same query ID and with QR also set. When the master receives that response, it deletes the query from its retry queue, completing the notification process for that change and that server.
Copies of the message arrive from several servers, and the last one wins because a server only sends after it has the new data. The master can also stagger when it tells each server, so that they do not all fetch at once.
§5Security Considerations
The document believes the NOTIFY operation has only two security considerations.
First, a NOTIFY request with a forged IP and UDP source address can cause a slave to send spurious SOA queries to its masters, leading to a benign denial of service attack if the forged requests are sent very often.
Second, TCP spoofing could be used against a slave server given NOTIFY as a means of synchronizing an SOA query, and UDP or DNS spoofing as a means of forcing a zone transfer.
Because the message carries no proof of who sent it, someone could send fake ones to make the secondaries do extra work. The effect is a slowdown rather than anything worse.
- Forged source addressA slave can be made to send pointless SOA queries to its masters, a benign denial of service if sent often.
- Spoofed transfersTCP spoofing could synchronise an SOA query and UDP spoofing could force a zone transfer.