rfc2136.txt

bind 9.3结合mysql数据库

Network Working Group                                  P. Vixie, Editor
Request for Comments: 2136                                          ISC
Updates: 1035                                                S. Thomson
Category: Standards Track                                      Bellcore
                                                             Y. Rekhter
                                                                  Cisco
                                                               J. Bound
                                                                    DEC
                                                             April 1997

         Dynamic Updates in the Domain Name System (DNS UPDATE)

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

   The Domain Name System was originally designed to support queries of
   a statically configured database.  While the data was expected to
   change, the frequency of those changes was expected to be fairly low,
   and all updates were made as external edits to a zone's Master File.

   Using this specification of the UPDATE opcode, it is possible to add
   or delete RRs or RRsets from a specified zone.  Prerequisites are
   specified separately from update operations, and can specify a
   dependency upon either the previous existence or nonexistence of an
   RRset, or the existence of a single RR.

   UPDATE is atomic, i.e., all prerequisites must be satisfied or else
   no update operations will take place.  There are no data dependent
   error conditions defined after the prerequisites have been met.

1 - Definitions

   This document intentionally gives more definition to the roles of
   "Master," "Slave," and "Primary Master" servers, and their
   enumeration in NS RRs, and the SOA MNAME field.  In that sense, the
   following server type definitions can be considered an addendum to
   [RFC1035], and are intended to be consistent with [RFC1996]:

      Slave           an authoritative server that uses AXFR or IXFR to
                      retrieve the zone and is named in the zone's NS
                      RRset.



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


      Master          an authoritative server configured to be the
                      source of AXFR or IXFR data for one or more slave
                      servers.

      Primary Master  master server at the root of the AXFR/IXFR
                      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.

   A domain name identifies a node within the domain name space tree
   structure.  Each node has a set (possibly empty) of Resource Records
   (RRs).  All RRs having the same NAME, CLASS and TYPE are called a
   Resource Record Set (RRset).

   The pseudocode used in this document is for example purposes only.
   If it is found to disagree with the text, the text shall be
   considered authoritative.  If the text is found to be ambiguous, the
   pseudocode can be used to help resolve the ambiguity.

   1.1 - Comparison Rules

   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
   RDLENGTH and RDATA fields are equal.  Note that the time-to-live
   (TTL) field is explicitly excluded from the comparison.

   1.1.2. The rules for comparison of character strings in names are
   specified in [RFC1035 2.3.3].

   1.1.3. Wildcarding is disabled.  That is, a wildcard ("*") in an
   update only matches a wildcard ("*") in the zone, and vice versa.

   1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
   the update, and will not otherwise be followed.  All UPDATE
   operations are done on the basis of canonical names.

   1.1.5. The following RR types cannot be appended to an RRset.  If the
   following comparison rules are met, then an attempt to add the new RR
   will result in the replacement of the previous RR:

      SOA    compare only NAME, CLASS and TYPE -- it is not possible to
             have more than one SOA per zone, even if any of the data
             fields differ.

      WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
             -- only one WKS RR is possible for this tuple, even if the
             services masks differ.




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


      CNAME  compare only NAME, CLASS, and TYPE -- it is not possible
             to have more than one CNAME RR, even if their data fields
             differ.

   1.2 - Glue RRs

   For the purpose of determining whether a domain name used in the
   UPDATE protocol is contained within a specified zone, a domain name
   is "in" a zone if it is owned by that zone's domain name.  See
   section 7.18 for details.

   1.3 - New Assigned Numbers

      CLASS = NONE (254)
      RCODE = YXDOMAIN (6)
      RCODE = YXRRSET (7)
      RCODE = NXRRSET (8)
      RCODE = NOTAUTH (9)
      RCODE = NOTZONE (10)
      Opcode = UPDATE (5)

