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

bind-3.2.

Arends, et al.           Expires August 26, 2003               [Page 17]

Internet-Draft           DNSSEC Resource Records           February 2003


5. The DS Resource Record

   The DS Resource Record refers to a KEY RR and is used in the DNS KEY
   authentication process.  A DS RR refers to a KEY RR by storing the
   key tag, algorithm number, and a digest of KEY RR.  Note that while
   the digest should be sufficient to identify the key, storing the key
   tag and key algorithm helps make the identification process more
   efficient.  By authenticating the DS record, a resolver can
   authenticate the KEY RR to which the DS record points.  The key
   authentication process is described in [11].

   The DS RR and its corresponding KEY RR have the same owner name, but
   they are stored in different locations.  The DS RR appears only on
   the upper (parental) side of a delegation, and is authoritative data
   in the parent zone.  For example, the DS RR for "example.com" is
   stored in the "com" zone (the parent zone) rather than in the
   "example.com" zone (the child zone).  The corresponding KEY RR is
   stored in the "example.com" zone (the child zone).  This simplifies
   DNS zone management and zone signing, but introduces special response
   processing requirements for the DS RR; these are described in [11].

   The type number for the DS record is 43.

   The DS resource record is class independent.

   There are no special TTL requirements on the DS resource record.

5.1 DS RDATA Wire Format

   The RDATA for a DS RR consists of 2 octet Key Tag field, a one octet
   Algorithm field, a one octet Digest Type field, and a Digest field.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Key Tag             |  Algorithm    |  Digest Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Digest                             /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


5.1.1 The Key Tag Field

   The Key Tag field lists the key tag of the KEY RR referred to by the
   DS record.  The KEY RR MUST be a zone key.  The KEY RR Flags MUST
   have Flags bit 7 set to value 1.



Arends, et al.           Expires August 26, 2003               [Page 18]

Internet-Draft           DNSSEC Resource Records           February 2003


   The Key Tag used by the DS RR is identical to the Key Tag used by the
   SIG RR and Appendix B describes how to compute a Key Tag.

5.1.2 The Algorithm Field

   The Algorithm field lists the algorithm number of the KEY RR referred
   to by the DS record.

   The algorithm number used by the DS RR is identical to the algorithm
   number used by the SIG RR and KEY RR.  Appendix A.1 lists the
   algorithm number types.

5.1.3 The Digest Type Field

   The DS RR refers to a KEY RR by including a digest of that KEY RR.
   The Digest Type field identifies the algorithm used to construct the
   digest and Appendix A.2 lists the possible digest algorithm types.

5.1.4 The Digest Field

   The DS record refers to a KEY RR by including a digest of that KEY
   RR.  The Digest field holds the digest.

   The digest is calculated by concatenating the canonical form of the
   fully qualified owner name of the KEY RR (abbreviated below as "key
   RR name") with the KEY RDATA, and then applying the digest algorithm.

     digest = digest_algorithm( KEY RR name | KEY RDATA);

      "|" denotes concatenation

     KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key.


   The size of the digest may vary depending on the digest algorithm and
   KEY RR size.  Currently, the defined digest algorithm is SHA-1, which
   produces a 20 octet digest.

5.2 The DS RR Presentation Format

   The presentation format of the RDATA portion is as follows:

   The Key Tag field is represented as an unsigned decimal integer.

   The Algorithm field is represented either as an unsigned decimal
   integer or as an algorithm mnemonic specified in Appendix A.1.

   The Digest Type field is represented as an unsigned decimal integer.



Arends, et al.           Expires August 26, 2003               [Page 19]

Internet-Draft           DNSSEC Resource Records           February 2003


   The Digest is represented as a sequence of case-insensitive
   hexadecimal digits.  Whitespace is allowed within the hexadecimal
   text.

5.3 DS RR Example

   The following example shows a KEY RR and its corresponding DS RR.

   dskey.example.com. 86400 IN KEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                             fwJr1AYtsmx3TGkJaNXVbfi/
                                             2pHm822aJ5iI9BMzNXxeYCmZ
                                             DRD99WYwYqUSdjMmmAphXdvx
                                             egXd/M5+X7OrzKBaMbCVdFLU
                                             Uh6DhweJBjEVv5f2wwjM9Xzc
                                             nOf+EPbtG9DMBmADjFDc2w/r
                                             ljwvFw==
                                             ) ;  key id = 60485

   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                              98631FAD1A292118 )


   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." KEY RR, and value 5 denotes the algorithm used
   by this "dskey.example.com." KEY RR.  The value 1 is the algorithm
   used to construct the digest, and the rest of the RDATA text is the
   digest in hexadecimal.























