rfc2137.txt

bind 9.3结合mysql数据库

   The class of any update authorizing KEY RR must be the same as the
   class of any RR's being added or deleted.

3.1.3 Update Key Signatory Field

   The four bit "signatory field" (see RFC 2065) of any update
   authorizing KEY RR must be non-zero.  The bits have the meanings
   described below for non-zone keys (see section 3.2 for zone type
   keys).

                    UPDATE KEY RR SIGNATORY FIELD BITS

         0           1           2           3
   +-----------+-----------+-----------+-----------+
   |   zone    |  strong   |  unique   |  general  |
   +-----------+-----------+-----------+-----------+

   Bit 0, zone control - If nonzero, this key is authorized to attach,
        detach, and move zones by creating and deleting NS, glue A, and
        zone KEY RR(s).  If zero, the key can not authorize any update
        that would effect such RRs.  This bit is meaningful for both
        type A and type B dynamic secure zones.




Eastlake                    Standards Track                     [Page 6]

RFC 2137                         SDNSDU                       April 1997


        NOTE:  do not confuse the "zone" signatory field bit with the
        "zone" key type bit.

   Bit 1, strong update - If nonzero, this key is authorized to add and
        delete RRs even if there are other RRs with the same owner name
        and class that are authenticated by a SIG signed with a
        different dynamic update KEY. If zero, the key can only
        authorize updates where any existing RRs of the same owner and
        class are authenticated by a SIG using the same key.  This bit
        is meaningful only for type A dynamic zones and is ignored in
        type B dynamic zones.

        Keeping this bit zero on multiple KEY RRs with the same or
        nested wild card owner names permits multiple entities to exist
        that can create and delete names but can not effect RRs with
        different owner names from any they created.  In effect, this
        creates two levels of dynamic update key, strong and weak, where
        weak keys are limited in interfering with each other but a
        strong key can interfere with any weak keys or other strong
        keys.

   Bit 2, unique name update - If nonzero, this key is authorized to add
        and update RRs for only a single owner name.  If there already
        exist RRs with one or more names signed by this key, they may be
        updated but no new name created until the number of existing
        names is reduced to zero.  This bit is meaningful only for mode
        A dynamic zones and is ignored in mode B dynamic zones. This bit
        is meaningful only if the owner name is a wildcard.  (Any
        dynamic update KEY with a non-wildcard name is, in effect, a
        unique name update key.)

        This bit can be used to restrict a KEY from flooding a zone with
        new names.  In conjunction with a local administratively imposed
        limit on the number of dynamic RRs with a particular name, it
        can completely restrict a KEY from flooding a zone with RRs.

   Bit 3, general update - The general update signatory field bit has no
        special meaning.  If the other three bits are all zero, it must
        be one so that the field is non-zero to designate that the key
        is an update key.  The meaning of all values of the signatory
        field with the general bit and one or more other signatory field
        bits on is reserved.

   All the signatory bit update authorizations described above only
   apply if the update is within the name and class scope as per
   sections 3.1.1 and 3.1.2.





Eastlake                    Standards Track                     [Page 7]

RFC 2137                         SDNSDU                       April 1997


3.2 Zone Keys and Update Modes

   Zone type keys are automatically authorized to sign anything in their
   zone, of course, regardless of the value of their signatory field.
   For zone keys, the signatory field bits have different means than
   they they do for update keys, as shown below.  The signatory field
   MUST be zero if dynamic update is not supported for a zone and MUST
   be non-zero if it is.

                     ZONE KEY RR SIGNATORY FIELD BITS

                  0           1           2           3
            +-----------+-----------+-----------+-----------+
            |   mode    |  strong   |  unique   |  general  |
            +-----------+-----------+-----------+-----------+

   Bit 0, mode - This bit indicates the update mode for this zone.  Zero
        indicates mode A while a one indicates mode B.

   Bit 1, strong update - If nonzero, this indicates that the "strong"
        key feature described in section 3.1.3 above is implemented and
        enabled for this secure zone.  If zero, the feature is not
        available.  Has no effect if the zone is a mode B secure update
        zone.

   Bit 2, unique name update - If nonzero, this indicates that the
        "unique name" feature described in section 3.1.3 above is
        implemented and enabled for this secure zone.  If zero, this
        feature is not available.  Has no effect if the zone is a mode B
        secure update zone.

   Bit 3, general - This bit has no special meeting.  If dynamic update
        for a zone is supported and the other bits in the zone key
        signatory field are zero, it must be a one.  The meaning of zone
        keys where the signatory field has the general bit and one or
        more other bits on is reserved.

   If there are multiple dynamic update KEY RRs for a zone and zone
   policy is in transition, they might have different non-zero signatory
   fields.  In that case, strong and unique name restrictions must be
   enforced as long as there is a non-expired zone key being advertised
   that indicates mode A with the strong or unique name bit on
   respectively.  Mode B updates MUST be supported as long as there is a
   non-expired zone key that indicates mode B.  Mode A updates may be
   treated as mode B updates at server option if non-expired zone keys
   indicate that both are supported.