2 - Update Message Format

   The DNS Message Format is defined by [RFC1035 4.1].  Some extensions
   are necessary (for example, more error codes are possible under
   UPDATE than under QUERY) and some fields must be overloaded (see
   description of CLASS fields below).

   The overall format of an UPDATE message is, following [ibid]:

      +---------------------+
      |        Header       |
      +---------------------+
      |         Zone        | specifies the zone to be updated
      +---------------------+
      |     Prerequisite    | RRs or RRsets which must (not) preexist
      +---------------------+
      |        Update       | RRs or RRsets to be added or deleted
      +---------------------+
      |   Additional Data   | additional data
      +---------------------+










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


   The Header Section specifies that this message is an UPDATE, and
   describes the size of the other sections.  The Zone Section names the
   zone that is to be updated by this message.  The Prerequisite Section
   specifies the starting invariants (in terms of zone content) required
   for this update.  The Update Section contains the edits to be made,
   and the Additional Data Section contains data which may be necessary
   to complete, but is not part of, this update.

   2.1 - Transport Issues

   An update transaction may be carried in a UDP datagram, if the
   request fits, or in a TCP connection (at the discretion of the
   requestor).  When TCP is used, the message is in the format described
   in [RFC1035 4.2.2].

   2.2 - Message Header

   The header of the DNS Message Format is defined by [RFC 1035 4.1].
   Not all opcodes define the same set of flag bits, though as a
   practical matter most of the bits defined for QUERY (in [ibid]) are
   identically defined by the other opcodes.  UPDATE uses only one flag
   bit (QR).

   The DNS Message Format specifies record counts for its four sections
   (Question, Answer, Authority, and Additional).  UPDATE uses the same
   fields, and the same section formats, but the naming and use of these
   sections differs as shown in the following modified header, after
   [RFC1035 4.1.1]:

                                      1  1  1  1  1  1
        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                      ID                       |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |QR|   Opcode  |          Z         |   RCODE   |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                    ZOCOUNT                    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                    PRCOUNT                    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                    UPCOUNT                    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                    ADCOUNT                    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+







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


   These fields are used as follows:

   ID      A 16-bit identifier assigned by the entity that generates any
           kind of request.  This identifier is copied in the
           corresponding reply and can be used by the requestor to match
           replies to outstanding requests, or by the server to detect
           duplicated requests from some requestor.

   QR      A one bit field that specifies whether this message is a
           request (0), or a response (1).

   Opcode  A four bit field that specifies the kind of request in this
           message.  This value is set by the originator of a request
           and copied into the response.  The Opcode value that
           identifies an UPDATE message is five (5).

   Z       Reserved for future use.  Should be zero (0) in all requests
           and responses.  A non-zero Z field should be ignored by
           implementations of this specification.

   RCODE   Response code - this four bit field is undefined in requests
           and set in responses.  The values and meanings of this field
           within responses are as follows:

              Mneumonic   Value   Description
              ------------------------------------------------------------
              NOERROR     0       No error condition.
              FORMERR     1       The name server was unable to interpret
                                  the request due to a format error.
              SERVFAIL    2       The name server encountered an internal
                                  failure while processing this request,
                                  for example an operating system error
                                  or a forwarding timeout.
              NXDOMAIN    3       Some name that ought to exist,
                                  does not exist.
              NOTIMP      4       The name server does not support
                                  the specified Opcode.
              REFUSED     5       The name server refuses to perform the
                                  specified operation for policy or
                                  security reasons.
              YXDOMAIN    6       Some name that ought not to exist,
                                  does exist.
              YXRRSET     7       Some RRset that ought not to exist,
                                  does exist.
              NXRRSET     8       Some RRset that ought to exist,
                                  does not exist.





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


              NOTAUTH     9       The server is not authoritative for
                                  the zone named in the Zone Section.
              NOTZONE     10      A name used in the Prerequisite or
                                  Update Section is not within the
                                  zone denoted by the Zone Section.

   ZOCOUNT The number of RRs in the Zone Section.

   PRCOUNT The number of RRs in the Prerequisite Section.

   UPCOUNT The number of RRs in the Update Section.

   ADCOUNT The number of RRs in the Additional Data Section.

   2.3 - Zone Section

   The Zone Section has the same format as that specified in [RFC1035
   4.1.2], with the fields redefined as follows:

                                      1  1  1  1  1  1
        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                                               |
      /                     ZNAME                     /
      /                                               /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                     ZTYPE                     |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                     ZCLASS                    |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   UPDATE uses this section to denote the zone of the records being
   updated.  All records to be updated must be in the same zone, and
   therefore the Zone Section is allowed to contain exactly one record.
   The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
   the zone's class.

   2.4 - Prerequisite Section

   This section contains a set of RRset prerequisites which must be
   satisfied at the time the UPDATE packet is received by the primary
   master server.  The format of this section is as specified by
   [RFC1035 4.1.3].  There are five possible sets of semantics that can
   be expressed here, summarized as follows and then explained below.

      (1)  RRset exists (value independent).  At least one RR with a
           specified NAME and TYPE (in the zone and class specified by
           the Zone Section) must exist.



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


      (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.

      (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.

      (4)  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.

      (5)  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.

   The syntax of these is as follows:

   2.4.1 - RRset Exists (Value Independent)

   At least one RR with a specified NAME and TYPE (in the zone and class
   specified in the Zone Section) must exist.