rfc1996.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 396 行 · 第 1/2 页

   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: [phone]
   EMail: [e-mail]



















Vixie                       Standards Track                     [Page 7]