$Id: notify.txt,v 1.2 1994/10/27 02:51:25 vixie Exp $

Author: Paul Vixie

0. RATIONALE AND SCOPE

This document defines a new DNS opcode called NOTIFY whose numeric value is
4.  All fields not required for this initial use specification are required
to be zero, and implementations are free to ignore any request or response
packets for this this is not the case.  The intent is to permit future use
specifications to be backward compatible with implementations conforming
only to the initial use specification.

One section (query) and one RR type (SOA) are defined at this time.  Use of
the other sections or of other RR types is not defined by this document, and
implementations are allowed to ignore packets containing such values unless
they also implement some later standard that specifies their use.

1. NOTIFY PROTOCOL

When a master has updated an authoritative RR and has reason to suspect that
the slave servers will be interested in the fact of said update, it can
send the new RR to each known slave server using a best efforts protocol
based on the NOTIFY opcode.

NOTIFY is similar to QUERY in that it has an initiator packet with QR "off"
and a response packet with QR "on".  The response packet 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 remove it from the retry queue.

A NOTIFY is sent to a server repeatedly until either too many copies have
been sent (a "timeout") or until a NOTIFY-QR is received from the slave with
a matching query ID and IP source address.  The interval between
retransmissions, and the total number of retransmissions, is an operational
parameter specifiable by the name server administrator, perhaps on a per-
zone basis.  Reasonable defaults are a 60 second interval and 5 attempts; it
is also reasonable to use additive or exponential backoff for the retry
interval.

A NOTIFY packet has QCOUNT>0, ANCOUNT=AUCOUNT=ADCOUNT=0.  In the future, it
is expected that this specification will be amended such that ANCOUNT,
AUCOUNT, and/or ADCOUNT will be allowed to be nonzero, as a way to indicate
that the new data is contained within the NOTIFY packet, possibly along with
authentication data to validate this update.  For now we are defining NOTIFY
as merely a hint that the secondaries should query the master for a new copy
of the RR(s) specified in the query section.  As a result of this query,
the secondary may decide to take some action such as initiating a zone
transfer.

Note that there is at this time no specification for incremental updates; the
slave servers are _not_ free to overlay a previous AXFR's data with data
from a QUERY, even 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 a hint.

The only useful hint at this time is that the SOA has changed.  If a slave
retrieves an SOA due to a NOTIFY hint, and that SOA has a new serial number,
then a zone transfer should be initiated exactly as if the zone's refresh time
had been reached.  No other hints have defined consequences at this time, and
implementations are free to ignore them.

Definition: a master server is any authoritative server that is the source
	of AXFR from one or more slave servers.  The server named by the SOA
	may be a master unless the slave servers use some protocol other
	than AXFR to retrieve zone updates (e.g., FTP).

Definition: the primary master is the server at the root of the dependency
	tree.  It is the source of AXFR data for zero or more slaves.  The
	source of the primary master's copy of the zone is external to the
	DNS.  The primary master is named in the zone's SOA.

Definition: a slave server is any authoritative server that uses AXFR to
	retrieve the zone.

Corollary: the host named in a zone's SOA will either be a master or it will
	be some unrelated host where the zone data happens to be stored (an
	FTP or NFS server, for example.)

Requirement: for a zone to make use of the NOTIFY protocol, its servers must
	be organized into a tree such that there is a primary master, and
	all slaves must use AXFR either from the primary master or from some
	slave which is also a master.  No loops are permitted in the slave
	dependency graph.

Requirement: for a zone to make use of the NOTIFY protocol, all NS RRs at the
	root of the zone (under the delegation point) must use AXFR to do
	zone updates (e.g., rather than FTP or NFS.)

In order to support unregistered secondaries, all servers shall maintain a
list of host addresses that have successfully AXFR'd a given zone.  NOTIFY
requests must be sent to each such address whose last successful AXFR was
within the zone's REFRESH interval.  In addition, the primary master will
send a NOTIFY to all servers named by the zone's NS RR.

In a deep tree where some slaves AXFR new zones from other slaves, it can
happen that some slaves will receive multiple NOTIFYs of the same SOA change:
one from the primary master, and one from each slave-master that it has
AXFR'd from within the last REFRESH period.  The protocol permits this by
requiring that NOTIFY be sent by a slave-master only _after_ it has
successfully retrieved a zone.  Barring delivery reordering, the last NOTIFY
any slave receives will be the one indicating the latest change.  Since a
slave always requests SOA's and AXFR's from its own designated master(s), it
will have an opportunity to retry its SOA query after its master(s) have
completed each zone update.

A zone transfer that results from a NOTIFY should be staggered by a random
amount of time so that all the slaves will not synchronously request a zone
transfer whenever the serial number changes.  It is reasonable that the
delay will occur before the slave even bothers to ask for the new SOA, but
it is not reasonable for the master to insert the delay before sending the
NOTIFY to all secondaries.  The delay should be chosen to be between 10 and
60 seconds, unless these limits are overridden by the name server
administrator.

2. ZONE HAS UPDATED ON PRIMARY MASTER

Send a NOTIFY to all servers named in the NS RR except the one that is also
named in the SOA, and to all servers which have successfully AXFR'd the zone
within the last REFRESH interval, with the following characteristics:

	op:	NOTIFY
	resp:	NOERROR
	flags:	AA
	qcount:	1
	qname:	(zone name)
	qclass:	(zone class)
	qtype:	T_SOA
	ancount, aucount, adcount: 0

Note that setting any flag other than AA should cause slave servers to
ignore this query.  Only AA is defined, the others are all MBZ.

2a. ZONE HAS UPDATED ON SLAVE-MASTER

As above for PRIMARY MASTER, except that NOTIFY is sent only to recent AXFR
peers.  Servers named in the NS RR will only be notified by the PRIMARY
MASTER.

2. SLAVE RECEIVES A notify PACKET FROM PRIMARY MASTER OR SLAVE-MASTER

When a slave server receives a "NOTIFY" packet from one of its designated
masters for the zone enclosing the given QNAME, with QTYPE=SOA and !QR, it
marks its internal representation of the designated zone as "need to check
serial number", which operation should proceed as early as is convenient.
It will then send a packet back to the NOTIFY source, with the following
characteristics:

	op:	NOTIFY
	resp:	NOERROR
	flags:	QR AA
	qcount:	1
	qname:	(zone)
	qclass:	C_IN
	qtype:	T_SOA
	ancount, aucount, adcount: 0

Note that this is intentionally identical to the NOTIFY request except
that the QR bit is also set.

3. PRIMARY MASTER OR SLAVE-MASTER RECEIVES A notify-qr PACKET FROM SLAVE

When a master server receives a "NOTIFY" packet (with QR), it deletes this
query from the retry queue, thus completing the "notification process" of
this zone to this server.
