idnits 2.17.1 draft-ietf-dnsext-dnssec-records-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC2535, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 501 has weird spacing: '...decimal integ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 17, 2004) is 7283 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Mnemonic' is mentioned on line 1162, but not defined == Missing Reference: 'RSAMD5' is mentioned on line 1165, but not defined == Missing Reference: 'DH' is mentioned on line 1166, but not defined == Missing Reference: 'DSA' is mentioned on line 1167, but not defined == Missing Reference: 'ECC' is mentioned on line 1168, but not defined == Missing Reference: 'RSASHA1' is mentioned on line 1169, but not defined == Missing Reference: 'INDIRECT' is mentioned on line 1170, but not defined == Missing Reference: 'PRIVATEDNS' is mentioned on line 1171, but not defined == Missing Reference: 'PRIVATEOID' is mentioned on line 1172, but not defined == Unused Reference: 'RFC2671' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dnsext-nsec-rdata' is defined on line 1082, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-dnssec-intro-10 == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-protocol-06 ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3757 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-06) exists of draft-ietf-dnsext-nsec-rdata-05 -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 7 errors (**), 0 flaws (~~), 18 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions R. Arends 3 Internet-Draft Telematica Instituut 4 Expires: November 15, 2004 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 May 17, 2004 14 Resource Records for the DNS Security Extensions 15 draft-ietf-dnsext-dnssec-records-08 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 15, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This document is part of a family of documents that describes the DNS 46 Security Extensions (DNSSEC). The DNS Security Extensions are a 47 collection of resource records and protocol modifications that 48 provide source authentication for the DNS. This document defines the 49 public key (DNSKEY), delegation signer (DS), resource record digital 50 signature (RRSIG), and authenticated denial of existence (NSEC) 51 resource records. The purpose and format of each resource record is 52 described in detail, and an example of each resource record is given. 54 This document obsoletes RFC 2535 and incorporates changes from all 55 updates to RFC 2535. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1 Background and Related Documents . . . . . . . . . . . . . 4 61 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3.1 Technical Changes or Corrections . . . . . . . . . . . 4 64 1.3.2 Typos and Minor Corrections . . . . . . . . . . . . . 5 65 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 6 66 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 6 67 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 6 68 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 7 69 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 7 70 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 7 71 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 7 72 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 7 73 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 8 74 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 9 75 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 9 76 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 10 77 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 10 78 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 10 79 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 11 80 3.1.5 Signature Expiration and Inception Fields . . . . . . 11 81 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 11 82 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 12 83 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 12 84 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 13 85 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13 86 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 15 87 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 15 88 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 15 89 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 16 90 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 17 91 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 17 92 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 17 93 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 19 94 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 19 95 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 20 96 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 20 97 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 20 98 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 20 99 5.2 Processing of DS RRs When Validating Responses . . . . . . 20 100 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 21 101 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 21 102 6. Canonical Form and Order of Resource Records . . . . . . . . . 22 103 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 22 104 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 22 105 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 23 106 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 107 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 108 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 110 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 111 10.2 Informative References . . . . . . . . . . . . . . . . . . . 28 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 113 A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 30 114 A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 30 115 A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 30 116 A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 31 117 B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 32 118 B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 33 119 Intellectual Property and Copyright Statements . . . . . . . . 34 121 1. Introduction 123 The DNS Security Extensions (DNSSEC) introduce four new DNS resource 124 record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the 125 purpose of each resource record (RR), the RR's RDATA format, and its 126 presentation format (ASCII representation). 128 1.1 Background and Related Documents 130 The reader is assumed to be familiar with the basic DNS concepts 131 described in [RFC1034], [RFC1035] and subsequent RFCs that update 132 them: [RFC2136], [RFC2181] and [RFC2308]. 134 This document is part of a family of documents that define the DNS 135 security extensions. The DNS security extensions (DNSSEC) are a 136 collection of resource records and DNS protocol modifications that 137 add source authentication and data integrity to the Domain Name 138 System (DNS). An introduction to DNSSEC and definitions of common 139 terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description 140 of DNS protocol modifications can be found in 141 [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC 142 resource records. 144 1.2 Reserved Words 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 1.3 Editors' Notes 152 1.3.1 Technical Changes or Corrections 154 Please report technical corrections to dnssec-editors@east.isi.edu. 155 To assist the editors, please indicate the text in error and point 156 out the RFC that defines the correct behavior. For a technical 157 change where no RFC that defines the correct behavior, or if there's 158 more than one applicable RFC and the definitions conflict, please 159 post the issue to namedroppers. 161 An example correction to dnssec-editors might be: Page X says 162 "DNSSEC RRs SHOULD be automatically returned in responses." This was 163 true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the 164 DNSSEC RR types MUST NOT be included in responses unless the resolver 165 indicated support for DNSSEC. 167 1.3.2 Typos and Minor Corrections 169 Please report any typos corrections to dnssec-editors@east.isi.edu. 170 To assist the editors, please provide enough context for us to find 171 the incorrect text quickly. 173 An example message to dnssec-editors might be: page X says "the 174 DNSSEC standard has been in development for over 1 years". It 175 should read "over 10 years". 177 2. The DNSKEY Resource Record 179 DNSSEC uses public key cryptography to sign and authenticate DNS 180 resource record sets (RRsets). The public keys are stored in DNSKEY 181 resource records and are used in the DNSSEC authentication process 182 described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its 183 authoritative RRsets using a private key and stores the corresponding 184 public key in a DNSKEY RR. A resolver can then use the public key to 185 authenticate signatures covering the RRsets in the zone. 187 The DNSKEY RR is not intended as a record for storing arbitrary 188 public keys and MUST NOT be used to store certificates or public keys 189 that do not directly relate to the DNS infrastructure. 191 The Type value for the DNSKEY RR type is 48. 193 The DNSKEY RR is class independent. 195 The DNSKEY RR has no special TTL requirements. 197 2.1 DNSKEY RDATA Wire Format 199 The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 200 octet Protocol Field, a 1 octet Algorithm Field, and the Public Key 201 Field. 203 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Flags | Protocol | Algorithm | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 / / 209 / Public Key / 210 / / 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 2.1.1 The Flags Field 215 Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, 216 then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner 217 name MUST be the name of a zone. If bit 7 has value 0, then the 218 DNSKEY record holds some other type of DNS public key, such as a 219 public key used by TKEY and MUST NOT be used to verify RRSIGs that 220 cover RRsets. 222 Bit 15 of the Flags field is the Secure Entry Point flag, described 223 in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a 224 key intended for use as a secure entry point. This flag is only 225 intended to be to a hint to zone signing or debugging software as to 226 the intended use of this DNSKEY record; validators MUST NOT alter 227 their behavior during the signature validation process in any way 228 based on the setting of this bit. This also means a DNSKEY RR with 229 the SEP bit set would also need the Zone Key flag set in order to 230 legally be able to generate signatures. A DNSKEY RR with the SEP set 231 and the Zone Key flag not set is an invalid DNSKEY. 233 Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon 234 creation of the DNSKEY RR, and MUST be ignored upon reception. 236 2.1.2 The Protocol Field 238 The Protocol Field MUST have value 3 and the DNSKEY RR MUST be 239 treated as invalid during signature verification if found to be some 240 value other than 3. 242 2.1.3 The Algorithm Field 244 The Algorithm field identifies the public key's cryptographic 245 algorithm and determines the format of the Public Key field. A list 246 of DNSSEC algorithm types can be found in Appendix A.1 248 2.1.4 The Public Key Field 250 The Public Key Field holds the public key material. The format 251 depends on the algorithm of the key being stored and are described in 252 separate documents. 254 2.1.5 Notes on DNSKEY RDATA Design 256 Although the Protocol Field always has value 3, it is retained for 257 backward compatibility with early versions of the KEY record. 259 2.2 The DNSKEY RR Presentation Format 261 The presentation format of the RDATA portion is as follows: 263 The Flag field MUST be represented as an unsigned decimal integer 264 with a value of 0, 256, or 257. 266 The Protocol Field MUST be represented as an unsigned decimal integer 267 with a value of 3. 269 The Algorithm field MUST be represented either as an unsigned decimal 270 integer or as an algorithm mnemonic as specified in Appendix A.1. 272 The Public Key field MUST be represented as a Base64 encoding of the 273 Public Key. Whitespace is allowed within the Base64 text. For a 274 definition of Base64 encoding, see [RFC1521] Section 5.2. 276 2.3 DNSKEY RR Example 278 The following DNSKEY RR stores a DNS zone key for example.com. 280 example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 281 Cbl+BBZH4b/0PY1kxkmvHjcZc8no 282 kfzj31GajIQKY+5CptLr3buXA10h 283 WqTkF7H6RfoRqXQeogmMHfpftf6z 284 Mv1LyBUgia7za6ZEzOJBOztyvhjL 285 742iU/TpPSEDhm2SNKLijfUppn1U 286 aNvv4w== ) 288 The first four text fields specify the owner name, TTL, Class, and RR 289 type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in 290 the Flags field has value 1. Value 3 is the fixed Protocol value. 291 Value 5 indicates the public key algorithm. Appendix A.1 identifies 292 algorithm type 5 as RSA/SHA1 and indicates that the format of the 293 RSA/SHA1 public key field is defined in [RFC3110]. The remaining 294 text is a Base64 encoding of the public key. 296 3. The RRSIG Resource Record 298 DNSSEC uses public key cryptography to sign and authenticate DNS 299 resource record sets (RRsets). Digital signatures are stored in 300 RRSIG resource records and are used in the DNSSEC authentication 301 process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator 302 can use these RRSIG RRs to authenticate RRsets from the zone. The 303 RRSIG RR MUST only be used to carry verification material (digital 304 signatures) used to secure DNS operations. 306 An RRSIG record contains the signature for an RRset with a particular 307 name, class, and type. The RRSIG RR specifies a validity interval 308 for the signature and uses the Algorithm, the Signer's Name, and the 309 Key Tag to identify the DNSKEY RR containing the public key that a 310 validator can use to verify the signature. 312 Because every authoritative RRset in a zone must be protected by a 313 digital signature, RRSIG RRs must be present for names containing a 314 CNAME RR. This is a change to the traditional DNS specification 315 [RFC1034] that stated that if a CNAME is present for a name, it is 316 the only type allowed at that name. A RRSIG and NSEC (see Section 4) 317 MUST exist for the same name as a CNAME resource record in a signed 318 zone. 320 The Type value for the RRSIG RR type is 46. 322 The RRSIG RR is class independent. 324 An RRSIG RR MUST have the same class as the RRset it covers. 326 The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset 327 it covers. This is an exception to the [RFC2181] rules for TTL 328 values of individual RRs within a RRset: individual RRSIG with the 329 same owner name will have different TTL values if the RRsets they 330 cover have different TTL values. 332 3.1 RRSIG RDATA Wire Format 334 The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a 335 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original 336 TTL field, a 4 octet Signature Expiration field, a 4 octet Signature 337 Inception field, a 2 octet Key tag, the Signer's Name field, and the 338 Signature field. 340 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type Covered | Algorithm | Labels | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Original TTL | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Signature Expiration | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Signature Inception | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Key Tag | / 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / 353 / / 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 / / 356 / Signature / 357 / / 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 3.1.1 The Type Covered Field 362 The Type Covered field identifies the type of the RRset that is 363 covered by this RRSIG record. 365 3.1.2 The Algorithm Number Field 367 The Algorithm Number field identifies the cryptographic algorithm 368 used to create the signature. A list of DNSSEC algorithm types can 369 be found in Appendix A.1 371 3.1.3 The Labels Field 373 The Labels field specifies the number of labels in the original RRSIG 374 RR owner name. The significance of this field is that a validator 375 uses it to determine if the answer was synthesized from a wildcard. 376 If so, it can be used to determine what owner name was used in 377 generating the signature. 379 To validate a signature, the validator needs the original owner name 380 that was used to create the signature. If the original owner name 381 contains a wildcard label ("*"), the owner name may have been 382 expanded by the server during the response process, in which case the 383 validator will need to reconstruct the original owner name in order 384 to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] 385 describes how to use the Labels field to reconstruct the original 386 owner name. 388 The value of the Labels field MUST NOT count either the null (root) 389 label that terminates the owner name or the wildcard label (if 390 present). The value of the Labels field MUST be less than or equal 391 to the number of labels in the RRSIG owner name. For example, 392 "www.example.com." has a Labels field value of 3, and 393 "*.example.com." has a Labels field value of 2. Root (".") has a 394 Labels field value of 0. 396 Although the wildcard label is not included in the count stored in 397 the Labels field of the RRSIG RR, the wildcard label is part of the 398 RRset's owner name when generating or verifying the signature. 400 3.1.4 Original TTL Field 402 The Original TTL field specifies the TTL of the covered RRset as it 403 appears in the authoritative zone. 405 The Original TTL field is necessary because a caching resolver 406 decrements the TTL value of a cached RRset. In order to validate a 407 signature, a validator requires the original TTL. 408 [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original 409 TTL field value to reconstruct the original TTL. 411 3.1.5 Signature Expiration and Inception Fields 413 The Signature Expiration and Inception fields specify a validity 414 period for the signature. The RRSIG record MUST NOT be used for 415 authentication prior to the inception date and MUST NOT be used for 416 authentication after the expiration date. 418 Signature Expiration and Inception field values are in POSIX.1 time 419 format: a 32-bit unsigned number of seconds elapsed since 1 January 420 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The 421 longest interval which can be expressed by this format without 422 wrapping is approximately 136 years. An RRSIG RR can have an 423 Expiration field value which is numerically smaller than the 424 Inception field value if the expiration field value is near the 425 32-bit wrap-around point or if the signature is long lived. Because 426 of this, all comparisons involving these fields MUST use "Serial 427 number arithmetic" as defined in [RFC1982]. As a direct consequence, 428 the values contained in these fields cannot refer to dates more than 429 68 years in either the past or the future. 431 3.1.6 The Key Tag Field 433 The Key Tag field contains the key tag value of the DNSKEY RR that 434 validates this signature. Appendix B explains how to calculate Key 435 Tag values. 437 3.1.7 The Signer's Name Field 439 The Signer's Name field value identifies the owner name of the DNSKEY 440 RR which a validator should use to validate this signature. The 441 Signer's Name field MUST contain the name of the zone of the covered 442 RRset. A sender MUST NOT use DNS name compression on the Signer's 443 Name field when transmitting a RRSIG RR. 445 3.1.8 The Signature Field 447 The Signature field contains the cryptographic signature that covers 448 the RRSIG RDATA (excluding the Signature field) and the RRset 449 specified by the RRSIG owner name, RRSIG class, and RRSIG Type 450 Covered field. The format of this field depends on the algorithm in 451 use and these formats are described in separate companion documents. 453 3.1.8.1 Signature Calculation 455 A signature covers the RRSIG RDATA (excluding the Signature Field) 456 and covers the data RRset specified by the RRSIG owner name, RRSIG 457 class, and RRSIG Type Covered fields. The RRset is in canonical form 458 (see Section 6) and the set RR(1),...RR(n) is signed as follows: 460 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where 462 "|" denotes concatenation; 464 RRSIG_RDATA is the wire format of the RRSIG RDATA fields 465 with the Signer's Name field in canonical form and 466 the Signature field excluded; 468 RR(i) = owner | type | class | TTL | RDATA length | RDATA 470 "owner" is the fully qualified owner name of the RRset in 471 canonical form (for RRs with wildcard owner names, the 472 wildcard label is included in the owner name); 474 Each RR MUST have the same owner name as the RRSIG RR; 476 Each RR MUST have the same class as the RRSIG RR; 478 Each RR in the RRset MUST have the RR type listed in the 479 RRSIG RR's Type Covered field; 481 Each RR in the RRset MUST have the TTL listed in the 482 RRSIG Original TTL Field; 484 Any DNS names in the RDATA field of each RR MUST be in 485 canonical form; and 487 The RRset MUST be sorted in canonical order. 489 See Section 6.1 and Section 6.2 for details on canonical name order 490 and canonical RR form. 492 3.2 The RRSIG RR Presentation Format 494 The presentation format of the RDATA portion is as follows: 496 The Type Covered field is represented as a RR type mnemonic. When 497 the mnemonic is not known, the TYPE representation as described in 498 [RFC3597] (section 5) MUST be used. 500 The Algorithm field value MUST be represented either as an unsigned 501 decimal integer or as an algorithm mnemonic as specified in Appendix 502 A.1. 504 The Labels field value MUST be represented as an unsigned decimal 505 integer. 507 The Original TTL field value MUST be represented as an unsigned 508 decimal integer. 510 The Signature Expiration Time and Inception Time field values MUST be 511 represented either as seconds since 1 January 1970 00:00:00 UTC or in 512 the form YYYYMMDDHHmmSS in UTC, where: 513 YYYY is the year (0000-9999, but see Section 3.1.5); 514 MM is the month number (01-12); 515 DD is the day of the month (01-31); 516 HH is the hour in 24 hours notation (00-23); 517 mm is the minute (00-59); and 518 SS is the second (00-59). 520 The Key Tag field MUST be represented as an unsigned decimal integer. 522 The Signer's Name field value MUST be represented as a domain name. 524 The Signature field is represented as a Base64 encoding of the 525 signature. Whitespace is allowed within the Base64 text. See 526 Section 2.2. 528 3.3 RRSIG RR Example 530 The following RRSIG RR stores the signature for the A RRset of 531 host.example.com: 533 host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 534 20030220173103 2642 example.com. 535 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr 536 PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o 537 B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t 538 GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG 539 J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) 541 The first four fields specify the owner name, TTL, Class, and RR type 542 (RRSIG). The "A" represents the Type Covered field. The value 5 543 identifies the algorithm used (RSA/SHA1) to create the signature. 544 The value 3 is the number of Labels in the original owner name. The 545 value 86400 in the RRSIG RDATA is the Original TTL for the covered A 546 RRset. 20030322173103 and 20030220173103 are the expiration and 547 inception dates, respectively. 2642 is the Key Tag, and example.com. 548 is the Signer's Name. The remaining text is a Base64 encoding of the 549 signature. 551 Note that combination of RRSIG RR owner name, class, and Type Covered 552 indicate that this RRSIG covers the "host.example.com" A RRset. The 553 Label value of 3 indicates that no wildcard expansion was used. The 554 Algorithm, Signer's Name, and Key Tag indicate this signature can be 555 authenticated using an example.com zone DNSKEY RR whose algorithm is 556 5 and key tag is 2642. 558 4. The NSEC Resource Record 560 The NSEC resource record lists two separate things: the owner name of 561 the next authoritative RRset in the canonical ordering of the zone, 562 and the set of RR types present at the NSEC RR's owner name. The 563 complete set of NSEC RRs in a zone both indicate which authoritative 564 RRsets exist in a zone and also form a chain of authoritative owner 565 names in the zone. This information is used to provide authenticated 566 denial of existence for DNS data, as described in 567 [I-D.ietf-dnsext-dnssec-protocol]. 569 Because every authoritative name in a zone must be part of the NSEC 570 chain, NSEC RRs must be present for names containing a CNAME RR. 571 This is a change to the traditional DNS specification [RFC1034] that 572 stated that if a CNAME is present for a name, it is the only type 573 allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist 574 for the same name as a CNAME resource record in a signed zone. 576 See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone 577 signer determines precisely which NSEC RRs it needs to include in a 578 zone. 580 The type value for the NSEC RR is 47. 582 The NSEC RR is class independent. 584 The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL 585 field. This is in the spirit of negative caching [RFC2308]. 587 4.1 NSEC RDATA Wire Format 589 The RDATA of the NSEC RR is as shown below: 591 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 / Next Domain Name / 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 / Type Bit Maps / 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 4.1.1 The Next Domain Name Field 601 The Next Domain Name field contains the owner name of the next 602 authoritative owner name in the canonical ordering of the zone; see 603 Section 6.1 for an explanation of canonical ordering. The value of 604 the Next Domain Name field in the last NSEC record in the zone is the 605 name of the zone apex (the owner name of the zone's SOA RR). 607 A sender MUST NOT use DNS name compression on the Next Domain Name 608 field when transmitting an NSEC RR. 610 Owner names of RRsets not authoritative for the given zone (such as 611 glue records) MUST NOT be listed in the Next Domain Name unless at 612 least one authoritative RRset exists at the same owner name. 614 4.1.2 The Type Bit Maps Field 616 The Type Bit Maps field identifies the RRset types which exist at the 617 NSEC RR's owner name. 619 The RR type space is split into 256 window blocks, each representing 620 the low-order 8 bits of the 16-bit RR type space. Each block that has 621 at least one active RR type is encoded using a single octet window 622 number (from 0 to 255), a single octet bitmap length (from 1 to 32) 623 indicating the number of octets used for the window block's bitmap, 624 and up to 32 octets (256 bits) of bitmap. 626 Blocks are present in the NSEC RR RDATA in increasing numerical 627 order. 629 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ 631 where "|" denotes concatenation. 633 Each bitmap encodes the low-order 8 bits of RR types within the 634 window block, in network bit order. The first bit is bit 0. For 635 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds 636 to RR type 2 (NS), and so forth. For window block 1, bit 1 637 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to 638 1, it indicates that an RRset of that type is present for the NSEC 639 RR's owner name. If a bit is set to 0, it indicates that no RRset of 640 that type is present for the NSEC RR's owner name. 642 Bits representing pseudo-types MUST be set to 0, since they do not 643 appear in zone data. If encountered, they MUST be ignored upon 644 reading. 646 Blocks with no types present MUST NOT be included. Trailing zero 647 octets in the bitmap MUST be omitted. The length of each block's 648 bitmap is determined by the type code with the largest numerical 649 value, within that block, among the set of RR types present at the 650 NSEC RR's owner name. Trailing zero octets not specified MUST be 651 interpreted as zero octets. 653 The bitmap for the NSEC RR at a delegation point requires special 654 attention. Bits corresponding to the delegation NS RRset and the RR 655 types for which the parent zone has authoritative data MUST be set to 656 1; bits corresponding to any non-NS RRset for which the parent is not 657 authoritative MUST be set to 0. 659 A zone MUST NOT include an NSEC RR for any domain name that only 660 holds glue records. 662 4.1.3 Inclusion of Wildcard Names in NSEC RDATA 664 If a wildcard owner name appears in a zone, the wildcard label ("*") 665 is treated as a literal symbol and is treated the same as any other 666 owner name for purposes of generating NSEC RRs. Wildcard owner names 667 appear in the Next Domain Name field without any wildcard expansion. 668 [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards 669 on authenticated denial of existence. 671 4.2 The NSEC RR Presentation Format 673 The presentation format of the RDATA portion is as follows: 675 The Next Domain Name field is represented as a domain name. 677 The Type Bit Maps field is represented as a sequence of RR type 678 mnemonics. When the mnemonic is not known, the TYPE representation 679 as described in [RFC3597] (section 5) MUST be used. 681 4.3 NSEC RR Example 683 The following NSEC RR identifies the RRsets associated with 684 alfa.example.com. and identifies the next authoritative name after 685 alfa.example.com. 687 alfa.example.com. 86400 IN NSEC host.example.com. ( 688 A MX RRSIG NSEC TYPE1234 ) 690 The first four text fields specify the name, TTL, Class, and RR type 691 (NSEC). The entry host.example.com. is the next authoritative name 692 after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, 693 and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and 694 TYPE1234 RRsets associated with the name alfa.example.com. 696 The RDATA section of the NSEC RR above would be encoded as: 698 0x04 'h' 'o' 's' 't' 699 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 700 0x03 'c' 'o' 'm' 0x00 701 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 702 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 703 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 704 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 705 0x00 0x00 0x00 0x00 0x20 707 Assuming that the validator can authenticate this NSEC record, it 708 could be used to prove that beta.example.com does not exist, or could 709 be used to prove there is no AAAA record associated with 710 alfa.example.com. Authenticated denial of existence is discussed in 711 [I-D.ietf-dnsext-dnssec-protocol]. 713 5. The DS Resource Record 715 The DS Resource Record refers to a DNSKEY RR and is used in the DNS 716 DNSKEY authentication process. A DS RR refers to a DNSKEY RR by 717 storing the key tag, algorithm number, and a digest of the DNSKEY RR. 718 Note that while the digest should be sufficient to identify the 719 public key, storing the key tag and key algorithm helps make the 720 identification process more efficient. By authenticating the DS 721 record, a resolver can authenticate the DNSKEY RR to which the DS 722 record points. The key authentication process is described in 723 [I-D.ietf-dnsext-dnssec-protocol]. 725 The DS RR and its corresponding DNSKEY RR have the same owner name, 726 but they are stored in different locations. The DS RR appears only 727 on the upper (parental) side of a delegation, and is authoritative 728 data in the parent zone. For example, the DS RR for "example.com" is 729 stored in the "com" zone (the parent zone) rather than in the 730 "example.com" zone (the child zone). The corresponding DNSKEY RR is 731 stored in the "example.com" zone (the child zone). This simplifies 732 DNS zone management and zone signing, but introduces special response 733 processing requirements for the DS RR; these are described in 734 [I-D.ietf-dnsext-dnssec-protocol]. 736 The type number for the DS record is 43. 738 The DS resource record is class independent. 740 The DS RR has no special TTL requirements. 742 5.1 DS RDATA Wire Format 744 The RDATA for a DS RR consists of a 2 octet Key Tag field, a one 745 octet Algorithm field, a one octet Digest Type field, and a Digest 746 field. 748 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Key Tag | Algorithm | Digest Type | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 / / 754 / Digest / 755 / / 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 5.1.1 The Key Tag Field 760 The Key Tag field lists the key tag of the DNSKEY RR referred to by 761 the DS record. 763 The Key Tag used by the DS RR is identical to the Key Tag used by 764 RRSIG RRs. Appendix B describes how to compute a Key Tag. 766 5.1.2 The Algorithm Field 768 The Algorithm field lists the algorithm number of the DNSKEY RR 769 referred to by the DS record. 771 The algorithm number used by the DS RR is identical to the algorithm 772 number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm 773 number types. 775 5.1.3 The Digest Type Field 777 The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY 778 RR. The Digest Type field identifies the algorithm used to construct 779 the digest. Appendix A.2 lists the possible digest algorithm types. 781 5.1.4 The Digest Field 783 The DS record refers to a DNSKEY RR by including a digest of that 784 DNSKEY RR. 786 The digest is calculated by concatenating the canonical form of the 787 fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, 788 and then applying the digest algorithm. 790 digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); 792 "|" denotes concatenation 794 DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. 796 The size of the digest may vary depending on the digest algorithm and 797 DNSKEY RR size. As of the time of writing, the only defined digest 798 algorithm is SHA-1, which produces a 20 octet digest. 800 5.2 Processing of DS RRs When Validating Responses 802 The DS RR links the authentication chain across zone boundaries, so 803 the DS RR requires extra care in processing. The DNSKEY RR referred 804 to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST 805 have Flags bit 7 set to value 1. If the DNSKEY flags do not indicate 806 a DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT 807 be used in the validation process. 809 5.3 The DS RR Presentation Format 811 The presentation format of the RDATA portion is as follows: 813 The Key Tag field MUST be represented as an unsigned decimal integer. 815 The Algorithm field MUST be represented either as an unsigned decimal 816 integer or as an algorithm mnemonic specified in Appendix A.1. 818 The Digest Type field MUST be represented as an unsigned decimal 819 integer. 821 The Digest MUST be represented as a sequence of case-insensitive 822 hexadecimal digits. Whitespace is allowed within the hexadecimal 823 text. 825 5.4 DS RR Example 827 The following example shows a DNSKEY RR and its corresponding DS RR. 829 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz 830 fwJr1AYtsmx3TGkJaNXVbfi/ 831 2pHm822aJ5iI9BMzNXxeYCmZ 832 DRD99WYwYqUSdjMmmAphXdvx 833 egXd/M5+X7OrzKBaMbCVdFLU 834 Uh6DhweJBjEVv5f2wwjM9Xzc 835 nOf+EPbtG9DMBmADjFDc2w/r 836 ljwvFw== 837 ) ; key id = 60485 839 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 840 98631FAD1A292118 ) 842 The first four text fields specify the name, TTL, Class, and RR type 843 (DS). Value 60485 is the key tag for the corresponding 844 "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm 845 used by this "dskey.example.com." DNSKEY RR. The value 1 is the 846 algorithm used to construct the digest, and the rest of the RDATA 847 text is the digest in hexadecimal. 849 6. Canonical Form and Order of Resource Records 851 This section defines a canonical form for resource records, a 852 canonical ordering of DNS names, and a canonical ordering of resource 853 records within an RRset. A canonical name order is required to 854 construct the NSEC name chain. A canonical RR form and ordering 855 within an RRset are required to construct and verify RRSIG RRs. 857 6.1 Canonical DNS Name Order 859 For purposes of DNS security, owner names are ordered by treating 860 individual labels as unsigned left-justified octet strings. The 861 absence of a octet sorts before a zero value octet, and upper case 862 US-ASCII letters are treated as if they were lower case US-ASCII 863 letters. 865 To compute the canonical ordering of a set of DNS names, start by 866 sorting the names according to their most significant (rightmost) 867 labels. For names in which the most significant label is identical, 868 continue sorting according to their next most significant label, and 869 so forth. 871 For example, the following names are sorted in canonical DNS name 872 order. The most significant label is "example". At this level, 873 "example" sorts first, followed by names ending in "a.example", then 874 names ending "z.example". The names within each level are sorted in 875 the same way. 877 example 878 a.example 879 yljkjljk.a.example 880 Z.a.example 881 zABC.a.EXAMPLE 882 z.example 883 \001.z.example 884 *.z.example 885 \200.z.example 887 6.2 Canonical RR Form 889 For purposes of DNS security, the canonical form of an RR is the wire 890 format of the RR where: 891 1. Every domain name in the RR is fully expanded (no DNS name 892 compression) and fully qualified; 893 2. All uppercase US-ASCII letters in the owner name of the RR are 894 replaced by the corresponding lowercase US-ASCII letters; 896 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, 897 HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, 898 SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in 899 the DNS names contained within the RDATA are replaced by the 900 corresponding lowercase US-ASCII letters; 901 4. If the owner name of the RR is a wildcard name, the owner name is 902 in its original unexpanded form, including the "*" label (no 903 wildcard substitution); and 904 5. The RR's TTL is set to its original value as it appears in the 905 originating authoritative zone or the Original TTL field of the 906 covering RRSIG RR. 908 6.3 Canonical RR Ordering Within An RRset 910 For purposes of DNS security, RRs with the same owner name, class, 911 and type are sorted by treating the RDATA portion of the canonical 912 form of each RR as a left-justified unsigned octet sequence where the 913 absence of an octet sorts before a zero octet. 915 [RFC2181] specifies that an RRset is not allowed to contain duplicate 916 records (multiple RRs with the same owner name, class, type, and 917 RDATA). Therefore, if an implementation detects duplicate RRs when 918 putting the RRset in canonical form, the implementation MUST treat 919 this as a protocol error. If the implementation chooses to handle 920 this protocol error in the spirit of the robustness principle (being 921 liberal in what it accepts), the implementation MUST remove all but 922 one of the duplicate RR(s) for purposes of calculating the canonical 923 form of the RRset. 925 7. IANA Considerations 927 This document introduces no new IANA considerations, because all of 928 the protocol parameters used in this document have already been 929 assigned by previous specifications. However, since the evolution of 930 DNSSEC has been long and somewhat convoluted, this section attempts 931 to describe the current state of the IANA registries and other 932 protocol parameters which are (or once were) related to DNSSEC. 934 Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA 935 considerations. 937 DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to 938 the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS 939 Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, 940 and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [RFC3755] 941 also marked type 30 (NXT) as Obsolete, and restricted use of types 942 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security 943 protocol described in [RFC2931] and the transaction KEY Resource 944 Record described in [RFC2930]. 946 DNS Security Algorithm Numbers: [RFC2535] created an IANA registry 947 for DNSSEC Resource Record Algorithm field numbers, and assigned 948 values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] 949 altered this registry to include flags for each entry regarding 950 its use with the DNS security extensions. Each algorithm entry 951 could refer to an algorithm that can be used for zone signing, 952 transaction security (see [RFC2931]) or both. Values 6-251 are 953 available for assignment by IETF standards action. See Appendix A 954 for a full listing of the DNS Security Algorithm Numbers entries 955 at the time of writing and their status of use in DNSSEC. 957 [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and 958 assigned value 0 to reserved and value 1 to SHA-1. 960 KEY Protocol Values: [RFC2535] created an IANA Registry for KEY 961 Protocol Values, but [RFC3445] re-assigned all values other than 3 962 to reserved and closed this IANA registry. The registry remains 963 closed, and all KEY and DNSKEY records are required to have 964 Protocol Octet value of 3. 966 Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA 967 registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, 968 this registry only contains an assignment for bit 7 (the ZONE bit) 969 and a reservation for bit 15 for the Secure Entry Point flag (SEP 970 bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by 971 IETF Standards Action. 973 8. Security Considerations 975 This document describes the format of four DNS resource records used 976 by the DNS security extensions, and presents an algorithm for 977 calculating a key tag for a public key. Other than the items 978 described below, the resource records themselves introduce no 979 security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] 980 and [I-D.ietf-dnsext-dnssec-protocol] for additional security 981 considerations related to the use of these records. 983 The DS record points to a DNSKEY RR using a cryptographic digest, the 984 key algorithm type and a key tag. The DS record is intended to 985 identify an existing DNSKEY RR, but it is theoretically possible for 986 an attacker to generate a DNSKEY that matches all the DS fields. The 987 probability of constructing such a matching DNSKEY depends on the 988 type of digest algorithm in use. The only currently defined digest 989 algorithm is SHA-1, and the working group believes that constructing 990 a public key which would match the algorithm, key tag, and SHA-1 991 digest given in a DS record would be a sufficiently difficult problem 992 that such an attack is not a serious threat at this time. 994 The key tag is used to help select DNSKEY resource records 995 efficiently, but it does not uniquely identify a single DNSKEY 996 resource record. It is possible for two distinct DNSKEY RRs to have 997 the same owner name, the same algorithm type, and the same key tag. 998 An implementation which uses only the key tag to select a DNSKEY RR 999 might select the wrong public key in some circumstances. 1001 9. Acknowledgments 1003 This document was created from the input and ideas of the members of 1004 the DNS Extensions Working Group and working group mailing list. The 1005 editors would like to express their thanks for the comments and 1006 suggestions received during the revision of these security extension 1007 specifications. While explicitly listing everyone who has 1008 contributed during the decade during which DNSSEC has been under 1009 development would be an impossible task, 1010 [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the 1011 participants who were kind enough to comment on these documents. 1013 10. References 1015 10.1 Normative References 1017 [I-D.ietf-dnsext-dnssec-intro] 1018 Arends, R., Austein, R., Larson, M., Massey, D. and S. 1019 Rose, "DNS Security Introduction and Requirements", 1020 draft-ietf-dnsext-dnssec-intro-10 (work in progress), May 1021 2004. 1023 [I-D.ietf-dnsext-dnssec-protocol] 1024 Arends, R., Austein, R., Larson, M., Massey, D. and S. 1025 Rose, "Protocol Modifications for the DNS Security 1026 Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in 1027 progress), May 2004. 1029 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1030 STD 13, RFC 1034, November 1987. 1032 [RFC1035] Mockapetris, P., "Domain names - implementation and 1033 specification", STD 13, RFC 1035, November 1987. 1035 [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 1036 Mail Extensions) Part One: Mechanisms for Specifying and 1037 Describing the Format of Internet Message Bodies", RFC 1038 1521, September 1993. 1040 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1041 August 1996. 1043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1044 Requirement Levels", BCP 14, RFC 2119, March 1997. 1046 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 1047 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1048 April 1997. 1050 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1051 Specification", RFC 2181, July 1997. 1053 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1054 NCACHE)", RFC 2308, March 1998. 1056 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 1057 2671, August 1999. 1059 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 1060 SIG(0)s)", RFC 2931, September 2000. 1062 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 1063 Name System (DNS)", RFC 3110, May 2001. 1065 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 1066 Resource Record (RR)", RFC 3445, December 2002. 1068 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1069 (RR) Types", RFC 3597, September 2003. 1071 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 1072 (RR)", RFC 3658, December 2003. 1074 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 1075 Signer", RFC 3755, April 2004. 1077 [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure 1078 Entry Point Flag", RFC 3757, April 2004. 1080 10.2 Informative References 1082 [I-D.ietf-dnsext-nsec-rdata] 1083 Schlyter, J., "KEY RR Secure Entry Point Flag", 1084 draft-ietf-dnsext-nsec-rdata-05 (work in progress), March 1085 2004. 1087 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1088 RFC 2535, March 1999. 1090 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 1091 RR)", RFC 2930, September 2000. 1093 Authors' Addresses 1095 Roy Arends 1096 Telematica Instituut 1097 Drienerlolaan 5 1098 7522 NB Enschede 1099 NL 1101 EMail: roy.arends@telin.nl 1102 Rob Austein 1103 Internet Systems Consortium 1104 950 Charter Street 1105 Redwood City, CA 94063 1106 USA 1108 EMail: sra@isc.org 1110 Matt Larson 1111 VeriSign, Inc. 1112 21345 Ridgetop Circle 1113 Dulles, VA 20166-6503 1114 USA 1116 EMail: mlarson@verisign.com 1118 Dan Massey 1119 USC Information Sciences Institute 1120 3811 N. Fairfax Drive 1121 Arlington, VA 22203 1122 USA 1124 EMail: masseyd@isi.edu 1126 Scott Rose 1127 National Institute for Standards and Technology 1128 100 Bureau Drive 1129 Gaithersburg, MD 20899-8920 1130 USA 1132 EMail: scott.rose@nist.gov 1134 Appendix A. DNSSEC Algorithm and Digest Types 1136 The DNS security extensions are designed to be independent of the 1137 underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS 1138 resource records all use a DNSSEC Algorithm Number to identify the 1139 cryptographic algorithm in use by the resource record. The DS 1140 resource record also specifies a Digest Algorithm Number to identify 1141 the digest algorithm used to construct the DS record. The currently 1142 defined Algorithm and Digest Types are listed below. Additional 1143 Algorithm or Digest Types could be added as advances in cryptography 1144 warrant. 1146 A DNSSEC aware resolver or name server MUST implement all MANDATORY 1147 algorithms. 1149 A.1 DNSSEC Algorithm Types 1151 The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify 1152 the security algorithm being used. These values are stored in the 1153 "Algorithm number" field in the resource record RDATA. 1155 Some algorithms are usable only for zone signing (DNSSEC), some only 1156 for transaction security mechanisms (SIG(0) and TSIG), and some for 1157 both. Those usable for zone signing may appear in DNSKEY, RRSIG, and 1158 DS RRs. Those usable for transaction security would be present in 1159 SIG(0) and KEY RRs as described in [RFC2931] 1161 Zone 1162 Value Algorithm [Mnemonic] Signing References Status 1163 ----- -------------------- --------- ---------- --------- 1164 0 reserved 1165 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED 1166 2 Diffie-Hellman [DH] n RFC 2539 - 1167 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL 1168 4 Elliptic Curve [ECC] TBA - 1169 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY 1170 252 Indirect [INDIRECT] n - 1171 253 Private [PRIVATEDNS] y see below OPTIONAL 1172 254 Private [PRIVATEOID] y see below OPTIONAL 1173 255 reserved 1175 6 - 251 Available for assignment by IETF Standards Action. 1177 A.1.1 Private Algorithm Types 1179 Algorithm number 253 is reserved for private use and will never be 1180 assigned to a specific algorithm. The public key area in the DNSKEY 1181 RR and the signature area in the RRSIG RR begin with a wire encoded 1182 domain name, which MUST NOT be compressed. The domain name indicates 1183 the private algorithm to use and the remainder of the public key area 1184 is determined by that algorithm. Entities should only use domain 1185 names they control to designate their private algorithms. 1187 Algorithm number 254 is reserved for private use and will never be 1188 assigned to a specific algorithm. The public key area in the DNSKEY 1189 RR and the signature area in the RRSIG RR begin with an unsigned 1190 length byte followed by a BER encoded Object Identifier (ISO OID) of 1191 that length. The OID indicates the private algorithm in use and the 1192 remainder of the area is whatever is required by that algorithm. 1193 Entities should only use OIDs they control to designate their private 1194 algorithms. 1196 A.2 DNSSEC Digest Types 1198 A "Digest Type" field in the DS resource record types identifies the 1199 cryptographic digest algorithm used by the resource record. The 1200 following table lists the currently defined digest algorithm types. 1202 VALUE Algorithm STATUS 1203 0 Reserved - 1204 1 SHA-1 MANDATORY 1205 2-255 Unassigned - 1207 Appendix B. Key Tag Calculation 1209 The Key Tag field in the RRSIG and DS resource record types provides 1210 a mechanism for selecting a public key efficiently. In most cases, a 1211 combination of owner name, algorithm, and key tag can efficiently 1212 identify a DNSKEY record. Both the RRSIG and DS resource records 1213 have corresponding DNSKEY records. The Key Tag field in the RRSIG 1214 and DS records can be used to help select the corresponding DNSKEY RR 1215 efficiently when more than one candidate DNSKEY RR is available. 1217 However, it is essential to note that the key tag is not a unique 1218 identifier. It is theoretically possible for two distinct DNSKEY RRs 1219 to have the same owner name, the same algorithm, and the same key 1220 tag. The key tag is used to limit the possible candidate keys, but it 1221 does not uniquely identify a DNSKEY record. Implementations MUST NOT 1222 assume that the key tag uniquely identifies a DNSKEY RR. 1224 The key tag is the same for all DNSKEY algorithm types except 1225 algorithm 1 (please see Appendix B.1 for the definition of the key 1226 tag for algorithm 1). The key tag algorithm is the sum of the wire 1227 format of the DNSKEY RDATA broken into 2 octet groups. First the 1228 RDATA (in wire format) is treated as a series of 2 octet groups, 1229 these groups are then added together ignoring any carry bits. 1231 A reference implementation of the key tag algorithm is as an ANSI C 1232 function is given below with the RDATA portion of the DNSKEY RR is 1233 used as input. It is not necessary to use the following reference 1234 code verbatim, but the numerical value of the Key Tag MUST be 1235 identical to what the reference implementation would generate for the 1236 same input. 1238 Please note that the algorithm for calculating the Key Tag is almost 1239 but not completely identical to the familiar ones complement checksum 1240 used in many other Internet protocols. Key Tags MUST be calculated 1241 using the algorithm described here rather than the ones complement 1242 checksum. 1244 The following ANSI C reference implementation calculates the value of 1245 a Key Tag. This reference implementation applies to all algorithm 1246 types except algorithm 1 (see Appendix B.1). The input is the wire 1247 format of the RDATA portion of the DNSKEY RR. The code is written 1248 for clarity, not efficiency. 1250 /* 1251 * Assumes that int is at least 16 bits. 1252 * First octet of the key tag is the most significant 8 bits of the 1253 * return value; 1254 * Second octet of the key tag is the least significant 8 bits of the 1255 * return value. 1256 */ 1258 unsigned int 1259 keytag ( 1260 unsigned char key[], /* the RDATA part of the DNSKEY RR */ 1261 unsigned int keysize /* the RDLENGTH */ 1262 ) 1263 { 1264 unsigned long ac; /* assumed to be 32 bits or larger */ 1265 int i; /* loop index */ 1267 for ( ac = 0, i = 0; i < keysize; ++i ) 1268 ac += (i & 1) ? key[i] : key[i] << 8; 1269 ac += (ac >> 16) & 0xFFFF; 1270 return ac & 0xFFFF; 1271 } 1273 B.1 Key Tag for Algorithm 1 (RSA/MD5) 1275 The key tag for algorithm 1 (RSA/MD5) is defined differently than the 1276 key tag for all other algorithms, for historical reasons. For a 1277 DNSKEY RR with algorithm 1, the key tag is defined to be the most 1278 significant 16 bits of the least significant 24 bits in the public 1279 key modulus (in other words, the 4th to last and 3rd to last octets 1280 of the public key modulus). 1282 Please note that Algorithm 1 is NOT RECOMMENDED. 1284 Intellectual Property Statement 1286 The IETF takes no position regarding the validity or scope of any 1287 intellectual property or other rights that might be claimed to 1288 pertain to the implementation or use of the technology described in 1289 this document or the extent to which any license under such rights 1290 might or might not be available; neither does it represent that it 1291 has made any effort to identify any such rights. Information on the 1292 IETF's procedures with respect to rights in standards-track and 1293 standards-related documentation can be found in BCP-11. Copies of 1294 claims of rights made available for publication and any assurances of 1295 licenses to be made available, or the result of an attempt made to 1296 obtain a general license or permission for the use of such 1297 proprietary rights by implementors or users of this specification can 1298 be obtained from the IETF Secretariat. 1300 The IETF invites any interested party to bring to its attention any 1301 copyrights, patents or patent applications, or other proprietary 1302 rights which may cover technology that may be required to practice 1303 this standard. Please address the information to the IETF Executive 1304 Director. 1306 Full Copyright Statement 1308 Copyright (C) The Internet Society (2004). All Rights Reserved. 1310 This document and translations of it may be copied and furnished to 1311 others, and derivative works that comment on or otherwise explain it 1312 or assist in its implementation may be prepared, copied, published 1313 and distributed, in whole or in part, without restriction of any 1314 kind, provided that the above copyright notice and this paragraph are 1315 included on all such copies and derivative works. However, this 1316 document itself may not be modified in any way, such as by removing 1317 the copyright notice or references to the Internet Society or other 1318 Internet organizations, except as needed for the purpose of 1319 developing Internet standards in which case the procedures for 1320 copyrights defined in the Internet Standards process must be 1321 followed, or as required to translate it into languages other than 1322 English. 1324 The limited permissions granted above are perpetual and will not be 1325 revoked by the Internet Society or its successors or assignees. 1327 This document and the information contained herein is provided on an 1328 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1329 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1330 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1331 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1332 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1334 Acknowledgment 1336 Funding for the RFC Editor function is currently provided by the 1337 Internet Society.