draft-ietf-dnsind-notify-04.txt   draft-ietf-dnsind-notify-05.txt 
DNSIND Working Group Paul Vixie (ISC) DNSIND Working Group Paul Vixie (ISC)
<draft-ietf-dnsind-notify-04.txt> <draft-ietf-dnsind-notify-05.txt>
Updates: RFC 1035 Updates: RFC 1035
DNS NOTIFY: a mechanism for prompt notification of 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-
skipping to change at page 4, line 38 skipping to change at page 4, line 38
Primary Master master server at the root of the zone transfer depen- Primary Master master server at the root of the zone transfer depen-
dency graph. The primary master is named in the dency graph. The primary master is named in the
zone's SOA MNAME field and optionally by an NS RR. zone's SOA MNAME field and optionally by an NS RR.
There is by definition only one primary master server There is by definition only one primary master server
per zone. per zone.
Stealth like a slave server except not listed in an NS RR for Stealth like a slave server except not listed in an NS RR for
the zone. A stealth server, unless explicitly con- the zone. A stealth server, unless explicitly con-
figured to do otherwise, will set the AA bit in figured to do otherwise, will set the AA bit in
responses and be capable of acting as a master. A responses and be capable of acting as a master. A
stealth server will only be recognized by other stealth server will only be known by other servers if
servers if it sends queries from the DNS service port they are given static configuration data indicating
(UDP 53). its existence.
The zone's servers must be organized into a dependency graph such that 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 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- either from the primary master or from some slave which is also a mas-
ter. No loops are permitted in the AXFR dependency graph. ter. No loops are permitted in the AXFR dependency graph.
3.0 - Semantic Details 3.0 - Semantic Details
Master servers should maintain a list of stealth servers which have On a best efforts basis, NOTIFY requests should be sent to each slave
queried the SOA of the zone within the last SOA REFRESH interval. On a server whose last successful query for the changed RRset's
best efforts basis, NOTIFY requests should be sent to each slave server <name,class,type> was within the SOA refresh interval. Master servers
address whose last successful query for the changed RRset's might also be statically configured with a list of stealth servers who
<name,class,type> was within that interval. (Retaining this state should be notified of zone SOA changes. Retaining query state informa-
information across host reboots is optional, but it is reasonable to tion across host reboots is optional, but it is reasonable to simply
simply execute an SOA NOTIFY transaction on each authority zone when a execute an SOA NOTIFY transaction on each authority zone when a server
server first starts.) first starts.
In a deep tree where some slaves fetch new zones from other slaves, it 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 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 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 which it has requested this RRset's <name,class,type< within the last
SOA REFRESH interval. The protocol supports this multiplicity by SOA REFRESH interval. The protocol supports this multiplicity by
requiring that NOTIFY be sent by a slave/master only AFTER it has 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 updated the SOA RR or has determined that no update is necessary, which
in practice means after a successful zone transfer. Thus, barring in practice means after a successful zone transfer. Thus, barring
delivery reordering, the last NOTIFY any slave receives will be the one delivery reordering, the last NOTIFY any slave receives will be the one
 End of changes. 3 change blocks. 
12 lines changed or deleted 12 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/