< draft-ietf-dnsind-notify-06.txt   draft-ietf-dnsind-notify-07.txt >
DNSIND Working Group Paul Vixie (ISC) DNSIND Working Group Paul Vixie (ISC)
INTERNET-DRAFT February, 1996 INTERNET-DRAFT March, 1996
<draft-ietf-dnsind-notify-06.txt> <draft-ietf-dnsind-notify-07.txt>
Updates: RFC 1035 Updates: RFC 1035
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) 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 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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
may be interested, the master may send the changed RR's name, class, 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 type, and optionally, new RDATA(s), to each known slave server using a
best efforts protocol based on the NOTIFY opcode. best efforts protocol based on the NOTIFY opcode.
3.2. NOTIFY uses the DNS Message Format, although it uses only a subset 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 of the available fields. Fields not otherwise described herein are to
be filled with binary zero (0), and implementations must ignore all be filled with binary zero (0), and implementations must ignore all
messages for which this is not the case. messages for which this is not the case.
3.3. NOTIFY is similar to QUERY in that it has a request message with 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 header QR flag ``clear'' and a response message with QR ``set''.
The response message contains no useful information, but its reception The response message contains no useful information, but its reception
by the master is an indication that the slave has received the NOTIFY 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 and that the master can remove the slave from any retry queue for this
NOTIFY event. NOTIFY event.
3.4. A master repeatedly sends a NOTIFY request to a slave until either 3.4. The transport protocol used for a NOTIFY transaction will be UDP
too many copies have been sent (a ``timeout''), an ICMP message unless the master has reason to believe that TCP is necessary; for
indicating that the port is unreachable, or until a NOTIFY response is example, if a firewall has been installed between master and slave, and
received from the slave with a matching query ID, QNAME, and IP source only TCP has been allowed; or, if the changed RR is too large to fit in
address. a UDP/DNS datagram.
3.5. If TCP is used, both master and slave must continue to offer name
service during the transaction, even when the TCP transaction is not
making progress. The NOTIFY request is sent once, and a ``timeout'' is
said to have occurred if no NOTIFY response is received within a
reasonable interval.
3.6. If UDP is used, a master periodically 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, IP
source address, and UDP source port number.
Note: Note:
The interval between retransmissions, and the total number of The interval between transmissions, and the total number of
retransmissions, should be operational parameters specifiable by the retransmissions, should be operational parameters specifiable by the
name server administrator, perhaps on a per-zone basis. Reasonable name server administrator, perhaps on a per-zone basis. Reasonable
defaults are a 60 second interval and 5 attempts. It is also defaults are a 60 second interval (or timeout if using TCP), and a
reasonable to use additive or exponential backoff for the retry maximum of 5 retransmissions (for UDP). It is considered reasonable
interval. to use additive or exponential backoff for the retry interval.
3.4. A NOTIFY request has QCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0. 3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, ADCOUNT>=0.
If ANCOUNT>0, then the answer section represents an unsecure hint at the 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 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 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 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, 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. 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 3.8. 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 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 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 ``data present; data same'' condition can lead a slave to act
differently if ANCOUNT>0 than it would if ANCOUNT=0. differently if ANCOUNT>0 than it would if ANCOUNT=0.
3.6. This version of the NOTIFY specification makes no use of the 3.9. This version of the NOTIFY specification makes no use of the
authority or additional data sections, and so conforming implementations authority or additional data sections, and so conforming implementations
should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a should set AUCOUNT=0 and ADCOUNT=0 when transmitting requests. Since a
future revision of this specification may define a backwards compatible future revision of this specification may define a backwards compatible
use for either or both of these sections, current implementations must use for either or both of these sections, current implementations must
ignore these sections, but not the entire message, if AUCOUNT>0 and/or ignore these sections, but not the entire message, if AUCOUNT>0 and/or
ADCOUNT>0. ADCOUNT>0.
3.7. If a slave receives a NOTIFY request from a host that is not a 3.10. If a slave receives a NOTIFY request from a host that is not a
known master for the zone containing the QNAME, it should ignore the known master for the zone containing the QNAME, it should ignore the
request 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 request 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 error. slave's state list of masters for the zone, which would be an error.
3.8. The only defined NOTIFY event at this time is that the SOA RR has 3.11. 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. be initiated.
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 NOTIFY event, and not at any of the other known masters. This
represents a departure from [RFC1035], which specifies that upon represents a departure from [RFC1035], which specifies that upon
expiry of the SOA REFRESH interval, all known masters should be expiry of the SOA REFRESH interval, all known masters should be
queried in turn. queried in turn.
4 - Semantic Details 4.1. Retaining query state information across host 4 - Details and Examples
reboots is optional, but it is reasonable to simply execute an SOA
NOTIFY transaction on each authority zone when a server first starts. 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.
4.2. Each slave is likely to receive several copies of the same NOTIFY 4.2. Each slave is likely to receive several copies of the same NOTIFY
request: One from the primary master, and one from each other slave as request: One from the primary master, and one from each other slave as
that slave transfers the new zone and notifies its potential peers. The that slave transfers the new zone and notifies its potential peers. The
NOTIFY protocol supports this multiplicity by requiring that NOTIFY be NOTIFY protocol supports this multiplicity by requiring that NOTIFY be
sent by a slave/master only AFTER it has updated the SOA RR or has 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 determined that no update is necessary, which in practice means after a
successful zone transfer. Thus, barring delivery reordering, the last successful zone transfer. Thus, barring delivery reordering, the last
NOTIFY any slave receives will be the one indicating the latest change. 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 Since a slave always requests SOAs and AXFR/IXFRs only from its known
skipping to change at page 7, line 5 skipping to change at page 7, line 32
This is intended to be identical to the NOTIFY request, except that the This is intended to be identical to the NOTIFY request, except that the
QR bit is also set. The query ID of the response must be the same as QR bit is also set. The query ID of the response must be the same as
was received in the request. was received in the request.
4.8 - Master Receives a NOTIFY Response from Slave 4.8 - Master Receives a NOTIFY Response from Slave
When a master server receives a NOTIFY response, 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 5 - 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 NOTIFY request with a forged IP/UDP source address can cause a
false slave.
2. That a NOTIFY request with a forged IP/UDP source address can cause a
slave to send spurious SOA queries to its masters, leading to a slave to send spurious SOA queries to its masters, leading to a
benign denial of service attack if the forged requests are sent very benign denial of service attack if the forged requests are sent very
often. often.
3. That TCP spoofing could be used against a slave server given NOTIFY 2. 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 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 6 - 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, February 1996, M. Ohta, "Incremental Zone Transfer", Internet Draft, February 1996,
<draft-ietf-dnsind-ixfr-06.txt>. <draft-ietf-dnsind-ixfr-06.txt>.
Author's Address 7 - 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. 16 change blocks. 
28 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/