idnits 2.17.00 (12 Aug 2021) /tmp/idnits19209/draft-ietf-dnsext-dnssec-records-04.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 497 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 (September 16, 2003) is 6821 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: 'DH' is mentioned on line 1125, but not defined == Missing Reference: 'DSA' is mentioned on line 1126, but not defined == Missing Reference: 'ECC' is mentioned on line 1127, but not defined == Unused Reference: 'RFC2671' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: 'RFC3597' is defined on line 1018, but no explicit reference was found in the text ** 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) == Outdated reference: draft-ietf-dnsext-delegation-signer has been published as RFC 3658 == Outdated reference: draft-ietf-dnsext-dnssec-intro has been published as RFC 4033 == Outdated reference: draft-ietf-dnsext-dnssec-protocol has been published as RFC 4035 == Outdated reference: draft-ietf-dnsext-keyrr-key-signing-flag has been published as RFC 3757 == Outdated reference: draft-ietf-dnsext-dnssec-2535typecode-change has been published as RFC 3755 -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 14 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: March 16, 2004 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 September 16, 2003 14 Resource Records for the DNS Security Extensions 15 draft-ietf-dnsext-dnssec-records-04 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 March 16, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). 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 existance (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 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 64 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 65 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 66 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 6 67 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 68 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 70 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 71 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 72 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . . . . 7 73 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7 74 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8 75 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9 76 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . . 9 77 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 78 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 79 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 80 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 81 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 82 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 83 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11 84 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 85 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13 86 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13 87 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15 88 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 89 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 90 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 16 91 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 16 92 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 16 93 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17 94 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18 95 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18 96 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 19 97 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19 98 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19 99 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19 100 5.2 Processing of DS RRs When Validating Responses . . . . . . . 19 101 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 20 102 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20 103 6. Canonical Form and Order of Resource Records . . . . . . . . 21 104 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21 105 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21 106 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22 107 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 108 8. Security Considerations . . . . . . . . . . . . . . . . . . 25 109 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 110 Normative References . . . . . . . . . . . . . . . . . . . . 27 111 Informative References . . . . . . . . . . . . . . . . . . . 29 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 113 A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 31 114 A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 31 115 A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 31 116 A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 32 117 B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 33 118 B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 34 119 Intellectual Property and Copyright Statements . . . . . . . 35 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 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 [RFC1034], RFC1035 [RFC1035] and subsequent 132 RFC's that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and 133 RFC2308 [RFC2308]. 135 This document is part of a family of documents that define the DNS 136 security extensions. The DNS security extensions (DNSSEC) are a 137 collection of resource records and DNS protocol modifications that 138 add source authentication and data integrity the Domain Name System 139 (DNS). An introduction to DNSSEC and definition of common terms can 140 be found in [I-D.ietf-dnsext-dnssec-intro]. A description of DNS 141 protocol modifications can be found in 142 [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC 143 resource records. 145 1.2 Reserved Words 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 1.3 Editors' Notes 153 1.3.1 Open Technical Issues 155 The cryptographic algorithm types (Appendix A) requires input from 156 the working group. The DSA algorithm was moved to OPTIONAL. This 157 had strong consensus in workshops and various discussions and a 158 separate internet draft solely to move DSA from MANDATORY to OPTIONAL 159 seemed excessive. This draft solicits input on that proposed change. 161 1.3.2 Technical Changes or Corrections 163 Please report technical corrections to dnssec-editors@east.isi.edu. 164 To assist the editors, please indicate the text in error and point 165 out the RFC that defines the correct behavior. For a technical 166 change where no RFC that defines the correct behavior, or if there's 167 more than one applicable RFC and the definitions conflict, please 168 post the issue to namedroppers. 170 An example correction to dnssec-editors might be: Page X says 171 "DNSSEC RRs SHOULD be automatically returned in responses." This was 172 true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the 173 DNSSEC RR types MUST NOT be included in responses unless the resolver 174 indicated support for DNSSEC. 176 1.3.3 Typos and Minor Corrections 178 Please report any typos corrections to dnssec-editors@east.isi.edu. 179 To assist the editors, please provide enough context for us to find 180 the incorrect text quickly. 182 An example message to dnssec-editors might be: page X says "the 183 DNSSEC standard has been in development for over 1 years". It 184 should read "over 10 years". 186 2. The DNSKEY Resource Record 188 DNSSEC uses public key cryptography to sign and authenticate DNS 189 resource record sets (RRsets). The public keys are stored in DNSKEY 190 resource records and are used in the DNSSEC authentication process 191 described in [I-D.ietf-dnsext-dnssec-protocol]. For example, a zone 192 signs its authoritative RRsets using a private key and stores the 193 corresponding public key in a DNSKEY RR. A resolver can then use 194 these signatures to authenticate RRsets from the zone. 196 The DNSKEY RR may also be used to store public keys associated with 197 other DNS operations such as TKEY [RFC2930]. The DNSKEY RR is not, 198 however, intended as a record for storing arbitrary public keys. The 199 DNSKEY RR MUST NOT be used to store certificates or public keys that 200 do not directly relate to the DNS infrastructure. 202 The Type value for the DNSKEY RR type is 48. 204 The DNSKEY RR is class independent. 206 The DNSKEY RR has no special TTL requirements. 208 2.1 DNSKEY RDATA Wire Format 210 The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 211 octet Protocol Field, a 1 octet Algorithm Field , and the Public Key 212 Field. 214 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Flags | Protocol | Algorithm | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 / / 220 / Public Key / 221 / / 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 2.1.1 The Flags Field 226 Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, 227 then the DNSKEY record holds a DNS zone key and the DNSKEY's owner 228 name MUST be the name of a zone. If bit 7 has value 0, then the 229 DNSKEY record holds some other type of DNS public key, such as a 230 public key used by TKEY. 232 Bit 15 of the Flags field is the Secure Entry Point flag, described 233 in [I-D.ietf-dnsext-keyrr-key-signing-flag]. If bit 15 has value 1, 234 then the DNSKEY record holds a key intended for use as a secure entry 235 point. This flag is only intended to be to a hint to zone signing or 236 debugging software as to the intended use of this DNSKEY record; 237 security-aware resolvers MUST NOT alter their behavior during the 238 signature validation process in any way based on the setting of this 239 bit. 241 Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon 242 creation of the DNSKEY RR, and MUST be ignored upon reception. 244 2.1.2 The Protocol Field 246 The Protocol Field MUST have value 3 and MUST be treated as invalid 247 during signature verification if found to be some value other than 3. 249 2.1.3 The Algorithm Field 251 The Algorithm field identifies the public key's cryptographic 252 algorithm and determines the format of the Public Key field. A list 253 of DNSSEC algorithm types can be found in Appendix A.1 255 2.1.4 The Public Key Field 257 The Public Key Field holds the public key material itself. 259 2.1.5 Notes on DNSKEY RDATA Design 261 Although the Protocol Field always has value 3, it is retained for 262 backward compatibility with early versions of the KEY record. 264 2.2 The DNSKEY RR Presentation Format 266 The presentation format of the RDATA portion is as follows: 268 The Flag field MUST be represented as an unsigned decimal integer 269 with a value of 0, 256, or 257. 271 The Protocol Field MUST be represented as an unsigned decimal integer 272 with a value of 3. 274 The Algorithm field MUST be represented either as an unsigned 275 decimal integer or as an algorithm mnemonic as specified in Appendix 276 A.1. 278 The Public Key field MUST be represented as a Base64 encoding of the 279 Public Key. Whitespace is allowed within the Base64 text. For a 280 definition of Base64 encoding, see [RFC1521] Section 5.2. 282 2.3 DNSKEY RR Example 284 The following DNSKEY RR stores a DNS zone key for example.com. 286 example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 287 Cbl+BBZH4b/0PY1kxkmvHjcZc8no 288 kfzj31GajIQKY+5CptLr3buXA10h 289 WqTkF7H6RfoRqXQeogmMHfpftf6z 290 Mv1LyBUgia7za6ZEzOJBOztyvhjL 291 742iU/TpPSEDhm2SNKLijfUppn1U 292 aNvv4w== ) 294 The first four text fields specify the owner name, TTL, Class, and RR 295 type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in 296 the Flags field has value 1. Value 3 is the fixed Protocol value. 297 Value 5 indicates the public key algorithm. Appendix A.1 identifies 298 algorithm type 5 as RSA/SHA1 and indicates that the format of the 299 RSA/SHA1 public key field is defined in [RFC3110]. The remaining 300 text is a Base64 encoding of the public key. 302 3. The RRSIG Resource Record 304 DNSSEC uses public key cryptography to sign and authenticate DNS 305 resource record sets (RRsets). Digital signatures are stored in 306 RRSIG resource records and are used in the DNSSEC authentication 307 process described in [I-D.ietf-dnsext-dnssec-protocol]. A 308 security-aware resolver can use these RRSIG RRs to authenticate 309 RRsets from the zone. The RRSIG RR MUST only be used to carry 310 verification material (digital signatures) used to secure DNS 311 operations. 313 A RRSIG record contains the signature for an RRset with a particular 314 name, class, and type. The RRSIG RR specifies a validity interval 315 for the signature and uses the Algorithm, the Signer's Name, and the 316 Key Tag to identify the DNSKEY RR containing the public key that a 317 resolver can use to verify the signature. 319 The Type value for the RRSIG RR type is 46. 321 The RRSIG RR is class independent. 323 A RRSIG RR MUST have the same class as the RRset it covers. 325 The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset 326 it covers. 328 3.1 RRSIG RDATA Wire Format 330 The RDATA for a RRSIG RR consists of a 2 octet Type Covered field, a 331 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original 332 TTL field, a 4 octet Signature Expiration field, a 4 octet Signature 333 Inception field, a 2 octet Key tag, the Signer's Name field, and the 334 Signature field. 336 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type Covered | Algorithm | Labels | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Original TTL | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Signature Expiration | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Signature Inception | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Key Tag | / 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / 349 / / 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 / / 352 / Signature / 353 / / 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 3.1.1 The Type Covered Field 358 The Type Covered field identifies the type of the RRset which is 359 covered by this RRSIG record. 361 3.1.2 The Algorithm Number Field 363 The Algorithm Number field identifies the cryptographic algorithm 364 used to create the signature. A list of DNSSEC algorithm types can 365 be found in Appendix A.1 367 3.1.3 The Labels Field 369 The Labels field specifies the number of labels in the original RRSIG 370 RR owner name. The significance of this field is that from it a 371 verifier can determine if the answer was synthesized from a wildcard. 372 If so, it can be used to determine what owner name was used in 373 generating the signature. 375 To validate a signature, the validator needs the original owner name 376 that was used to create the signature. If the original owner name 377 contains a wildcard label ("*"), the owner name may have been 378 expanded by the server during the response process, in which case the 379 validator will need to reconstruct the original owner name in order 380 to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] 381 describes how to use the Labels field to reconstruct the original 382 owner name. 384 The value of the Label field MUST NOT count either the null (root) 385 label that terminates the owner name or the wildcard label (if 386 present). The value of the Label field MUST be less than or equal to 387 the number of labels in the RRSIG owner name. For example, 388 "www.example.com." has a Label field value of 3, and "*.example.com." 389 has a Label field value of 2. Root (".") has a Label field value of 390 0. 392 Note that, although the wildcard label is not included in the count 393 stored in the Label field of the RRSIG RR, the wildcard label is part 394 of the RRset's owner name when generating or verifying the signature. 396 3.1.4 Original TTL Field 398 The Original TTL field specifies the TTL of the covered RRset as it 399 appears in the authoritative zone. 401 The Original TTL field is necessary because a caching resolver 402 decrements the TTL value of a cached RRset. In order to validate a 403 signature, a resolver requires the original TTL. 404 [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original 405 TTL field value to reconstruct the original TTL. 407 The Original TTL value MUST be greater than or equal to the TTL value 408 of the RRSIG record itself. 410 3.1.5 Signature Expiration and Inception Fields 412 The Signature Expiration and Inception fields specify a validity 413 period for the signature. The RRSIG record MUST NOT be used for 414 authentication prior to the inception date and MUST NOT be used for 415 authentication after the expiration date. 417 Signature Expiration and Inception field values are in POSIX.1 time 418 format: a 32-bit unsigned number of seconds elapsed since 1 January 419 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The 420 longest interval which can be expressed by this format without 421 wrapping is approximately 136 years. A RRSIG RR can have an 422 Expiration field value which is numerically smaller than the 423 Inception field value if the expiration field value is near the 424 32-bit wrap-around point or if the signature is long lived. Because 425 of this, all comparisons involving these fields MUST use "Serial 426 number arithmetic" as defined in [RFC1982]. As a direct consequence, 427 the values contained in these fields cannot refer to dates more than 428 68 years in either the past or the future. 430 3.1.6 The Key Tag Field 432 The Key Tag field contains the key tag value of the DNSKEY RR that 433 validates this signature. Appendix B explains how to calculate Key 434 Tag values. 436 3.1.7 The Signer's Name Field 438 The Signer's Name field value identifies the owner name of the DNSKEY 439 RR which a security-aware resolver should use to validate this 440 signature. The Signer's Name field MUST contain the name of the zone 441 of the covered RRset. A sender MUST NOT use DNS name compression on 442 the Signer's Name field when transmitting a RRSIG RR. A receiver 443 which receives a RRSIG RR containing a compressed Signer's Name field 444 SHOULD decompress the field value. 446 3.1.8 The Signature Field 448 The Signature field contains the cryptographic signature which covers 449 the RRSIG RDATA (excluding the Signature field) and the RRset 450 specified by the RRSIG owner name, RRSIG class, and RRSIG Type 451 Covered field. 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 field. 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 | class | type | 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 3.2 The RRSIG RR Presentation Format 491 The presentation format of the RDATA portion is as follows: 493 The Type Covered field value MUST be represented either as an 494 unsigned decimal integer or as the mnemonic for the covered RR type. 496 The Algorithm field value MUST be represented either as an unsigned 497 decimal integer or as an algorithm mnemonic as specified in Appendix 498 A.1. 500 The Labels field value MUST be represented as an unsigned decimal 501 integer. 503 The Original TTL field value MUST be represented as an unsigned 504 decimal integer. 506 The Signature Inception Time and Expiration Time field values MUST be 507 represented in the form YYYYMMDDHHmmSS in UTC, where: 509 YYYY is the year (0000-9999, but see Section 3.1.5); 511 MM is the month number (01-12); 513 DD is the day of the month (01-31); 515 HH is the hour in 24 hours notation (00-23); 517 mm is the minute (00-59); 519 SS is the second (00-59). 521 The Key Tag field MUST be represented as an unsigned decimal integer. 523 The Signer's Name field value MUST be represented as a domain name. 525 The Signature field is represented as a Base64 encoding of the 526 signature. Whitespace is allowed within the Base64 text. For a 527 definition of Base64 encoding see [RFC1521] Section 5.2. 529 3.3 RRSIG RR Example 531 The following a RRSIG RR stores the signature for the A RRset of 532 host.example.com: 534 host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 535 20030220173103 2642 example.com. 536 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr 537 PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o 538 B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t 539 GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG 540 J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) 542 The first four fields specify the owner name, TTL, Class, and RR type 543 (RRSIG). The "A" represents the Type Covered field. The value 5 544 identifies the Algorithm used (RSA-SHA1) to create the signature. 545 The value 3 is the number of Labels in the original owner name. The 546 value 86400 in the RRSIG RDATA is the Original TTL for the covered A 547 RRset. 20030322173103 and 20030220173103 are the expiration and 548 inception dates, respectively. 2642 is the Key Tag, and example.com. 549 is the Signer's Name. The remaining text is a Base64 encoding of the 550 signature. 552 Note that combination of RRSIG RR owner name, class, and Type Covered 553 indicate that this RRSIG covers the "host.example.com" A RRset. The 554 Label value of 3 indicates that no wildcard expansion was used. The 555 Algorithm, Signer's Name, and Key Tag indicate this signature can be 556 authenticated using an example.com zone DNSKEY RR whose algorithm is 557 5 and key tag is 2642. 559 4. The NSEC Resource Record 561 The NSEC resource record lists two separate things: the owner name of 562 the next authoritative RRset in the canonical ordering of the zone, 563 and the set of RR types present at the NSEC RR's owner name. The 564 complete set of NSEC RRs in a zone both indicate which authoritative 565 RRsets exist in a zone and also form a chain of authoritative owner 566 names in the zone. This information is used to provide authenticated 567 denial of existence for DNS data, as described in 568 [I-D.ietf-dnsext-dnssec-protocol]. 570 The type value for the NSEC RR is 47. 572 The NSEC RR is class independent. 574 The NSEC RR has no special TTL requirements. 576 4.1 NSEC RDATA Wire Format 578 The RDATA of the NSEC RR is as shown below: 580 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 / Next Domain Name / 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 / Type Bit Map / 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 4.1.1 The Next Domain Name Field 590 The Next Domain Name field contains the owner name of the next 591 authoritative RRset in the canonical ordering of the zone; see 592 Section 6.1 for an explanation of canonical ordering. The value of 593 the Next Domain Name field in the last NSEC record in the zone is the 594 name of the zone apex (the owner name name of the zone's SOA RR). 596 A sender MUST NOT use DNS name compression on the Next Domain Name 597 field when transmitting an NSEC RR. A receiver which receives an 598 NSEC RR containing a compressed Next Domain Name field SHOULD 599 decompress the field value. 601 Owner names of RRsets not authoritative for the given zone (such as 602 glue records) MUST NOT be listed in the Next Domain Name unless at 603 least one authoritative RRset exists at the same owner name. 605 4.1.2 The Type Bit Map Field 607 The Type Bit Map field identifies the RRset types which exist at the 608 NSEC RR's owner name. 610 Each bit in the Type Bit Map field corresponds to an RR type. Bit 1 611 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), 612 and so forth. If a bit is set to 1, it indicates that an RRset of 613 that type is present for the NSEC's owner name. If a bit is set to 0, 614 it indicates that no RRset of that type present for the NSEC's owner 615 name. 617 A zone MUST NOT generate an NSEC RR for any domain name that only 618 holds glue records. 620 Bits representing pseudo-RR types MUST be set to 0, since they do not 621 appear in zone data. If encountered, they must be ignored upon 622 reading. 624 Trailing zero octets MUST be omitted. The length of the Type Bit Map 625 field varies, and is determined by the type code with the largest 626 numerical value among the set of RR types present at the NSEC RR's 627 owner name. Trailing zero octets not specified MUST be interpreted 628 as zero octets. 630 The above Type Bit Map format MUST NOT be used when an RR type code 631 with numerical value greater than 127 is present. 633 Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A 634 value of 0 in bit 0 denotes the format described above, therefore bit 635 0 MUST have a value of 0. The format and meaning of a Type Bit Map 636 with a value of 1 in bit 0 is undefined. 638 4.1.3 Inclusion of Wildcard Names in NSEC RDATA 640 If a wildcard owner name appears in a zone, the wildcard label ("*") 641 is treated as a literal symbol and is treated the same as any other 642 owner name for purposes of generating NSEC RRs. Wildcard owner names 643 appear in the Next Domain Name field without any wildcard expansion. 644 [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards 645 on authenticated denial of existence. 647 4.2 The NSEC RR Presentation Format 649 The presentation format of the RDATA portion is as follows: 651 The Next Domain Name field is represented as a domain name. 653 The Type Bit Map field is represented either as a sequence of RR type 654 mnemonics or as a sequence of unsigned decimal integers denoting the 655 RR type codes. 657 4.3 NSEC RR Example 659 The following NSEC RR identifies the RRsets associated with 660 alfa.example.com. and identifies the next authoritative name after 661 alfa.example.com. 663 alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC 665 The first four text fields specify the name, TTL, Class, and RR type 666 (NSEC). The entry host.example.com. is the next authoritative name 667 after alfa.example.com. in canonical order. The A, MX, RRSIG and NSEC 668 mnemonics indicate there are A, MX, RRSIG and NSEC RRsets associated 669 with the name alfa.example.com. 671 Note that the NSEC record can be used in authenticated denial of 672 existence proofs. If the example NSEC record were authenticated, it 673 could be used to prove that beta.example.com does not exist or could 674 be used to prove there is no AAAA record associated with 675 alfa.example.com. Authenticated denial of existence is discussed in 676 [I-D.ietf-dnsext-dnssec-protocol]. 678 5. The DS Resource Record 680 The DS Resource Record refers to a DNSKEY RR and is used in the DNS 681 DNSKEY authentication process. A DS RR refers to a DNSKEY RR by 682 storing the key tag, algorithm number, and a digest of the DNSKEY RR. 683 Note that while the digest should be sufficient to identify the key, 684 storing the key tag and key algorithm helps make the identification 685 process more efficient. By authenticating the DS record, a resolver 686 can authenticate the DNSKEY RR to which the DS record points. The 687 key authentication process is described in 688 [I-D.ietf-dnsext-dnssec-protocol]. 690 The DS RR and its corresponding DNSKEY RR have the same owner name, 691 but they are stored in different locations. The DS RR appears only 692 on the upper (parental) side of a delegation, and is authoritative 693 data in the parent zone. For example, the DS RR for "example.com" is 694 stored in the "com" zone (the parent zone) rather than in the 695 "example.com" zone (the child zone). The corresponding DNSKEY RR is 696 stored in the "example.com" zone (the child zone). This simplifies 697 DNS zone management and zone signing, but introduces special response 698 processing requirements for the DS RR; these are described in 699 [I-D.ietf-dnsext-dnssec-protocol]. 701 The type number for the DS record is 43. 703 The DS resource record is class independent. 705 The DS RR has no special TTL requirements. 707 5.1 DS RDATA Wire Format 709 The RDATA for a DS RR consists of a 2 octet Key Tag field, a one 710 octet Algorithm field, a one octet Digest Type field, and a Digest 711 field. 713 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Key Tag | Algorithm | Digest Type | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 / / 719 / Digest / 720 / / 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 5.1.1 The Key Tag Field 725 The Key Tag field lists the key tag of the DNSKEY RR referred to by 726 the DS record. 728 The Key Tag used by the DS RR is identical to the Key Tag used by 729 RRSIG RRs. Appendix B describes how to compute a Key Tag. 731 5.1.2 The Algorithm Field 733 The Algorithm field lists the algorithm number of the DNSKEY RR 734 referred to by the DS record. 736 The algorithm number used by the DS RR is identical to the algorithm 737 number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm 738 number types. 740 5.1.3 The Digest Type Field 742 The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY 743 RR. The Digest Type field identifies the algorithm used to construct 744 the digest. Appendix A.2 lists the possible digest algorithm types. 746 5.1.4 The Digest Field 748 The DS record refers to a DNSKEY RR by including a digest of that 749 DNSKEY RR. The Digest field holds the digest. 751 The digest is calculated by concatenating the canonical form of the 752 fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, 753 and then applying the digest algorithm. 755 digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); 757 "|" denotes concatenation 759 DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. 761 The size of the digest may vary depending on the digest algorithm and 762 DNSKEY RR size. Currently, the only defined digest algorithm is 763 SHA-1, which produces a 20 octet digest. 765 5.2 Processing of DS RRs When Validating Responses 767 The DS RR links the authentication chain across zone boundaries, so 768 the DS RR requires extra care in processing. The DNSKEY RR referred 769 to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST 770 have Flags bit 7 set to value 1. If the key tag does not indicate a 771 DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT be 772 used in the validation process. 774 5.3 The DS RR Presentation Format 776 The presentation format of the RDATA portion is as follows: 778 The Key Tag field MUST be represented as an unsigned decimal integer. 780 The Algorithm field MUST be represented either as an unsigned decimal 781 integer or as an algorithm mnemonic specified in Appendix A.1. 783 The Digest Type field MUST be represented as an unsigned decimal 784 integer. 786 The Digest MUST be represented as a sequence of case-insensitive 787 hexadecimal digits. Whitespace is allowed within the hexadecimal 788 text. 790 5.4 DS RR Example 792 The following example shows a DNSKEY RR and its corresponding DS RR. 794 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz 795 fwJr1AYtsmx3TGkJaNXVbfi/ 796 2pHm822aJ5iI9BMzNXxeYCmZ 797 DRD99WYwYqUSdjMmmAphXdvx 798 egXd/M5+X7OrzKBaMbCVdFLU 799 Uh6DhweJBjEVv5f2wwjM9Xzc 800 nOf+EPbtG9DMBmADjFDc2w/r 801 ljwvFw== 802 ) ; key id = 60485 804 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 805 98631FAD1A292118 ) 807 The first four text fields specify the name, TTL, Class, and RR type 808 (DS). Value 60485 is the key tag for the corresponding 809 "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm 810 used by this "dskey.example.com." DNSKEY RR. The value 1 is the 811 algorithm used to construct the digest, and the rest of the RDATA 812 text is the digest in hexadecimal. 814 6. Canonical Form and Order of Resource Records 816 This section defines a canonical form for resource records, a 817 canonical ordering of DNS names, and a canonical ordering of resource 818 records within an RRset. A canonical name order is required to 819 construct the NSEC name chain. A canonical RR form and ordering 820 within an RRset are required to construct and verify RRSIG RRs. 822 6.1 Canonical DNS Name Order 824 For purposes of DNS security, owner names are ordered by treating 825 individual labels as unsigned left-justified octet strings. The 826 absence of a octet sorts before a zero value octet, and upper case 827 US-ASCII letters are treated as if they were lower case US-ASCII 828 letters. 830 To compute the canonical ordering of a set of DNS names, start by 831 sorting the names according to their most significant (rightmost) 832 labels. For names in which the most significant label is identical, 833 continue sorting according to their next most significant label, and 834 so forth. 836 For example, the following names are sorted in canonical DNS name 837 order. The most significant label is "example". At this level, 838 "example" sorts first, followed by names ending in "a.example", then 839 names ending "z.example". The names within each level are sorted in 840 the same way. 842 example 843 a.example 844 yljkjljk.a.example 845 Z.a.example 846 zABC.a.EXAMPLE 847 z.example 848 \001.z.example 849 *.z.example 850 \200.z.example 852 6.2 Canonical RR Form 854 For purposes of DNS security, the canonical form of an RR is the wire 855 format of the RR where: 857 1. Every domain name in the RR is fully expanded (no DNS name 858 compression) and fully qualified; 860 2. All uppercase US-ASCII letters in the owner name of the RR are 861 replaced by the corresponding lowercase US-ASCII letters; 863 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, 864 HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, 865 SRV, DNAME, or A6, all uppercase US-ASCII letters in the DNS 866 names contained within the RDATA are replaced by the 867 corresponding lowercase US-ASCII letters; 869 4. If the owner name of the RR is a wildcard name, the owner name is 870 in its original unexpanded form, including the "*" label (no 871 wildcard substitution); and 873 5. The RR's TTL is set to its original value as it appears in the 874 originating authoritative zone or the Original TTL field of the 875 covering RRSIG RR. 877 6.3 Canonical RR Ordering Within An RRset 879 For purposes of DNS security, RRs with same owner name, same class, 880 and same type are sorted by RDATA: first by RDATA length, shortest to 881 longest, then by the canonical form of the RDATA itself in the case 882 of length equality, treating the RDATA portion of the canonical form 883 of each RR as a left justified unsigned octet sequence. The absence 884 of an octet sorts before a zero octet. 886 7. IANA Considerations 888 This document introduces no new IANA considerations, because all of 889 the protocol parameters used in this document have already been 890 assigned by previous specifications. However, since the evolution of 891 DNSSEC has been long and somewhat convoluted, this section attempts 892 to describe the current state of the IANA registries and other 893 protocol parameters which are (or once were) related to DNSSEC. 895 DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to 896 the SIG, KEY, and NXT RRs, respectively. 897 [I-D.ietf-dnsext-delegation-signer] assigned DNS Resource Record 898 Type 43 to DS. [I-D.ietf-dnsext-dnssec-2535typecode-change] 899 assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, 900 respectively. [I-D.ietf-dnsext-dnssec-2535typecode-change] also 901 marked type 30 (NXT) as Obsolete, and restricted use of types 24 902 (SIG) and 25 (KEY) to the "SIG(0)" transaction security protocol 903 described in [RFC2931]. 905 SIG(0) Algorithm Numbers: [RFC2535] created an IANA registry for 906 DNSSEC Resource Record Algorithm field numbers, and assigned 907 values 1-4 and 252-255. [RFC3110] assigned value 5. 908 [I-D.ietf-dnsext-dnssec-2535typecode-change] renamed this registry 909 to "SIG(0) Algorithm Numbers" to indicate that this registry is 910 now used only by the "SIG(0)" transaction security protocol 911 described in [RFC2931]. 913 DNS Security Algorithm Numbers: 914 [I-D.ietf-dnsext-dnssec-2535typecode-change] created a new "DNS 915 Security Algorithm Numbers" registry, assigned initial values to 916 algorithms 2 (Diffie-Hellman), 3 (DSA/SHA-1), 5 (RSA/SHA-1), 253 917 (private algorithms - domain name) and 254 (private algorithms - 918 OID), and reserved values 0, 1, and 255. As stated in 919 [I-D.ietf-dnsext-dnssec-2535typecode-change], value 4 and values 920 6-252 are available for assignment by IETF Standards Action. 922 [I-D.ietf-dnsext-delegation-signer] created an IANA registry for 923 DNSSEC DS Digest Types, and assigned value 0 to reserved and value 924 1 to SHA-1. 926 KEY Protocol Values: [RFC2535] created an IANA Registry for KEY 927 Protocol Values, but [RFC3445] re-assigned all assigned values 928 other than 3 to reserved and closed this IANA registry. The 929 registry remains closed, and all KEY and DNSKEY records are 930 required to have Protocol Octet value of 3. 932 Flag bits in the KEY and DNSKEY RRs: The Flag bits in the KEY and 933 DNSKEY RRs are not assigned by IANA, and there is no IANA registry 934 for these flags. All changes to the meaning of the Flag bits in 935 the KEY and DNSKEY RRs require a standards action. 937 Bit zero of Type Bit Map in NSEC RRs: The meaning of a value of 1 in 938 bit zero of the Type Bit Map of an NSEC RR can only be assigned by 939 a standards action. 941 8. Security Considerations 943 This document describes the format of four DNS resource records used 944 by the DNS security extensions, and presents an algorithm for 945 calculating a key tag for a public key. Other than the items 946 described below, the resource records themselves introduce no 947 security considerations. The use of these records is specified in a 948 separate document, and security considerations related to the use 949 these resource records are discussed in that document. 951 The DS record points to a DNSKEY RR using a cryptographic digest, the 952 key algorithm type and a key tag. The DS record is intended to 953 identify an existing DNSKEY RR, but it is theoretically possible for 954 an attacker to generate a DNSKEY that matches all the DS fields. The 955 probability of constructing such a matching DNSKEY depends on the 956 type of digest algorithm in use. The only currently defined digest 957 algorithm is SHA-1, and the working group believes that constructing 958 a public key which would match the algorithm, key tag, and SHA-1 959 digest given in a DS record would be a sufficiently difficult problem 960 that such an attack is not a serious threat at this time. 962 The key tag is used to help select DNSKEY resource records 963 efficiently, but it does not uniquely identify a single DNSKEY 964 resource record. It is possible for two distinct DNSKEY RRs to have 965 the same owner name, the same algorithm type, and the same key tag. 966 An implementation which used only the key tag to select a DNSKEY RR 967 might select the wrong public key in some circumstances. 969 9. Acknowledgments 971 This document was created from the input and ideas of several members 972 of the DNS Extensions Working Group and working group mailing list. 973 The co-authors of this draft would like to express their thanks for 974 the comments and suggestions received during the revision of these 975 security extension specifications. 977 Normative References 979 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 980 STD 13, RFC 1034, November 1987. 982 [RFC1035] Mockapetris, P., "Domain names - implementation and 983 specification", STD 13, RFC 1035, November 1987. 985 [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 986 Mail Extensions) Part One: Mechanisms for Specifying and 987 Describing the Format of Internet Message Bodies", RFC 988 1521, September 1993. 990 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 991 August 1996. 993 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 994 Requirement Levels", BCP 14, RFC 2119, March 1997. 996 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 997 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 998 April 1997. 1000 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1001 Specification", RFC 2181, July 1997. 1003 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1004 NCACHE)", RFC 2308, March 1998. 1006 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 1007 2671, August 1999. 1009 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 1010 SIG(0)s)", RFC 2931, September 2000. 1012 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 1013 Name System (DNS)", RFC 3110, May 2001. 1015 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 1016 Resource Record (RR)", RFC 3445, December 2002. 1018 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1019 (RR) Types", RFC 3597, September 2003. 1021 [I-D.ietf-dnsext-delegation-signer] 1022 Gudmundsson, O., "Delegation Signer Resource Record", 1023 draft-ietf-dnsext-delegation-signer-15 (work in progress), 1024 June 2003. 1026 [I-D.ietf-dnsext-dnssec-intro] 1027 Arends, R., Austein, R., Larson, M., Massey, D. and S. 1028 Rose, "DNS Security Introduction and Requirements", 1029 draft-ietf-dnsext-dnssec-intro-06 (work in progress), 1030 September 2003. 1032 [I-D.ietf-dnsext-dnssec-protocol] 1033 Arends, R., Austein, R., Larson, M., Massey, D. and S. 1034 Rose, "Protocol Modifications for the DNS Security 1035 Extensions", draft-ietf-dnsext-dnssec-protocol-02 (work in 1036 progress), September 2003. 1038 [I-D.ietf-dnsext-keyrr-key-signing-flag] 1039 Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure 1040 Entry Point (SEP) Flag", 1041 draft-ietf-dnsext-keyrr-key-signing-flag-08 (work in 1042 progress), July 2003. 1044 [I-D.ietf-dnsext-dnssec-2535typecode-change] 1045 Weiler, S., "Legacy Resolver Compatibility for Delegation 1046 Signer", draft-ietf-dnsext-dnssec-2535typecode-change-04 1047 (work in progress), August 2003. 1049 Informative References 1051 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1052 RFC 2535, March 1999. 1054 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 1055 RR)", RFC 2930, September 2000. 1057 Authors' Addresses 1059 Roy Arends 1060 Telematica Instituut 1061 Drienerlolaan 5 1062 7522 NB Enschede 1063 NL 1065 EMail: roy.arends@telin.nl 1067 Rob Austein 1068 Internet Software Consortium 1069 40 Gavin Circle 1070 Reading, MA 01867 1071 USA 1073 EMail: sra@isc.org 1075 Matt Larson 1076 VeriSign, Inc. 1077 21345 Ridgetop Circle 1078 Dulles, VA 20166-6503 1079 USA 1081 EMail: mlarson@verisign.com 1083 Dan Massey 1084 USC Information Sciences Institute 1085 3811 N. Fairfax Drive 1086 Arlington, VA 22203 1087 USA 1089 EMail: masseyd@isi.edu 1090 Scott Rose 1091 National Institute for Standards and Technology 1092 100 Bureau Drive 1093 Gaithersburg, MD 20899-8920 1094 USA 1096 EMail: scott.rose@nist.gov 1098 Appendix A. DNSSEC Algorithm and Digest Types 1100 The DNS security extensions are designed to be independent of the 1101 underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS 1102 resource records all use a DNSSEC Algorithm Number to identify the 1103 cryptographic algorithm in use by the resource record. The DS 1104 resource record also specifies a Digest Algorithm Number to identify 1105 the digest algorithm used to construct the DS record. The currently 1106 defined Algorithm and Digest Types are listed below. Additional 1107 Algorithm or Digest Types could be added as advances in cryptography 1108 warrant. 1110 A DNSSEC aware resolver or name server MUST implement all MANDATORY 1111 algorithms. 1113 A.1 DNSSEC Algorithm Types 1115 An "Algorithm Number" field in the DNSKEY, RRSIG, and DS resource 1116 record types identifies the cryptographic algorithm used by the 1117 resource record. Algorithm specific formats are described in 1118 separate documents. The following table lists the currently defined 1119 algorithm types and provides references to their supporting 1120 documents: 1122 VALUE Algorithm [mnemonic] RFC STATUS 1123 0 Reserved - - 1124 1 RSA/MD5 [RSA/MD5] RFC 2537 NOT RECOMMENDED 1125 2 Diffie-Hellman [DH] RFC 2539 OPTIONAL 1126 3 DSA [DSA] RFC 2536 OPTIONAL 1127 4 elliptic curve [ECC] TBA OPTIONAL 1128 5 RSA/SHA1 [RSA/SHA1] RFC 3110 MANDATORY 1129 6-251 available for assignment - 1130 252 reserved - 1131 253 private [PRIVATE_DNS] see below OPTIONAL 1132 254 private [PRIVATE_OID] see below OPTIONAL 1133 255 reserved - - 1135 A.1.1 Private Algorithm Types 1137 Algorithm number 253 is reserved for private use and will never be 1138 assigned to a specific algorithm. The public key area in the DNSKEY 1139 RR and the signature area in the RRSIG RR begin with a wire encoded 1140 domain name, which MUST NOT be compressed. The domain name indicates 1141 the private algorithm to use and the remainder of the public key area 1142 is determined by that algorithm. Entities should only use domain 1143 names they control to designate their private algorithms. 1145 Algorithm number 254 is reserved for private use and will never be 1146 assigned to a specific algorithm. The public key area in the DNSKEY 1147 RR and the signature area in the RRSIG RR begin with an unsigned 1148 length byte followed by a BER encoded Object Identifier (ISO OID) of 1149 that length. The OID indicates the private algorithm in use and the 1150 remainder of the area is whatever is required by that algorithm. 1151 Entities should only use OIDs they control to designate their private 1152 algorithms. 1154 A.2 DNSSEC Digest Types 1156 A "Digest Type" field in the DS resource record types identifies the 1157 cryptographic digest algorithm used by the resource record. The 1158 following table lists the currently defined digest algorithm types. 1160 VALUE Algorithm STATUS 1161 0 Reserved - 1162 1 SHA-1 MANDATORY 1163 2-255 Unassigned - 1165 Appendix B. Key Tag Calculation 1167 The Key Tag field in the RRSIG and DS resource record types provides 1168 a mechanism for selecting a public key efficiently. In most cases, a 1169 combination of owner name, algorithm, and key tag can efficiently 1170 identify a DNSKEY record. Both the RRSIG and DS resource records 1171 have corresponding DNSKEY records. The Key Tag field in the RRSIG 1172 and DS records can be used to help select the corresponding DNSKEY RR 1173 efficiently when more than one candidate DNSKEY RR is available. 1175 However, it is essential to note that the key tag is not a unique 1176 identifier. It is theoretically possible for two distinct DNSKEY RRs 1177 to have the same owner name, the same algorithm, and the same key 1178 tag. The key tag is used to limit the possible candidate keys, but it 1179 does not uniquely identify a DNSKEY record. Implementations MUST NOT 1180 assume that the key tag uniquely identifies a DNSKEY RR. 1182 The key tag is the same for all DNSKEY algorithm types except 1183 algorithm 1 (please see Appendix B.1 for the definition of the key 1184 tag for algorithm 1). The key tag algorithm is the sum of the wire 1185 format of the DNSKEY RDATA broken into 2 octet groups. First the 1186 RDATA (in wire format) is treated as a series of 2 octet groups, 1187 these groups are then added together ignoring any carry bits. A 1188 reference implementation of the key tag algorithm is as am ANSI C 1189 function is given below with the RDATA portion of the DNSKEY RR is 1190 used as input. It is not necessary to use the following reference 1191 code verbatim, but the numerical value of the Key Tag MUST be 1192 identical to what the reference implementation would generate for the 1193 same input. 1195 Please note that the algorithm for calculating the Key Tag is almost 1196 but not completely identical to the familiar ones complement checksum 1197 used in many other Internet protocols. Key Tags MUST be calculated 1198 using the algorithm described here rather than the ones complement 1199 checksum. 1201 The following ANSI C reference implementation calculates the value of 1202 a Key Tag. This reference implementation applies to all algorithm 1203 types except algorithm 1 (see Appendix B.1). The input is the wire 1204 format of the RDATA portion of the DNSKEY RR. The code is written 1205 for clarity, not efficiency. 1207 /* 1208 * Assumes that int is at least 16 bits. 1209 * First octet of the key tag is the most significant 8 bits of the 1210 * return value; 1211 * Second octet of the key tag is the least significant 8 bits of the 1212 * return value. 1214 */ 1216 unsigned int 1217 keytag ( 1218 unsigned char key[], /* the RDATA part of the DNSKEY RR */ 1219 unsigned int keysize /* the RDLENGTH */ 1220 ) 1221 { 1222 unsigned long ac; /* assumed to be 32 bits or larger */ 1223 int i; /* loop index */ 1225 for ( ac = 0, i = 0; i < keysize; ++i ) 1226 ac += (i & 1) ? key[i] : key[i] << 8; 1227 ac += (ac >> 16) & 0xFFFF; 1228 return ac & 0xFFFF; 1229 } 1231 B.1 Key Tag for Algorithm 1 (RSA/MD5) 1233 The key tag for algorithm 1 (RSA/MD5) is defined differently than the 1234 key tag for all other algorithms, for historical reasons. For a 1235 DNSKEY RR with algorithm 1, the key tag is defined to be the most 1236 significant 16 bits of the least significant 24 bits in the public 1237 key modulus (in other words, the 4th to last and 3rd to last octets 1238 of the public key modulus). 1240 Please note that Algorithm 1 is NOT RECOMMENDED. 1242 Intellectual Property Statement 1244 The IETF takes no position regarding the validity or scope of any 1245 intellectual property or other rights that might be claimed to 1246 pertain to the implementation or use of the technology described in 1247 this document or the extent to which any license under such rights 1248 might or might not be available; neither does it represent that it 1249 has made any effort to identify any such rights. Information on the 1250 IETF's procedures with respect to rights in standards-track and 1251 standards-related documentation can be found in BCP-11. Copies of 1252 claims of rights made available for publication and any assurances of 1253 licenses to be made available, or the result of an attempt made to 1254 obtain a general license or permission for the use of such 1255 proprietary rights by implementors or users of this specification can 1256 be obtained from the IETF Secretariat. 1258 The IETF invites any interested party to bring to its attention any 1259 copyrights, patents or patent applications, or other proprietary 1260 rights which may cover technology that may be required to practice 1261 this standard. Please address the information to the IETF Executive 1262 Director. 1264 Full Copyright Statement 1266 Copyright (C) The Internet Society (2003). All Rights Reserved. 1268 This document and translations of it may be copied and furnished to 1269 others, and derivative works that comment on or otherwise explain it 1270 or assist in its implementation may be prepared, copied, published 1271 and distributed, in whole or in part, without restriction of any 1272 kind, provided that the above copyright notice and this paragraph are 1273 included on all such copies and derivative works. However, this 1274 document itself may not be modified in any way, such as by removing 1275 the copyright notice or references to the Internet Society or other 1276 Internet organizations, except as needed for the purpose of 1277 developing Internet standards in which case the procedures for 1278 copyrights defined in the Internet Standards process must be 1279 followed, or as required to translate it into languages other than 1280 English. 1282 The limited permissions granted above are perpetual and will not be 1283 revoked by the Internet Society or its successors or assignees. 1285 This document and the information contained herein is provided on an 1286 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1287 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1288 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1289 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1290 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1292 Acknowledgement 1294 Funding for the RFC Editor function is currently provided by the 1295 Internet Society.