draft-ietf-dnsext-dnssec-records-09.txt

bind 9.3结合mysql数据库

   text is the digest in hexadecimal.







Arends, et al.          Expires January 13, 2005               [Page 20]

Internet-Draft          DNSSEC Resource Records                July 2004


6.  Canonical Form and Order of Resource Records

   This section defines a canonical form for resource records, a
   canonical ordering of DNS names, and a canonical ordering of resource
   records within an RRset.  A canonical name order is required to
   construct the NSEC name chain.  A canonical RR form and ordering
   within an RRset are required to construct and verify RRSIG RRs.

6.1  Canonical DNS Name Order

   For purposes of DNS security, owner names are ordered by treating
   individual labels as unsigned left-justified octet strings.  The
   absence of a octet sorts before a zero value octet, and upper case
   US-ASCII letters are treated as if they were lower case US-ASCII
   letters.

   To compute the canonical ordering of a set of DNS names, start by
   sorting the names according to their most significant (rightmost)
   labels.  For names in which the most significant label is identical,
   continue sorting according to their next most significant label, and
   so forth.

   For example, the following names are sorted in canonical DNS name
   order.  The most significant label is "example".  At this level,
   "example" sorts first, followed by names ending in "a.example", then
   names ending "z.example".  The names within each level are sorted in
   the same way.

             example
             a.example
             yljkjljk.a.example
             Z.a.example
             zABC.a.EXAMPLE
             z.example
             \001.z.example
             *.z.example
             \200.z.example


6.2  Canonical RR Form

   For purposes of DNS security, the canonical form of an RR is the wire
   format of the RR where:
   1.  Every domain name in the RR is fully expanded (no DNS name
       compression) and fully qualified;
   2.  All uppercase US-ASCII letters in the owner name of the RR are
       replaced by the corresponding lowercase US-ASCII letters;




Arends, et al.          Expires January 13, 2005               [Page 21]

Internet-Draft          DNSSEC Resource Records                July 2004


   3.  If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
       SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in
       the DNS names contained within the RDATA are replaced by the
       corresponding lowercase US-ASCII letters;
   4.  If the owner name of the RR is a wildcard name, the owner name is
       in its original unexpanded form, including the "*" label (no
       wildcard substitution); and
   5.  The RR's TTL is set to its original value as it appears in the
       originating authoritative zone or the Original TTL field of the
       covering RRSIG RR.

6.3  Canonical RR Ordering Within An RRset

   For purposes of DNS security, RRs with the same owner name, class,
   and type are sorted by treating the RDATA portion of the canonical
   form of each RR as a left-justified unsigned octet sequence where the
   absence of an octet sorts before a zero octet.

   [RFC2181] specifies that an RRset is not allowed to contain duplicate
   records (multiple RRs with the same owner name, class, type, and
   RDATA).  Therefore, if an implementation detects duplicate RRs when
   putting the RRset in canonical form, the implementation MUST treat
   this as a protocol error.  If the implementation chooses to handle
   this protocol error in the spirit of the robustness principle (being
   liberal in what it accepts), the implementation MUST remove all but
   one of the duplicate RR(s) for purposes of calculating the canonical
   form of the RRset.























Arends, et al.          Expires January 13, 2005               [Page 22]

Internet-Draft          DNSSEC Resource Records                July 2004