Arends, et al.           Expires August 26, 2003               [Page 20]

Internet-Draft           DNSSEC Resource Records           February 2003


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 NXT name chain.  A canonical RR form and ordering
   within an RRset are required to construct and verify SIG 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



Arends, et al.           Expires August 26, 2003               [Page 21]

Internet-Draft           DNSSEC Resource Records           February 2003


       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, or A6, all uppercase US-ASCII letters in the DNS
       names within the RDATA of the RR 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
       authoritative zone containing the RR or the Original TTL field of
       the covering SIG RR.

   Editors' Note: the above definition sacrifices readability for an
   attempt at precision.  Please send better text!

6.3 Canonical RR Ordering Within An RRset

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

























Arends, et al.           Expires August 26, 2003               [Page 22]

Internet-Draft           DNSSEC Resource Records           February 2003


7. IANA Considerations

   This document introduces one new IANA consideration.  RFC 2535 [14]
   created an IANA registry for DNS Security Algorithm Numbers.  This
   document re-assigns DNS Security Algorithm Number 252 to be
   "reserved".  This value is no longer available for assignment by
   IANA.

   This document clarifies the use of existing DNS resource records.
   For completeness, the IANA considerations from the previous documents
   which defined these resource records are summarized below.  No IANA
   changes are made by this document other than the one change described
   in the first paragraph of this section.

   [14] updated the IANA registry for DNS Resource Record Types, and
   assigned types 24,25, and 30 to the SIG, KEY, and NXT RRs,
   respectively.  [9] assigned DNS Resource Record Type 43 to DS.

   [14] created an IANA registry for DNSSEC Resource Record Algorithm
   Numbers.  Values to 1-4, and 252-255 were assigned by [14].  Value 5
   was assigned by [8].  Value 252 is re-assigned by this document, as
   noted above.

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

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

   The Flag bits in the KEY RR are not assigned by IANA, and there is no
   IANA registry for these flags.  All changes to the meaning of the KEY
   RR Flag bits require a standards action.

   The meaning of a value of 1 in bit zero of the Type Bit Map of an NXT
   RR can only be assigned by a standards action.














Arends, et al.           Expires August 26, 2003               [Page 23]

Internet-Draft           DNSSEC Resource Records           February 2003


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.  The use of these records is specified in a
   separate document, and security considerations related to the use
   these resource records are discussed in that document.

   The DS record points to a KEY RR using a cryptographic digest, the
   key algorithm type and a key tag.  The DS record is intended to
   identify an existing KEY RR, but it is theoretically possible for an
   attacker to generate a KEY that matches all the DS fields.  The
   probability of constructing such a matching KEY 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 KEY resource records efficiently,
   but it does not uniquely identify a single KEY resource record.  It
   is possible for two distinct KEY RRs to have the same owner name, the
   same algorithm type, and the same key tag.  An implementation which
   used only the key tag to select a KEY RR might select the wrong
   public key in some circumstances.  Implementations MUST NOT assume
   the key tag is unique public key identifier; this is clearly stated
   in Appendix B.






















Arends, et al.           Expires August 26, 2003               [Page 24]

Internet-Draft           DNSSEC Resource Records           February 2003


9. Acknowledgments

   This document was created from the input and ideas of several members
   of the DNS Extensions Working Group and working group mailing list.
   The co-authors of this draft would like to express their thanks for
   the comments and suggestions received during the revision of these
   security extension specifications.