One document matched: draft-ietf-dnsind-notify-04.txt
Differences from draft-ietf-dnsind-notify-03.txt
DNSIND Working Group Paul Vixie (ISC)
INTERNET-DRAFT October, 1995
<draft-ietf-dnsind-notify-04.txt>
Updates: RFC 1035
DNS NOTIFY: a mechanism for prompt notification of zone changes
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as `work in progress.'
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
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
changed and that a query should be initiated to discover the new
data.
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 benefi-
cial in that they reduce load on the master servers, but that benefit
comes at the cost of long intervals of incoherence among authority
servers whenever the zone is updated.
Expires May, 1996 [Page 1]
INTERNET-DRAFT DNS NOTIFY October 1995
The DNS NOTIFY transaction allows master servers to inform slave servers
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.
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.
This document intentionally gives more definition to the roles of ``Mas-
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
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.
NOTIFY borrows its packet data format from QUERY, although it uses only
a subset of the fields present. Fields not otherwise described herein
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
``set'' and a response packet with QR ``clear''. The response packet
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.
A master repeatedly sends NOTIFY-!QR to a slave until either too many
copies have been sent (a ``timeout''), an ICMP message indicating that
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.
Expires May, 1996 [Page 2]
INTERNET-DRAFT DNS NOTIFY October 1995
A NOTIFY-!QR 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 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.
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 packet, if AUCOUNT>0 and/or
ADCOUNT>0.
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 request
and produce an error message in its operations log.
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.
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
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
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.)
Expires May, 1996 [Page 3]
INTERNET-DRAFT DNS NOTIFY October 1995
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.
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 recognized by other
servers if it sends queries from the DNS service port
(UDP 53).
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.
Expires May, 1996 [Page 4]
INTERNET-DRAFT DNS NOTIFY October 1995
3.0 - Semantic Details
Master servers should maintain a list of stealth servers which have
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 server
address whose last successful query for the changed RRset's
<name,class,type> was within that interval. (Retaining this 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.)
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 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.
If a master server seeks to avoid causing a large number of simultaneous
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. 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.
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.
Expires May, 1996 [Page 5]
INTERNET-DRAFT DNS NOTIFY October 1995
3.1 - Zone has Updated on Primary Master
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 optionally
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)
op: NOTIFY
resp: NOERROR
flags: AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
3.1.1 - Zone has Updated on a Slave that is also a Master
As above in 3.1, except that only those authoritative name servers
(i.e., those listed in the zone's NS RRset) which have queried for this
name and type within the SOA REFRESH interval need to be notified.
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
When a slave server receives a NOTIFY request from one of its locally
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
refresh timer had expired. It will also send a NOTIFY response back to
the NOTIFY request's source, with the following characteristics:
query ID: (same)
op: NOTIFY
resp: NOERROR
flags: QR AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
This is intended to be identical to the NOTIFY-!QR, except that the QR
bit is also set, and the query ID must be the same as was received in
the NOTIFY-!QR request.
Expires May, 1996 [Page 6]
INTERNET-DRAFT DNS NOTIFY October 1995
3.2 - Master Receives a NOTIFY-QR Packet from Slave
When a master server receives a NOTIFY-QR packet, it deletes this query
from the retry queue, thus completing the ``notification process'' of
``this'' RRset change to ``that'' server.
Security Considerations
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
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
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
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
+1 415 747 0204
<paul@vix.com>
Expires May, 1996 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 11:10:56 |