396 lines
15 KiB
Plaintext
396 lines
15 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Vixie Standards Track [Page 1]
|
||
|
||
RFC 1996 DNS NOTIFY August 1996
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
Vixie Standards Track [Page 2]
|
||
|
||
RFC 1996 DNS NOTIFY August 1996
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
Vixie Standards Track [Page 3]
|
||
|
||
RFC 1996 DNS NOTIFY August 1996
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
Vixie Standards Track [Page 4]
|
||
|
||
RFC 1996 DNS NOTIFY August 1996
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Vixie Standards Track [Page 5]
|
||
|
||
RFC 1996 DNS NOTIFY August 1996
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Vixie Standards Track [Page 6]
|
||
|
||
RFC 1996 DNS NOTIFY August 1996
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Vixie Standards Track [Page 7]
|
||
|