rfc2136.txt

bind 9.3结合mysql数据库

   3.4.1.3 - Pseudocode For Update Section Prescan

      [rr] for rr in updates
           if (zone_of(rr.name) != ZNAME)
                return (NOTZONE);
           if (rr.class == zclass)
                if (rr.type & ANY|AXFR|MAILA|MAILB)
                     return (FORMERR)
           elsif (rr.class == ANY)
                if (rr.ttl != 0 || rr.rdlength != 0
                    || rr.type & AXFR|MAILA|MAILB)
                     return (FORMERR)
           elsif (rr.class == NONE)
                if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
                     return (FORMERR)
           else
                return (FORMERR)

   3.4.2 - Update

   The Update Section is parsed into RRs and these RRs are processed in
   order.

   3.4.2.1. If any system failure (such as an out of memory condition,
   or a hardware error in persistent storage) occurs during the
   processing of this section, signal SERVFAIL to the requestor and undo
   all updates applied to the zone during this transaction.

   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
   fields both match), the Zone RR is replaced by Update RR.  If the
   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
   lower (according to [RFC1982]) than or equal to the current Zone SOA
   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
   RR.

   3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
   all Zone RRs with the same NAME are deleted, unless the NAME is the
   same as ZNAME in which case only those RRs whose TYPE is other than
   SOA or NS are deleted.  For any Update RR whose CLASS is ANY and
   whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
   deleted, unless the NAME is the same as ZNAME in which case neither
   SOA or NS RRs will be deleted.





Vixie, et. al.              Standards Track                    [Page 14]

RFC 2136                       DNS Update                     April 1997


   3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
   NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
   unless the NAME is the same as ZNAME and either the TYPE is SOA or
   the TYPE is NS and the matching Zone RR is the only NS remaining in
   the RRset, in which case this Update RR is ignored.

   3.4.2.5. Signal NOERROR to the requestor.

   3.4.2.6 - Table Of Metavalues Used In Update Section

   CLASS    TYPE     RDATA    Meaning
   ---------------------------------------------------------
   ANY      ANY      empty    Delete all RRsets from a name
   ANY      rrset    empty    Delete an RRset
   NONE     rrset    rr       Delete an RR from an RRset
   zone     rrset    rr       Add to an RRset

   3.4.2.7 - Pseudocode For Update Section Processing

      [rr] for rr in updates
           if (rr.class == zclass)
                if (rr.type == CNAME)
                     if (zone_rrset<rr.name, ~CNAME>)
                          next [rr]
                elsif (zone_rrset<rr.name, CNAME>)
                     next [rr]
                if (rr.type == SOA)
                     if (!zone_rrset<rr.name, SOA> ||
                         zone_rr<rr.name, SOA>.serial > rr.soa.serial)
                          next [rr]
                for zrr in zone_rrset<rr.name, rr.type>
                     if (rr.type == CNAME || rr.type == SOA ||
                         (rr.type == WKS && rr.proto == zrr.proto &&
                          rr.address == zrr.address) ||
                         rr.rdata == zrr.rdata)
                          zrr = rr
                          next [rr]
                zone_rrset<rr.name, rr.type> += rr
           elsif (rr.class == ANY)
                if (rr.type == ANY)
                     if (rr.name == zname)
                          zone_rrset<rr.name, ~(SOA|NS)> = Nil
                     else
                          zone_rrset<rr.name, *> = Nil
                elsif (rr.name == zname &&
                       (rr.type == SOA || rr.type == NS))
                     next [rr]
                else



Vixie, et. al.              Standards Track                    [Page 15]

