draft-ietf-dnsind-notify-00.txt   draft-ietf-dnsind-notify-01.txt 
Internet Area P. Vixie Internet Area P. Vixie
DNSIND Working Group DNSIND Working Group Vixie Enterprises
<draft-ietf-dnsind-notify-00.txt> 30 November 1994
Updates: RFC 1035
Notify: a mechanism for prompt notification of authority zone changes Notify: a mechanism for prompt notification of authority zone changes
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 40
This draft describes a new DNS opcode, NOTIFY, by which a master This draft describes a new DNS opcode, NOTIFY, 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.
0. Rationale and Scope 0. Rationale and Scope
Slow propagation of new and changed data in a DNS zone can be due to 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 a zone's relatively long refresh times. Longer refresh times are
beneficial in that they reduce load on the master servers, but that beneficial in that they reduce load on the master servers, but that
benefit comes at the cost of new data not becoming available to DNS benefit comes at the cost of having changes not become visible to DNS
clients until a sometimes inconvenient interval has elapsed. clients until a sometimes inconvenient interval has elapsed.
The Notify DNS message allows master servers to inform slave servers The Notify DNS message allows master servers to inform slave servers
when data have changed, an interrupt as opposed to poll model, which when data have changed, an interrupt as opposed to poll model, which
it is hoped will reduce propagation delay while not unduly increasing it is hoped will reduce propagation delay while not unduly increasing
the masters' load. the masters' load.
This document defines a new DNS opcode called NOTIFY whose numeric This document defines a new DNS opcode called NOTIFY whose numeric
value is four (4). All fields not otherwise specified must contain value is four (4). All fields not otherwise specified must contain
binary zero, and implementations are free to ignore any request or binary zero, and implementations must ignore any request or response
packets where this is not the case.
<draft-vixie-dns-notify-00.txt>DNS NOTIFY 30 November 1994
response packets where this is not the case. The intent of this
requirement is to permit future use specifications to be backward
compatible with implementations conforming only to the initial use
specification.
This document intentionally gives more definition to the roles of DNS This document intentionally gives more definition to the roles of DNS
master and slave servers, their enumeration in NS RRs, and the SOA master and slave servers, their enumeration in NS RRs, and the SOA
MNAME field. In that sense, this document can be considered an MNAME field. In that sense, this document can be considered an
addendum to RFC 1035. addendum to RFC 1035.
1. NOTIFY Message 1. NOTIFY Message
When a master has updated one or more RRs in which slave servers may 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 and type to be interested, the master may send the changed RR's name, type, and
each known slave server using a best efforts protocol based on the optionally, new RDATA(s), to each known slave server using a best
NOTIFY opcode. efforts protocol based on the NOTIFY opcode.
One section (query) and one RR type (SOA) are defined at this time.
Use of other sections or of other RR types is not defined by this
document, and implementations are free to ignore packets containing
such values unless they also implement some future specification(s)
which specify their use.
NOTIFY is similar to QUERY in that it has an initiator packet with QR NOTIFY is similar to QUERY in that it has an initiator packet with QR
``set'' and a response packet with QR ``clear''. The response packet ``set'' and a response packet with QR ``clear''. The response packet
contains no useful information, but its reception by the master is a contains no useful information, but its reception by the master is a
hint that the slave has received the NOTIFY and that the master can hint that the slave has received the NOTIFY and that the master can
remove the slave from any retry queue for this NOTIFY event. remove the slave from any retry queue for this NOTIFY event.
A master repeatedly sends NOTIFY to a slave until either too many A master repeatedly sends NOTIFY to a slave until either too many
copies have been sent (a ``timeout'') or until a NOTIFY-QR is copies have been sent (a ``timeout'') or until a NOTIFY-QR is
received from the slave with a matching query ID, QNAME, and IP received from the slave with a matching query ID, QNAME, and IP
source address. The interval between retransmissions, and the total source address. The interval between retransmissions, and the total
number of retransmissions, should be operational parameters number of retransmissions, should be operational parameters
specifiable by the name server administrator, perhaps on a per-zone specifiable by the name server administrator, perhaps on a per-zone
basis. Reasonable defaults are a 60 second interval and 5 attempts. basis. Reasonable defaults are a 60 second interval and 5 attempts.
It is also reasonable to use additive or exponential backoff for the It is also reasonable to use additive or exponential backoff for the
retry interval. retry interval.
A NOTIFY packet has QCOUNT>0, ANCOUNT=AUCOUNT=ADCOUNT=0. In the A NOTIFY packet has QCOUNT>0, ANCOUNT>=0, AUCOUNT=ADCOUNT=0. If
future, it is expected that this specification will be amended such ANCOUNT is nonzero, then the answer section represents an unsecure
that ANCOUNT, AUCOUNT, and/or ADCOUNT may be allowed to be nonzero, hint at the new RR set for this <QNAME,QCLASS,QTYPE>. A slave
to indicate that the new data is contained within the NOTIFY packet, receiving such an update is free to treat equivilence of this answer
possibly along with authentication data to validate this update. For section with its local data as a ``no further work needs to be done''
now, NOTIFY is merely a hint that the slave server should query the indication; if ANCOUNT=0 or the answer section is present and differs
master for a new copy of the RR(s) specified in the query section. from the slave's local data, then the slave is required to query its
As a result of this query, the slave server may decide to take some defined masters to retrieve the new data. In no case shall the
action, such as initiating a zone transfer. answer section of a NOTIFY-!QR 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 based on a
NOTIFY-!QR answer section.
<draft-vixie-dns-notify-00.txt>DNS NOTIFY 30 November 1994 In the future, it is expected that this specification will be amended
such that AUCOUNT or ADCOUNT may be allowed to be nonzero, to
indicate that the new data is signed and secure, and can therefore be
trusted. Until that work has been completed and a standard has been
made, any packet with AUCOUNT<>0 or ADCOUNT<>0 must be ignored by any
server receiving it.
Note that there is at this time no specification for incremental NOTE
updates; the slave servers are NOT free to overlay a previous AXFR's There is at this time no specification for incremental
data with data from a QUERY, even if that QUERY occurred as a result updates; the slave servers are NOT free to overlay a
of a NOTIFY and the response to the QUERY is authoritative. NOTIFY previous AXFR's data with data from a non-AXFR QUERY, even
may be the basis on which incremental updates are specified, but at if that QUERY occurred as a result of a NOTIFY and the
response to the QUERY is authoritative. NOTIFY may be the
basis on which incremental updates are specified, but at
this time it is only an ``update hint.'' this time it is only an ``update hint.''
If a slave receives a NOTIFY request from a host which is not listed If a slave receives a NOTIFY request from a host which is not listed
in the slave's static list of masters for the zone containing the in the slave's static list of masters for the zone containing the
QNAME, it must ignore the request and may log an error in its QNAME, it must ignore the request and may log an error in its
operations log. This is necessary for security reasons. operations log. Implementations must also ignore NOTIFY requests
Implementations are also free to ignore NOTIFY requests that come that come from a UDP port other than the DNS port (53), as these are
from a UDP port other than the DNS port (53), as these are by by definition not from another name server.
definition not from another name server.
The only useful hint at this time is that the SOA RR has changed. The only useful hint at this time is that the SOA RR has changed.
Upon receipt of a NOTIFY hint for QTYPE=SOA, the slave should behave Upon completion of a NOTIFY transaction for QTYPE=SOA, the slave
as though the zone given in the QNAME had reached its REFRESH should behave as though the zone given in the QNAME had reached its
interval, i.e., it should query the master that sent the NOTIFY REFRESH interval [see RFC 1035], i.e., it should query the master
request, asking for the same QTYPE and QNAME as were given in the that sent the NOTIFY request, asking for the same QTYPE and QNAME as
NOTIFY request. If an answer comes, and the SOA RR has a newer were given in the NOTIFY request. If an answer comes, and the SOA RR
serial number than the slave's current copy of the zone, then a zone has a newer serial number than the slave's current copy of the zone,
transfer should be initiated. then a zone transfer should be initiated.
2. Some Definitions and Two Requirements 2. Some Definitions and Two Requirements
Definition: a Master Server is any authoritative server configured Definition: a Master Server is any authoritative server configured
to be the source of AXFR from one or more slave servers. It is to be the source of AXFR from one or more slave servers. It is
named in an NS RR for the zone. named in an NS RR for the zone.
Definition: a Slave Server is a possibly-authoritative server which Definition: a Slave Server is a quasi-authoritative server which
uses AXFR to retrieve the zone. All slave servers are named in uses AXFR to retrieve the zone. All slave servers are named in
the NS RRs for the zone. Slaves which use AXFR to retrieve a the NS RRs for the zone. Slaves which use AXFR to retrieve a
zone, and which respect the SOA timeouts, but which are not zone, and which respect the SOA timeouts, but which are not
listed in the zone's NS RR set, are ``unregistered''. listed in the zone's NS RR set, are ``unregistered''.
Unregistered slaves are sometimes used to hot-wire a cache, and Unregistered slaves are sometimes used to hot-wire a cache, and
are outside the scope of the DNS prototols, but NOTIFY defines are outside the scope of the DNS prototols, but NOTIFY defines
optional support for them. Note that a server is not, in the optional support for them. Note that a server is not, in the
strict RFC 1035 sense of the term, ``authoritative'' for a zones strict RFC 1035 sense of the term, ``authoritative'' for a zones
it loads via AXFR, unless it is listed in the zone's NS RR set. it loads via AXFR, unless it is listed in the zone's NS RR set.
The question of whether such servers should set the AA bit on The question of whether such servers should set the AA bit on
responses they generate from such data, remains open. responses they generate from such data, remains open.
Definition: the Primary Master Server is the master server at the Definition: the Primary Master Server is the master server at the
root of the AXFR dependency graph. The primary master is named root of the AXFR dependency graph. The primary master is named
in the zone's SOA MNAME field and by an NS RR. The source of in the zone's SOA MNAME field and by an NS RR. The source of
the primary master's zone data is external to the DNS and is not the primary master's zone data is external to the DNS and is not
a formal concern of this document. a formal concern of this document.
<draft-vixie-dns-notify-00.txt>DNS NOTIFY 30 November 1994
Requirement: for a zone to make use of the NOTIFY protocol, its Requirement: for a zone to make use of the NOTIFY protocol, its
servers must be organized into a dependency graph such that servers must be organized into a dependency graph such that
there is a primary master, and all other servers must use AXFR there is a primary master, and all other servers must use AXFR
either from the primary master or from some slave which is also either from the primary master or from some slave which is also
a master. A slave which is also a master is referred to later a master. A slave which is also a master is referred to later
in this document as a ``slave-master''. No loops are permitted in this document as a ``slave-master''. No loops are permitted
in the AXFR dependency graph. in the AXFR dependency graph.
Requirement: for a zone to make use of the NOTIFY protocol, all Requirement: for a zone to make use of the NOTIFY protocol, all
servers named in the zone's NS RR set (under the delegation servers named in the zone's NS RR set (under the delegation
skipping to change at page 4, line 45 skipping to change at page 4, line 49
master from which it has requested this RR's name and type within the master from which it has requested this RR's name and type within the
last SOA REFRESH interval. The protocol supports this multiplicity last SOA REFRESH interval. The protocol supports this multiplicity
by requiring that NOTIFY be sent by a slave-master only AFTER it has by requiring that NOTIFY be sent by a slave-master only AFTER it has
updated the RR. With an SOA NOTIFY, the RR can only change after a updated the RR. With an SOA NOTIFY, the RR can only change after a
subsequent AXFR. Thus, barring delivery reordering, the last NOTIFY subsequent AXFR. Thus, barring delivery reordering, the last NOTIFY
any slave receives will be the one indicating the latest change. any slave receives will be the one indicating the latest change.
Since a slave always requests SOAs and AXFRs only from its locally Since a slave always requests SOAs and AXFRs only from its locally
designated masters, it will have an opportunity to retry its SOA designated masters, it will have an opportunity to retry its SOA
query after its masters have completed each zone update. query after its masters have completed each zone update.
A zone transfer resulting from an SOA NOTIFY should be deferred for a If a master server seeks to avoid causing a large number of
random period of time so that a large number of slaves will not simultaneous outbound zone transfers, it may delay for an arbitrary
simultaneously request a zone transfer when the serial number length of time before sending a NOTIFY message to any given slave.
changes. It is reasonable that the delay will occur before the slave It is expected that the time will be chosen at random, so that each
even bothers to ask for the new SOA, but it is not reasonable for the slave will begin its transfer at a unique time, perhaps with some
master to insert the delay before sending the SOA NOTIFY to any weighting so that pending outbound NOTIFY's are more likely to be
slaves. The delay should be chosen to be between 10 and 60 seconds, sent out whenever a zone transfer completes. The delay shall not in
unless these limits are overridden by the name server administrator. any case be longer than the SOA REFRESH time, and 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 less
than a megabyte in size.
The rest of this section is concerned only with SOA NOTIFY. 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 multiplicitous notifications
lead to pummeling the master server.
<draft-vixie-dns-notify-00.txt>DNS NOTIFY 30 November 1994 The rest of this section is concerned only with SOA NOTIFY.
3.a. Zone has Updated on Primary Master 3.a. Zone has Updated on Primary Master
Primary master sends a NOTIFY request to all servers named in the NS Primary master sends a NOTIFY request to all servers named in the NS
RR, except the one that is also named in the SOA MNAME, and RR, except the one that is also named in the SOA MNAME, and
optionally to all name servers which have queried for this SOA within optionally to all name servers which have queried for this SOA within
the last SOA REFRESH interval. The NOTIFY has the following the last SOA REFRESH interval. The NOTIFY has the following
characteristics: characteristics:
query ID: (new) query ID: (new)
skipping to change at page 6, line 5 skipping to change at page 6, line 23
query ID: (same) query ID: (same)
op: NOTIFY op: NOTIFY
resp: NOERROR resp: NOERROR
flags: QR AA flags: QR AA
qcount: 1 qcount: 1
qname: (zone name) qname: (zone name)
qclass: C_IN qclass: C_IN
qtype: T_SOA qtype: T_SOA
ancount, aucount, adcount: 0 ancount, aucount, adcount: 0
<draft-vixie-dns-notify-00.txt>DNS NOTIFY 30 November 1994
Note that this is intentionally identical to the NOTIFY request, Note that this is intentionally identical to the NOTIFY request,
except that the QR bit is also set. Note, also, that the query ID except that the QR bit is also set. Note, also, that the query ID
must be the same as was received in the NOTIFY request. must be the same as was received in the NOTIFY request.
3.c. Master Receives a NOTIFY-QR Packet from Slave 3.c. Master Receives a NOTIFY-QR Packet from Slave
When a master server receives a NOTIFY packet (with QR), it deletes When a master server receives a NOTIFY packet (with QR), it deletes
this query from the retry queue, thus completing the ``notification this query from the retry queue, thus completing the ``notification
process'' of ``this'' RR change to ``that'' server. process'' of ``this'' RR change to ``that'' server.
 End of changes. 15 change blocks. 
61 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/