7.  IANA Considerations

   This document introduces no new IANA considerations, because all of
   the protocol parameters used in this document have already been
   assigned by previous specifications.  However, since the evolution of
   DNSSEC has been long and somewhat convoluted, this section attempts
   to describe the current state of the IANA registries and other
   protocol parameters which are (or once were) related to DNSSEC.

   Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA
   considerations.

   DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
      the SIG, KEY, and NXT RRs, respectively.  [RFC3658] assigned DNS
      Resource Record Type 43 to DS.  [RFC3755] assigned types 46, 47,
      and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
      [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted
      use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
      security protocol described in [RFC2931] and the transaction KEY
      Resource Record described in [RFC2930].

   DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
      for DNSSEC Resource Record Algorithm field numbers, and assigned
      values 1-4 and 252-255.  [RFC3110] assigned value 5.  [RFC3755]
      altered this registry to include flags for each entry regarding
      its use with the DNS security extensions.  Each algorithm entry
      could refer to an algorithm that can be used for zone signing,
      transaction security (see [RFC2931]) or both.  Values 6-251 are
      available for assignment by IETF standards action.  See Appendix A
      for a full listing of the DNS Security Algorithm Numbers entries
      at the time of writing and their status of use in DNSSEC.

      [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
      assigned value 0 to reserved and value 1 to SHA-1.

   KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
      Protocol Values, but [RFC3445] re-assigned all values other than 3
      to reserved and closed this IANA registry.  The registry remains
      closed, and all KEY and DNSKEY records are required to have
      Protocol Octet value of 3.

   Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
      registry for the DNSSEC KEY and DNSKEY RR flag bits.  Initially,
      this registry only contains an assignment for bit 7 (the ZONE bit)
      and a reservation for bit 15 for the Secure Entry Point flag (SEP
      bit) [RFC3757].  Bits 0-6 and 8-14 are available for assignment by
      IETF Standards Action.




Arends, et al.          Expires January 13, 2005               [Page 23]

Internet-Draft          DNSSEC Resource Records                July 2004


8.  Security Considerations

   This document describes the format of four DNS resource records used
   by the DNS security extensions, and presents an algorithm for
   calculating a key tag for a public key.  Other than the items
   described below, the resource records themselves introduce no
   security considerations.  Please see [I-D.ietf-dnsext-dnssec-intro]
   and [I-D.ietf-dnsext-dnssec-protocol] for additional security
   considerations related to the use of these records.

   The DS record points to a DNSKEY RR using a cryptographic digest, the
   key algorithm type and a key tag.  The DS record is intended to
   identify an existing DNSKEY RR, but it is theoretically possible for
   an attacker to generate a DNSKEY that matches all the DS fields.  The
   probability of constructing such a matching DNSKEY depends on the
   type of digest algorithm in use.  The only currently defined digest
   algorithm is SHA-1, and the working group believes that constructing
   a public key which would match the algorithm, key tag, and SHA-1
   digest given in a DS record would be a sufficiently difficult problem
   that such an attack is not a serious threat at this time.

   The key tag is used to help select DNSKEY resource records
   efficiently, but it does not uniquely identify a single DNSKEY
   resource record.  It is possible for two distinct DNSKEY RRs to have
   the same owner name, the same algorithm type, and the same key tag.
   An implementation which uses only the key tag to select a DNSKEY RR
   might select the wrong public key in some circumstances.

   The table of algorithms in Appendix A and the key tag calculation
   algorithms in Appendix B include the RSA/MD5 algorithm for
   completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
   explained in [RFC3110].



















Arends, et al.          Expires January 13, 2005               [Page 24]

Internet-Draft          DNSSEC Resource Records                July 2004


9.  Acknowledgments

   This document was created from the input and ideas of the members of
   the DNS Extensions Working Group and working group mailing list.  The
   editors would like to express their thanks for the comments and
   suggestions received during the revision of these security extension
   specifications.  While explicitly listing everyone who has
   contributed during the decade during which DNSSEC has been under
   development would be an impossible task,
   [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
   participants who were kind enough to comment on these documents.








































Arends, et al.          Expires January 13, 2005               [Page 25]

Internet-Draft          DNSSEC Resource Records                July 2004


10.  References

10.1  Normative References

   [I-D.ietf-dnsext-dnssec-intro]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "DNS Security Introduction and Requirements",
              draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
              2004.

   [I-D.ietf-dnsext-dnssec-protocol]
              Arends, R., Austein, R., Larson, M., Massey, D. and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
              progress), May 2004.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, March 1998.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
              2671, August 1999.

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
              SIG(0)s)", RFC 2931, September 2000.

   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
              Name System (DNS)", RFC 3110, May 2001.

   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY



Arends, et al.          Expires January 13, 2005               [Page 26]

Internet-Draft          DNSSEC Resource Records                July 2004


              Resource Record (RR)", RFC 3445, December 2002.

   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 3548, July 2003.

   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, September 2003.

   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
              (RR)", RFC 3658, December 2003.

   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
              Signer", RFC 3755, April 2004.

   [RFC3757]  Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
              Entry Point Flag", RFC 3757, April 2004.

10.2  Informative References

   [I-D.ietf-dnsext-nsec-rdata]
              Schlyter, J., "DNSSEC NSEC RDATA Format",