doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc1996.txt b/doc/rfc/rfc1996.txt
new file mode 100644
index 0000000..b08f200
--- /dev/null
+++ b/doc/rfc/rfc1996.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           P. Vixie
+Request for Comments: 1996                                           ISC
+Updates: 1035                                                August 1996
+Category: Standards Track
+
+
+    A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo 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.
+
+1. Rationale and Scope
+
+   1.1. 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 beneficial 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.
+
+   1.2. 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 specification only allows
+   slaves to be notified of SOA RR changes, but the architechture of
+   NOTIFY is intended to be extensible to other RR types.
+
+   1.3. This document intentionally gives more definition to the roles
+   of "Master," "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].
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 1]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+2. Definitions and Invariants
+
+   2.1. 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.
+
+   Primary Master  master server at the root of the zone transfer
+                   dependency 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
+                   configured to do otherwise, will set the AA bit in
+                   responses and be capable of acting as a master.  A
+                   stealth server will only be known by other servers if
+                   they are given static configuration data indicating
+                   its existence.
+
+   Notify Set      set of servers to be notified of changes to some
+                   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 server
+                   administrator to override this set or add elements to
+                   it (such as, for example, stealth servers).
+
+   2.2. 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 master.  No loops are permitted in the AXFR dependency
+   graph.
+
+3. NOTIFY Message
+
+   3.1. 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.
+
+   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 be filled with binary zero (0), and implementations
+
+
+
+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 with
+   the header QR flag "clear" and a response message with QR "set".  The
+   response message 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.
+
+   3.4. The transport protocol used for a NOTIFY transaction will be UDP
+   unless the master has reason to believe that TCP is necessary; for
+   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 to
+   fit in 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:
+      The interval between transmissions, and the total number of
+      retransmissions, should be operational parameters specifiable by
+      the name server administrator, perhaps on a per-zone basis.
+      Reasonable defaults are a 60 second interval (or timeout if
+      using TCP), and a maximum of 5 retransmissions (for UDP).  It is
+      considered reasonable to use additive or exponential backoff for
+      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 an
+   unsecure hint at the 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 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, then the slave should query its
+   known masters to retrieve the new data.
+
+   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 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 act
+   differently if ANCOUNT>0 than it would if ANCOUNT=0.
+
+   3.9. 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 message, if AUCOUNT>0 and/or ADCOUNT>0.
+
+   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
+   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 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.
+
+   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 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.
+
+   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 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 not
+   implement the NOTIFY opcode, it will respond with a NOTIMP
+   (unimplemented feature error) message.  A master server who receives
+   such a NOTIMP should consider the NOTIFY transaction complete for
+
+
+
+Vixie                       Standards Track                     [Page 4]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   that slave.
+
+4. Details and Examples
+
+   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 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 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 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.
+
+   4.3. 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.
+
+   Note:
+      This delay 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.
+
+   4.4. A slave which receives a valid NOTIFY should defer action on any
+   subsequent 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 5]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   4.5 Zone has Updated on Primary Master
+
+   Primary master sends a NOTIFY request to all servers named in Notify
+   Set.  The NOTIFY request has the following characteristics:
+
+      query ID:   (new)
+      op:         NOTIFY (4)
+      resp:       NOERROR
+      flags:      AA
+      qcount:     1
+      qname:      (zone name)
+      qclass:     (zone class)
+      qtype:      T_SOA
+
+   4.6 Zone has Updated on a Slave that is also a Master
+
+   As above in 4.5, except that this server's Notify Set may be
+   different from the Primary Master's due to optional static
+   specification of local stealth servers.
+
+   4.7 Slave Receives a NOTIFY Request 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=0, 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 (4)
+      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 request, except that
+   the QR bit is also set.  The query ID of the response must be the
+   same as was received in the request.
+
+   4.8 Master Receives a NOTIFY Response from Slave
+
+   When a master server receives a NOTIFY response, it deletes this
+   query from the retry queue, thus completing the "notification
+   process" of "this" RRset change to "that" server.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 6]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+5. Security Considerations
+
+   We believe that the NOTIFY operation's only security considerations
+   are:
+
+   1. 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.
+
+   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 means of forcing a zone transfer.
+
+6. References
+
+   [RFC1035]
+      Mockapetris, P., "Domain Names - Implementation and
+      Specification", STD 13, RFC 1035, November 1987.
+
+   [IXFR]
+      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
+
+7. Author's Address
+
+   Paul Vixie
+   Internet Software Consortium
+   Star Route Box 159A
+   Woodside, CA 94062
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 7]
+