As per Relevance of the word response, we have this rfc below:
Network Working Group P.
Request for Comments: 1996
Updates: 1035 August 1996
Category: Standards
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo describes the NOTIFY opcode for DNS, by which a
server advises a set of slave servers that the master's data has
changed and that a query should be initiated to discover the
data
1. Rationale and
1.1. Slow propagation of new and changed data in a DNS zone can
due to a zone's relatively long refresh times. Longer refresh
are beneficial in that they reduce load on the master servers,
that benefit comes at the cost of long intervals of incoherence
authority servers whenever the zone is updated
1.2. The DNS NOTIFY transaction allows master servers to inform
servers when the zone has changed -- an interrupt as opposed to
model -- which it is hoped will reduce propagation delay while
unduly increasing the masters' load. This specification only
slaves to be notified of SOA RR changes, but the architechture
NOTIFY is intended to be extensible to other RR types
1.3. This document intentionally gives more definition to the
of "Master," "Slave" and "Stealth" servers, their enumeration in
RRs, and the SOA MNAME field. In that sense, this document can
considered an addendum to [RFC1035].
Vixie Standards Track [Page 1]
RFC 1996 DNS NOTIFY August 1996
2. Definitions and
2.1. The following definitions are used in this document
Slave an authoritative server which uses zone transfer
retrieve the zone. All slave servers are named
the NS RRs for the zone
Master any authoritative server configured to be the
of zone transfer for one or more slave servers
Primary Master master server at the root of the zone
dependency graph. The primary master is named in
zone's SOA MNAME field and optionally by an NS RR
There is by definition only one primary master
per zone
Stealth like a slave server except not listed in an NS RR
the zone. A stealth server, unless
configured to do otherwise, will set the AA bit
responses and be capable of acting as a master.
stealth server will only be known by other servers
they are given static configuration data
its existence
Notify Set set of servers to be notified of changes to
zone. Default is all servers named in the NS RRset
except for any server also named in the SOA MNAME
Some implementations will permit the name
administrator to override this set or add elements
it (such as, for example, stealth servers).
2.2. The zone's servers must be organized into a dependency
such that there is a primary master, and all other servers must
AXFR or IXFR either from the primary master or from some slave
is also a master. No loops are permitted in the AXFR
graph
3. NOTIFY
3.1. When a master has updated one or more RRs in which slave
may be interested, the master may send the changed RR's name, class
type, and optionally, new RDATA(s), to each known slave server
a best efforts protocol based on the NOTIFY opcode
3.2. NOTIFY uses the DNS Message Format, although it uses only
subset of the available fields. Fields not otherwise
herein are to be filled with binary zero (0), and
Vixie Standards Track [Page 2]
RFC 1996 DNS NOTIFY August 1996
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
the header QR flag "clear" and a response message with QR "set".
response message contains no useful information, but its reception
the master is an indication that the slave has received the
and that the master can remove the slave from any retry queue
this NOTIFY event
3.4. The transport protocol used for a NOTIFY transaction will be
unless the master has reason to believe that TCP is necessary;
example, if a firewall has been installed between master and slave
and only TCP has been allowed; or, if the changed RR is too large
fit in a UDP/DNS datagram
3.5. If TCP is used, both master and slave must continue to
name service during the transaction, even when the TCP transaction
not making progress. The NOTIFY request is sent once, and
"timeout" is said to have occurred if no NOTIFY response is
within a reasonable interval
3.6. If UDP is used, a master periodically sends a NOTIFY request
a slave until either too many copies have been sent (a "timeout"),
ICMP message indicating that the port is unreachable, or until
NOTIFY response is received from the slave with a matching query ID
QNAME, IP source address, and UDP source port number
Note
The interval between transmissions, and the total number
retransmissions, should be operational parameters specifiable
the name server administrator, perhaps on a per-zone basis
Reasonable defaults are a 60 second interval (or timeout
using TCP), and a maximum of 5 retransmissions (for UDP). It
considered reasonable to use additive or exponential backoff
the retry interval
3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
ADCOUNT>=0. If ANCOUNT>0, then the answer section represents
unsecure hint at the new RRset for this .
slave receiving such a hint is free to treat equivilence of
answer section with its local data as a "no further work needs to
done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer
differs from the slave's local data, then the slave should query
known masters to retrieve the new data
3.8. In no case shall the answer section of a NOTIFY request be
to update a slave's local data, or to indicate that a zone
needs to be undertaken, or to change the slave's zone refresh timers
Vixie Standards Track [Page 3]
RFC 1996 DNS NOTIFY August 1996
Only a "data present; data same" condition can lead a slave to
differently if ANCOUNT>0 than it would if ANCOUNT=0.
3.9. This version of the NOTIFY specification makes no use of
authority or additional data sections, and so
implementations should set AUCOUNT=0 and ADCOUNT=0 when
requests. Since a future revision of this specification may define
backwards compatible use for either or both of these sections
current implementations must ignore these sections, but not
entire message, if AUCOUNT>0 and/or ADCOUNT>0.
3.10. If a slave receives a NOTIFY request from a host that is not
known master for the zone containing the QNAME, it should ignore
request and produce an error message in its operations log
Note
This implies that slaves of a multihomed master must either
their master by the "closest" of the master's
addresses, or must know all of the master's interface addresses
Otherwise, a valid NOTIFY request might come from an
that is not on the slave's state list of masters for the zone
which would be an error
3.11. The only defined NOTIFY event at this time is that the SOA
has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA
the slave should behave as though the zone given in the QNAME
reached its REFRESH interval (see [RFC1035]), i.e., it should
its masters for the SOA of the zone given in the NOTIFY QNAME,
check the answer to see if the SOA SERIAL has been incremented
the last time the zone was fetched. If so, a zone transfer (
AXFR or IXFR) should be initiated
Note
Because a deep server dependency graph may have multiple
from the primary master to any given slave, it is possible
a slave will receive a NOTIFY from one of its known masters
though the rest of its known masters have not yet updated
copies of the zone. Therefore, when issuing a QUERY for
zone's SOA, the query should be directed at the known master
was the source of the NOTIFY event, and not at any of the
known masters. This represents a departure from [RFC1035],
which specifies that upon expiry of the SOA REFRESH interval
all known masters should be queried in turn
3.12. If a NOTIFY request is received by a slave who does
implement the NOTIFY opcode, it will respond with a
(unimplemented feature error) message. A master server who
such a NOTIMP should consider the NOTIFY transaction complete
Vixie Standards Track [Page 4]
RFC 1996 DNS NOTIFY August 1996
that slave
4. Details and
4.1. Retaining query state information across host reboots
optional, but it is reasonable to simply execute an SOA
transaction on each authority zone when a server first starts
4.2. Each slave is likely to receive several copies of the
NOTIFY request: One from the primary master, and one from each
slave as that slave transfers the new zone and notifies its
peers. The NOTIFY protocol supports this multiplicity by
that NOTIFY be sent by a slave/master only AFTER it has updated
SOA RR or has determined that no update is necessary, which
practice means after a successful zone transfer. Thus,
delivery reordering, the last NOTIFY any slave receives will be
one indicating the latest change. Since a slave always requests
and AXFR/IXFRs only from its known masters, it will have
opportunity to retry its QUERY for the SOA after each of its
have completed each zone update
4.3. If a master server seeks to avoid causing a large number
simultaneous outbound zone transfers, it may delay for an
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
slave will begin its transfer at a unique time. The delay shall
in any case be longer than the SOA REFRESH time
Note
This delay should be a parameter that each primary master
server can specify, perhaps on a per-zone basis. Random
of between 30 and 60 seconds would seem adequate if the
share a LAN and the zones are of moderate size
4.4. A slave which receives a valid NOTIFY should defer action on
subsequent NOTIFY with the same until it
completed the transaction begun by the first NOTIFY. This
rejection is necessary to avoid having multiple notifications lead
pummeling the master server
Vixie Standards Track [Page 5]
RFC 1996 DNS NOTIFY August 1996
4.5 Zone has Updated on Primary
Primary master sends a NOTIFY request to all servers named in
Set. The NOTIFY request has the following characteristics
query ID: (new
op: NOTIFY (4)
resp:
flags:
qcount: 1
qname: (zone name
qclass: (zone class
qtype: T_
4.6 Zone has Updated on a Slave that is also a
As above in 4.5, except that this server's Notify Set may
different from the Primary Master's due to optional
specification of local stealth servers
4.7 Slave Receives a NOTIFY Request from a
When a slave server receives a NOTIFY request from one of its
designated masters for the zone enclosing the given QNAME,
QTYPE=SOA and QR=0, it should enter the state it would if the zone'
refresh timer had expired. It will also send a NOTIFY response
to the NOTIFY request's source, with the following characteristics
query ID: (same
op: NOTIFY (4)
resp:
flags: QR
qcount: 1
qname: (zone name
qclass: (zone class
qtype: T_
This is intended to be identical to the NOTIFY request, except
the QR bit is also set. The query ID of the response must be
same as was received in the request
4.8 Master Receives a NOTIFY Response from
When a master server receives a NOTIFY response, it deletes
query from the retry queue, thus completing the "
process" of "this" RRset change to "that" server
Vixie Standards Track [Page 6]
RFC 1996 DNS NOTIFY August 1996
5. Security
We believe that the NOTIFY operation's only security
are
1. That a NOTIFY request with a forged IP/UDP source address
cause a slave to send spurious SOA queries to its masters
leading to a benign denial of service attack if the
requests are sent very often
2. That TCP spoofing could be used against a slave server
NOTIFY as a means of synchronizing an SOA query and UDP/
spoofing as a means of forcing a zone transfer
6.
[RFC1035]
Mockapetris, P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, November 1987.
[IXFR
Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
7. Author's
Paul
Internet Software
Star Route Box 159
Woodside, CA 94062
Phone: +1 415 747 0204
EMail: paul@vix.
Vixie Standards Track [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
