rfc4034.txt

非常好的dns解析软件

   warrant them.

   A DNSSEC aware resolver or name server MUST implement all MANDATORY
   algorithms.

A.1.  DNSSEC Algorithm Types

   The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
   security algorithm being used.  These values are stored in the
   "Algorithm number" field in the resource record RDATA.

   Some algorithms are usable only for zone signing (DNSSEC), some only
   for transaction security mechanisms (SIG(0) and TSIG), and some for
   both.  Those usable for zone signing may appear in DNSKEY, RRSIG, and
   DS RRs.  Those usable for transaction security would be present in
   SIG(0) and KEY RRs, as described in [RFC2931].

                                Zone
   Value Algorithm [Mnemonic]  Signing  References   Status
   ----- -------------------- --------- ----------  ---------
     0   reserved
     1   RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
     2   Diffie-Hellman [DH]      n      [RFC2539]   -
     3   DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
     4   Elliptic Curve [ECC]              TBA       -
     5   RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY
   252   Indirect [INDIRECT]      n                  -
   253   Private [PRIVATEDNS]     y      see below  OPTIONAL
   254   Private [PRIVATEOID]     y      see below  OPTIONAL
   255   reserved

   6 - 251  Available for assignment by IETF Standards Action.









Arends, et al.              Standards Track                    [Page 24]

RFC 4034                DNSSEC Resource Records               March 2005


A.1.1.  Private Algorithm Types

   Algorithm number 253 is reserved for private use and will never be
   assigned to a specific algorithm.  The public key area in the DNSKEY
   RR and the signature area in the RRSIG RR begin with a wire encoded
   domain name, which MUST NOT be compressed.  The domain name indicates
   the private algorithm to use, and the remainder of the public key
   area is determined by that algorithm.  Entities should only use
   domain names they control to designate their private algorithms.

   Algorithm number 254 is reserved for private use and will never be
   assigned to a specific algorithm.  The public key area in the DNSKEY
   RR and the signature area in the RRSIG RR begin with an unsigned
   length byte followed by a BER encoded Object Identifier (ISO OID) of
   that length.  The OID indicates the private algorithm in use, and the
   remainder of the area is whatever is required by that algorithm.
   Entities should only use OIDs they control to designate their private
   algorithms.

A.2.  DNSSEC Digest Types

   A "Digest Type" field in the DS resource record types identifies the
   cryptographic digest algorithm used by the resource record.  The
   following table lists the currently defined digest algorithm types.

              VALUE   Algorithm                 STATUS
                0      Reserved                   -
                1      SHA-1                   MANDATORY
              2-255    Unassigned                 -

Appendix B.  Key Tag Calculation

   The Key Tag field in the RRSIG and DS resource record types provides
   a mechanism for selecting a public key efficiently.  In most cases, a
   combination of owner name, algorithm, and key tag can efficiently
   identify a DNSKEY record.  Both the RRSIG and DS resource records
   have corresponding DNSKEY records.  The Key Tag field in the RRSIG
   and DS records can be used to help select the corresponding DNSKEY RR
   efficiently when more than one candidate DNSKEY RR is available.

   However, it is essential to note that the key tag is not a unique
   identifier.  It is theoretically possible for two distinct DNSKEY RRs
   to have the same owner name, the same algorithm, and the same key
   tag.  The key tag is used to limit the possible candidate keys, but
   it does not uniquely identify a DNSKEY record.  Implementations MUST
   NOT assume that the key tag uniquely identifies a DNSKEY RR.





Arends, et al.              Standards Track                    [Page 25]

RFC 4034                DNSSEC Resource Records               March 2005


   The key tag is the same for all DNSKEY algorithm types except
   algorithm 1 (please see Appendix B.1 for the definition of the key
   tag for algorithm 1).  The key tag algorithm is the sum of the wire
   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
   RDATA (in wire format) is treated as a series of 2 octet groups.
   These groups are then added together, ignoring any carry bits.

   A reference implementation of the key tag algorithm is as an ANSI C
   function is given below, with the RDATA portion of the DNSKEY RR is
   used as input.  It is not necessary to use the following reference
   code verbatim, but the numerical value of the Key Tag MUST be
   identical to what the reference implementation would generate for the
   same input.

   Please note that the algorithm for calculating the Key Tag is almost
   but not completely identical to the familiar ones-complement checksum
   used in many other Internet protocols.  Key Tags MUST be calculated
   using the algorithm described here rather than the ones complement
   checksum.

   The following ANSI C reference implementation calculates the value of
   a Key Tag.  This reference implementation applies to all algorithm
   types except algorithm 1 (see Appendix B.1).  The input is the wire
   format of the RDATA portion of the DNSKEY RR.  The code is written
   for clarity, not efficiency.

   /*
    * Assumes that int is at least 16 bits.
    * First octet of the key tag is the most significant 8 bits of the
    * return value;
    * Second octet of the key tag is the least significant 8 bits of the
    * return value.
    */

   unsigned int
   keytag (
           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
           unsigned int keysize  /* the RDLENGTH */
          )
   {
           unsigned long ac;     /* assumed to be 32 bits or larger */
           int i;                /* loop index */

           for ( ac = 0, i = 0; i < keysize; ++i )
                   ac += (i & 1) ? key[i] : key[i] << 8;
           ac += (ac >> 16) & 0xFFFF;
           return ac & 0xFFFF;
   }



Arends, et al.              Standards Track                    [Page 26]

RFC 4034                DNSSEC Resource Records               March 2005


B.1.  Key Tag for Algorithm 1 (RSA/MD5)

   The key tag for algorithm 1 (RSA/MD5) is defined differently from the
   key tag for all other algorithms, for historical reasons.  For a
   DNSKEY RR with algorithm 1, the key tag is defined to be the most
   significant 16 bits of the least significant 24 bits in the public
   key modulus (in other words, the 4th to last and 3rd to last octets
   of the public key modulus).

   Please note that Algorithm 1 is NOT RECOMMENDED.









































Arends, et al.              Standards Track                    [Page 27]

RFC 4034                DNSSEC Resource Records               March 2005


Authors' Addresses

   Roy Arends
   Telematica Instituut
   Brouwerijstraat 1
   7523 XC  Enschede
   NL

   EMail: [e-mail]


   Rob Austein
   Internet Systems Consortium
   950 Charter Street
   Redwood City, CA  94063
   USA

   EMail: [e-mail]


   Matt Larson
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   USA

   EMail: [e-mail]


   Dan Massey
   Colorado State University
   Department of Computer Science
   Fort Collins, CO 80523-1873

   EMail: [e-mail]


   Scott Rose
   National Institute for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-8920
   USA

   EMail: [e-mail]







Arends, et al.              Standards Track                    [Page 28]

RFC 4034                DNSSEC Resource Records               March 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Arends, et al.              Standards Track                    [Page 29]