Eastlake                    Standards Track                     [Page 8]

RFC 2137                         SDNSDU                       April 1997


   A server that will be executing update operations on a zone, that is,
   the primary master server, MUST not advertize a zone key that will
   attract requests for a mode or features that it can not support.

3.3 Wildcard Key Punch Through

   Just as a zone key is valid throughout the entire zone, update keys
   with wildcard names are valid throughout their extended scope, within
   the zone. That is, they remain valid for any name that would match
   them, even existing specific names within their apparent scope.

   If this were not so, then whenever a name within a wildcard scope was
   created by dynamic update, it would be necessary to first create a
   copy of the KEY RR with this name, because otherwise the existence of
   the more specific name would hide the authorizing KEY RR and would
   make later updates impossible.  An updater could create such a KEY RR
   but could not zone sign it with their authorizing signer.  They would
   have to sign it with the same key using the wildcard name as signer.
   Thus in creating, for example, one hundred type A RRs authorized by a
   *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100
   KEYs, and 200 SIGs would have to be created as opposed to merely 100
   As and 100 SIGs with key punch through.

4. Update Signatures

   Two kinds of signatures can appear in updates.  Request signatures,
   which are always required, cover the entire request and authenticate
   the DNS header, including opcode, counts, etc., as well as the data.
   Data signatures, on the other hand, appear only among the RRs to be
   added and are only required for mode A operation.  These two types of
   signatures are described further below.

4.1 Update Request Signatures

   An update can effect multiple owner names in a zone.  It may be that
   these different names are covered by different dynamic update keys.
   For every owner name effected, the updater must know a private key
   valid for that name (and the zone's class) and must prove this by
   appending request SIG RRs under each such key.

   As specified in RFC 2065, a request signature is a SIG RR occurring
   at the end of a request with a type covered field of zero.  For an
   update, request signatures occur in the Additional information
   section.  Each request SIG signs the entire request, including DNS
   header, but excluding any other request SIG(s) and with the ARCOUNT
   in the DNS header set to what it wold be without the request SIGs.





Eastlake                    Standards Track                     [Page 9]

RFC 2137                         SDNSDU                       April 1997


4.2 Update Data Signatures

   Mode A dynamic secure zones require that the update requester provide
   SIG RRs that will authenticate the after update state of all RR sets
   that are changed by the update and are non-empty after the update.
   These SIG RRs appear in the request as RRs to be added and the
   request must delete any previous data SIG RRs that are invalidated by
   the request.

   In Mode B dynamic secure zones, all zone data is authenticated by
   zone key SIG RRs.  In this case, data signatures need not be included
   with the update.  A resolver can determine which mode an updatable
   secure zone is using by examining the signatory field bits of the
   zone KEY RR (see section 3.2).

5. Security Considerations

   Any zone permitting dynamic updates is inherently less secure than a
   static secure zone maintained off line as recommended in RFC 2065. If
   nothing else, secure dynamic update requires on line change to and
   re-signing of the zone SOA resource record (RR) to increase the SOA
   serial number.  This means that compromise of the primary server host
   could lead to arbitrary serial number changes.

   Isolation of dynamic RRs to separate zones from those holding most
   static RRs can limit the damage that could occur from breach of a
   dynamic zone's security.

References

   [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
   Extensions", RFC 2065, CyberCash, Iris, January 1997.

   [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
   April 1997.

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
   Specifications", STD 13, RFC 1035, November 1987.

   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
   STD 13, RFC 1034, November 1987.









Eastlake                    Standards Track                    [Page 10]

RFC 2137                         SDNSDU                       April 1997


Author's Address

   Donald E. Eastlake, 3rd
   CyberCash, Inc.
   318 Acton Street
   Carlisle, MA 01741 USA

   Phone:   [phone]
            [phone] (fax)
            [phone] (main office, Reston, Virginia, USA)
   EMail:   [e-mail]








































Eastlake                    Standards Track                    [Page 11]