rfc2136.txt

bind 9.3结合mysql数据库

   For this prerequisite, a requestor adds to the section a single RR
   whose NAME and TYPE are equal to that of the zone RRset whose
   existence is required.  RDLENGTH is zero and RDATA is therefore
   empty.  CLASS must be specified as ANY to differentiate this
   condition from that of an actual RR whose RDLENGTH is naturally zero
   (0) (e.g., NULL).  TTL is specified as zero (0).

   2.4.2 - RRset Exists (Value Dependent)

   A set of RRs with a specified NAME and TYPE exists and has the same
   members with the same RDATAs as the RRset specified here in this
   section.  While RRset ordering is undefined and therefore not
   significant to this comparison, the sets be identical in their
   extent.

   For this prerequisite, a requestor adds to the section an entire
   RRset whose preexistence is required.  NAME and TYPE are that of the
   RRset being denoted.  CLASS is that of the zone.  TTL must be
   specified as zero (0) and is ignored when comparing RRsets for
   identity.







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


   2.4.3 - RRset Does Not Exist

   No RRs with a specified NAME and TYPE (in the zone and class denoted
   by the Zone Section) can exist.

   For this prerequisite, a requestor adds to the section a single RR
   whose NAME and TYPE are equal to that of the RRset whose nonexistence
   is required.  The RDLENGTH of this record is zero (0), and RDATA
   field is therefore empty.  CLASS must be specified as NONE in order
   to distinguish this condition from a valid RR whose RDLENGTH is
   naturally zero (0) (for example, the NULL RR).  TTL must be specified
   as zero (0).

   2.4.4 - Name Is In Use

   Name is in use.  At least one RR with a specified NAME (in the zone
   and class specified by the Zone Section) must exist.  Note that this
   prerequisite is NOT satisfied by empty nonterminals.

   For this prerequisite, a requestor adds to the section a single RR
   whose NAME is equal to that of the name whose ownership of an RR is
   required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS must
   be specified as ANY to differentiate this condition from that of an
   actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL).  TYPE
   must be specified as ANY to differentiate this case from that of an
   RRset existence test.  TTL is specified as zero (0).

   2.4.5 - Name Is Not In Use

   Name is not in use.  No RR of any type is owned by a specified NAME.
   Note that this prerequisite IS satisfied by empty nonterminals.

   For this prerequisite, a requestor adds to the section a single RR
   whose NAME is equal to that of the name whose nonownership of any RRs
   is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
   must be specified as NONE.  TYPE must be specified as ANY.  TTL must
   be specified as zero (0).

   2.5 - Update Section

   This section contains RRs to be added to or deleted from the zone.
   The format of this section is as specified by [RFC1035 4.1.3].  There
   are four possible sets of semantics, summarized below and with
   details to follow.







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


      (1) Add RRs to an RRset.
      (2) Delete an RRset.
      (3) Delete all RRsets from a name.
      (4) Delete an RR from an RRset.

   The syntax of these is as follows:

   2.5.1 - Add To An RRset

   RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
   and RDATA are those being added, and CLASS is the same as the zone
   class.  Any duplicate RRs will be silently ignored by the primary
   master.

   2.5.2 - Delete An RRset

   One RR is added to the Update Section whose NAME and TYPE are those
   of the RRset to be deleted.  TTL must be specified as zero (0) and is
   otherwise not used by the primary master.  CLASS must be specified as
   ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
   If no such RRset exists, then this Update RR will be silently ignored
   by the primary master.

   2.5.3 - Delete All RRsets From A Name

   One RR is added to the Update Section whose NAME is that of the name
   to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
   be specified as zero (0) and is otherwise not used by the primary
   master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
   and RDATA must therefore be empty.  If no such RRsets exist, then
   this Update RR will be silently ignored by the primary master.

   2.5.4 - Delete An RR From An RRset

   RRs to be deleted are added to the Update Section.  The NAME, TYPE,
   RDLENGTH and RDATA must match the RR being deleted.  TTL must be
   specified as zero (0) and will otherwise be ignored by the primary
   master.  CLASS must be specified as NONE to distinguish this from an
   RR addition.  If no such RRs exist, then this Update RR will be
   silently ignored by the primary master.











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


   2.6 - Additional Data Section

   This section contains RRs which are related to the update itself, or
   to new RRs being added by the update.  For example, out of zone glue
   (A RRs referred to by new NS RRs) should be presented here.  The
   server can use or ignore out of zone glue, at the discretion of the
   server implementor.  The format of this section is as specified by
   [RFC1035 4.1.3].