RFC 2136                       DNS Update                     April 1997


                     zone_rrset<rr.name, rr.type> = Nil
           elsif (rr.class == NONE)
                if (rr.type == SOA)
                     next [rr]
                if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
                     next [rr]
                zone_rr<rr.name, rr.type, rr.data> = Nil
      return (NOERROR)

   3.5 - Stability

   When a zone is modified by an UPDATE operation, the server must
   commit the change to nonvolatile storage before sending a response to
   the requestor or answering any queries or transfers for the modified
   zone.  It is reasonable for a server to store only the update records
   as long as a system reboot or power failure will cause these update
   records to be incorporated into the zone the next time the server is
   started.  It is also reasonable for the server to copy the entire
   modified zone to nonvolatile storage after each update operation,
   though this would have suboptimal performance for large zones.

   3.6 - Zone Identity

   If the zone's SOA SERIAL is changed by an update operation, that
   change must be in a positive direction (using modulo 2**32 arithmetic
   as specified by [RFC1982]).  Attempts to replace an SOA with one
   whose SERIAL is less than the current one will be silently ignored by
   the primary master server.

   If the zone's SOA's SERIAL is not changed as a result of an update
   operation, then the server shall increment it automatically before
   the SOA or any changed name or RR or RRset is included in any
   response or transfer.  The primary master server's implementor might
   choose to autoincrement the SOA SERIAL if any of the following events
   occurs:

   (1)  Each update operation.

   (2)  A name, RR or RRset in the zone has changed and has subsequently
        been visible to a DNS client since the unincremented SOA was
        visible to a DNS client, and the SOA is about to become visible
        to a DNS client.

   (3)  A configurable period of time has elapsed since the last update
        operation.  This period shall be less than or equal to one third
        of the zone refresh time, and the default shall be the lesser of
        that maximum and 300 seconds.




Vixie, et. al.              Standards Track                    [Page 16]

RFC 2136                       DNS Update                     April 1997


   (4)  A configurable number of updates has been applied since the last
        SOA change.  The default value for this configuration parameter
        shall be one hundred (100).

   It is imperative that the zone's contents and the SOA's SERIAL be
   tightly synchronized.  If the zone appears to change, the SOA must
   appear to change as well.

   3.7 - Atomicity

   During the processing of an UPDATE transaction, the server must
   ensure atomicity with respect to other (concurrent) UPDATE or QUERY
   transactions.  No two transactions can be processed concurrently if
   either depends on the final results of the other; in particular, a
   QUERY should not be able to retrieve RRsets which have been partially
   modified by a concurrent UPDATE, and an UPDATE should not be able to
   start from prerequisites that might not still hold at the completion
   of some other concurrent UPDATE.  Finally, if two UPDATE transactions
   would modify the same names, RRs or RRsets, then such UPDATE
   transactions must be serialized.

   3.8 - Response

   At the end of UPDATE processing, a response code will be known.  A
   response message is generated by copying the ID and Opcode fields
   from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
   and ADCOUNT fields and associated sections, or placing zeros (0) in
   the these "count" fields and not including any part of the original
   update.  The QR bit is set to one (1), and the response is sent back
   to the requestor.  If the requestor used UDP, then the response will
   be sent to the requestor's source UDP port.  If the requestor used
   TCP, then the response will be sent back on the requestor's open TCP
   connection.

4 - Requestor Behaviour

   4.1. From a requestor's point of view, any authoritative server for
   the zone can appear to be able to process update requests, even
   though only the primary master server is actually able to modify the
   zone's master file.  Requestors are expected to know the name of the
   zone they intend to update and to know or be able to determine the
   name servers for that zone.









Vixie, et. al.              Standards Track                    [Page 17]

RFC 2136                       DNS Update                     April 1997


   4.2. If update ordering is desired, the requestor will need to know
   the value of the existing SOA RR.  Requestors who update the SOA RR
   must update the SOA SERIAL field in a positive direction (as defined
   by [RFC1982]) and also preserve the other SOA fields unless the
   requestor's explicit intent is to change them.  The SOA SERIAL field
   must never be set to zero (0).

   4.3. If the requestor has reasonable cause to believe that all of a
   zone's servers will be equally reachable, then it should arrange to
   try the primary master server (as given by the SOA MNAME field if
   matched by some NS NSDNAME) first to avoid unnecessary forwarding
   inside the slave servers.  (Note that the primary master will in some
   cases not be reachable by all requestors, due to firewalls or network
   partitioning.)

   4.4. Once the zone's name servers been found and possibly sorted so
   that the ones more likely to be reachable and/or support the UPDATE
   opcode are listed first, the requestor composes an UPDATE message of
   the following form and sends it to the first name server on its list:

      ID:                        (new)
      Opcode:                    UPDATE
      Zone zcount:               1
      Zone zname:                (zone name)
      Zone zclass:               (zone class)
      Zone ztype:                T_SOA
      Prerequisite Section:      (see previous text)
      Update Section:            (see previous text)
      Additional Data Section:   (empty)

   4.5. If the requestor receives a response, and the response has an
   RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
   appropriate response to its caller.

   4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
   if no response is received within an implementation dependent timeout
   period, or if an ICMP error is received indicating that the server's
   port is unreachable, then the requestor will delete the unusable
   server from its internal name server list and try the next one,
   repeating until the name server list is empty.  If the requestor runs
   out of servers to try, an appropriate error will be returned to the
   requestor's caller.









