rfc4034.txt

非常好的dns解析软件

   The first four text fields specify the name, TTL, Class, and RR type
   (DS).  Value 60485 is the key tag for the corresponding
   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the
   algorithm used to construct the digest, and the rest of the RDATA
   text is the digest in hexadecimal.

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 in order to construct and verify RRSIG
   RRs.

6.1.  Canonical DNS Name Order

   For the 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 uppercase
   US-ASCII letters are treated as if they were lowercase US-ASCII
   letters.







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


   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
   by 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 the 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;

   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.





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


6.3.  Canonical RR Ordering within an RRset

   For the 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
   in which 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, it 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), it MUST remove all but one of the duplicate RR(s) for the
   purposes of calculating the canonical form of the RRset.

7.  IANA Considerations

   This document introduces no new IANA considerations, as 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 that are (or once were) related to DNSSEC.

   Please refer to [RFC4035] 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 to 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 ([RFC3755]).
      See Appendix A for a full listing of the DNS Security Algorithm
      Numbers entries at the time of this writing and their status for
      use in DNSSEC.




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


      [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] reassigned 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 a
      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 assignments for bit 7 (the ZONE bit)
      and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
      As stated in [RFC3755], bits 0-6 and 8-14 are available for
      assignment by IETF Standards Action.

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 [RFC4033] and [RFC4035] for
   additional security considerations related to the use of these
   records.

   The DS record points to a DNSKEY RR by 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 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 that 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 that uses only the key tag to select a DNSKEY RR
   might select the wrong public key in some circumstances.  Please see
   Appendix B for further details.







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


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

9.  Acknowledgements

   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.  Although explicitly listing everyone who has
   contributed during the decade in which DNSSEC has been under
   development would be impossible, [RFC4033] includes a list of some of
   the participants who were kind enough to comment on these documents.

10.  References

10.1.  Normative References

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

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

   [RFC2536]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
              System (DNS)", RFC 2536, March 1999.

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

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





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


   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
              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 (DS)", RFC 3755, May 2004.

   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
              System KEY (DNSKEY) Resource Record (RR) Secure Entry
              Point (SEP) Flag", RFC 3757, April 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

10.2.  Informative References

   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
              Extensions", RFC 2535, March 1999.

   [RFC2537]  Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
              Name System (DNS)", RFC 2537, March 1999.

   [RFC2539]  Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
              Domain Name System (DNS)", RFC 2539, March 1999.

   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
              RR)", RFC 2930, September 2000.

   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
              RDATA Format", RFC 3845, August 2004.








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


Appendix A.  DNSSEC Algorithm and Digest Types

   The DNS security extensions are designed to be independent of the
   underlying cryptographic algorithms.  The DNSKEY, RRSIG, and DS
   resource records all use a DNSSEC Algorithm Number to identify the
   cryptographic algorithm in use by the resource record.  The DS
   resource record also specifies a Digest Algorithm Number to identify
   the digest algorithm used to construct the DS record.  The currently
   defined Algorithm and Digest Types are listed below.  Additional
   Algorithm or Digest Types could be added as advances in cryptography