3 - Server Behavior

   A server, upon receiving an UPDATE request, will signal NOTIMP to the
   requestor if the UPDATE opcode is not recognized or if it is
   recognized but has not been implemented.  Otherwise, processing
   continues as follows.

   3.1 - Process Zone Section

   3.1.1. The Zone Section is checked to see that there is exactly one
   RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
   requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
   so named is one of this server's authority zones, else signal NOTAUTH
   to the requestor.  If the server is a zone slave, the request will be
   forwarded toward the primary master.

   3.1.2 - Pseudocode For Zone Section Processing

      if (zcount != 1 || ztype != SOA)
           return (FORMERR)
      if (zone_type(zname, zclass) == SLAVE)
           return forward()
      if (zone_type(zname, zclass) == MASTER)
           return update()
      return (NOTAUTH)

   Sections 3.2 through 3.8 describe the primary master's behaviour,
   whereas Section 6 describes a forwarder's behaviour.

   3.2 - Process Prerequisite Section

   Next, the Prerequisite Section is checked to see that all
   prerequisites are satisfied by the current state of the zone.  Using
   the definitions expressed in Section 1.2, if any RR's NAME is not
   within the zone specified in the Zone Section, signal NOTZONE to the
   requestor.






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


   3.2.1. For RRs in this section whose CLASS is ANY, test to see that
   TTL and RDLENGTH are both zero (0), else signal FORMERR to the
   requestor.  If TYPE is ANY, test to see that there is at least one RR
   in the zone whose NAME is the same as that of the Prerequisite RR,
   else signal NXDOMAIN to the requestor.  If TYPE is not ANY, test to
   see that there is at least one RR in the zone whose NAME and TYPE are
   the same as that of the Prerequisite RR, else signal NXRRSET to the
   requestor.

   3.2.2. For RRs in this section whose CLASS is NONE, test to see that
   the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
   requestor.  If the TYPE is ANY, test to see that there are no RRs in
   the zone whose NAME is the same as that of the Prerequisite RR, else
   signal YXDOMAIN to the requestor.  If the TYPE is not ANY, test to
   see that there are no RRs in the zone whose NAME and TYPE are the
   same as that of the Prerequisite RR, else signal YXRRSET to the
   requestor.

   3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
   test to see that the TTL is zero (0), else signal FORMERR to the
   requestor.  Then, build an RRset for each unique <NAME,TYPE> and
   compare each resulting RRset for set equality (same members, no more,
   no less) with RRsets in the zone.  If any Prerequisite RRset is not
   entirely and exactly matched by a zone RRset, signal NXRRSET to the
   requestor.  If any RR in this section has a CLASS other than ZCLASS
   or NONE or ANY, signal FORMERR to the requestor.

   3.2.4 - Table Of Metavalues Used In Prerequisite Section

   CLASS    TYPE     RDATA    Meaning
   ------------------------------------------------------------
   ANY      ANY      empty    Name is in use
   ANY      rrset    empty    RRset exists (value independent)
   NONE     ANY      empty    Name is not in use
   NONE     rrset    empty    RRset does not exist
   zone     rrset    rr       RRset exists (value dependent)















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


   3.2.5 - Pseudocode for Prerequisite Section Processing

      for rr in prerequisites
           if (rr.ttl != 0)
                return (FORMERR)
           if (zone_of(rr.name) != ZNAME)
                return (NOTZONE);
           if (rr.class == ANY)
                if (rr.rdlength != 0)
                     return (FORMERR)
                if (rr.type == ANY)
                     if (!zone_name<rr.name>)
                          return (NXDOMAIN)
                else
                     if (!zone_rrset<rr.name, rr.type>)
                          return (NXRRSET)
           if (rr.class == NONE)
                if (rr.rdlength != 0)
                     return (FORMERR)
                if (rr.type == ANY)
                     if (zone_name<rr.name>)
                          return (YXDOMAIN)
                else
                     if (zone_rrset<rr.name, rr.type>)
                          return (YXRRSET)
           if (rr.class == zclass)
                temp<rr.name, rr.type> += rr
           else
                return (FORMERR)

      for rrset in temp
           if (zone_rrset<rrset.name, rrset.type> != rrset)
                return (NXRRSET)

   3.3 - Check Requestor's Permissions

   3.3.1. Next, the requestor's permission to update the RRs named in
   the Update Section may be tested in an implementation dependent
   fashion or using mechanisms specified in a subsequent Secure DNS
   Update protocol.  If the requestor does not have permission to
   perform these updates, the server may write a warning message in its
   operations log, and may either signal REFUSED to the requestor, or
   ignore the permission problem and proceed with the update.








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


   3.3.2. While the exact processing is implementation defined, if these
   verification activities are to be performed, this is the point in the
   server's processing where such performance should take place, since
   if a REFUSED condition is encountered after an update has been
   partially applied, it will be necessary to undo the partial update
   and restore the zone to its original state before answering the
   requestor.

   3.3.3 - Pseudocode for Permission Checking

      if (security policy exists)
           if (this update is not permitted)
                if (local option)
                     log a message about permission problem
                if (local option)
                     return (REFUSED)

   3.4 - Process Update Section

   Next, the Update Section is processed as follows.

   3.4.1 - Prescan

   The Update Section is parsed into RRs and each RR's CLASS is checked
   to see if it is ANY, NONE, or the same as the Zone Class, else signal
   a FORMERR to the requestor.  Using the definitions in Section 1.2,
   each RR's NAME must be in the zone specified by the Zone Section,
   else signal NOTZONE to the requestor.

   3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
   ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
   unrecognized type, then signal FORMERR to the requestor.  For RRs
   whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
   else signal a FORMERR to the requestor.  For any RR whose CLASS is
   ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
   the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
   MAILB, or any other QUERY metatype besides ANY, or any unrecognized
   type, else signal FORMERR to the requestor.













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