Vixie, et. al.              Standards Track                    [Page 18]

RFC 2136                       DNS Update                     April 1997


5 - Duplicate Detection, Ordering and Mutual Exclusion

   5.1. For correct operation, mechanisms may be needed to ensure
   idempotence, order UPDATE requests and provide mutual exclusion.  An
   UPDATE message or response might be delivered zero times, one time,
   or multiple times.  Datagram duplication is of particular interest
   since it covers the case of the so-called "replay attack" where a
   correct request is duplicated maliciously by an intruder.

   5.2. Multiple UPDATE requests or responses in transit might be
   delivered in any order, due to network topology changes or load
   balancing, or to multipath forwarding graphs wherein several slave
   servers all forward to the primary master.  In some cases, it might
   be required that the earlier update not be applied after the later
   update, where "earlier" and "later" are defined by an external time
   base visible to some set of requestors, rather than by the order of
   request receipt at the primary master.

   5.3. A requestor can ensure transaction idempotence by explicitly
   deleting some "marker RR" (rather than deleting the RRset of which it
   is a part) and then adding a new "marker RR" with a different RDATA
   field.  The Prerequisite Section should specify that the original
   "marker RR" must be present in order for this UPDATE message to be
   accepted by the server.

   5.4. If the request is duplicated by a network error, all duplicate
   requests will fail since only the first will find the original
   "marker RR" present and having its known previous value.  The
   decisions of whether to use such a "marker RR" and what RR to use are
   left up to the application programmer, though one obvious choice is
   the zone's SOA RR as described below.

   5.5. Requestors can ensure update ordering by externally
   synchronizing their use of successive values of the "marker RR."
   Mutual exclusion can be addressed as a degenerate case, in that a
   single succession of the "marker RR" is all that is needed.

   5.6. A special case where update ordering and datagram duplication
   intersect is when an RR validly changes to some new value and then
   back to its previous value.  Without a "marker RR" as described
   above, this sequence of updates can leave the zone in an undefined
   state if datagrams are duplicated.

   5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
   a requestor could first retrieve the SOA RR, and build an UPDATE
   message one of whose prerequisites was the old SOA RR.  It would then
   specify updates that would delete this SOA RR and add a new one with
   an incremented SOA SERIAL, along with whatever actual prerequisites



Vixie, et. al.              Standards Track                    [Page 19]

RFC 2136                       DNS Update                     April 1997


   and updates were the object of the transaction.  If the transaction
   succeeds, the requestor knows that the RRs being changed were not
   otherwise altered by any other requestor.

6 - Forwarding

   When a zone slave forwards an UPDATE message upward toward the zone's
   primary master server, it must allocate a new ID and prepare to enter
   the role of "forwarding server," which is a requestor with respect to
   the forward server.

   6.1. The set of forward servers will be same as the set of servers
   this zone slave would use as the source of AXFR or IXFR data.  So,
   while the original requestor might have used the zone's NS RRset to
   locate its update server, a forwarder always forwards toward its
   designated zone master servers.

   6.2. If the original requestor used TCP, then the TCP connection from
   the requestor is still open and the forwarder must use TCP to forward
   the message.  If the original requestor used UDP, the forwarder may
   use either UDP or TCP to forward the message, at the whim of the
   implementor.

   6.3. It is reasonable for forward servers to be forwarders
   themselves, if the AXFR dependency graph being followed is a deep one
   involving firewalls and multiple connectivity realms.  In most cases
   the AXFR dependency graph will be shallow and the forward server will
   be the primary master server.