draft-ietf-dnsind-notify-07.txt   rfc1996.txt 
DNSIND Working Group Paul Vixie (ISC) Network Working Group P. Vixie
INTERNET-DRAFT March, 1996 Request for Comments: 1996 ISC
<draft-ietf-dnsind-notify-07.txt> Updates: 1035 August 1996
Category: Standards Track
Updates: RFC 1035
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of this Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the This document specifies an Internet standards track protocol for the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Internet community, and requests discussion and suggestions for
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), improvements. Please refer to the current edition of the "Internet
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or Official Protocol Standards" (STD 1) for the standardization state
ftp.isi.edu (US West Coast). and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This draft describes the NOTIFY opcode for DNS, by which a master 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 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 changed and that a query should be initiated to discover the new
data. data.
1 - Rationale and Scope 1. Rationale and Scope
1.1. Slow propagation of new and changed data in a DNS zone can be due 1.1. Slow propagation of new and changed data in a DNS zone can be
to a zone's relatively long refresh times. Longer refresh times are due to a zone's relatively long refresh times. Longer refresh times
beneficial in that they reduce load on the master servers, but that are beneficial in that they reduce load on the master servers, but
benefit comes at the cost of long intervals of incoherence among that benefit comes at the cost of long intervals of incoherence among
authority servers whenever the zone is updated. authority servers whenever the zone is updated.
1.2. The DNS NOTIFY transaction allows master servers to inform slave 1.2. The DNS NOTIFY transaction allows master servers to inform slave
servers when the zone has changed -- an interrupt as opposed to poll servers when the zone has changed -- an interrupt as opposed to poll
model -- which it is hoped will reduce propagation delay while not model -- which it is hoped will reduce propagation delay while not
unduly increasing the masters' load. This specification only allows unduly increasing the masters' load. This specification only allows
slaves to be notified of SOA RR changes, but the architechture of NOTIFY slaves to be notified of SOA RR changes, but the architechture of
is intended to be extensible to other RR types. NOTIFY is intended to be extensible to other RR types.
1.3. This document intentionally gives more definition to the roles of 1.3. This document intentionally gives more definition to the roles
``Master,'' ``Slave'' and ``Stealth'' servers, their enumeration in NS of "Master," "Slave" and "Stealth" servers, their enumeration in NS
RRs, and the SOA MNAME field. In that sense, this document can be RRs, and the SOA MNAME field. In that sense, this document can be
considered an addendum to [RFC1035]. considered an addendum to [RFC1035].
2 - Definitions and Invariants 2. Definitions and Invariants
2.1. The following definitions are used in this document: 2.1. The following definitions are used in this document:
Slave an authoritative server which uses zone transfer to Slave an authoritative server which uses zone transfer to
retrieve the zone. All slave servers are named in retrieve the zone. All slave servers are named in
the NS RRs for the zone. the NS RRs for the zone.
Master any authoritative server configured to be the source Master any authoritative server configured to be the source
of zone transfer for one or more slave servers. of zone transfer for one or more slave servers.
Primary Master master server at the root of the zone transfer Primary Master master server at the root of the zone transfer
dependency graph. The primary master is named in the dependency graph. The primary master is named in the
zone's SOA MNAME field and optionally by an NS RR. zone's SOA MNAME field and optionally by an NS RR.
There is by definition only one primary master server There is by definition only one primary master server
per zone. per zone.
Stealth like a slave server except not listed in an NS RR for Stealth like a slave server except not listed in an NS RR for
the zone. A stealth server, unless explicitly the zone. A stealth server, unless explicitly
configured to do otherwise, will set the AA bit in configured to do otherwise, will set the AA bit in
responses and be capable of acting as a master. A responses and be capable of acting as a master. A
stealth server will only be known by other servers if stealth server will only be known by other servers if
they are given static configuration data indicating they are given static configuration data indicating
its existence. its existence.
Notify Set set of servers to be notified of changes to some Notify Set set of servers to be notified of changes to some
zone. Default is all servers named in the NS RRset, zone. Default is all servers named in the NS RRset,
except for any server also named in the SOA MNAME. except for any server also named in the SOA MNAME.
Some implementations will permit the name server Some implementations will permit the name server
administrator to override this set or add elements to administrator to override this set or add elements to
it (such as, for example, stealth servers). it (such as, for example, stealth servers).
2.2. The zone's servers must be organized into a dependency graph such 2.2. The zone's servers must be organized into a dependency graph
that there is a primary master, and all other servers must use AXFR or such that there is a primary master, and all other servers must use
IXFR either from the primary master or from some slave which is also a AXFR or IXFR either from the primary master or from some slave which
master. No loops are permitted in the AXFR dependency graph. is also a master. No loops are permitted in the AXFR dependency
graph.
3 - NOTIFY Message 3. NOTIFY Message
3.1. When a master has updated one or more RRs in which slave servers 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, 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 type, and optionally, new RDATA(s), to each known slave server using
best efforts protocol based on the NOTIFY opcode. a best efforts protocol based on the NOTIFY opcode.
3.2. NOTIFY uses the DNS Message Format, although it uses only a subset 3.2. NOTIFY uses the DNS Message Format, although it uses only a
of the available fields. Fields not otherwise described herein are to subset of the available fields. Fields not otherwise described
be filled with binary zero (0), and implementations must ignore all herein are to be filled with binary zero (0), and implementations
messages for which this is not the case. 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 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 header QR flag "clear" and a response message with QR "set". The
The response message contains no useful information, but its reception response message contains no useful information, but its reception by
by the master is an indication that the slave has received the NOTIFY 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 and that the master can remove the slave from any retry queue for
NOTIFY event. this NOTIFY event.
3.4. The transport protocol used for a NOTIFY transaction will be UDP 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 unless the master has reason to believe that TCP is necessary; for
example, if a firewall has been installed between master and slave, and example, if a firewall has been installed between master and slave,
only TCP has been allowed; or, if the changed RR is too large to fit in and only TCP has been allowed; or, if the changed RR is too large to
a UDP/DNS datagram. fit in a UDP/DNS datagram.
3.5. If TCP is used, both master and slave must continue to offer name 3.5. If TCP is used, both master and slave must continue to offer
service during the transaction, even when the TCP transaction is not name service during the transaction, even when the TCP transaction is
making progress. The NOTIFY request is sent once, and a ``timeout'' is not making progress. The NOTIFY request is sent once, and a
said to have occurred if no NOTIFY response is received within a "timeout" is said to have occurred if no NOTIFY response is received
reasonable interval. within a reasonable interval.
3.6. If UDP is used, a master periodically sends a NOTIFY request to a 3.6. If UDP is used, a master periodically sends a NOTIFY request to
slave until either too many copies have been sent (a ``timeout''), an 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 ICMP message indicating that the port is unreachable, or until a
response is received from the slave with a matching query ID, QNAME, IP NOTIFY response is received from the slave with a matching query ID,
source address, and UDP source port number. QNAME, IP source address, and UDP source port number.
Note: Note:
The interval between transmissions, and the total number of The interval between transmissions, and the total number of
retransmissions, should be operational parameters specifiable by the retransmissions, should be operational parameters specifiable by
name server administrator, perhaps on a per-zone basis. Reasonable the name server administrator, perhaps on a per-zone basis.
defaults are a 60 second interval (or timeout if using TCP), and a Reasonable defaults are a 60 second interval (or timeout if
maximum of 5 retransmissions (for UDP). It is considered reasonable using TCP), and a maximum of 5 retransmissions (for UDP). It is
to use additive or exponential backoff for the retry interval. 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. 3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
If ANCOUNT>0, then the answer section represents an unsecure hint at the ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an
new RRset for this <QNAME,QCLASS,QTYPE>. A slave receiving such a hint unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A
is free to treat equivilence of this answer section with its local data slave receiving such a hint is free to treat equivilence of this
as a ``no further work needs to be done'' indication. If ANCOUNT=0, or answer section with its local data as a "no further work needs to be
ANCOUNT>0 and the answer section differs from the slave's local data, done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section
then the slave should query its known masters to retrieve the new data. 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 3.8. In no case shall the answer section of a NOTIFY request be used
update a slave's local data, or to indicate that a zone transfer needs to update a slave's local data, or to indicate that a zone transfer
to be undertaken, or to change the slave's zone refresh timers. Only a needs to be undertaken, or to change the slave's zone refresh timers.
``data present; data same'' condition can lead a slave to act
Only a "data present; data same" condition can lead a slave to act
differently if ANCOUNT>0 than it would if ANCOUNT=0. differently if ANCOUNT>0 than it would if ANCOUNT=0.
3.9. This version of the NOTIFY specification makes no use of the 3.9. This version of the NOTIFY specification makes no use of the
authority or additional data sections, and so conforming implementations authority or additional data sections, and so conforming
should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
future revision of this specification may define a backwards compatible requests. Since a future revision of this specification may define a
use for either or both of these sections, current implementations must backwards compatible use for either or both of these sections,
ignore these sections, but not the entire message, if AUCOUNT>0 and/or current implementations must ignore these sections, but not the
ADCOUNT>0. 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 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 known master for the zone containing the QNAME, it should ignore the
request and produce an error message in its operations log. request and produce an error message in its operations log.
Note: Note:
This implies that slaves of a multihomed master must either know This implies that slaves of a multihomed master must either know
their master by the ``closest'' of the master's interface addresses, their master by the "closest" of the master's interface
or must know all of the master's interface addresses. Otherwise, a addresses, or must know all of the master's interface addresses.
valid NOTIFY request might come from an address that is not on the Otherwise, a valid NOTIFY request might come from an address
slave's state list of masters for the zone, which would be an error. 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 3.11. The only defined NOTIFY event at this time is that the SOA RR
changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, the has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA,
slave should behave as though the zone given in the QNAME had reached the slave should behave as though the zone given in the QNAME had
its REFRESH interval (see [RFC1035]), i.e., it should query its masters reached its REFRESH interval (see [RFC1035]), i.e., it should query
for the SOA of the zone given in the NOTIFY QNAME, and check the answer its masters for the SOA of the zone given in the NOTIFY QNAME, and
to see if the SOA SERIAL has been incremented since the last time the check the answer to see if the SOA SERIAL has been incremented since
zone was fetched. If so, a zone transfer (either AXFR or IXFR) should the last time the zone was fetched. If so, a zone transfer (either
be initiated. AXFR or IXFR) should be initiated.
Note: Note:
Because a deep server dependency graph may have multiple paths from Because a deep server dependency graph may have multiple paths
the primary master to any given slave, it is possible that a slave from the primary master to any given slave, it is possible that
will receive a NOTIFY from one of its known masters even though the a slave will receive a NOTIFY from one of its known masters even
rest of its known masters have not yet updated their copies of the though the rest of its known masters have not yet updated their
zone. Therefore, when issuing a QUERY for the zone's SOA, the query copies of the zone. Therefore, when issuing a QUERY for the
should be directed at the known master who was the source of the zone's SOA, the query should be directed at the known master who
NOTIFY event, and not at any of the other known masters. This was the source of the NOTIFY event, and not at any of the other
represents a departure from [RFC1035], which specifies that upon known masters. This represents a departure from [RFC1035],
expiry of the SOA REFRESH interval, all known masters should be which specifies that upon expiry of the SOA REFRESH interval,
queried in turn. all known masters should be queried in turn.
4 - Details and Examples 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.1. Retaining query state information across host reboots is optional, 4. Details and Examples
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 4.1. Retaining query state information across host reboots is
request: One from the primary master, and one from each other slave as optional, but it is reasonable to simply execute an SOA NOTIFY
that slave transfers the new zone and notifies its potential peers. The transaction on each authority zone when a server first starts.
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 4.2. Each slave is likely to receive several copies of the same
determined that no update is necessary, which in practice means after a NOTIFY request: One from the primary master, and one from each other
successful zone transfer. Thus, barring delivery reordering, the last slave as that slave transfers the new zone and notifies its potential
NOTIFY any slave receives will be the one indicating the latest change. peers. The NOTIFY protocol supports this multiplicity by requiring
Since a slave always requests SOAs and AXFR/IXFRs only from its known that NOTIFY be sent by a slave/master only AFTER it has updated the
masters, it will have an opportunity to retry its QUERY for the SOA SOA RR or has determined that no update is necessary, which in
after each of its masters have completed each zone update. 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 4.3. If a master server seeks to avoid causing a large number of
simultaneous outbound zone transfers, it may delay for an arbitrary simultaneous outbound zone transfers, it may delay for an arbitrary
length of time before sending a NOTIFY message to any given slave. It length of time before sending a NOTIFY message to any given slave.
is expected that the time will be chosen at random, so that each slave It is expected that the time will be chosen at random, so that each
will begin its transfer at a unique time. The delay shall not in any slave will begin its transfer at a unique time. The delay shall not
case be longer than the SOA REFRESH time. in any case be longer than the SOA REFRESH time.
Note: Note:
This delay should be a parameter that each primary master name server This delay should be a parameter that each primary master name
can specify, perhaps on a per-zone basis. Random delays of between server can specify, perhaps on a per-zone basis. Random delays
30 and 60 seconds would seem adequate if the servers share a LAN and of between 30 and 60 seconds would seem adequate if the servers
the zones are of moderate size. share a LAN and the zones are of moderate size.
4.4. A slave which receives a valid NOTIFY should defer action on any 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 subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
completed the transaction begun by the first NOTIFY. This duplicate completed the transaction begun by the first NOTIFY. This duplicate
rejection is necessary to avoid having multiple notifications lead to rejection is necessary to avoid having multiple notifications lead to
pummeling the master server. pummeling the master server.
4.5 - Zone has Updated on Primary Master 4.5 Zone has Updated on Primary Master
Primary master sends a NOTIFY request to all servers named in Notify Primary master sends a NOTIFY request to all servers named in Notify
Set. The NOTIFY request has the following characteristics: Set. The NOTIFY request has the following characteristics:
query ID: (new) query ID: (new)
op: NOTIFY (4) op: NOTIFY (4)
resp: NOERROR resp: NOERROR
flags: AA flags: AA
qcount: 1 qcount: 1
qname: (zone name) qname: (zone name)
qclass: (zone class) qclass: (zone class)
qtype: T_SOA qtype: T_SOA
4.6 - Zone has Updated on a Slave that is also a Master 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 As above in 4.5, except that this server's Notify Set may be
from the Primary Master's due to optional static specification of local different from the Primary Master's due to optional static
stealth servers. specification of local stealth servers.
4.7 - Slave Receives a NOTIFY Request from a Master 4.7 Slave Receives a NOTIFY Request from a Master
When a slave server receives a NOTIFY request from one of its locally When a slave server receives a NOTIFY request from one of its locally
designated masters for the zone enclosing the given QNAME, with 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 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 refresh timer had expired. It will also send a NOTIFY response back
the NOTIFY request's source, with the following characteristics: to the NOTIFY request's source, with the following characteristics:
query ID: (same) query ID: (same)
op: NOTIFY (4) op: NOTIFY (4)
resp: NOERROR resp: NOERROR
flags: QR AA flags: QR AA
qcount: 1 qcount: 1
qname: (zone name) qname: (zone name)
qclass: (zone class) qclass: (zone class)
qtype: T_SOA qtype: T_SOA
This is intended to be identical to the NOTIFY request, except that the This is intended to be identical to the NOTIFY request, except that
QR bit is also set. The query ID of the response must be the same as the QR bit is also set. The query ID of the response must be the
was received in the request. same as was received in the request.
4.8 - Master Receives a NOTIFY Response from Slave 4.8 Master Receives a NOTIFY Response from Slave
When a master server receives a NOTIFY response, it deletes this query When a master server receives a NOTIFY response, it deletes this
from the retry queue, thus completing the ``notification process'' of query from the retry queue, thus completing the "notification
``this'' RRset change to ``that'' server. process" of "this" RRset change to "that" server.
5 - Security Considerations 5. Security Considerations
We believe that the NOTIFY operation's only security considerations are: 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 1. That a NOTIFY request with a forged IP/UDP source address can
slave to send spurious SOA queries to its masters, leading to a cause a slave to send spurious SOA queries to its masters,
benign denial of service attack if the forged requests are sent very leading to a benign denial of service attack if the forged
often. requests are sent very often.
2. That TCP spoofing could be used against a slave server given NOTIFY 2. That TCP spoofing could be used against a slave server given
as a means of synchronizing an SOA query and UDP/DNS spoofing as a NOTIFY as a means of synchronizing an SOA query and UDP/DNS
means of forcing a zone transfer. spoofing as a means of forcing a zone transfer.
6 - References 6. References
[RFC1035] [RFC1035]
P. Mockapetris, "Domain Names - Implementation and Specification", Mockapetris, P., "Domain Names - Implementation and
RFC 1035, USC/Information Sciences Institute, November 1987. Specification", STD 13, RFC 1035, November 1987.
[IXFR] [IXFR]
M. Ohta, "Incremental Zone Transfer", Internet Draft, February 1996, Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
<draft-ietf-dnsind-ixfr-06.txt>.
7 - Author's Address 7. Author's Address
Paul Vixie Paul Vixie
Internet Software Consortium Internet Software Consortium
Star Route Box 159A Star Route Box 159A
Woodside, CA 94062 Woodside, CA 94062
+1 415 747 0204
<paul@vix.com> Phone: +1 415 747 0204
EMail: paul@vix.com
 End of changes. 55 change blocks. 
202 lines changed or deleted 203 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/