draft-ietf-dnsind-notify-05.txt   draft-ietf-dnsind-notify-06.txt 
DNSIND Working Group Paul Vixie (ISC) DNSIND Working Group Paul Vixie (ISC)
<draft-ietf-dnsind-notify-05.txt> <draft-ietf-dnsind-notify-06.txt>
Updates: RFC 1035 Updates: RFC 1035
DNS NOTIFY: a mechanism for prompt notification of zone changes A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
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
uments of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas,
its working groups. Note that other groups may also distribute work- and its working groups. Note that other groups may also distribute
ing documents as Internet-Drafts. working 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
time. It is inappropriate to use Internet-Drafts as reference mate- time. It is inappropriate to use Internet-Drafts as reference
rial or to cite them other than as `work in progress.' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
Rim). ftp.isi.edu (US West Coast).
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.0 - Rationale and Scope 1 - Rationale and Scope
Slow propagation of new and changed data in a DNS zone can be due to a 1.1. Slow propagation of new and changed data in a DNS zone can be due
zone's relatively long refresh times. Longer refresh times are benefi- to a zone's relatively long refresh times. Longer refresh times are
cial in that they reduce load on the master servers, but that benefit beneficial in that they reduce load on the master servers, but that
comes at the cost of long intervals of incoherence among authority benefit comes at the cost of long intervals of incoherence among
servers whenever the zone is updated. authority servers whenever the zone is updated.
The DNS NOTIFY transaction allows master servers to inform slave servers 1.2. The DNS NOTIFY transaction allows master servers to inform slave
when the zone has changed -- an interrupt as opposed to poll model -- servers when the zone has changed -- an interrupt as opposed to poll
which it is hoped will reduce propagation delay while not unduly model -- which it is hoped will reduce propagation delay while not
increasing the masters' load. 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.
This document defines a new DNS opcode called NOTIFY whose numeric value 1.3. This document intentionally gives more definition to the roles of
is four (4). All fields not otherwise specified must contain binary ``Master,'' ``Slave'' and ``Stealth'' servers, their enumeration in NS
zero, and implementations must ignore any request or response packets RRs, and the SOA MNAME field. In that sense, this document can be
where this is not the case. considered an addendum to [RFC1035].
This document intentionally gives more definition to the roles of ``Mas- 2 - Definitions and Invariants
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].
1.0 - NOTIFY Message 2.1. The following definitions are used in this document:
When a master has updated one or more RRs in which slave servers may be Slave an authoritative server which uses zone transfer to
interested, the master may send the changed RR's name, class, type, and retrieve the zone. All slave servers are named in
optionally, new RDATA(s), to each known slave server using a best the NS RRs for the zone.
efforts protocol based on the NOTIFY opcode.
NOTIFY borrows its packet data format from QUERY, although it uses only Master any authoritative server configured to be the source
a subset of the fields present. Fields not otherwise described herein of zone transfer for one or more slave servers.
are to be filled with binary zero (0), and implementations must ignore
all packets for which this is not the case.
NOTIFY is similar to QUERY in that it has an initiator packet with QR Primary Master master server at the root of the zone transfer
``set'' and a response packet with QR ``clear''. The response packet dependency graph. The primary master is named in the
contains no useful information, but its reception by the master is an zone's SOA MNAME field and optionally by an NS RR.
indication that the slave has received the NOTIFY and that the master There is by definition only one primary master server
can remove the slave from any retry queue for this NOTIFY event. per zone.
A master repeatedly sends NOTIFY-!QR to a slave until either too many Stealth like a slave server except not listed in an NS RR for
copies have been sent (a ``timeout''), an ICMP message indicating that the zone. A stealth server, unless explicitly
the port, host, or net is unreachable, or until a NOTIFY-QR is received configured to do otherwise, will set the AA bit in
from the slave with a matching query ID, QNAME, and IP source address. responses and be capable of acting as a master. A
The interval between retransmissions, and the total number of retrans- stealth server will only be known by other servers if
missions, should be operational parameters specifiable by the name they are given static configuration data indicating
server administrator, perhaps on a per-zone basis. Reasonable defaults its existence.
are a 60 second interval and 5 attempts. It is also reasonable to use
additive or exponential backoff for the retry interval.
A NOTIFY-!QR packet has QCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0. Notify Set set of servers to be notified of changes to some
If ANCOUNT is nonzero, then the answer section represents an unsecure zone. Default is all servers named in the NS RRset,
hint at the new RR set for this <QNAME,QCLASS,QTYPE>. A slave receiving except for any server also named in the SOA MNAME.
such a hint is free to treat equivilence of this answer section with its Some implementations will permit the name server
local data as a ``no further work needs to be done'' indication; if administrator to override this set or add elements to
ANCOUNT=0 or the answer section is present and differs from the slave's it (such as, for example, stealth servers).
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.
This version of the NOTIFY specification makes no use of the authority 2.2. The zone's servers must be organized into a dependency graph such
or additional data sections, and so conforming implementations should that there is a primary master, and all other servers must use AXFR or
set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a future IXFR either from the primary master or from some slave which is also a
revision of this specification may define a backwards compatible use for master. No loops are permitted in the AXFR dependency graph.
either or both of these sections, current implementations must ignore
these sections, but not the entire packet, if AUCOUNT>0 and/or 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 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 ``set'' and a response message with QR ``clear''.
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. A master repeatedly 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, and IP source
address.
Note:
The interval between retransmissions, 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 and 5 attempts. It is also
reasonable to use additive or exponential backoff for the retry
interval.
3.4. A NOTIFY request has QCOUNT>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.5. 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. Only a
``data present; data same'' condition can lead a slave to act
differently if ANCOUNT>0 than it would if ANCOUNT=0.
3.6. 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. ADCOUNT>0.
If a slave receives a NOTIFY request from a host that is not a known 3.7. If a slave receives a NOTIFY request from a host that is not a
master for the zone containing the QNAME, it should ignore the request known master for the zone containing the QNAME, it should ignore the
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 addresses,
or must know all of the master's interface addresses. Otherwise, a 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 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 artifi- slave's state list of masters for the zone, which would be an error.
cial error.
The only defined NOTIFY event at this time is that the SOA RR has 3.8. 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 changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, the
slave should behave as though the zone given in the QNAME had reached 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 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 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 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 zone was fetched. If so, a zone transfer (either AXFR or IXFR) should
be initiated. (See [IXFR] for more information about incremental zone be initiated.
transfers.)
Note: Note:
Because a deep server dependency graph may have multiple paths from Because a deep server dependency graph may have multiple paths from
the primary master to any given slave, it is possible that a slave 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 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 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 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 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- NOTIFY event, and not at any of the other known masters. This
sents a departure from [RFC1035], which specifies that upon expiry of represents a departure from [RFC1035], which specifies that upon
the SOA REFRESH interval, all known masters should be queried in expiry of the SOA REFRESH interval, all known masters should be
turn. queried in turn.
2.0 - Definitions and Invariants
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. All
slave servers are named in the NS RRs for the zone.
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.
Stealth like a slave server except not listed in an NS RR for
the zone. A stealth server, unless explicitly con-
figured 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.
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 mas-
ter. No loops are permitted in the AXFR dependency graph.
3.0 - Semantic Details 4 - Semantic Details 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.
On a best efforts basis, NOTIFY requests should be sent to each slave 4.2. Each slave is likely to receive several copies of the same NOTIFY
server whose last successful query for the changed RRset's request: One from the primary master, and one from each other slave as
<name,class,type> was within the SOA refresh interval. Master servers that slave transfers the new zone and notifies its potential peers. The
might also be statically configured with a list of stealth servers who NOTIFY protocol supports this multiplicity by requiring that NOTIFY be
should be notified of zone SOA changes. Retaining query state informa- sent by a slave/master only AFTER it has updated the SOA RR or has
tion across host reboots is optional, but it is reasonable to simply determined that no update is necessary, which in practice means after a
execute an SOA NOTIFY transaction on each authority zone when a server successful zone transfer. Thus, barring delivery reordering, the last
first starts. 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.
In a deep tree where some slaves fetch new zones from other slaves, it 4.3. If a master server seeks to avoid causing a large number of
can happen that some slaves will receive multiple NOTIFYs of the same RR simultaneous outbound zone transfers, it may delay for an arbitrary
change: one from the primary master, and one from each other slave from length of time before sending a NOTIFY message to any given slave. It
which it has requested this RRset's <name,class,type< within the last is expected that the time will be chosen at random, so that each slave
SOA REFRESH interval. The protocol supports this multiplicity by will begin its transfer at a unique time. The delay shall not in any
requiring that NOTIFY be sent by a slave/master only AFTER it has case be longer than the SOA REFRESH time.
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.
If a master server seeks to avoid causing a large number of simultaneous Note:
outbound zone transfers, it may delay for an arbitrary length of time This delay should be a parameter that each primary master name server
before sending a NOTIFY message to any given slave. It is expected that can specify, perhaps on a per-zone basis. Random delays of between
the time will be chosen at random, so that each slave will begin its 30 and 60 seconds would seem adequate if the servers share a LAN and
transfer at a unique time. The delay shall not in any case be longer the zones are of moderate size.
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.
A slave which receives a valid NOTIFY should defer action on any subse- 4.4. A slave which receives a valid NOTIFY should defer action on any
quent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has completed subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
the transaction begun by the first NOTIFY. This duplicate rejection is completed the transaction begun by the first NOTIFY. This duplicate
necessary to avoid having multiple notifications lead to pummeling the rejection is necessary to avoid having multiple notifications lead to
master server. pummeling the master server.
3.1 - Zone has Updated on Primary Master 4.5 - Zone has Updated on Primary Master
Primary master sends a NOTIFY-!QR request to all servers named in the NS Primary master sends a NOTIFY request to all servers named in Notify
RR, except the one that is also named in the SOA MNAME, and optionally Set. The NOTIFY request has the following characteristics:
to all name servers which have queried for this SOA within the last SOA
REFRESH interval. The NOTIFY has the following characteristics:
query ID: (new) query ID: (new)
op: NOTIFY 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
3.1.1 - 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 3.1, except that only those authoritative name servers As above in 4.5, except that this server's Notify Set may be different
(i.e., those listed in the zone's NS RRset) which have queried for this from the Primary Master's due to optional static specification of local
name and type within the SOA REFRESH interval need to be notified. stealth servers.
Optionally, the slave/master may send to all servers which have sent
such recent queries, without regard to whether they are listed in the
zone's NS RRset.
3.2 - Slave Receives a NOTIFY-!QR Packet 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, 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 to
the NOTIFY request's source, with the following characteristics: the NOTIFY request's source, with the following characteristics:
query ID: (same) query ID: (same)
op: NOTIFY 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-!QR, except that the QR This is intended to be identical to the NOTIFY request, except that the
bit is also set, and the query ID must be the same as was received in QR bit is also set. The query ID of the response must be the same as
the NOTIFY-!QR request. was received in the request.
3.2 - Master Receives a NOTIFY-QR Packet from Slave 4.8 - Master Receives a NOTIFY Response from Slave
When a master server receives a NOTIFY-QR packet, it deletes this query When a master server receives a NOTIFY response, it deletes this query
from the retry queue, thus completing the ``notification process'' of from the retry queue, thus completing the ``notification process'' of
``this'' RRset change to ``that'' server. ``this'' RRset change to ``that'' server.
Security Considerations 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 previous SOA query can optionally cause a master to NOTIFY a 1. That a previous SOA query can optionally cause a master to NOTIFY a
false slave. false slave.
skipping to change at page 7, line 34 skipping to change at page 7, line 28
as a means of synchronizing an SOA query and UDP/DNS spoofing as a as a means of synchronizing an SOA query and UDP/DNS spoofing as a
means of forcing a zone transfer. means of forcing a zone transfer.
References References
[RFC1035] [RFC1035]
P. Mockapetris, "Domain Names - Implementation and Specification", P. Mockapetris, "Domain Names - Implementation and Specification",
RFC 1035, USC/Information Sciences Institute, November 1987. RFC 1035, USC/Information Sciences Institute, November 1987.
[IXFR] [IXFR]
M. Ohta, "Incremental Zone Transfer", Internet Draft, July 1995, M. Ohta, "Incremental Zone Transfer", Internet Draft, February 1996,
<draft-ietf-dnsind-ixfr-02.txt>. <draft-ietf-dnsind-ixfr-06.txt>.
Author's Address 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 +1 415 747 0204
<paul@vix.com> <paul@vix.com>
 End of changes. 39 change blocks. 
174 lines changed or deleted 171 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/