idnits 2.17.00 (12 Aug 2021) /tmp/idnits24569/draft-ietf-dnsext-dnssec-records-01.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- 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 334 has weird spacing: '... key tag ...' == Line 865 has weird spacing: '...ong int ac;...' == 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 (February 2002) is 7399 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) ** Obsolete normative reference: RFC 2535 (ref. '6') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (ref. '8') (Obsoleted by RFC 6891) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' == Outdated reference: draft-ietf-dnsext-restrict-key-for-dnssec has been published as RFC 3445 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions R. Arends 3 Internet-Draft Nominum 4 Expires: August 2, 2002 M. Larson 5 VeriSign 6 D. Massey 7 USC/ISI 8 S. Rose 9 NIST 10 February 2002 12 Resource Records for DNS Security Extensions 13 draft-ietf-dnsext-dnssec-records-01 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 2, 2002. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). All Rights Reserved. 42 Abstract 44 The DNS Security Extensions (DNSSEC) introduce four resource records: 45 the KEY, DS, SIG, and NXT resource records. This document defines 46 the purpose and the RDATA format for each of these records. This 47 document is part of a family of documents that describe the DNS 48 Security Extensions (DNSSEC). The DNS Security Extensions are a 49 collection of new resource records and protocol modifications that 50 provide source authentication for the DNS. This document obsoletes 51 RFC 2535 and incorporates changes from all updates to RFC 2535. 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [4]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1 DNSSEC Document Family . . . . . . . . . . . . . . . . . . 4 61 2. The Key Resource Record . . . . . . . . . . . . . . . . . 5 62 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 63 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 64 2.1.1.1 Explanation for Choice of Bit 7 . . . . . . . . . . . . . 6 65 2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 6 66 2.1.2.1 Explanation for a Fixed Value Protocol Octet Field . . . . 6 67 2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 6 68 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7 69 2.3 KEY RR Examples . . . . . . . . . . . . . . . . . . . . . 7 70 2.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9 73 3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10 75 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10 76 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10 77 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10 78 3.1.5 Signature Expiration and Inception Fields . . . . . . . . 10 79 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 10 80 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11 81 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11 82 3.2 The NXT RR Presentation Format (placeholder) . . . . . . . 11 83 3.3 Calculating the signature . . . . . . . . . . . . . . . . 11 84 4. The NXT Resource Record . . . . . . . . . . . . . . . . . 13 85 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 13 86 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 13 87 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 13 88 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 14 89 5. The DS Resource Record . . . . . . . . . . . . . . . . . . 15 90 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 91 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 15 92 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 15 93 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 16 94 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 16 95 5.2 DS Record Example . . . . . . . . . . . . . . . . . . . . 16 96 5.3 Resolver Example . . . . . . . . . . . . . . . . . . . . . 16 97 6. DNSSEC message bits . . . . . . . . . . . . . . . . . . . 18 98 6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 18 99 6.2 The DO Extended Flags Field Bit . . . . . . . . . . . . . 18 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 20 101 8. Security Considerations . . . . . . . . . . . . . . . . . 21 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 22 103 References . . . . . . . . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 24 105 A. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 25 106 Full Copyright Statement . . . . . . . . . . . . . . . . . 26 108 1. Introduction 110 The reader to assumed to be familiar with common DNSSEC terminology 111 as defined in [13] and familiar with the basic DNS concepts described 112 in RFC1034 [1] and RFC1035 [2]. 114 The DNS Security Extensions (DNSSEC) introduce four resource records: 115 KEY, DS, SIG, and NXT resource records. This document defines the 116 purpose of each resource record, the RDATA format, the ASCII 117 representation, and an example of each RR type is given. Sections 2- 118 5 describe the KEY, DS, SIG, and NXT records. Section 6 describe the 119 DNSSEC header bits. 121 1.1 DNSSEC Document Family 123 This document is part of a family of documents that define the DNS 124 security extensions. The DNS security extensions (DNSSEC) are a 125 collection of resource records and DNS protocol modifications that 126 add source authentication the Domain Name System (DNS). An 127 introduction to DNSSEC and definition of common terms can be found in 128 (RFC TBA). A description of DNS protocol modifications can be found 129 in (RFC TBA). This document defines the DNSSEC resource records. 131 2. The Key Resource Record 133 Public keys used by the DNS infrastructure are stored in KEY resource 134 records. A secure DNS zone will store its public key in a KEY RR and 135 this KEY RR can be used to authenticate other RR sets in the zone. 136 The KEY RR MAY also be used to store other types of DNS public keys, 137 such as the keys used by SIG(0) [10] or TKEY [9]. These public keys 138 are used to authenticate DNS messages such as a request to 139 dynamically update a DNS zone. 141 The KEY RR MUST only be used for public keys used for DNS purposes, 142 all other uses are obsolete. The KEY RR plays an essential role in 143 the secure processing of DNS messages and is included in various 144 responses. The KEY RR MUST NOT be used to store certificates or 145 public keys that do not directly relate to the DNS infrastructure. 146 Examples of certificates and public keys that MUST NOT be stored in 147 the KEY RR include X.509 certificates, IPSEC public keys, and SSH 148 public keys. 150 The type number for the KEY RR is 25. 152 The KEY RR is class independent. 154 2.1 KEY RDATA Wire Format 156 The RDATA for a KEY RR consists of a 2 octet Flags Fields, a Protocol 157 Octet, a one octet Algorithm number, and the public key. 159 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | flags | protocol | algorithm | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | / 165 / public key / 166 / / 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 169 2.1.1 The Flags Field 171 Bit 7 of the Flags Field is the "zone key flag". Bits 0-6 and 8-15 172 are reserved for future use. Bits 0-6 and 8-15 MUST be set to 0 and 173 MUST be ignored during processing. 175 The zone key flag (bit 7) determines whether the KEY holds a DNS zone 176 key. If bit 7 is 1, then the KEY record holds a DNS zone key. If 177 bit 7 is 0, then the KEY record holds some other type of DNSSEC 178 infrastructure public key, such as a public key used by SIG(0) or 179 TKEY. Resolvers MUST check the zone key flag in order to determine 180 if the KEY record holds a DNS zone key. 182 2.1.1.1 Explanation for Choice of Bit 7 184 The choice of bit 7 as the zone key flag was made in order to provide 185 backwards compatibility with an earlier version of the KEY record. 186 This earlier version was defined in [6] and [15] eliminated all flags 187 except the bit 7 zone key flag. 189 2.1.2 The Protocol Octet Field 191 The Protocol Octet value MUST be 3. 193 2.1.2.1 Explanation for a Fixed Value Protocol Octet Field 195 The Protocol Octet field is included for backwards compatibility with 196 an earlier version of the KEY record. This earlier version of the 197 KEY record was defined in [6] and [15] restricted the possible 198 Protocol Octet values to 3. 200 2.1.3 The Algorithm and Public Key Fields 202 The Algorithm Field identifies the public key's cryptographic 203 algorithm and determines the format of the Public Key Field. 205 Algorithm values are defined in separate documents. The following 206 table shows the currently defined Algorithm formats: 208 VALUE Algorithm RFC STATUS 209 0 Reserved - - 210 1 RSA/MD5 RFC 2536 NOT RECOMMENDED 211 2 Diffie-Hellman RFC 2539 OPTIONAL 212 3 DSA RFC 2536 MANDATORY 213 4 elliptic curve Work in Progress 214 5 RSA/SHA1 RFC 3110 MANDATORY 215 6-251 available for assignment - 216 252 reserved - indirect keys 217 253 private - domain name 218 254 private - OID 219 255 reserved - - 221 It is expected that a signed zone will contain at least one KEY 222 record with one of the MANDATORY algorithms. A DNS security aware 223 resolver MUST implement all MANDATORY and SHOULD implement all 224 OPTIONAL algorithms. Currently RSA/MD5 is NOT RECOMMENDED for zone 225 signing, but it may be found in older DNS implementations. 227 Therefore, if may be useful for a security aware resolver to 228 implement RSA/MD5 as well as RSA/SHA1. 230 Algorithm number 252 is reserved for indirect key format where the 231 actual key material is elsewhere (non-DNS). This format will be 232 defined in a separate document. 234 Algorithm numbers 253 and 254 are reserved for private use and will 235 never be assigned a specific algorithm. For number 253, the public 236 key area and the signature begin with a wire encoded domain name 237 indicating the algorithm the key uses. Only local domain name 238 compression is permitted. The remainder of the public key area is 239 privately defined. For number 254, the public key area for the KEY 240 RR and the signature begin with an unsigned length byte followed by a 241 BER encoded Object Identifier (ISO OID) of that length. The OID 242 indicates the private algorithm in use and the remainder of the area 243 is whatever is required by that algorithm. Entities should only use 244 domain names and OIDs they control to designate their private 245 algorithms. 247 2.2 The KEY RR Presentation Format 249 A KEY RR may appear as a single line. The presentation format of the 250 RDATA portion is as follows: 252 The Flag field is represented as an unsigned integer. 254 The Protocol Octet field is represented as the unsigned integer 3. 256 The Algorithm Field is represented as an unsigned integer or as 257 mnemonic specified. The mnemonic is listed in the document defining 258 the algorithm. 260 The Public Key Field is a Base 64 encoding of the Public Key Field. 262 2.3 KEY RR Examples 264 2.3.1 Example 1 266 The following KEY RR stores a DNS zone key for isi.edu. 268 isi.edu. 86400 IN KEY 256 3 5 ( AQPT0sh3WjVeRY3WqpBjtf 269 270 xxDw==) 272 256 indicates the flags field has the zone key bit is set. 3 is the 273 fixed Protocol Octet value. 5 indicates the public key algorithm is 274 RSA/SHA1 RFC 3110]. The remaining text is base 64 encoding of the 275 public key and the format of the public key is defined in [12]. 277 Resolvers might use this public key to authenticate signed RR sets 278 such as the A RR set for www.isi.edu. The authentication process 279 used by resolvers is described in [14]. 281 2.3.2 Example 2 283 The following KEY RR stores a public key used by SIG(0) 285 ddnskey.isi.edu. 86400 IN KEY 0 3 3 ( AQPT0sh3WjVeRY3WqpBjtf 286 287 xxDw==) 289 0 indicates the flags field does not have the zone key bit is not 290 set. 3 is the fixed Protocol Octet value. 5 indicates the public 291 key algorithm is DSA [7]. The remaining text is base 64 encoding of 292 the public key and the format of the public key is defined in [7]. 294 This public key can be used to sign dynamic DNS updates for the 295 isi.edu zone. The process is for signing the dynamic DNS updates is 296 described in [11]. 298 3. The SIG Resource Record 300 The SIG or "signature" resource record (RR) is the fundamental way 301 that data is authenticated in the secure Domain Name System (DNS). 302 As such it is the heart of the security provided. 304 The SIG RR authenticates an RRset [5] of a particular type, class, 305 and name and binds it to a time interval and the signer's name. The 306 signer is the key (and associated KEY record) from which the RR 307 originated. A SIG record can also be used for transaction security 308 [transaction ref/section]. This type of SIG is known as SIG(0) and 309 its RDATA is in the same format, with some values loosing their 310 meaning and given default values. The variations are mentioned in 311 [10]. 313 The type number for the SIG RR type is 24. 315 The SIG RR is class independent, but MUST have the same class as the 316 RRset it covers. The TTL for the SIG RR SHOULD be the same as the 317 RRset it covers. 319 3.1 The SIG RDATA 321 The RDATA portion of a SIG RR is as shown below: 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 For RRset SIGs, the type covered MUST be the same as the type of data 346 in the associated RRset. For SIG(0), this field MUST be zero [10] 348 3.1.2 The Algorithm Number Field 350 The Algorithm Number field in the RDATA is the same field as found in 351 the algorithm field of the KEY record RDATA [section 2.2.3]. 353 3.1.3 The Labels Field 355 The "labels" octet is an unsigned count of how many labels there are 356 in the original SIG RR owner name. This does not count null labels 357 for root and any initial "*" for a wildcard. The labels count MUST 358 be less than or equal to the number of labels in the SIG owner name. 360 3.1.4 Original TTL Field 362 The "original TTL" field is included in the RDATA portion to avoid 363 authentication problems caused by caching servers decrementing the 364 real TTL field. The signatures covers this field (as part of the SIG 365 RDATA) while the TTL field is not. In a SIG(0), the Original TTL 366 field (and the TTL field) MUST be zero. 368 The "original TTL" value MUST be greater than or equal to the TTL of 369 the SIG record itself. 371 3.1.5 Signature Expiration and Inception Fields 373 The SIG is valid from the "signature inception" time until the 374 "signature expiration" time. Both are unsigned numbers of seconds 375 since the start of 1 January 1970, GMT, ignoring leap seconds. Ring 376 arithmetic is used as for DNS SOA serial numbers [3], which means 377 that these times can never be more than about 68 years in the past or 378 the future. This means that these times are ambiguous modulo ~136.09 379 years. 381 A SIG RR may have an expiration time numerically less than the 382 inception time if the expiration time is near the 32-bit wrap around 383 point and/or the signature is long lived. 385 3.1.6 The Key Tag Field 387 The "Key Tag" is a two-octet quantity that is used to efficiently 388 select between multiple keys that may be applicable. The Key Tag 389 value may differ depending on the key algorithm in use, as described 390 in Appendix (A). 392 3.1.7 The Signer's Name Field 394 The signer's name field MUST contain the name of the zone to which 395 the data and signature belong. The combination of signer's name, key 396 tag, and algorithm MUST identify a zone key if the SIG is to be 397 considered material. In a SIG(0), the signer's name MUST be the 398 originating host of the DNS message [10]. 400 3.1.8 The Signature Field 402 The actual signature portion of the SIG RR binds the other RDATA 403 fields to the RRset of the "type covered" RRs with that owner name 404 and class. 406 3.2 The NXT RR Presentation Format (placeholder) 408 This section will be here in the next revision. 410 3.3 Calculating the signature 412 To generate the signature over an RRset, a data sequence is 413 constructed as follows (where "|" is concatenation): 415 signature = sign(RDATA | RR(1) | RR(2)... ) 417 RR(N) = name | class | type | original TTL(stored in SIG RDATA) | 418 RDATA 420 To generate a signature over a DNS message (SIG(0)), a data sequence 421 is constructed as follows: 423 If the DNS message is sent via UDP: 425 signature = sign(RDATA | full query | full response - SIG(0)) 427 If the DNS message is sent via TCP, the first packet's SIG(0) is 428 calculated as above, with each additional packet (if any) calculated 429 as follows: 431 signature = sign(RDATA | DNS payload - SIG(0) | previous packet) 433 where "previous packet" is the previous DNS packet with accompanying 434 SIG(0), but without any other headers (i.e. TCP/IP, etc.). 436 In all the examples, 438 RDATA is the wire format of all the RDATA fields in the SIG RR itself 439 (including the canonical form of the signer's name) before but not 440 including the signature, and 442 RR(num) is the RRset with the same owner name and class and type 443 covered as the SIG RR in canonical form. 445 Name is the Fully Qualified Domain Name (FQDN) in canonical form. 447 The canonical form for a Resource Record (RR) is the wire format of 448 the RR. Names MUST be expanded (no name compression allowed). Name 449 characters MUST be set to lower case. Wildcards MUST be unexpanded. 450 The RR MUST have the original TTL. 452 How this data sequence is processed into the signature is algorithm 453 dependent. These algorithm dependent formats and procedures are 454 described in separate documents. 456 SIGs SHOULD NOT be generated for any "meta-type" such as ANY, AXFR, 457 etc. 459 4. The NXT Resource Record 461 The collection of NXT or "next" resource records (RR) is used to 462 indicate what names and RRsets [5] exist in a zone. 464 The NXT RR lists the next canonical name in the zone and lists what 465 RR types are present for the current name of the NXT RR. 467 The set of NXT RRs in a zone is a chain of all authoritative names in 468 that zone. 470 Glue address records MUST NOT be covered by a NXT RR. 472 The type number for the NXT RR is 30. 474 The NXT RR is class independent. 476 The NXT RR TTL SHOULD NOT exceed the zone minimum TTL. 478 4.1 NXT RDATA Wire Format 480 The RDATA of the NXT RR is as shown below: 482 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 / next domain name / 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 / type bit map / 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 4.1.1 The Next Domain Name Field 492 The "next domain name" field contains the next owner name in 493 canonical order. Canonical order means sorted by label, highest 494 level label first. The "next domain name" field of the NXT RR at the 495 last name in the zone contains the zone apex name. 497 Glue address record names MUST NOT be covered by the "next domain 498 name" field. 500 The "next domain name" field allows message compression. 502 4.1.2 The Type Bit Map Field 504 The "type bit map" field format contains a single bit per RR type for 505 RRsets with the same owner name as the NXT RR. A one bit indicates 506 that an RRset of that type exist for the owner name. A zero bit 507 indicates that no RRset of that type exist for the owner name. 509 The first bit represents RR type zero. RR type number zero is not 510 assigned and the corresponding bit MUST be zero. If the zero bit is 511 one, it indicates that an unspecified format is used. This format is 512 not used when there exist an RR type number greater than 127. 514 The OPT RR [8] type MUST NOT be covered by the type bit map field 515 since it is not part of the zone data. The corresponding OPT RR type 516 bit (40) MUST be zero. 518 Trailing zero octets MUST be omitted. Trailing zero octets not 519 specified MUST be interpreted as zero octets. Glue address record 520 types MUST NOT be covered by the type bit map field. 522 4.2 The NXT RR Presentation Format 524 A NXT RR may appear as a single line. The presentation format of the 525 RDATA portion is as follows: 527 The "next domain name" field is represented as a domain name. 529 The "type bit map" field is represented as a sequence of RR type 530 mnemonics or as an unsigned integer. 532 5. The DS Resource Record 534 The DS record is a major change to DNS: it is the first resource 535 record that can appear only on the upper side of a delegation. Other 536 keys MAY sign the child's apex KEY RRset. DS records MUST point to 537 zone KEY records that are allowed to authenticate DNS data. 539 The type number for the DS record is 43. 541 The DS record is class independent. 543 5.1 DS RDATA Wire Format 545 This record contains these fields: key tag, algorithm, digest type, 546 and the digest of a public key KEY record that is allowed and/or used 547 to sign the child's apex KEY RRset. 549 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | key tag | algorithm | Digest type | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Digest | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | (20 bytes for SHA-1) | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 560 | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 5.1.1 The Key Tag Field 567 The key tag value is the same key tag value in the SIG RRs generated 568 using the KEY record this DS record points too. Having the key tag 569 in the RDATA provides additional reliability in matching than just 570 the KEY digest alone. See the key tag for details. 572 5.1.2 The Algorithm Field 574 The algorithm value has the same defined values as the KEY and SIG 575 records. The value MUST be an algorithm number assigned in the range 576 1..251 and the algorithm MUST be allowed to sign DNS data. 578 5.1.3 The Digest Type Field 580 The digest type is an identifier for the digest algorithm used. The 581 following numbers have been assigned and the assignment of future 582 numbers requires IETF standards action. 584 VALUE Algorithm STATUS 585 0 Reserved - 586 1 RSA/SHA-1 MANDATORY 587 2-255 Unassigned - 589 5.1.4 The Digest Field 591 The digest is calculated over the canonical name of the delegated 592 domain name followed by the whole RDATA of the KEY record (all four 593 fields). The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, 594 regardless of key size. Other digest algorithms may have a differing 595 digest size, to be described in other documents. 597 digest = hash( cannonical FQDN on KEY RR | KEY_RR_rdata) 599 KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key 601 5.2 DS Record Example 603 The presentation format of the DS record consists of three numbers 604 (key tag, algorithm and digest type) followed by the digest itself 605 presented in hex: 607 example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890 609 This is a example of a KEY record and corresponding DS record. 611 dskey.example. KEY 256 3 1 ( 612 encoded public key 613 ) ; key id = 28668 614 DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE 616 5.3 Resolver Example 618 To create a chain of trust, a resolver goes from trusted KEY to DS to 619 KEY. 621 Assume the key for domain "example." is trusted. Zone "example." 622 contains at least the following records: 623 example. SOA (soa stuff) 624 example. NS ns.example. 625 example. KEY (encoded public key) 626 example. NXT NS SOA KEY SIG NXT 627 example. SIG(SOA) 628 example. SIG(NS) 629 example. SIG(NXT) 630 example. SIG(KEY) 631 secure.example. NS ns1.secure.example. 632 secure.example. DS tag=10243 alg=3 digest_type=1 633 secure.example. NXT NS SIG NXT DS unsecure.example. 634 secure.example. SIG(NXT) 635 secure.example. SIG(DS) 636 unsecure.example NS ns1.unsecure.example. 637 unsecure.example. NXT NS SIG NXT .example. 638 unsecure.example. SIG(NXT) 640 In zone "secure.example." following records exist: 641 secure.example. SOA (soa stuff) 642 secure.example. NS ns1.secure.example. 643 secure.example. KEY (tag=12345 alg=3) 644 secure.example. SIG(KEY) (key-tag=12345 alg=3) 645 secure.example. SIG(SOA) (key-tag=12345 alg=3) 646 secure.example. SIG(NS) (key-tag=12345 alg=5) 648 In this example the private key for "example." signs the DS record 649 for "secure.example.", making that a secure delegation. The DS 650 record states which key is expected to sign the RRsets at 651 "secure.example.". Here "secure.example." signs its KEY RRset with 652 the KEY identified in the DS RRset, thus the KEY RRset is validated 653 and trusted. 655 This example has only one DS record for the child, but parents MUST 656 allow multiple DS records to facilitate key rollover. It is strongly 657 recommended that the DS RRset be kept small: two or three DS records 658 should be sufficient in all cases. 660 The resolver determines the security status of "unsecure.example." by 661 examining the parent zone's NXT record for this name. The absence of 662 the DS bit indicates an unsecure delegation. 664 6. DNSSEC message bits 666 There are 3 new bits allocated for use with DNSSEC. The DO bit is 667 used to indicate to a server that the resolver is able to accept 668 DNSSEC security RRs (KEY SIG NXT DS). The CD and AD bits are used to 669 indicate if non-authenticated data is accepted, and if data is 670 authenticated. 672 6.1 The AD and CD Header Bits 674 Two bits are allocated in the header section. The CD (checking 675 disabled) bit and the AD (authentic data) bit. 677 The Header contains the following fields: 679 1 1 1 1 1 1 680 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 681 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 682 | ID | 683 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 684 |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | 685 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 686 | QDCOUNT | 687 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 688 | ANCOUNT | 689 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 690 | NSCOUNT | 691 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 692 | ARCOUNT | 693 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 695 The usage of the CD and AD bits are defined in [14] 697 6.2 The DO Extended Flags Field Bit 699 The DO (DNSSEC OK) bit is allocated from the EDNS0 [8] extended flags 700 field. In the context of the OPT RR, the DO bit is the most 701 significant bit in the 3rd octet of the TTL field. 703 The TTL field of the OPT RR is defined as follows: 705 1 1 1 1 1 1 706 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 707 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 708 | EXTENDED-RCODE | VERSION | 709 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 710 |DO| Z | 711 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 712 The usage of the DO bit is defined in [14] 714 7. IANA Considerations 716 This document clarifies the use of existing types and introduces no 717 new IANA considerations. 719 The definitions of the flag bits in the KEY RR are set by working 720 group consensus and there is no IANA registry for their definition. 721 Changes to the meaning of the bits in the flags section of the KEY 722 RDATA must be done through working group consensus. 724 RFC 2535 created an IANA registry for DNSSEC Resource Record 725 algorithm Octet values. Values to 1-5, and 255 were assigned and 726 values 6-254 were made available for assignment by IANA. This 727 document re-assigns DNS KEY Resource Record Protocol Octet values 1, 728 2, 4, and 255 to ``reserved''. DNS Key Resource Record Protocol 729 Octet Value 3 remains unchanged as ``DNSSEC''. 731 New protocol values are no longer available for assignment by IANA 732 and this document closes the IANA registry for DNS KEY Resource 733 Record Protocol Octet Values. Assignment of any future KEY Resource 734 Record Protocol Octet values requires a standards action. New 735 numbers for algorithm values will continue to be assigned by IANA. 737 IANA needs to open a new registry for the DS RR type digest 738 algorithms. Defined types are: 0 is Reserved, 1 is SHA-1. Adding 739 new reservations requires IETF standards action. 741 8. Security Considerations 743 This document describes the format of resource records used by DNS 744 security. The threats facing DNS are described in a separate 745 document and these records are used to help counter those threats. 746 The records themselves introduce no new security considerations, but 747 the protocol use of these records is described in a second document. 749 9. Acknowledgements 751 This document was created from the input and ideas of several members 752 of the DNS Extensions Working Group and working group mailing list. 753 The co-authors of this draft would like to express their thanks for 754 the comments and suggestions received during the re-writing of these 755 security extension specifications. 757 References 759 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 760 13, RFC 1034, November 1987. 762 [2] Mockapetris, P., "Domain names - implementation and 763 specification", STD 13, RFC 1035, November 1987. 765 [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 766 August 1996. 768 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 769 Levels", BCP 14, RFC 2119, March 1997. 771 [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 772 RFC 2181, July 1997. 774 [6] Eastlake, D., "Domain Name System Security Extensions", RFC 775 2535, March 1999. 777 [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 778 (DNS)", RFC 2536, March 1999. 780 [8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 781 August 1999. 783 [9] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 784 2930, September 2000. 786 [10] Eastlake, D., "DNS Request and Transaction Signatures ( 787 SIG(0)s)", RFC 2931, September 2000. 789 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 790 Update", RFC 3007, November 2000. 792 [12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 793 System (DNS)", RFC 3110, May 2001. 795 [13] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC Intro", 796 February 2002. 798 [14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC 799 Protocol", February 2002. 801 [15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 802 Record", draft-ietf-dnsext-restrict-key-for-dnssec-01 (work in 803 progress), January 2002. 805 Authors' Addresses 807 Roy Arends 808 Nominum, Inc. 809 2385 Bay Street 810 Redwood City, CA 94063 811 USA 813 EMail: roy.arends@nominum.com 815 Matt Larson 816 VeriSign, Inc. 817 21345 Ridgetop Circle 818 Dulles, VA 20166-6503 819 USA 821 EMail: mlarson@verisign.com 823 Dan Massey 824 USC Information Sciences Institute 825 3811 N. Fairfax Drive 826 Arlington, VA 22203 827 USA 829 EMail: masseyd@isi.edu 831 Scott Rose 832 National Institute for Standards and Technology 833 100 Bureau Drive 834 Gaithersburg, MD 20899-3460 835 USA 837 EMail: scott.rose@nist.gov 839 Appendix A. Key Tag Calculation 841 The key tag field in the SIG RR is just a means of more efficiently 842 selecting the correct KEY RR to use when there is more than one KEY 843 RR candidate available, for example, in verifying a signature. It is 844 possible for more than one candidate key to have the same tag, in 845 which case each must be tried until one works or all fail. The 846 following reference implementation of how to calculate the Key Tag, 847 for all algorithms other than algorithm 1 (which is NOT RECOMMENDED), 848 is in ANSI C. The input is the key material in base 64,not the 849 entire RDATA of the KEY record that contains the public key. It is 850 coded for clarity, not efficiency. 852 /* assumes int is at least 16 bits 853 first byte of the key tag is the most significant byte of return 854 value 855 second byte of the key tag is the least significant byte of 856 return value 857 */ 859 int keytag ( 861 unsigned char key[], /* the RDATA part of the KEY RR */ 862 unsigned int keysize, /* the RDLENGTH */ 863 ) 864 { 865 long int ac; /* assumed to be 32 bits or larger */ 867 for ( ac = 0, i = 0; i < keysize; ++i ) 868 ac += (i&1) ? key[i] : key[i]<<8; 869 ac += (ac>>16) & 0xFFFF; 870 return ac & 0xFFFF; 871 } 873 Full Copyright Statement 875 Copyright (C) The Internet Society (2002). All Rights Reserved. 877 This document and translations of it may be copied and furnished to 878 others, and derivative works that comment on or otherwise explain it 879 or assist in its implementation may be prepared, copied, published 880 and distributed, in whole or in part, without restriction of any 881 kind, provided that the above copyright notice and this paragraph are 882 included on all such copies and derivative works. However, this 883 document itself may not be modified in any way, such as by removing 884 the copyright notice or references to the Internet Society or other 885 Internet organizations, except as needed for the purpose of 886 developing Internet standards in which case the procedures for 887 copyrights defined in the Internet Standards process must be 888 followed, or as required to translate it into languages other than 889 English. 891 The limited permissions granted above are perpetual and will not be 892 revoked by the Internet Society or its successors or assigns. 894 This document and the information contained herein is provided on an 895 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 896 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 897 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 898 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 899 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 901 Acknowledgement 903 Funding for the RFC Editor function is currently provided by the 904 Internet Society.