draft-ietf-dnsind-notify-02.txt   draft-ietf-dnsind-notify-03.txt 
Internet Area P. Vixie Internet Area P. Vixie
DNSIND Working Group Vixie Enterprises DNSIND Working Group Vixie Enterprises
<draft-ietf-dnsind-notify-02.txt> 09-July-1995 <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 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 doc-
documents of the Internet Engineering Task Force (IETF), its areas, uments of the Internet Engineering Task Force (IETF), its areas, and
and its working groups. Note that other groups may also distribute its working groups. Note that other groups may also distribute work-
working 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
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet-Drafts as reference mate-
material or to cite them other than as `work in progress.' rial 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 Directories on ds.internic.net (US East Coast), nic.nordu.net Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(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
skipping to change at page 2, line 5 skipping to change at page 2, line 5
clients until a potentially lengthy interval has elapsed. clients until a potentially lengthy interval has elapsed.
The DNS NOTIFY transaction allows master servers to inform slave The DNS NOTIFY transaction allows master servers to inform slave
servers when data have changed -- an interrupt as opposed to poll servers when data have 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. unduly increasing 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
<draft-ietf-dnsind-notify-02.txt>- 2 - 09-July-1995 <draft-ietf-dnsind-notify-xx.txt> -2- 04-August-1995
binary zero, and implementations must ignore any request or response binary zero, and implementations must ignore any request or response
packets where this is not the case. packets where this is not the case.
This document intentionally gives more definition to the roles of This document intentionally gives more definition to the roles of
``Master,'' ``Slave'' and ``Stealth'' servers, their enumeration in ``Master,'' ``Slave'' and ``Stealth'' servers, their enumeration in
NS RRs, and the SOA MNAME field. In that sense, this document can be NS RRs, and the SOA MNAME field. In that sense, this document can be
considered an addendum to RFC 1035. considered an 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, type, and be interested, the master may send the changed RR's name, class,
optionally, new RDATA(s), to each known slave server using a best type, and optionally, new RDATA(s), to each known slave server using
efforts protocol based on the NOTIFY opcode. a best efforts protocol based on the NOTIFY opcode.
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 specifi-
specifiable by the name server administrator, perhaps on a per-zone able by the name server administrator, perhaps on a per-zone basis.
basis. Reasonable defaults are a 60 second interval and 5 attempts. Reasonable defaults are a 60 second interval and 5 attempts. It is
It is also reasonable to use additive or exponential backoff for the also reasonable to use additive or exponential backoff for the retry
retry interval. interval.
A NOTIFY packet has QCOUNT>0, ANCOUNT>=0, AUCOUNT=0, ADCOUNT=0. If A NOTIFY packet has QCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0. If
ANCOUNT is nonzero, then the answer section represents an unsecure ANCOUNT is nonzero, then the answer section represents an unsecure
hint at the new RR set for this <QNAME,QCLASS,QTYPE>. A slave 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 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'' 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 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 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 masters to retrieve the new data. In no case shall the answer sec-
section of a NOTIFY-!QR be used to update a slave's local data, or to 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 indicate that a zone transfer needs to be undertaken, or to change
the slave's zone refresh timers. Only a ``data present; data same'' 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 condition can lead a slave to act differently based on a NOTIFY-!QR
answer section. answer section.
In the future, it is expected that this specification will be amended This version of the NOTIFY specification makes no use of the author-
such that AUCOUNT or ADCOUNT may be allowed to be nonzero, to ity or additional data sections, and so conforming implementations
indicate that the new data is signed and secure, and can therefore be should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since
<draft-ietf-dnsind-notify-02.txt>- 3 - 09-July-1995 <draft-ietf-dnsind-notify-xx.txt> -3- 04-August-1995
trusted. Until that work has been completed and a standard has been a future revision of this specification may define a backwards com-
made, any packet with AUCOUNT<>0 or ADCOUNT<>0 must be ignored by any patible use for either or both of these sections, current implementa-
server receiving it. tions must ignore them if present.
If a slave receives a NOTIFY request from a host which is not listed If a slave receives a NOTIFY request from a host that 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 should ignore the request and produce an error message in
operations log. its operations log.
NOTE: This implies that slaves of a multihomed master must either
specify the ``closest'' of the master's interface addresses,
or must list them all. Otherwise, the NOTIFY-!QR might come
from an address that is not on the slave's state list of mas-
ters for the zone, which would be an artificial error.
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 completion of a NOTIFY transaction for QTYPE=SOA, the slave Upon completion of a NOTIFY transaction for QTYPE=SOA, the slave
should behave as though the zone given in the QNAME had reached its should behave as though the zone given in the QNAME had reached its
REFRESH interval [see RFC 1035], i.e., it should query the master 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 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 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, has a newer serial number than the slave's current copy of the zone,
then a zone transfer should be initiated. then a zone transfer should be initiated.
skipping to change at page 3, line 37 skipping to change at page 3, line 43
Definition: the Primary Master Server is the host at the Definition: the Primary Master Server is the host at the
root of the AXFR/IXFR dependency graph. The primary master is root of the AXFR/IXFR dependency graph. The primary master is
named in the zone's SOA MNAME field, and optionally by an NS RR. named in the zone's SOA MNAME field, and optionally by an NS RR.
The source of the primary master's zone data is external to the The source of the primary master's zone data is external to the
DNS, for example, the host's file system. DNS, for example, the host's file system.
Definition: a Master Server is any authoritative server configured Definition: a Master Server is any authoritative server configured
to be the source of AXFR/IXFR from one or more slave servers. to be the source of AXFR/IXFR from one or more slave servers.
It is named in an NS RR for the zone. It is named in an NS RR for the zone.
Definition: a Slave Server is a an authoritative server which Definition: a Slave Server is a an authoritative server that uses
uses AXFR/IXFR to retrieve the zone. All slave servers are AXFR/IXFR to retrieve the zone. All slave servers are named in
named in the NS RRs for the zone. A slave server can also act the NS RRs for the zone. A slave server can also act as a mas-
as a master in the case of a deep AXFR/IXFR tree. ter in the case of a deep AXFR/IXFR tree.
Definition: a Stealth Server is a potentially authoritative server Definition: a Stealth Server is a potentially authoritative server
which that uses AXFR/IXFR as described above for ``Slave Server.''
uses AXFR/IXFR as described above for ``Slave Server.'' Stealth Stealth servers are not named in the NS RRs for the zone, and
servers are not named in the NS RRs for the zone, and are thus are thus useful only as a way to ``hotwire the cache.'' A
useful only as a way to ``hotwire the cache.'' A stealth server stealth server will, unless explicitly configured to do other-
will, unless explicitly configured to do otherwise, sets the AA wise, set the AA bit in responses and is capable of acting as a
bit in responses and is capable of acting as a Master. A Master. A stealth server will only be recognized by other
stealth server will only be recognized by other servers if it
sends queries from the DNS service port (UDP 53). <draft-ietf-dnsind-notify-xx.txt> -4- 04-August-1995
servers if it sends queries from the DNS service port (UDP 53).
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
<draft-ietf-dnsind-notify-02.txt>- 4 - 09-July-1995
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. No loops are permitted in the AXFR dependency graph. a master. No loops are permitted 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
point) must use AXFR to do zone updates, or, if some other point) must use AXFR to do zone updates, or, if some other pro-
protocol is used (e.g., FTP or NFS), it must simulate all of the tocol is used (e.g., FTP or NFS), it must simulate all of the
semantics of SOA/AXFR/IXFR. semantics of SOA/AXFR/IXFR.
3. Semantic Details 3. 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 best efforts basis, NOTIFY requests should be sent to each slave a best efforts basis, NOTIFY requests should be sent to each slave
server address whose last successful query for the changed RR's name server address whose last successful query for the changed RR's name
and type was within that interval. (Retaining this state information and type was within that interval. (Retaining this state information
across host reboots is optional, but it is reasonable to simply across host reboots is optional, but it is reasonable to simply exe-
execute a NOTIFY transaction on each authority zone when a server cute a NOTIFY transaction on each authority zone when a server first
first starts.) starts.)
In a deep tree where some slaves fetch new zones from other slaves, 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 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 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 slave 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/IXFR. Thus, barring delivery reordering, the last subsequent AXFR/IXFR. Thus, barring delivery reordering, the last
NOTIFY any slave receives will be the one indicating the latest NOTIFY any slave receives will be the one indicating the latest
change. Since a slave always requests SOAs and AXFR/IXFRs only from change. Since a slave always requests SOAs and AXFR/IXFRs only from
its locally designated masters, it will have an opportunity to retry its locally designated masters, it will have an opportunity to retry
its SOA query after its masters have completed each zone update. its SOA query after its masters have completed each zone update.
If a master server seeks to avoid causing a large number of If a master server seeks to avoid causing a large number of simulta-
simultaneous outbound zone transfers, it may delay for an arbitrary neous outbound zone transfers, it may delay for an arbitrary length
length of time before sending a NOTIFY message to any given slave. of time before sending a NOTIFY message to any given slave. It is
It is expected that the time will be chosen at random, so that each expected that the time will be chosen at random, so that each slave
slave will begin its transfer at a unique time, perhaps with some will begin its transfer at a unique time, perhaps with some weighting
weighting so that pending outbound NOTIFY's are more likely to be so that pending outbound NOTIFY's are more likely to be sent out
sent out whenever a zone transfer completes. The delay shall not in whenever a zone transfer completes. The delay shall not in any case
any case be longer than the SOA REFRESH time, and should be a be longer than the SOA REFRESH time, and should be a parameter that
parameter that each primary master name server can specify, perhaps each primary master name server can specify, perhaps on a per-zone
on a per-zone basis. Random delays of between 30 and 60 seconds basis. Random delays of between 30 and 60 seconds would seem
would seem adequate if the servers share a LAN and the zones are less
than a megabyte in size.
A slave which receives a valid NOTIFY should defer action on any <draft-ietf-dnsind-notify-xx.txt> -5- 04-August-1995
subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
<draft-ietf-dnsind-notify-02.txt>- 5 - 09-July-1995 adequate if the servers share a LAN and the zones are less than a
megabyte in size.
completed the transaction begun by the first NOTIFY. This duplicate A slave which receives a valid NOTIFY should defer action on any sub-
sequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has com-
pleted 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.
The rest of this section is concerned only with SOA NOTIFY. 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 option-
optionally to all name servers which have queried for this SOA within ally to all name servers which have queried for this SOA within the
the last SOA REFRESH interval. The NOTIFY has the following last SOA REFRESH interval. The NOTIFY has the following characteris-
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: C_IN qclass: (zone class)
qtype: T_SOA qtype: T_SOA
ancount, aucount, adcount: 0 ancount, aucount, adcount: 0
Note that setting any flag other than AA should cause slave servers Note that setting any flag other than AA should cause slave servers
to ignore this query. Only AA is defined, the others all must to ignore this query. Only AA is defined, the others all must con-
contain binary zero. tain binary zero.
3.a.1. Zone has Updated on a Slave that is also a Master 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.a, 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 RR set) which have queried for
this name and type within the SOA REFRESH interval need to be this name and type within the SOA REFRESH interval need to be noti-
notified. Optionally, the slave/master may send to all servers which fied. Optionally, the slave/master may send to all servers which
have sent such recent queries, without regard to whether they are have sent such recent queries, without regard to whether they are
listed in the zone's NS RR set. listed in the zone's NS RR set.
3.b. Slave Receives a NOTIFY Packet from a Master 3.b. Slave Receives a NOTIFY 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
<draft-ietf-dnsind-notify-xx.txt> -6- 04-August-1995
to 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 op: NOTIFY
resp: NOERROR resp: NOERROR
<draft-ietf-dnsind-notify-02.txt>- 6 - 09-July-1995
flags: QR AA flags: QR AA
qcount: 1 qcount: 1
qname: (zone name) qname: (zone name)
qclass: C_IN qclass: (zone class)
qtype: T_SOA qtype: T_SOA
ancount, aucount, adcount: 0 ancount, aucount, adcount: 0
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.
Security Considerations Security Considerations
DNS security is being considered overall by the DNSSEC working group.
We believe that the NOTIFY operation's only security considerations We believe that the NOTIFY operation's only security considerations
are (A) that a previous SOA query can optionally cause a master to are: (A) that a previous SOA query can optionally cause a master to
NOTIFY a false slave, and (B) that a NOTIFY request with a forged NOTIFY a false slave; (B) that a NOTIFY request with a forged IP/UDP
IP/UDP source address can cause a slave to send spurious SOA queries source address can cause a slave to send spurious SOA queries to its
to its masters, leading to the possibility of a benign denial of masters, leading to a benign denial of service attack if the forged
service attack if the forged requests are received very often. requests are sent very often; and (C) 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.
Author's Address Author's Address
Paul Vixie Paul Vixie
Vixie Enterprises Vixie Enterprises
Star Route Box 159A Star Route Box 159A
Woodside, CA 94062 Woodside, CA 94062
Phone: +1 415 747 0204 Phone: +1 415 747 0204
 End of changes. 31 change blocks. 
84 lines changed or deleted 90 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/