idnits 2.17.1 draft-ietf-dnsext-dnssec-records-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1308. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 == 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 (October 10, 2004) is 7138 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 1164, but not defined == Missing Reference: 'RSAMD5' is mentioned on line 1167, but not defined == Missing Reference: 'DH' is mentioned on line 1168, but not defined == Missing Reference: 'DSA' is mentioned on line 1169, but not defined == Missing Reference: 'ECC' is mentioned on line 1170, but not defined == Missing Reference: 'RSASHA1' is mentioned on line 1171, but not defined == Missing Reference: 'INDIRECT' is mentioned on line 1172, but not defined == Missing Reference: 'PRIVATEDNS' is mentioned on line 1173, but not defined == Missing Reference: 'PRIVATEOID' is mentioned on line 1174, but not defined == Unused Reference: 'RFC2136' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'RFC2671' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC3845' is defined on line 1092, 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 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** 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) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2537 (Obsoleted by RFC 3110) -- Obsolete informational reference (is this intentional?): RFC 3845 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 11 errors (**), 0 flaws (~~), 17 warnings (==), 12 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: April 10, 2005 R. Austein 5 ISC 6 M. Larson 7 VeriSign 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 October 10, 2004 14 Resource Records for the DNS Security Extensions 15 draft-ietf-dnsext-dnssec-records-11 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 10, 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2004). 48 Abstract 49 This document is part of a family of documents that describes the DNS 50 Security Extensions (DNSSEC). The DNS Security Extensions are a 51 collection of resource records and protocol modifications that 52 provide source authentication for the DNS. This document defines the 53 public key (DNSKEY), delegation signer (DS), resource record digital 54 signature (RRSIG), and authenticated denial of existence (NSEC) 55 resource records. The purpose and format of each resource record is 56 described in detail, and an example of each resource record is given. 58 This document obsoletes RFC 2535 and incorporates changes from all 59 updates to RFC 2535. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1 Background and Related Documents . . . . . . . . . . . . . 4 65 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 66 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 5 67 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 5 68 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 5 69 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 6 70 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 6 71 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 6 72 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 6 73 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 6 74 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 7 75 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 8 76 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 8 77 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 9 78 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 9 79 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 9 80 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 10 81 3.1.5 Signature Expiration and Inception Fields . . . . . . 10 82 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 10 83 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11 84 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11 85 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12 86 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13 87 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14 88 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14 89 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14 90 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 24 109 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 112 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 114 A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 29 115 A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29 116 A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 29 117 A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 30 118 B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 31 119 B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 32 120 Intellectual Property and Copyright Statements . . . . . . . . 33 122 1. Introduction 124 The DNS Security Extensions (DNSSEC) introduce four new DNS resource 125 record types: DNS Public Key (DNSKEY), Resource Record Signature 126 (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This 127 document defines the purpose of each resource record (RR), the RR's 128 RDATA format, and its presentation format (ASCII representation). 130 1.1 Background and Related Documents 132 This document is part of a family of documents that define DNSSEC, 133 which should be read together as a set. 135 [I-D.ietf-dnsext-dnssec-intro] contains an introduction to DNSSEC and 136 definition of common terms; the reader is assumed to be familiar with 137 this document. [I-D.ietf-dnsext-dnssec-intro] also contains a list 138 of other documents updated by and obsoleted by this document set. 140 [I-D.ietf-dnsext-dnssec-protocol] defines the DNSSEC protocol 141 operations. 143 The reader is also assumed to be familiar with the basic DNS concepts 144 described in [RFC1034], [RFC1035], and the subsequent documents that 145 update them, particularly [RFC2181] and [RFC2308]. 147 This document defines the DNSSEC resource records. 149 All numeric DNS type codes given in this document are decimal 150 integers. 152 1.2 Reserved Words 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2. The DNSKEY Resource Record 160 DNSSEC uses public key cryptography to sign and authenticate DNS 161 resource record sets (RRsets). The public keys are stored in DNSKEY 162 resource records and are used in the DNSSEC authentication process 163 described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its 164 authoritative RRsets using a private key and stores the corresponding 165 public key in a DNSKEY RR. A resolver can then use the public key to 166 validate signatures covering the RRsets in the zone, and thus 167 authenticate them. 169 The DNSKEY RR is not intended as a record for storing arbitrary 170 public keys and MUST NOT be used to store certificates or public keys 171 that do not directly relate to the DNS infrastructure. 173 The Type value for the DNSKEY RR type is 48. 175 The DNSKEY RR is class independent. 177 The DNSKEY RR has no special TTL requirements. 179 2.1 DNSKEY RDATA Wire Format 181 The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 182 octet Protocol Field, a 1 octet Algorithm Field, and the Public Key 183 Field. 185 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Flags | Protocol | Algorithm | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 / / 191 / Public Key / 192 / / 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 2.1.1 The Flags Field 197 Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, 198 then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner 199 name MUST be the name of a zone. If bit 7 has value 0, then the 200 DNSKEY record holds some other type of DNS public key and MUST NOT be 201 used to verify RRSIGs that cover RRsets. 203 Bit 15 of the Flags field is the Secure Entry Point flag, described 204 in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a 205 key intended for use as a secure entry point. This flag is only 206 intended to be to a hint to zone signing or debugging software as to 207 the intended use of this DNSKEY record; validators MUST NOT alter 208 their behavior during the signature validation process in any way 209 based on the setting of this bit. This also means a DNSKEY RR with 210 the SEP bit set would also need the Zone Key flag set in order to 211 legally be able to generate signatures. A DNSKEY RR with the SEP set 212 and the Zone Key flag not set MUST NOT be used to verify RRSIGs that 213 cover RRsets. 215 Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon 216 creation of the DNSKEY RR, and MUST be ignored upon reception. 218 2.1.2 The Protocol Field 220 The Protocol Field MUST have value 3 and the DNSKEY RR MUST be 221 treated as invalid during signature verification if found to be some 222 value other than 3. 224 2.1.3 The Algorithm Field 226 The Algorithm field identifies the public key's cryptographic 227 algorithm and determines the format of the Public Key field. A list 228 of DNSSEC algorithm types can be found in Appendix A.1 230 2.1.4 The Public Key Field 232 The Public Key Field holds the public key material. The format 233 depends on the algorithm of the key being stored and are described in 234 separate documents. 236 2.1.5 Notes on DNSKEY RDATA Design 238 Although the Protocol Field always has value 3, it is retained for 239 backward compatibility with early versions of the KEY record. 241 2.2 The DNSKEY RR Presentation Format 243 The presentation format of the RDATA portion is as follows: 245 The Flag field MUST be represented as an unsigned decimal integer. 246 Given the currently defined flags, the possible values are: 0, 256, 247 or 257. 249 The Protocol Field MUST be represented as an unsigned decimal integer 250 with a value of 3. 252 The Algorithm field MUST be represented either as an unsigned decimal 253 integer or as an algorithm mnemonic as specified in Appendix A.1. 255 The Public Key field MUST be represented as a Base64 encoding of the 256 Public Key. Whitespace is allowed within the Base64 text. For a 257 definition of Base64 encoding, see [RFC3548]. 259 2.3 DNSKEY RR Example 261 The following DNSKEY RR stores a DNS zone key for example.com. 263 example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 264 Cbl+BBZH4b/0PY1kxkmvHjcZc8no 265 kfzj31GajIQKY+5CptLr3buXA10h 266 WqTkF7H6RfoRqXQeogmMHfpftf6z 267 Mv1LyBUgia7za6ZEzOJBOztyvhjL 268 742iU/TpPSEDhm2SNKLijfUppn1U 269 aNvv4w== ) 271 The first four text fields specify the owner name, TTL, Class, and RR 272 type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in 273 the Flags field has value 1. Value 3 is the fixed Protocol value. 274 Value 5 indicates the public key algorithm. Appendix A.1 identifies 275 algorithm type 5 as RSA/SHA1 and indicates that the format of the 276 RSA/SHA1 public key field is defined in [RFC3110]. The remaining 277 text is a Base64 encoding of the public key. 279 3. The RRSIG Resource Record 281 DNSSEC uses public key cryptography to sign and authenticate DNS 282 resource record sets (RRsets). Digital signatures are stored in 283 RRSIG resource records and are used in the DNSSEC authentication 284 process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator 285 can use these RRSIG RRs to authenticate RRsets from the zone. The 286 RRSIG RR MUST only be used to carry verification material (digital 287 signatures) used to secure DNS operations. 289 An RRSIG record contains the signature for an RRset with a particular 290 name, class, and type. The RRSIG RR specifies a validity interval 291 for the signature and uses the Algorithm, the Signer's Name, and the 292 Key Tag to identify the DNSKEY RR containing the public key that a 293 validator can use to verify the signature. 295 Because every authoritative RRset in a zone must be protected by a 296 digital signature, RRSIG RRs must be present for names containing a 297 CNAME RR. This is a change to the traditional DNS specification 298 [RFC1034] that stated that if a CNAME is present for a name, it is 299 the only type allowed at that name. A RRSIG and NSEC (see Section 4) 300 MUST exist for the same name as a CNAME resource record in a signed 301 zone. 303 The Type value for the RRSIG RR type is 46. 305 The RRSIG RR is class independent. 307 An RRSIG RR MUST have the same class as the RRset it covers. 309 The TTL value of an RRSIG RR MUST match the TTL value of the RRset it 310 covers. This is an exception to the [RFC2181] rules for TTL values 311 of individual RRs within a RRset: individual RRSIG with the same 312 owner name will have different TTL values if the RRsets they cover 313 have different TTL values. 315 3.1 RRSIG RDATA Wire Format 317 The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a 318 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original 319 TTL field, a 4 octet Signature Expiration field, a 4 octet Signature 320 Inception field, a 2 octet Key tag, the Signer's Name field, and the 321 Signature field. 323 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type Covered | Algorithm | Labels | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Original TTL | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Signature Expiration | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Signature Inception | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Key Tag | / 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / 336 / / 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 / / 339 / Signature / 340 / / 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 3.1.1 The Type Covered Field 345 The Type Covered field identifies the type of the RRset that is 346 covered by this RRSIG record. 348 3.1.2 The Algorithm Number Field 350 The Algorithm Number field identifies the cryptographic algorithm 351 used to create the signature. A list of DNSSEC algorithm types can 352 be found in Appendix A.1 354 3.1.3 The Labels Field 356 The Labels field specifies the number of labels in the original RRSIG 357 RR owner name. The significance of this field is that a validator 358 uses it to determine if the answer was synthesized from a wildcard. 359 If so, it can be used to determine what owner name was used in 360 generating the signature. 362 To validate a signature, the validator needs the original owner name 363 that was used to create the signature. If the original owner name 364 contains a wildcard label ("*"), the owner name may have been 365 expanded by the server during the response process, in which case the 366 validator will need to reconstruct the original owner name in order 367 to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] 368 describes how to use the Labels field to reconstruct the original 369 owner name. 371 The value of the Labels field MUST NOT count either the null (root) 372 label that terminates the owner name or the wildcard label (if 373 present). The value of the Labels field MUST be less than or equal 374 to the number of labels in the RRSIG owner name. For example, 375 "www.example.com." has a Labels field value of 3, and 376 "*.example.com." has a Labels field value of 2. Root (".") has a 377 Labels field value of 0. 379 Although the wildcard label is not included in the count stored in 380 the Labels field of the RRSIG RR, the wildcard label is part of the 381 RRset's owner name when generating or verifying the signature. 383 3.1.4 Original TTL Field 385 The Original TTL field specifies the TTL of the covered RRset as it 386 appears in the authoritative zone. 388 The Original TTL field is necessary because a caching resolver 389 decrements the TTL value of a cached RRset. In order to validate a 390 signature, a validator requires the original TTL. 391 [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original 392 TTL field value to reconstruct the original TTL. 394 3.1.5 Signature Expiration and Inception Fields 396 The Signature Expiration and Inception fields specify a validity 397 period for the signature. The RRSIG record MUST NOT be used for 398 authentication prior to the inception date and MUST NOT be used for 399 authentication after the expiration date. 401 The Signature Expiration and Inception field values specify a date 402 and time in the form of a 32-bit unsigned number of seconds elapsed 403 since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network 404 byte order. The longest interval which can be expressed by this 405 format without wrapping is approximately 136 years. An RRSIG RR can 406 have an Expiration field value which is numerically smaller than the 407 Inception field value if the expiration field value is near the 408 32-bit wrap-around point or if the signature is long lived. Because 409 of this, all comparisons involving these fields MUST use "Serial 410 number arithmetic" as defined in [RFC1982]. As a direct consequence, 411 the values contained in these fields cannot refer to dates more than 412 68 years in either the past or the future. 414 3.1.6 The Key Tag Field 416 The Key Tag field contains the key tag value of the DNSKEY RR that 417 validates this signature, in network byte order. Appendix B explains 418 how to calculate Key Tag values. 420 3.1.7 The Signer's Name Field 422 The Signer's Name field value identifies the owner name of the DNSKEY 423 RR which a validator is supposed to use to validate this signature. 424 The Signer's Name field MUST contain the name of the zone of the 425 covered RRset. A sender MUST NOT use DNS name compression on the 426 Signer's Name field when transmitting a RRSIG RR. 428 3.1.8 The Signature Field 430 The Signature field contains the cryptographic signature that covers 431 the RRSIG RDATA (excluding the Signature field) and the RRset 432 specified by the RRSIG owner name, RRSIG class, and RRSIG Type 433 Covered field. The format of this field depends on the algorithm in 434 use and these formats are described in separate companion documents. 436 3.1.8.1 Signature Calculation 438 A signature covers the RRSIG RDATA (excluding the Signature Field) 439 and covers the data RRset specified by the RRSIG owner name, RRSIG 440 class, and RRSIG Type Covered fields. The RRset is in canonical form 441 (see Section 6) and the set RR(1),...RR(n) is signed as follows: 443 signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where 445 "|" denotes concatenation; 447 RRSIG_RDATA is the wire format of the RRSIG RDATA fields 448 with the Signer's Name field in canonical form and 449 the Signature field excluded; 451 RR(i) = owner | type | class | TTL | RDATA length | RDATA 453 "owner" is the fully qualified owner name of the RRset in 454 canonical form (for RRs with wildcard owner names, the 455 wildcard label is included in the owner name); 457 Each RR MUST have the same owner name as the RRSIG RR; 459 Each RR MUST have the same class as the RRSIG RR; 461 Each RR in the RRset MUST have the RR type listed in the 462 RRSIG RR's Type Covered field; 464 Each RR in the RRset MUST have the TTL listed in the 465 RRSIG Original TTL Field; 467 Any DNS names in the RDATA field of each RR MUST be in 468 canonical form; and 470 The RRset MUST be sorted in canonical order. 472 See Section 6.2 and Section 6.3 for details on canonical form and 473 ordering of RRsets. 475 3.2 The RRSIG RR Presentation Format 477 The presentation format of the RDATA portion is as follows: 479 The Type Covered field is represented as a RR type mnemonic. When 480 the mnemonic is not known, the TYPE representation as described in 481 [RFC3597] (section 5) MUST be used. 483 The Algorithm field value MUST be represented either as an unsigned 484 decimal integer or as an algorithm mnemonic as specified in Appendix 485 A.1. 487 The Labels field value MUST be represented as an unsigned decimal 488 integer. 490 The Original TTL field value MUST be represented as an unsigned 491 decimal integer. 493 The Signature Expiration Time and Inception Time field values MUST be 494 represented either as an unsigned decimal integer indicating seconds 495 since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in 496 UTC, where: 497 YYYY is the year (0001-9999, but see Section 3.1.5); 498 MM is the month number (01-12); 499 DD is the day of the month (01-31); 500 HH is the hour in 24 hours notation (00-23); 501 mm is the minute (00-59); and 502 SS is the second (00-59). 503 Note that it is always be possible to distinguish between these two 504 formats, because the YYYYMMDDHHmmSS format will always be exactly 14 505 digits, while the decimal representation of a 32-bit unsigned integer 506 can never be longer than 10 digits. 508 The Key Tag field MUST be represented as an unsigned decimal integer. 510 The Signer's Name field value MUST be represented as a domain name. 512 The Signature field is represented as a Base64 encoding of the 513 signature. Whitespace is allowed within the Base64 text. See 514 Section 2.2. 516 3.3 RRSIG RR Example 518 The following RRSIG RR stores the signature for the A RRset of 519 host.example.com: 521 host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 522 20030220173103 2642 example.com. 523 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr 524 PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o 525 B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t 526 GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG 527 J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) 529 The first four fields specify the owner name, TTL, Class, and RR type 530 (RRSIG). The "A" represents the Type Covered field. The value 5 531 identifies the algorithm used (RSA/SHA1) to create the signature. 532 The value 3 is the number of Labels in the original owner name. The 533 value 86400 in the RRSIG RDATA is the Original TTL for the covered A 534 RRset. 20030322173103 and 20030220173103 are the expiration and 535 inception dates, respectively. 2642 is the Key Tag, and example.com. 536 is the Signer's Name. The remaining text is a Base64 encoding of the 537 signature. 539 Note that combination of RRSIG RR owner name, class, and Type Covered 540 indicate that this RRSIG covers the "host.example.com" A RRset. The 541 Label value of 3 indicates that no wildcard expansion was used. The 542 Algorithm, Signer's Name, and Key Tag indicate this signature can be 543 authenticated using an example.com zone DNSKEY RR whose algorithm is 544 5 and key tag is 2642. 546 4. The NSEC Resource Record 548 The NSEC resource record lists two separate things: the next owner 549 name (in the canonical ordering of the zone) which contains 550 authoritative data or a delegation point NS RRset, and the set of RR 551 types present at the NSEC RR's owner name. The complete set of NSEC 552 RRs in a zone both indicate which authoritative RRsets exist in a 553 zone and also form a chain of authoritative owner names in the zone. 554 This information is used to provide authenticated denial of existence 555 for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol]. 557 Because every authoritative name in a zone must be part of the NSEC 558 chain, NSEC RRs must be present for names containing a CNAME RR. 559 This is a change to the traditional DNS specification [RFC1034] that 560 stated that if a CNAME is present for a name, it is the only type 561 allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist 562 for the same name as a CNAME resource record in a signed zone. 564 See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone 565 signer determines precisely which NSEC RRs it needs to include in a 566 zone. 568 The type value for the NSEC RR is 47. 570 The NSEC RR is class independent. 572 The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL 573 field. This is in the spirit of negative caching ([RFC2308]). 575 4.1 NSEC RDATA Wire Format 577 The RDATA of the NSEC RR is as shown below: 579 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 / Next Domain Name / 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 / Type Bit Maps / 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 4.1.1 The Next Domain Name Field 589 The Next Domain field contains the next owner name (in the canonical 590 ordering of the zone) which has authoritative data or contains a 591 delegation point NS RRset; see Section 6.1 for an explanation of 592 canonical ordering. The value of the Next Domain Name field in the 593 last NSEC record in the zone is the name of the zone apex (the owner 594 name of the zone's SOA RR). This indicates that the owner name of 595 the NSEC RR is the last name in the canonical ordering of the zone. 597 A sender MUST NOT use DNS name compression on the Next Domain Name 598 field when transmitting an NSEC RR. 600 Owner names of RRsets not authoritative for the given zone (such as 601 glue records) MUST NOT be listed in the Next Domain Name unless at 602 least one authoritative RRset exists at the same owner name. 604 4.1.2 The Type Bit Maps Field 606 The Type Bit Maps field identifies the RRset types which exist at the 607 NSEC RR's owner name. 609 The RR type space is split into 256 window blocks, each representing 610 the low-order 8 bits of the 16-bit RR type space. Each block that 611 has at least one active RR type is encoded using a single octet 612 window number (from 0 to 255), a single octet bitmap length (from 1 613 to 32) indicating the number of octets used for the window block's 614 bitmap, and up to 32 octets (256 bits) of bitmap. 616 Blocks are present in the NSEC RR RDATA in increasing numerical 617 order. 619 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ 621 where "|" denotes concatenation. 623 Each bitmap encodes the low-order 8 bits of RR types within the 624 window block, in network bit order. The first bit is bit 0. For 625 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds 626 to RR type 2 (NS), and so forth. For window block 1, bit 1 627 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set, 628 it indicates that an RRset of that type is present for the NSEC RR's 629 owner name. If a bit is clear, it indicates that no RRset of that 630 type is present for the NSEC RR's owner name. 632 Bits representing pseudo-types MUST be clear, since they do not 633 appear in zone data. If encountered, they MUST be ignored upon 634 reading. 636 Blocks with no types present MUST NOT be included. Trailing zero 637 octets in the bitmap MUST be omitted. The length of each block's 638 bitmap is determined by the type code with the largest numerical 639 value, within that block, among the set of RR types present at the 640 NSEC RR's owner name. Trailing zero octets not specified MUST be 641 interpreted as zero octets. 643 The bitmap for the NSEC RR at a delegation point requires special 644 attention. Bits corresponding to the delegation NS RRset and the RR 645 types for which the parent zone has authoritative data MUST be set; 646 bits corresponding to any non-NS RRset for which the parent is not 647 authoritative MUST be clear. 649 A zone MUST NOT include an NSEC RR for any domain name that only 650 holds glue records. 652 4.1.3 Inclusion of Wildcard Names in NSEC RDATA 654 If a wildcard owner name appears in a zone, the wildcard label ("*") 655 is treated as a literal symbol and is treated the same as any other 656 owner name for purposes of generating NSEC RRs. Wildcard owner names 657 appear in the Next Domain Name field without any wildcard expansion. 658 [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards 659 on authenticated denial of existence. 661 4.2 The NSEC RR Presentation Format 663 The presentation format of the RDATA portion is as follows: 665 The Next Domain Name field is represented as a domain name. 667 The Type Bit Maps field is represented as a sequence of RR type 668 mnemonics. When the mnemonic is not known, the TYPE representation 669 as described in [RFC3597] (section 5) MUST be used. 671 4.3 NSEC RR Example 673 The following NSEC RR identifies the RRsets associated with 674 alfa.example.com. and identifies the next authoritative name after 675 alfa.example.com. 677 alfa.example.com. 86400 IN NSEC host.example.com. ( 678 A MX RRSIG NSEC TYPE1234 ) 680 The first four text fields specify the name, TTL, Class, and RR type 681 (NSEC). The entry host.example.com. is the next authoritative name 682 after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, 683 and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and 684 TYPE1234 RRsets associated with the name alfa.example.com. 686 The RDATA section of the NSEC RR above would be encoded as: 688 0x04 'h' 'o' 's' 't' 689 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 690 0x03 'c' 'o' 'm' 0x00 691 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 692 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 693 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 694 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 695 0x00 0x00 0x00 0x00 0x20 697 Assuming that the validator can authenticate this NSEC record, it 698 could be used to prove that beta.example.com does not exist, or could 699 be used to prove there is no AAAA record associated with 700 alfa.example.com. Authenticated denial of existence is discussed in 701 [I-D.ietf-dnsext-dnssec-protocol]. 703 5. The DS Resource Record 705 The DS Resource Record refers to a DNSKEY RR and is used in the DNS 706 DNSKEY authentication process. A DS RR refers to a DNSKEY RR by 707 storing the key tag, algorithm number, and a digest of the DNSKEY RR. 708 Note that while the digest should be sufficient to identify the 709 public key, storing the key tag and key algorithm helps make the 710 identification process more efficient. By authenticating the DS 711 record, a resolver can authenticate the DNSKEY RR to which the DS 712 record points. The key authentication process is described in 713 [I-D.ietf-dnsext-dnssec-protocol]. 715 The DS RR and its corresponding DNSKEY RR have the same owner name, 716 but they are stored in different locations. The DS RR appears only 717 on the upper (parental) side of a delegation, and is authoritative 718 data in the parent zone. For example, the DS RR for "example.com" is 719 stored in the "com" zone (the parent zone) rather than in the 720 "example.com" zone (the child zone). The corresponding DNSKEY RR is 721 stored in the "example.com" zone (the child zone). This simplifies 722 DNS zone management and zone signing, but introduces special response 723 processing requirements for the DS RR; these are described in 724 [I-D.ietf-dnsext-dnssec-protocol]. 726 The type number for the DS record is 43. 728 The DS resource record is class independent. 730 The DS RR has no special TTL requirements. 732 5.1 DS RDATA Wire Format 734 The RDATA for a DS RR consists of a 2 octet Key Tag field, a one 735 octet Algorithm field, a one octet Digest Type field, and a Digest 736 field. 738 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Key Tag | Algorithm | Digest Type | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 / / 744 / Digest / 745 / / 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 5.1.1 The Key Tag Field 750 The Key Tag field lists the key tag of the DNSKEY RR referred to by 751 the DS record, in network byte order. 753 The Key Tag used by the DS RR is identical to the Key Tag used by 754 RRSIG RRs. Appendix B describes how to compute a Key Tag. 756 5.1.2 The Algorithm Field 758 The Algorithm field lists the algorithm number of the DNSKEY RR 759 referred to by the DS record. 761 The algorithm number used by the DS RR is identical to the algorithm 762 number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the 763 algorithm number types. 765 5.1.3 The Digest Type Field 767 The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY 768 RR. The Digest Type field identifies the algorithm used to construct 769 the digest. Appendix A.2 lists the possible digest algorithm types. 771 5.1.4 The Digest Field 773 The DS record refers to a DNSKEY RR by including a digest of that 774 DNSKEY RR. 776 The digest is calculated by concatenating the canonical form of the 777 fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, 778 and then applying the digest algorithm. 780 digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); 782 "|" denotes concatenation 784 DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. 786 The size of the digest may vary depending on the digest algorithm and 787 DNSKEY RR size. As of the time of writing, the only defined digest 788 algorithm is SHA-1, which produces a 20 octet digest. 790 5.2 Processing of DS RRs When Validating Responses 792 The DS RR links the authentication chain across zone boundaries, so 793 the DS RR requires extra care in processing. The DNSKEY RR referred 794 to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST 795 have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC 796 zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in 797 the validation process. 799 5.3 The DS RR Presentation Format 801 The presentation format of the RDATA portion is as follows: 803 The Key Tag field MUST be represented as an unsigned decimal integer. 805 The Algorithm field MUST be represented either as an unsigned decimal 806 integer or as an algorithm mnemonic specified in Appendix A.1. 808 The Digest Type field MUST be represented as an unsigned decimal 809 integer. 811 The Digest MUST be represented as a sequence of case-insensitive 812 hexadecimal digits. Whitespace is allowed within the hexadecimal 813 text. 815 5.4 DS RR Example 817 The following example shows a DNSKEY RR and its corresponding DS RR. 819 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz 820 fwJr1AYtsmx3TGkJaNXVbfi/ 821 2pHm822aJ5iI9BMzNXxeYCmZ 822 DRD99WYwYqUSdjMmmAphXdvx 823 egXd/M5+X7OrzKBaMbCVdFLU 824 Uh6DhweJBjEVv5f2wwjM9Xzc 825 nOf+EPbtG9DMBmADjFDc2w/r 826 ljwvFw== 827 ) ; key id = 60485 829 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 830 98631FAD1A292118 ) 832 The first four text fields specify the name, TTL, Class, and RR type 833 (DS). Value 60485 is the key tag for the corresponding 834 "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm 835 used by this "dskey.example.com." DNSKEY RR. The value 1 is the 836 algorithm used to construct the digest, and the rest of the RDATA 837 text is the digest in hexadecimal. 839 6. Canonical Form and Order of Resource Records 841 This section defines a canonical form for resource records, a 842 canonical ordering of DNS names, and a canonical ordering of resource 843 records within an RRset. A canonical name order is required to 844 construct the NSEC name chain. A canonical RR form and ordering 845 within an RRset are required to construct and verify RRSIG RRs. 847 6.1 Canonical DNS Name Order 849 For purposes of DNS security, owner names are ordered by treating 850 individual labels as unsigned left-justified octet strings. The 851 absence of a octet sorts before a zero value octet, and upper case 852 US-ASCII letters are treated as if they were lower case US-ASCII 853 letters. 855 To compute the canonical ordering of a set of DNS names, start by 856 sorting the names according to their most significant (rightmost) 857 labels. For names in which the most significant label is identical, 858 continue sorting according to their next most significant label, and 859 so forth. 861 For example, the following names are sorted in canonical DNS name 862 order. The most significant label is "example". At this level, 863 "example" sorts first, followed by names ending in "a.example", then 864 names ending "z.example". The names within each level are sorted in 865 the same way. 867 example 868 a.example 869 yljkjljk.a.example 870 Z.a.example 871 zABC.a.EXAMPLE 872 z.example 873 \001.z.example 874 *.z.example 875 \200.z.example 877 6.2 Canonical RR Form 879 For purposes of DNS security, the canonical form of an RR is the wire 880 format of the RR where: 881 1. Every domain name in the RR is fully expanded (no DNS name 882 compression) and fully qualified; 883 2. All uppercase US-ASCII letters in the owner name of the RR are 884 replaced by the corresponding lowercase US-ASCII letters; 886 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, 887 HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, 888 SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in 889 the DNS names contained within the RDATA are replaced by the 890 corresponding lowercase US-ASCII letters; 891 4. If the owner name of the RR is a wildcard name, the owner name is 892 in its original unexpanded form, including the "*" label (no 893 wildcard substitution); and 894 5. The RR's TTL is set to its original value as it appears in the 895 originating authoritative zone or the Original TTL field of the 896 covering RRSIG RR. 898 6.3 Canonical RR Ordering Within An RRset 900 For purposes of DNS security, RRs with the same owner name, class, 901 and type are sorted by treating the RDATA portion of the canonical 902 form of each RR as a left-justified unsigned octet sequence where the 903 absence of an octet sorts before a zero octet. 905 [RFC2181] specifies that an RRset is not allowed to contain duplicate 906 records (multiple RRs with the same owner name, class, type, and 907 RDATA). Therefore, if an implementation detects duplicate RRs when 908 putting the RRset in canonical form, the implementation MUST treat 909 this as a protocol error. If the implementation chooses to handle 910 this protocol error in the spirit of the robustness principle (being 911 liberal in what it accepts), the implementation MUST remove all but 912 one of the duplicate RR(s) for purposes of calculating the canonical 913 form of the RRset. 915 7. IANA Considerations 917 This document introduces no new IANA considerations, because all of 918 the protocol parameters used in this document have already been 919 assigned by previous specifications. However, since the evolution of 920 DNSSEC has been long and somewhat convoluted, this section attempts 921 to describe the current state of the IANA registries and other 922 protocol parameters which are (or once were) related to DNSSEC. 924 Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA 925 considerations. 927 DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to 928 the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS 929 Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, 930 and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. 931 [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted 932 use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction 933 security protocol described in [RFC2931] and the transaction KEY 934 Resource Record described in [RFC2930]. 936 DNS Security Algorithm Numbers: [RFC2535] created an IANA registry 937 for DNSSEC Resource Record Algorithm field numbers, and assigned 938 values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] 939 altered this registry to include flags for each entry regarding 940 its use with the DNS security extensions. Each algorithm entry 941 could refer to an algorithm that can be used for zone signing, 942 transaction security (see [RFC2931]) or both. Values 6-251 are 943 available for assignment by IETF standards action ([RFC3755]). 944 See Appendix A for a full listing of the DNS Security Algorithm 945 Numbers entries at the time of writing and their status of use in 946 DNSSEC. 948 [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and 949 assigned value 0 to reserved and value 1 to SHA-1. 951 KEY Protocol Values: [RFC2535] created an IANA Registry for KEY 952 Protocol Values, but [RFC3445] re-assigned all values other than 3 953 to reserved and closed this IANA registry. The registry remains 954 closed, and all KEY and DNSKEY records are required to have 955 Protocol Octet value of 3. 957 Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA 958 registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, 959 this registry only contains assignments for bit 7 (the ZONE bit) 960 and bit 15 (the Secure Entry Point flag (SEP) bit, see [RFC3757]). 961 As also stated in [RFC3755], bits 0-6 and 8-14 are available for 962 assignment by IETF Standards Action. 964 8. Security Considerations 966 This document describes the format of four DNS resource records used 967 by the DNS security extensions, and presents an algorithm for 968 calculating a key tag for a public key. Other than the items 969 described below, the resource records themselves introduce no 970 security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] 971 and [I-D.ietf-dnsext-dnssec-protocol] for additional security 972 considerations related to the use of these records. 974 The DS record points to a DNSKEY RR using a cryptographic digest, the 975 key algorithm type and a key tag. The DS record is intended to 976 identify an existing DNSKEY RR, but it is theoretically possible for 977 an attacker to generate a DNSKEY that matches all the DS fields. The 978 probability of constructing such a matching DNSKEY depends on the 979 type of digest algorithm in use. The only currently defined digest 980 algorithm is SHA-1, and the working group believes that constructing 981 a public key which would match the algorithm, key tag, and SHA-1 982 digest given in a DS record would be a sufficiently difficult problem 983 that such an attack is not a serious threat at this time. 985 The key tag is used to help select DNSKEY resource records 986 efficiently, but it does not uniquely identify a single DNSKEY 987 resource record. It is possible for two distinct DNSKEY RRs to have 988 the same owner name, the same algorithm type, and the same key tag. 989 An implementation which uses only the key tag to select a DNSKEY RR 990 might select the wrong public key in some circumstances. Please see 991 Appendix B for further details. 993 The table of algorithms in Appendix A and the key tag calculation 994 algorithms in Appendix B include the RSA/MD5 algorithm for 995 completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as 996 explained in [RFC3110]. 998 9. Acknowledgments 1000 This document was created from the input and ideas of the members of 1001 the DNS Extensions Working Group and working group mailing list. The 1002 editors would like to express their thanks for the comments and 1003 suggestions received during the revision of these security extension 1004 specifications. While explicitly listing everyone who has 1005 contributed during the decade during which DNSSEC has been under 1006 development would be an impossible task, 1007 [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the 1008 participants who were kind enough to comment on these documents. 1010 10. References 1012 10.1 Normative References 1014 [I-D.ietf-dnsext-dnssec-intro] 1015 Arends, R., Austein, R., Larson, M., Massey, D. and S. 1016 Rose, "DNS Security Introduction and Requirements", 1017 draft-ietf-dnsext-dnssec-intro-10 (work in progress), May 1018 2004. 1020 [I-D.ietf-dnsext-dnssec-protocol] 1021 Arends, R., Austein, R., Larson, M., Massey, D. and S. 1022 Rose, "Protocol Modifications for the DNS Security 1023 Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in 1024 progress), May 2004. 1026 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1027 STD 13, RFC 1034, November 1987. 1029 [RFC1035] Mockapetris, P., "Domain names - implementation and 1030 specification", STD 13, RFC 1035, November 1987. 1032 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1033 August 1996. 1035 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1036 Requirement Levels", BCP 14, RFC 2119, March 1997. 1038 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 1039 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1040 April 1997. 1042 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1043 Specification", RFC 2181, July 1997. 1045 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1046 NCACHE)", RFC 2308, March 1998. 1048 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 1049 (DNS)", RFC 2536, March 1999. 1051 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 1052 2671, August 1999. 1054 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 1055 SIG(0)s)", RFC 2931, September 2000. 1057 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 1058 Name System (DNS)", RFC 3110, May 2001. 1060 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 1061 Resource Record (RR)", RFC 3445, December 2002. 1063 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1064 Encodings", RFC 3548, July 2003. 1066 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1067 (RR) Types", RFC 3597, September 2003. 1069 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 1070 (RR)", RFC 3658, December 2003. 1072 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 1073 Signer", RFC 3755, April 2004. 1075 [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure 1076 Entry Point Flag", RFC 3757, April 2004. 1078 10.2 Informative References 1080 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1081 RFC 2535, March 1999. 1083 [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name 1084 System (DNS)", RFC 2537, March 1999. 1086 [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the 1087 Domain Name System (DNS)", RFC 2539, March 1999. 1089 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 1090 RR)", RFC 2930, September 2000. 1092 [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) 1093 RDATA Format", RFC 3845, August 2004. 1095 Authors' Addresses 1097 Roy Arends 1098 Telematica Instituut 1099 Drienerlolaan 5 1100 7522 NB Enschede 1101 NL 1103 EMail: roy.arends@telin.nl 1104 Rob Austein 1105 Internet Systems Consortium 1106 950 Charter Street 1107 Redwood City, CA 94063 1108 USA 1110 EMail: sra@isc.org 1112 Matt Larson 1113 VeriSign, Inc. 1114 21345 Ridgetop Circle 1115 Dulles, VA 20166-6503 1116 USA 1118 EMail: mlarson@verisign.com 1120 Dan Massey 1121 USC Information Sciences Institute 1122 3811 N. Fairfax Drive 1123 Arlington, VA 22203 1124 USA 1126 EMail: masseyd@isi.edu 1128 Scott Rose 1129 National Institute for Standards and Technology 1130 100 Bureau Drive 1131 Gaithersburg, MD 20899-8920 1132 USA 1134 EMail: scott.rose@nist.gov 1136 Appendix A. DNSSEC Algorithm and Digest Types 1138 The DNS security extensions are designed to be independent of the 1139 underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS 1140 resource records all use a DNSSEC Algorithm Number to identify the 1141 cryptographic algorithm in use by the resource record. The DS 1142 resource record also specifies a Digest Algorithm Number to identify 1143 the digest algorithm used to construct the DS record. The currently 1144 defined Algorithm and Digest Types are listed below. Additional 1145 Algorithm or Digest Types could be added as advances in cryptography 1146 warrant. 1148 A DNSSEC aware resolver or name server MUST implement all MANDATORY 1149 algorithms. 1151 A.1 DNSSEC Algorithm Types 1153 The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify 1154 the security algorithm being used. These values are stored in the 1155 "Algorithm number" field in the resource record RDATA. 1157 Some algorithms are usable only for zone signing (DNSSEC), some only 1158 for transaction security mechanisms (SIG(0) and TSIG), and some for 1159 both. Those usable for zone signing may appear in DNSKEY, RRSIG, and 1160 DS RRs. Those usable for transaction security would be present in 1161 SIG(0) and KEY RRs as described in [RFC2931] 1163 Zone 1164 Value Algorithm [Mnemonic] Signing References Status 1165 ----- -------------------- --------- ---------- --------- 1166 0 reserved 1167 1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED 1168 2 Diffie-Hellman [DH] n [RFC2539] - 1169 3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL 1170 4 Elliptic Curve [ECC] TBA - 1171 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY 1172 252 Indirect [INDIRECT] n - 1173 253 Private [PRIVATEDNS] y see below OPTIONAL 1174 254 Private [PRIVATEOID] y see below OPTIONAL 1175 255 reserved 1177 6 - 251 Available for assignment by IETF Standards Action. 1179 A.1.1 Private Algorithm Types 1181 Algorithm number 253 is reserved for private use and will never be 1182 assigned to a specific algorithm. The public key area in the DNSKEY 1183 RR and the signature area in the RRSIG RR begin with a wire encoded 1184 domain name, which MUST NOT be compressed. The domain name indicates 1185 the private algorithm to use and the remainder of the public key area 1186 is determined by that algorithm. Entities should only use domain 1187 names they control to designate their private algorithms. 1189 Algorithm number 254 is reserved for private use and will never be 1190 assigned to a specific algorithm. The public key area in the DNSKEY 1191 RR and the signature area in the RRSIG RR begin with an unsigned 1192 length byte followed by a BER encoded Object Identifier (ISO OID) of 1193 that length. The OID indicates the private algorithm in use and the 1194 remainder of the area is whatever is required by that algorithm. 1195 Entities should only use OIDs they control to designate their private 1196 algorithms. 1198 A.2 DNSSEC Digest Types 1200 A "Digest Type" field in the DS resource record types identifies the 1201 cryptographic digest algorithm used by the resource record. The 1202 following table lists the currently defined digest algorithm types. 1204 VALUE Algorithm STATUS 1205 0 Reserved - 1206 1 SHA-1 MANDATORY 1207 2-255 Unassigned - 1209 Appendix B. Key Tag Calculation 1211 The Key Tag field in the RRSIG and DS resource record types provides 1212 a mechanism for selecting a public key efficiently. In most cases, a 1213 combination of owner name, algorithm, and key tag can efficiently 1214 identify a DNSKEY record. Both the RRSIG and DS resource records 1215 have corresponding DNSKEY records. The Key Tag field in the RRSIG 1216 and DS records can be used to help select the corresponding DNSKEY RR 1217 efficiently when more than one candidate DNSKEY RR is available. 1219 However, it is essential to note that the key tag is not a unique 1220 identifier. It is theoretically possible for two distinct DNSKEY RRs 1221 to have the same owner name, the same algorithm, and the same key 1222 tag. The key tag is used to limit the possible candidate keys, but 1223 it does not uniquely identify a DNSKEY record. Implementations MUST 1224 NOT assume that the key tag uniquely identifies a DNSKEY RR. 1226 The key tag is the same for all DNSKEY algorithm types except 1227 algorithm 1 (please see Appendix B.1 for the definition of the key 1228 tag for algorithm 1). The key tag algorithm is the sum of the wire 1229 format of the DNSKEY RDATA broken into 2 octet groups. First the 1230 RDATA (in wire format) is treated as a series of 2 octet groups, 1231 these groups are then added together ignoring any carry bits. 1233 A reference implementation of the key tag algorithm is as an ANSI C 1234 function is given below with the RDATA portion of the DNSKEY RR is 1235 used as input. It is not necessary to use the following reference 1236 code verbatim, but the numerical value of the Key Tag MUST be 1237 identical to what the reference implementation would generate for the 1238 same input. 1240 Please note that the algorithm for calculating the Key Tag is almost 1241 but not completely identical to the familiar ones-complement checksum 1242 used in many other Internet protocols. Key Tags MUST be calculated 1243 using the algorithm described here rather than the ones complement 1244 checksum. 1246 The following ANSI C reference implementation calculates the value of 1247 a Key Tag. This reference implementation applies to all algorithm 1248 types except algorithm 1 (see Appendix B.1). The input is the wire 1249 format of the RDATA portion of the DNSKEY RR. The code is written 1250 for clarity, not efficiency. 1252 /* 1253 * Assumes that int is at least 16 bits. 1254 * First octet of the key tag is the most significant 8 bits of the 1255 * return value; 1256 * Second octet of the key tag is the least significant 8 bits of the 1257 * return value. 1258 */ 1260 unsigned int 1261 keytag ( 1262 unsigned char key[], /* the RDATA part of the DNSKEY RR */ 1263 unsigned int keysize /* the RDLENGTH */ 1264 ) 1265 { 1266 unsigned long ac; /* assumed to be 32 bits or larger */ 1267 int i; /* loop index */ 1269 for ( ac = 0, i = 0; i < keysize; ++i ) 1270 ac += (i & 1) ? key[i] : key[i] << 8; 1271 ac += (ac >> 16) & 0xFFFF; 1272 return ac & 0xFFFF; 1273 } 1275 B.1 Key Tag for Algorithm 1 (RSA/MD5) 1277 The key tag for algorithm 1 (RSA/MD5) is defined differently than the 1278 key tag for all other algorithms, for historical reasons. For a 1279 DNSKEY RR with algorithm 1, the key tag is defined to be the most 1280 significant 16 bits of the least significant 24 bits in the public 1281 key modulus (in other words, the 4th to last and 3rd to last octets 1282 of the public key modulus). 1284 Please note that Algorithm 1 is NOT RECOMMENDED. 1286 Intellectual Property Statement 1288 The IETF takes no position regarding the validity or scope of any 1289 Intellectual Property Rights or other rights that might be claimed to 1290 pertain to the implementation or use of the technology described in 1291 this document or the extent to which any license under such rights 1292 might or might not be available; nor does it represent that it has 1293 made any independent effort to identify any such rights. Information 1294 on the procedures with respect to rights in RFC documents can be 1295 found in BCP 78 and BCP 79. 1297 Copies of IPR disclosures made to the IETF Secretariat and any 1298 assurances of licenses to be made available, or the result of an 1299 attempt made to obtain a general license or permission for the use of 1300 such proprietary rights by implementers or users of this 1301 specification can be obtained from the IETF on-line IPR repository at 1302 http://www.ietf.org/ipr. 1304 The IETF invites any interested party to bring to its attention any 1305 copyrights, patents or patent applications, or other proprietary 1306 rights that may cover technology that may be required to implement 1307 this standard. Please address the information to the IETF at 1308 ietf-ipr@ietf.org. 1310 Disclaimer of Validity 1312 This document and the information contained herein are provided on an 1313 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1314 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1315 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1316 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1317 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1318 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1320 Copyright Statement 1322 Copyright (C) The Internet Society (2004). This document is subject 1323 to the rights, licenses and restrictions contained in BCP 78, and 1324 except as set forth therein, the authors retain all their rights. 1326 Acknowledgment 1328 Funding for the RFC Editor function is currently provided by the 1329 Internet Society.