draft-ietf-dnsind-notify-03.txt   draft-ietf-dnsind-notify-04.txt 
Internet Area P. Vixie DNSIND Working Group Paul Vixie (ISC)
DNSIND Working Group Vixie Enterprises <draft-ietf-dnsind-notify-04.txt>
<draft-ietf-dnsind-notify-03.txt> 04-August-1995
Updates: RFC 1035 Updates: RFC 1035
Notify: a mechanism for prompt notification of authority zone changes DNS NOTIFY: a mechanism for prompt notification of zone changes
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc- This document is an Internet-Draft. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work- its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts. ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 35 skipping to change at page 1, line 35
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Abstract Abstract
This draft describes the NOTIFY opcode for DNS, by which a master This draft 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.
0. Rationale and Scope 0.0 - Rationale and Scope
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 having changes not become visible to DNS
clients until a potentially lengthy interval has elapsed.
The DNS NOTIFY transaction allows master servers to inform slave Slow propagation of new and changed data in a DNS zone can be due to a
servers when data have changed -- an interrupt as opposed to poll zone's relatively long refresh times. Longer refresh times are benefi-
model -- which it is hoped will reduce propagation delay while not cial in that they reduce load on the master servers, but that benefit
unduly increasing the masters' load. comes at the cost of long intervals of incoherence among authority
servers whenever the zone is updated.
This document defines a new DNS opcode called NOTIFY whose numeric The DNS NOTIFY transaction allows master servers to inform slave servers
value is four (4). All fields not otherwise specified must contain 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.
<draft-ietf-dnsind-notify-xx.txt> -2- 04-August-1995 This document defines a new DNS opcode called NOTIFY whose numeric value
is four (4). All fields not otherwise specified must contain binary
zero, and implementations must ignore any request or response packets
where this is not the case.
binary zero, and implementations must ignore any request or response This document intentionally gives more definition to the roles of ``Mas-
packets where this is not the case. ter,'' ``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].
This document intentionally gives more definition to the roles of 1.0 - NOTIFY Message
``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 RFC 1035.
1. NOTIFY Message 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.
When a master has updated one or more RRs in which slave servers may NOTIFY borrows its packet data format from QUERY, although it uses only
be interested, the master may send the changed RR's name, class, a subset of the fields present. Fields not otherwise described herein
type, and optionally, new RDATA(s), to each known slave server using are to be filled with binary zero (0), and implementations must ignore
a best efforts protocol based on the NOTIFY opcode. all packets for which this is not the case.
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 an
hint that the slave has received the NOTIFY and that the master can indication that the slave has received the NOTIFY and that the master
remove the slave from any retry queue for this NOTIFY event. can remove the slave from any retry queue for this NOTIFY event.
A master repeatedly sends NOTIFY to a slave 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, QNAME, and IP
source address. The interval between retransmissions, and the total
number of retransmissions, should be operational parameters specifi-
able 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>=0, AUCOUNT>=0, ADCOUNT>=0. If
ANCOUNT is nonzero, then the answer section represents an unsecure
hint at the new RR set for this <QNAME,QCLASS,QTYPE>. A slave
receiving such an update 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 the answer section is present and differs
from the slave's local data, then the slave should query its defined
masters to retrieve the new data. In no case shall the answer sec-
tion 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.
This version of the NOTIFY specification makes no use of the author-
ity or additional data sections, and so conforming implementations
should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since
<draft-ietf-dnsind-notify-xx.txt> -3- 04-August-1995
a future revision of this specification may define a backwards com- A master repeatedly sends NOTIFY-!QR to a slave until either too many
patible use for either or both of these sections, current implementa- copies have been sent (a ``timeout''), an ICMP message indicating that
tions must ignore them if present. the port, host, or net is unreachable, or until a NOTIFY-QR is received
from the slave with a matching query ID, QNAME, and IP source address.
The interval between retransmissions, and the total number of retrans-
missions, should be operational parameters 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.
If a slave receives a NOTIFY request from a host that is not listed A NOTIFY-!QR packet has QCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0.
in the slave's static list of masters for the zone containing the If ANCOUNT is nonzero, then the answer section represents an unsecure
QNAME, it should ignore the request and produce an error message in hint at the new RR set for this <QNAME,QCLASS,QTYPE>. A slave receiving
its operations log. 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 the answer section is present and differs from the slave's
local data, then the slave should query its known masters to retrieve
the new data. In no case shall the 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 if ANCOUNT>0 than it would if ANCOUNT==0.
NOTE: This implies that slaves of a multihomed master must either This version of the NOTIFY specification makes no use of the authority
specify the ``closest'' of the master's interface addresses, or additional data sections, and so conforming implementations should
or must list them all. Otherwise, the NOTIFY-!QR might come set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a future
from an address that is not on the slave's state list of mas- revision of this specification may define a backwards compatible use for
ters for the zone, which would be an artificial error. either or both of these sections, current implementations must ignore
these sections, but not the entire packet, if AUCOUNT>0 and/or
ADCOUNT>0.
The only useful hint at this time is that the SOA RR has changed. If a slave receives a NOTIFY request from a host that is not a known
Upon completion of a NOTIFY transaction for QTYPE=SOA, the slave master for the zone containing the QNAME, it should ignore the request
should behave as though the zone given in the QNAME had reached its and produce an error message in its operations log.
REFRESH interval [see RFC 1035], i.e., it should query the master
that sent the NOTIFY request, asking for the same QTYPE and QNAME as
were given in the NOTIFY request. If an answer comes, and the SOA RR
has a newer serial number than the slave's current copy of the zone,
then a zone transfer should be initiated.
2. Some Definitions and Two Requirements 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-!QR might come from an address that is not on the
slave's state list of masters for the zone, which would be an artifi-
cial error.
Definition: the Primary Master Server is the host at the The only defined NOTIFY event at this time is that the SOA RR has
root of the AXFR/IXFR dependency graph. The primary master is changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, the
named in the zone's SOA MNAME field, and optionally by an NS RR. slave should behave as though the zone given in the QNAME had reached
The source of the primary master's zone data is external to the its REFRESH interval (see [RFC1035]), i.e., it should query its masters
DNS, for example, the host's file system. 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. (See [IXFR] for more information about incremental zone
transfers.)
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 repre-
sents a departure from [RFC1035], which specifies that upon expiry of
the SOA REFRESH interval, all known masters should be queried in
turn.
Definition: a Master Server is any authoritative server configured 2.0 - Definitions and Invariants
to be the source of AXFR/IXFR from one or more slave servers.
It is named in an NS RR for the zone.
Definition: a Slave Server is a an authoritative server that uses The following definitions are used in this document:
AXFR/IXFR to retrieve the zone. All slave servers are named in
the NS RRs for the zone. A slave server can also act as a mas-
ter in the case of a deep AXFR/IXFR tree.
Definition: a Stealth Server is a potentially authoritative server Slave an authoritative server which uses zone transfer to
that uses AXFR/IXFR as described above for ``Slave Server.'' retrieve the zone. All slave servers are named in
Stealth servers are not named in the NS RRs for the zone, and the NS RRs for the zone.
are thus useful only as a way to ``hotwire the cache.'' A
stealth server will, unless explicitly configured to do other-
wise, set the AA bit in responses and is capable of acting as a
Master. A stealth server will only be recognized by other
<draft-ietf-dnsind-notify-xx.txt> -4- 04-August-1995 Master any authoritative server configured to be the source
of zone transfer for one or more slave servers. All
slave servers are named in the NS RRs for the zone.
servers if it sends queries from the DNS service port (UDP 53). Primary Master master server at the root of the zone transfer depen-
dency 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.
Requirement: for a zone to make use of the NOTIFY protocol, its Stealth like a slave server except not listed in an NS RR for
servers must be organized into a dependency graph such that the zone. A stealth server, unless explicitly con-
there is a primary master, and all other servers must use AXFR figured to do otherwise, will set the AA bit in
either from the primary master or from some slave which is also responses and be capable of acting as a master. A
a master. No loops are permitted in the AXFR dependency graph. stealth server will only be recognized by other
servers if it sends queries from the DNS service port
(UDP 53).
Requirement: for a zone to make use of the NOTIFY protocol, all The zone's servers must be organized into a dependency graph such that
servers named in the zone's NS RR set (under the delegation there is a primary master, and all other servers must use AXFR or IXFR
point) must use AXFR to do zone updates, or, if some other pro- either from the primary master or from some slave which is also a mas-
tocol is used (e.g., FTP or NFS), it must simulate all of the ter. No loops are permitted in the AXFR dependency graph.
semantics of SOA/AXFR/IXFR.
3. Semantic Details 3.0 - Semantic Details
Master servers should maintain a list of stealth servers which have Master servers should maintain a list of stealth servers which have
queried the SOA of the zone within the last SOA REFRESH interval. On queried the SOA of the zone within the last SOA REFRESH interval. On a
a best efforts basis, NOTIFY requests should be sent to each slave best efforts basis, NOTIFY requests should be sent to each slave server
server address whose last successful query for the changed RR's name address whose last successful query for the changed RRset's
and type was within that interval. (Retaining this state information <name,class,type> was within that interval. (Retaining this state
across host reboots is optional, but it is reasonable to simply exe- information across host reboots is optional, but it is reasonable to
cute a NOTIFY transaction on each authority zone when a server first simply execute an SOA NOTIFY transaction on each authority zone when a
starts.) server first starts.)
In a deep tree where some slaves fetch new zones from other slaves,
it can happen that some slaves will receive multiple NOTIFYs of the
same RR change: one from the primary master, and one from each other
slave from which it has requested this RR's name and type within the
last SOA REFRESH interval. The protocol supports this multiplicity
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
subsequent AXFR/IXFR. 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 locally designated masters, it will have an opportunity to retry
its SOA query after its masters have completed each zone update.
If a master server seeks to avoid causing a large number of simulta-
neous 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, perhaps with some weighting
so that pending outbound NOTIFY's are more likely to be sent out
whenever a zone transfer completes. The delay shall not in 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
<draft-ietf-dnsind-notify-xx.txt> -5- 04-August-1995
adequate if the servers share a LAN and the zones are less than a In a deep tree where some slaves fetch new zones from other slaves, it
megabyte in size. can happen that some slaves will receive multiple NOTIFYs of the same RR
change: one from the primary master, and one from each other slave from
which it has requested this RRset's <name,class,type< within the last
SOA REFRESH interval. The 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.
A slave which receives a valid NOTIFY should defer action on any sub- If a master server seeks to avoid causing a large number of simultaneous
sequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has com- outbound zone transfers, it may delay for an arbitrary length of time
pleted the transaction begun by the first NOTIFY. This duplicate before sending a NOTIFY message to any given slave. It is expected that
rejection is necessary to avoid having multiple notifications lead to the time will be chosen at random, so that each slave will begin its
pummeling the master server. transfer at a unique time. The delay shall not in 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 of moderate size.
The rest of this section is concerned only with SOA NOTIFY. A slave which receives a valid NOTIFY should defer action on any subse-
quent 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.
3.a. Zone has Updated on Primary Master 3.1 - Zone has Updated on Primary Master
Primary master sends a NOTIFY request to all servers named in the NS Primary master sends a NOTIFY-!QR request to all servers named in the NS
RR, except the one that is also named in the SOA MNAME, and option- RR, except the one that is also named in the SOA MNAME, and optionally
ally to all name servers which have queried for this SOA within the to all name servers which have queried for this SOA within the last SOA
last SOA REFRESH interval. The NOTIFY has the following characteris- REFRESH interval. The NOTIFY has the following characteristics:
tics:
query ID: (new) query ID: (new)
op: NOTIFY op: NOTIFY
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
ancount, aucount, adcount: 0
Note that setting any flag other than AA should cause slave servers 3.1.1 - Zone has Updated on a Slave that is also a Master
to ignore this query. Only AA is defined, the others all must con-
tain binary zero.
3.a.1. Zone has Updated on a Slave that is also a Master
As above in 3.a, except that only those authoritative name servers As above in 3.1, except that only those authoritative name servers
(i.e., those listed in the zone's NS RR set) which have queried for (i.e., those listed in the zone's NS RRset) which have queried for this
this name and type within the SOA REFRESH interval need to be noti- name and type within the SOA REFRESH interval need to be notified.
fied. Optionally, the slave/master may send to all servers which Optionally, the slave/master may send to all servers which have sent
have sent such recent queries, without regard to whether they are such recent queries, without regard to whether they are listed in the
listed in the zone's NS RR set. zone's NS RRset.
3.b. Slave Receives a NOTIFY Packet from a Master 3.2 - Slave Receives a NOTIFY-!QR Packet 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, it should enter the state it would if the zone's QTYPE=SOA and !QR, it should enter the state it would if the zone's
refresh timer had expired. It will also send a NOTIFY response back refresh timer had expired. It will also send a NOTIFY response back to
the NOTIFY request's source, with the following characteristics:
<draft-ietf-dnsind-notify-xx.txt> -6- 04-August-1995
to the NOTIFY request's source, with the following characteristics:
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: (zone class) qclass: (zone class)
qtype: T_SOA qtype: T_SOA
ancount, aucount, adcount: 0
Note that this is intentionally identical to the NOTIFY request, This is intended to be identical to the NOTIFY-!QR, except that the QR
except that the QR bit is also set. Note, also, that the query ID bit is also set, and the query ID must be the same as was received in
must be the same as was received in the NOTIFY request. the NOTIFY-!QR request.
3.c. Master Receives a NOTIFY-QR Packet from Slave 3.2 - 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-QR packet, it deletes this query
this query from the retry queue, thus completing the ``notification from the retry queue, thus completing the ``notification process'' of
process'' of ``this'' RR change to ``that'' server. ``this'' RRset change to ``that'' server.
Security Considerations Security Considerations
We believe that the NOTIFY operation's only security considerations We believe that the NOTIFY operation's only security considerations are:
are: (A) that a previous SOA query can optionally cause a master to
NOTIFY a false slave; (B) that a NOTIFY request with a forged IP/UDP 1. That a previous SOA query can optionally cause a master to NOTIFY a
source address can cause a slave to send spurious SOA queries to its false slave.
masters, leading to a benign denial of service attack if the forged
requests are sent very often; and (C) that TCP spoofing could be used 2. That a NOTIFY request with a forged IP/UDP source address can cause a
against a slave server given NOTIFY as a means of synchronizing an slave to send spurious SOA queries to its masters, leading to a
SOA query and UDP/DNS spoofing as a means of forcing a zone transfer. benign denial of service attack if the forged requests are sent very
often.
3. 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.
References
[RFC1035]
P. Mockapetris, "Domain Names - Implementation and Specification",
RFC 1035, USC/Information Sciences Institute, November 1987.
[IXFR]
M. Ohta, "Incremental Zone Transfer", Internet Draft, July 1995,
<draft-ietf-dnsind-ixfr-02.txt>.
Author's Address Author's Address
Paul Vixie Paul Vixie
Vixie Enterprises Internet Software Consortium
Star Route Box 159A Star Route Box 159A
Woodside, CA 94062 Woodside, CA 94062
+1 415 747 0204
Phone: +1 415 747 0204 <paul@vix.com>
E-Mail: paul@vix.com
 End of changes. 43 change blocks. 
197 lines changed or deleted 197 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/