idnits 2.17.1 draft-ietf-dnsext-dnssec-records-02.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages 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 12 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 4 instances of lines with control characters 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 333 has weird spacing: '... key tag ...' == Line 1043 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 (October 29, 2002) is 7847 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) -- Looks like a reference, but probably isn't: 'DS RFC' on line 795 -- Looks like a reference, but probably isn't: 'KeyRestrict RFC' on line 799 == Unused Reference: '5' is defined on line 857, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 860, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 863, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 875, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 887, but no explicit reference was found in the text ** 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: A later version (-04) exists of draft-ietf-dnsext-restrict-key-for-dnssec-02 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Arends 3 Internet-Draft 4 Expires: April 29, 2003 M. Larson 5 VeriSign 6 D. Massey 7 USC/ISI 8 S. Rose 9 NIST 10 October 29, 2002 12 Resource Records for the DNS Security Extensions 13 draft-ietf-dnsext-dnssec-records-02 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 April 29, 2003. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). All Rights Reserved. 42 Abstract 44 This document is part of a family of documents that describe the DNS 45 Security Extensions (DNSSEC). The DNS Security Extensions are a 46 collection of resource records and protocol modifications that 47 provide source authentication for the DNS. This document defines the 48 KEY, DS, SIG, and NXT resource records. The purpose and format of 49 each resource record is descibed in detail and an example of each 50 resource record is given. 52 This document obsoletes RFC 2535 and incorporates changes from all 53 updates to RFC 2535. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Background and Related Documents . . . . . . . . . . . . . 4 59 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . 4 61 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . 4 62 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . 4 63 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . 5 64 2. The KEY Resource Record . . . . . . . . . . . . . . . . . 6 65 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 66 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 6 67 2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 7 68 2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 7 69 2.1.4 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . 7 70 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7 71 2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . 11 79 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 11 80 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11 81 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11 82 3.2 Calculating A Signature . . . . . . . . . . . . . . . . . 12 83 3.2.1 Calculating An RRset Signature . . . . . . . . . . . . . . 12 84 3.2.2 Calculating An Transaction Signature . . . . . . . . . . . 12 85 3.3 The SIG RR Presentation Format . . . . . . . . . . . . . . 13 86 3.4 Example of a SIG RR . . . . . . . . . . . . . . . . . . . 13 87 4. The NXT Resource Record . . . . . . . . . . . . . . . . . 15 88 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 15 89 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 15 90 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 16 91 4.1.2.1 Alternate Formats for the Type Bit Map Field . . . . . . . 16 92 4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . 16 93 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 16 94 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . 17 95 5. The DS Resource Record . . . . . . . . . . . . . . . . . . 18 96 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18 97 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 18 98 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 19 99 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 19 100 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 19 101 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . 19 102 5.3 DS Record Example . . . . . . . . . . . . . . . . . . . . 20 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 21 104 7. Security Considerations . . . . . . . . . . . . . . . . . 22 105 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23 106 References . . . . . . . . . . . . . . . . . . . . . . . . 24 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 25 108 A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . 26 109 A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 26 110 A.1.1 Indiret and Private Algorithm Types . . . . . . . . . . . 26 111 A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 27 112 B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 28 113 B.1 Key Tag for Algorithm 1 - RSA/MD5 . . . . . . . . . . . . 29 114 C. Canonical Form and Order of Resource Records . . . . . . 30 115 C.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 30 116 C.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 30 117 C.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 31 118 C.4 Canonical Ordering of RR Types . . . . . . . . . . . . . . 31 119 Full Copyright Statement . . . . . . . . . . . . . . . . . 32 121 1. Introduction 123 The DNS Security Extensions (DNSSEC) introduce four resource records: 124 the KEY, SIG, NXT, and DS resource records. This document defines 125 the purpose of each resource record (RR), the RR's RDATA format, and 126 its ASCII representation. An example of each RR type is also given. 128 1.1 Background and Related Documents 130 This document is part of a family of documents that define the DNS 131 security extensions. The DNS security extensions (DNSSEC) are a 132 collection of resource records and DNS protocol modifications that 133 add source authentication the Domain Name System (DNS). An 134 introduction to DNSSEC and definition of common terms can be found in 135 [13]. A description of DNS protocol modifications can be found in 136 [14]. This document defines the DNSSEC resource records. 138 The reader to assumed to be familiar with the basic DNS concepts 139 described in RFC1034 [1] and RFC1035 [2] and should also be familiar 140 with common DNSSEC terminology as defined in [13]. 142 1.2 Reserved Words 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [4]. 148 1.3 Editors Notes 150 1.3.1 Open Technical Issues 152 The NXT section (Section 4) requires input from the working group. 153 Since the opt-in issue is not resolved, this text describes the NXT 154 record as it was defined in RFC 2535. This section may need to be 155 updated, depending on the outcome of the opt-in discussion. 157 The cryptographic algorithm types (Appendix A) requires input from 158 the working group. The DSA algorithm was moved to OPTIONAL. This 159 had strong consensus in workshops and various discussions and a 160 seperate internet draft solely to move DSA from MANDATORY to OPTIONAL 161 seemed excessive. This draft solicts input on that proposed change. 163 The indirect and private algorithms types (Appendix A) are also worth 164 noting. See the text in that section. 166 1.3.2 Technical Changes or Corrections 168 Please report technical corrections to dnssec-editors@east.isi.edu. 170 To assist the editors, please indicate the text in error and point 171 out the RFC that defines the correct behavior. For a technical 172 change where there is no RFC that defines the correct behavior (or 173 RFCs provide conflicting answers), please post the issue to 174 namedroppers. 176 An example correction to dnssec-editors might be: Page X says 177 "DNSSEC RRs SHOULD be automatically returned in responses." This was 178 true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the 179 DNSSEC RR types MUST NOT be included in responses unless the resolver 180 indicated support for DNSSEC. 182 1.3.3 Typos and Minor Corrections 184 Please report any typos corrections to dnssec-editors@east.isi.edu. 185 To assist the editors, please provide enough context for us to 186 quickly find the incorrect text. 188 An example message to dnssec-editors might be: page X says "the 189 DNSSEC standard has been in development for over 1 years". It 190 should read "over 10 years". 192 2. The KEY Resource Record 194 DNSSEC uses public key cryptogrpahy to sign and authenticate DNS 195 resource record sets (RRsets). The public keys are stored in KEY 196 resource records and are used in the DNSSEC authentication process 197 described in [14]. In a typical example, a zone signs its 198 authorititave RRsets using a private key and stores the corresponding 199 public key in a KEY RR. A resolver can then use these signatures to 200 authenticate RRsets from the zone. 202 The KEY RR is also used to store public keys associated with other 203 DNS operations, such as SIG(0) [14] and TKEY [9]. In all cases, the 204 KEY RR plays a special role in secure DNS resolution and DNS message 205 processing. The KEY RR is not intended as a record for storing 206 arbitrary public keys. The KEY RR MUST NOT be used to store 207 certificates or public keys that do not directly relate to the DNS 208 infrastructure. Examples of certificates and public keys that MUST 209 NOT be stored in the KEY RR include X.509 certificates, IPSEC public 210 keys, and SSH public keys. 212 The type number for the KEY RR is 25. 214 The KEY RR is class independent. 216 There are no special TTL requirements on the KEY record. DNSSEC best 217 practices documents are encouraged to provide TTL recommendations. 219 2.1 KEY RDATA Wire Format 221 The RDATA for a KEY RR consists of a 2 octet Flags Fields, a Protocol 222 Octet, a one octet Algorithm Number, and the Public Key. 224 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Flags | Protocol | Algorithm | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | / 230 / Public Key / 231 / / 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 234 2.1.1 The Flags Field 236 Bit 7 of the Flags field is the Zone Key flag. If bit 7 is 1, then 237 the KEY record holds a DNS zone key and the KEY's owner name MUST be 238 the name of a zone. If bit 7 is 0, then the KEY record holds some 239 other type of DNS public key, such as a public key used by SIG(0) or 240 TKEY. 242 Bits 0-6 and 8-15 are reserved for future use and MUST be zero. 244 2.1.2 The Protocol Octet Field 246 The Protocol Octet field MUST be 3. 248 2.1.3 The Algorithm and Public Key Fields 250 The Algorithm field identifies the public key's cryptographic 251 algorithm and determines the format of the Public Key field. A list 252 of DNSSEC algorithm types can be found in Appendix A.1 254 2.1.4 Notes on KEY RDATA Design 256 Although the Protocol Octet field is always 3, it is retained for 257 backwards compatibility with an earlier version of the KEY record. 258 The use of bit 7 as the Zone Key Flag is also due to backwards 259 compatiblity issues. 261 2.2 The KEY RR Presentation Format 263 A KEY RR may appear as a single line or multiple lines separated with 264 newline characters if those lines are contained with parantheses. 265 The presentation format of the RDATA portion is as follows: 267 The Flag field is represented as an unsigned integer. 269 The Protocol Octet field is represented as the unsigned integer 3. 271 The Algorithm field is represented as an unsigned integer or as an 272 algorithm mnemonic specified in Appendix A.1. 274 The Public Key field is a Base 64 encoding of the Public Key Field. 276 2.3 KEY RR Example 278 The following KEY RR stores a DNS zone key for isi.edu. 280 isi.edu. 86400 IN KEY 256 3 5 ( AQPT0sh3WjVeRY3WqpBjtf 281 282 xxDw==) 284 The first four fields specify the owner name, TTL, Class, and RR type 285 (KEY). 256 indicates the Flags field has the zone key bit is set. 3 286 is the fixed Protocol Octet value. 5 indicates the public key 287 algorithm. Appendix A.1 identifies algorithm type 5 as RSA/SHA1 and 288 indicates that the format of the RSA/SHA1 public key field is defined 289 in [12]. The remaining text is a base 64 encoding of the public key. 291 3. The SIG Resource Record 293 DNSSEC uses public key cryptogrpahy to sign and authenticate DNS 294 resource record sets (RRsets). The signatures are stored in SIG 295 resource records and are used in the DNSSEC authentication process 296 described in [14]. In a typical example, a zone signs its 297 authorititave RRsets using a private key and stores the corresponding 298 signatures in SIG RRs. A resolver can then use these signatures to 299 authenticate RRsets from the zone. 301 A SIG record contains the signature for an RRset with a particular 302 name, class, and type. The SIG RR is said to "cover" this RRset. 303 The SIG RR also specifies a validity interval for the signature and 304 uses an algorithm signer's name, and key tag to identify the public 305 key (KEY record) that can be used to verify the signature. 307 The signature in SIG RR may also cover a transaction rather than an 308 RRset [14]. In this case, the "Type Covered" field is set to 0 and 309 the SIG RR is refered to as SIG(0) resource record. 311 The type number for the SIG RR type is 24. 313 The SIG RR is class independent, but MUST have the same class as the 314 RRset it covers. 316 The SIG RR TTL SHOULD match the TTL of the RRset it covers. 318 3.1 The SIG RDATA 320 The RDATA portion of a SIG RR is shown below: 322 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | type covered | algorithm | labels | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | original TTL | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | signature expiration | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | signature inception | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | key tag | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + 335 | / 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 337 / / 338 / signature / 339 / / 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 3.1.1 The Type Covered Field 344 The Type Covered field identifies the RRset type covered by the SIG 345 record. 347 If Type Covered field is set to 0, the record is referred to as a 348 SIG(0) RR and its signature covers a transaction rather than a 349 specific RRset. [14] descirbes how to sign transactions using SIG(0) 350 resource records. 352 3.1.2 The Algorithm Number Field 354 The Algorithm Number field identies the cryptographic algorithm used 355 to create the signature. A list of DNSSEC algorithm types can be 356 found in Appendix A.1 358 3.1.3 The Labels Field 360 The Labels field specifies the number of labels in the original SIG 361 RR owner name. It is included to handle signatures associated with 362 wildcard owner names. 364 To validate the signature, a resolver requires the original owner 365 name that was used when the signature was created. In most cases, 366 the owner name used when the signature was created is identical to 367 the owner name sent in any response. However, a wildcard owner name 368 will be expanded during the query/response process and [14] describes 369 how the label count is used to reconstruct the original (unexpanded) 370 owner name. 372 The Labels field does not count null labels for root and does not 373 count any initial "*" in a wildcard name. The Labels field MUST be 374 less than or equal to the number of labels in the SIG owner name. 375 For example, "www.example.com." has a label count of 3 and 376 "*.example.com." has a label count of 2. 378 3.1.4 Original TTL Field 380 The Original TTL field specifies the original TTL of the covered 381 RRset. 383 To validate the signature, a resolver requires the original TTL used 384 when the signature was created. However, caching servers will 385 decrement the TTL and [14] describes how the Original TTL field count 386 is used to reconstruct the original (undecremented) TTL. 388 If the Type Covered field is non-zero, the Original TTL value MUST be 389 greater than or equal to the TTL of the SIG record itself. If the 390 Type Covered field is 0 (i.e. a SIG(0) RR), the Original TTL field 391 SHOULD be zero. 393 3.1.5 Signature Expiration and Inception Fields 395 The Signature Inception and Signature Expiration fields specify a 396 validity period for the signature. The SIG record MUST NOT be used 397 for authentication prior to the inception date and MUST NOT be used 398 for authentication after the expiratiation date. 400 Inception and expiration dates are given as 32-bit unsigned numbers 401 of seconds since the start of 1 January 1970 GMT, ignoring leap 402 seconds. Ring arithmetic [3] to handle 32-bit wrap around. As 403 result, these times can never be more than 68 years in the past or 404 the future and the times are ambiguous modulo ~136 years. A SIG RR 405 can have an expiration time numerically smaller than the inception 406 time if the expiration time is near the 32-bit wrap around point and/ 407 or the signature is long lived. 409 3.1.6 The Key Tag Field 411 The Key Tag field contains the key tag of the public key (KEY RR) 412 used to authenticate this signature. The process of calculating a 413 key tag is given in Appendix B. 415 3.1.7 The Signer's Name Field 417 The Signer's Name field identifies the name of the KEY RR used to 418 authenticate this signature. If the Type Covered field is non-zero, 419 the Signer's Name MUST contain the name of the zone containing the 420 covered RRset and the SIG. The signer's name MAY be compressed with 421 standard DNS name compression when being transmitted over the 422 network. 424 If the Type Covered field is 0 (i.e. a SIG(0) RR), the signer's name 425 MUST be the name of the host originating the DNS message as described 426 in [10]. 428 3.1.8 The Signature Field 430 The Signature field contains the cryptographic signature. If the 431 Type Covered field is non-zero, the signature covers the SIG RDATA 432 (excluding the Signature field) and the RRset specified by the SIG 433 owner name, SIG class, and SIG Type Covered field. 435 3.2 Calculating A Signature 437 A signature covers either an RRset or a transaction. RRset 438 signatures and transaction signatures are distinguished by the Type 439 Covered field. RRset signatures have a non-zero Type Covered field. 440 SIG RRs SHOULD NOT be generated for any "meta-type" such as ANY or 441 AXFR. 443 3.2.1 Calculating An RRset Signature 445 A signature covers the SIG RDATA (excluding the Signature Field 446 itself) and covers the RRset specified by the SIG owner name, SIG 447 class, and SIG Type Covered field. The RRset is in cannonical form 448 (see Appendix C) and the set RR(1),...RR(n) is signed as follows: 450 signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where 452 "|" denotes append 454 SIG_RDATA is the wire format of the SIG RDATA fields with 455 the Signer's Name field in cannonical form. 456 the Signature field excluded. 458 RR(i) = fqdn | class | type | TTL | RDATA length | RDATA 460 fqdn is the Fully Qualified Domain Name in canonical 461 form. 463 All RR(i) MUST have the same fqdn as the SIG RR. 465 All RR(i) MUST have the same class as the SIG RR. 467 All RR(i) MUST have the RR type listed in SIG RR's 468 Type Covered field. 470 All RR(i) MUST have the TTL listed in the SIG Original 471 TTL Field 473 All names in the RDATA field are in canonical form 475 The set of all RR(i) is sorted into cannonical order. 477 3.2.2 Calculating An Transaction Signature 478 3.3 The SIG RR Presentation Format 480 A SIG RR may appear as a single logical line. The presentation 481 format of the RDATA portion is as follows: 483 The Type Covered field is represented by either an unsigned integer 484 or the mnemonic for the RR type. 486 The Algorithm field is represented as an unsigned integer or as an 487 algorithm mnemonic specified in Appendix A.1. 489 The Labels field is represented as an unsigned integer. 491 The Original TTL field is represented as an unsigned integer. It MAY 492 be omitted if it is equal the TTL of the SIG RR. 494 The Signature Inception Time and Expiration Time fields are 495 represented in the form YYYYMMDDHHmmSS, where: 497 YYYY is the year 499 MM is the month number (01-12) 501 DD is the day of the month (01-31) 503 HH is the hour in 24 hours notation (00-23) 505 mm is the minute (00-59) 507 SS is the second (00-59) 509 The Key Tag field is represented as an unsigned integer. 511 The Signer's Name field is represented as a domain name. 513 The Signature field is a Base 64 encoding of the signature. 515 3.4 Example of a SIG RR 517 The following a SIG RR stores the signature for the the A RRset of 518 host.example.com: 520 host.example.com. 30 IN SIG A 3 3 30 20011231120000 ( 521 20011108100000 65531 example.com 522 CGr0uS55C4l/2RRc2NrMJbRt4oP+xVxwgMkC 523 rJFXXDsybfEDdwoajAY= ) 525 The first four fields specify the owner name, TTL, Class, and RR type 526 (SIG). The "A" represents the Type Covered field. is the algorithm 527 used to create this signature. The first 3 identifies the Algorithm 528 used to create the signature. The second 3 is the number of Labels 529 in the original owner name and the 30 is the Original TTL for this 530 SIG RR and the covered A RRset. The two dates are the expiration and 531 inception dates. 65531 is the Key Tag and example.com. is the 532 Signer's Name. The remaining text is a base 64 encoding of the 533 signature. 535 Note that combination of SIG RR owner name, class, and and Type 536 Covered indicate this SIG covers the "host.example.com" A RRset. The 537 Label value of 3 indicates no wildcard expansion was used. The 538 Algorithm, Signer's Name, and Key Tag indicate this signature can be 539 authenticated using an example.com zone KEY RR whose algorithm is 3 540 and key tag is 65531. 542 4. The NXT Resource Record 544 The NXT resource record lists the RR types present at the NXT's owner 545 name and lists the next canonical name in the zone. The collection 546 of NXT or "next" resource records indicate what RRsets exist in a 547 zone and provide a chain of all authoritative owner names in that 548 zone. This information can be used for authenticated denial of 549 existence, as desribed in [14]. 551 Note that although a zone may contain non-authoritiative glue address 552 records, these non-authoritative glue records MUST NOT be used when 553 contructing the NXT resource record chain. 555 The type number for the NXT RR is 30. 557 The NXT RR is class independent. 559 The NXT RR TTL SHOULD NOT exceed the minimum TTL in the zone's SOA 560 RR. 562 4.1 NXT RDATA Wire Format 564 The RDATA of the NXT RR is as shown below: 566 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 / next domain name / 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 / type bit map / 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 4.1.1 The Next Domain Name Field 576 The Next Domain Name field contains the next authoritive owner name 577 in canonical order, where canonical order is defined in Appendix C.1. 578 For the last owner name in the zone, the Next Domain Name field 579 contains the zone apex name. 581 The Next Domain Name field allows message compression. 583 Note that non-authoritative glue address record names may exist in a 584 zone, but these non-authoritative glue records MUST NOT be listed in 585 the Next Domain Name. Any non-authoritative glue records are ignored 586 (treated as though they were never present) when constructing an NXT. 588 4.1.2 The Type Bit Map Field 590 The Type Bit Map field identifies the RRset types that exist at the 591 NXT's owner name. 593 Each bit in the Type Bit Map field corresponds to an RR type. Bit 594 one corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 595 (NS), and so forth. If a bit is set to 1, it indicates that an RRset 596 of that type exists for the NXT's owner name. If a bit is set to 597 zero, it indicates that no RRset of that type exists for the NXT's 598 owner name. 600 Trailing zero octets MUST be omitted. Thus the length of the Type 601 Bit Map field varies and is dependent on the largest RR type present 602 for the NXT's owner name. Trailing zero octets not specified MUST be 603 interpreted as zero octets. 605 Non-authoritative glue address record types MUST NOT be used when 606 constructing the type bit map field. The OPT RR [8] type (41) also 607 MUST NOT be used when constructing the type bit map field since it is 608 not part of the zone data. In other words, the OPT RR type bit (bit 609 41) MUST be zero. 611 4.1.2.1 Alternate Formats for the Type Bit Map Field 613 The above Type Bit Map format MUST NOT be used when an RR type number 614 greater than 127 is in use. 616 Bit 0 in the Type Bit Map Field is used to indicate an alternate 617 format for the Type Bit Map field. If bit 0 is set to 1, it 618 indicates some other format is being used for this field. No 619 alternate formats are defined as of this writing. 621 4.1.3 Inclusion of Wildcard Names in NXT RDATA 623 If a wildcard owner name appears in a zone, the wildcard is treated 624 as a literal symbol and is treated the same as any other owner name. 625 Wildcard owner names appear (unexpanded) in the Next Domain Name 626 field without any wildcard expansion. [14] describes the impact of 627 wildcards on authetnicated denial of existence. 629 4.2 The NXT RR Presentation Format 631 A NXT RR may appear as a single line. The presentation format of the 632 RDATA portion is as follows: 634 The Next Domain Name field is represented as a domain name. 636 The Type Bit Map field is represented as a sequence of RR type 637 mnemonics or as a sequence of unsigned integers denoting the RR 638 types. 640 4.3 NXT RR Example 642 The following NXT RR identifies the RRsets associated with 643 a.example.com and identifies the next authoritative name after 644 a.example.com. 646 a.example.com. 86400 IN NXT c.example.com. A MX NXT 648 The first four fields specify the name, TTL, Class, and RR type 649 (NXT). The entry c.example.com is the next authoritative name after 650 a.example.com (in cannonical order). The A MX and NXT nnemonics 651 indicate there are A, MX, and NXT RRsets associated with the name 652 a.example.com. 654 Note the NXT record can be used for authenticted denial of existence. 655 If the example NXT record were authenticed, it could be used to prove 656 that b.example.com does not exist or could be used to prove there is 657 no AAAA record assoicated with a.example.com. Authenticated denial 658 of existence is discussed in [14] 660 5. The DS Resource Record 662 The DS Resource Record points to a KEY RR and is used in the DNS KEY 663 authentication process. A DS RR points to a KEY RR by storing the 664 key tag, algorithm number, and a digest of KEY RR. Note that while 665 the digest should be sufficient to identify key, storing the key tag 666 and key algorithm helps make the identification process more 667 efficient and more secure. By authenticating the DS record, a 668 resolver can authenticate the KEY RR pointed to by the DS record. 669 The key authentication proces is described in [14]. 671 The DS RR and its corresponding KEY RR both have the same owner name, 672 but they are stored in different locations. The DS RR is the first 673 resource record that appears only on the upper side of a delegation. 674 In other words, the DS RR for "example.com" is stored in "com" (the 675 upper side of the delegation). The corresponding KEY RR is stored in 676 the "example.com" zone (the lower side of the delegation). This 677 simplifies DNS zone management and zone signing, but introduces 678 special response processing requirements that are described in [14]. 680 The type number for the DS record is 43. 682 The DS resource record is class independent. 684 There are no special TTL requirements on the DS resource record. 685 DNSSEC best practices documents are encouraged to provide TTL 686 recommendations. 688 5.1 DS RDATA Wire Format 690 The RDATA for a DS RR consists of 2 octet Key Tag, a one octet 691 Algorithm Number, a one octet Digest Type, and a Digest. 693 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | key tag | algorithm | Digest type | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Digest / 699 / / 700 / / 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 5.1.1 The Key Tag Field 705 The Key Tag field lists the key tag of the KEY RR pointed to by the 706 DS record. The KEY RR MUST be a a zone key. In other words, the KEY 707 RR Flags must have Flags bit 7 set to 1. 709 The key tag used by the DS RR is identical to the key tag used by the 710 SIG RR and Appendix B describes how to compute a key tag. 712 5.1.2 The Algorithm Field 714 The Algorithm field lists the algorithm number of the KEY RR pointed 715 to by the DS record. 717 The algorithm number used by the DS RR is identical to the algorithm 718 number used by the SIG RR and KEY RR. Appendix A.1 lists the 719 algorithm number types. 721 5.1.3 The Digest Type Field 723 The DS RR points to a KEY RR by including a digest of that KEY RR. 724 The Digest Type field identifes the algorithm used to construct the 725 digest and Appendix A.2 lists the possible digest algorithm types. 727 5.1.4 The Digest Field 729 The DS record points to a KEY RR by including a digest of that KEY 730 RR. The Digest field hold the digest. 732 For a given KEY RR, the digest is calculated by appending the KEY 733 RR's cannonical fully qualified owner name with the KEY RDATA and 734 then applying the digest algorithm. 736 digest = digest_algorithm( cannonical FQDN of KEY RR | KEY_RR_rdata) 738 "|" denotes append 740 KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key 742 The size of the digest can vary depending on the digest algorithm and 743 KEY RR size. However, the only currently defined digest algorithm is 744 SHA-1 and it always produces a 24 byte digest regardless of KEY RR 745 size. 747 5.2 The DS RR Presentation Format 749 A DS RR may appear as a single line or multiple lines separated with 750 newline characters if those lines are contained within parantheses. 751 The presentation format of the RDATA portion is as follows: 753 The Key Tag field is represented as an unsigned integer. 755 The Algorithm field is represented as an unsigned integer or as an 756 algorithm mnemonic specified in Appendix A.1. 758 The Digest Type field is represented as an unsigned integer. 760 The Digest is presented in hexadecimal. 762 5.3 DS Record Example 764 The following example shows a KEY RR and its corresponding DS RR. 766 dskey.example. 86400 IN KEY 256 3 1 ( AQPwHb4UL1U9RHaU8qP+Ts5bVOU 767 1s7fYbj2b3CCbzNdj4+/ECd18yKiy 768 UQqKqQFWW5T3iVc8SJOKnueJHt/Jb 769 /wt) ; key tag = 28668 770 dskey.example. 3600 IN DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE 772 The first four fields specify the name, TTL, Class, and RR type (DS). 773 28668 is the key tag for the corresponding "dskey.example." KEY RR 774 and 1 algorithm used by this "dskey.example." KEY RR. The second 1 775 is the algorithm used to construct the digest and the final string is 776 the digest in hex. 778 6. IANA Considerations 780 This document introduces no new IANA considerations. 782 This document only clarifies the use of existing DNS resource 783 records. However for completeness, the IANA considerations from 784 these previous documents are summarized below. No IANA changes are 785 made by this document. 787 RFC 2535 updated the IANA registry for DNS Resource Record Types and 788 assigned types 24,25, and 30 to the SIG, KEY, and NXT (respectively). 789 [DS RFC] assigned DNS Resource Record Type 43 to DS. 791 RFC 2535 created an IANA registry for DNSSEC Resource Record 792 Algorithm Numbers. Values to 1-4, and 252-255 were assigned by RFC 793 2535. Value 5 was assigned by RFC 3110. 795 [DS RFC] created an IANA registry for DNSSEC DS Digest Types and 796 assigned value 0 to reserved and value 1 to RSA/SHA-1. 798 RFC 2535 created an IANA Registry to KEY Protocol Octet Values, but 799 [KeyRestrict RFC] set all assigned values other than 3 to reserved 800 and closed this IANA registry. The registry remains closed and all 801 KEY records are required to have Protocol Octet value of 3. 803 The Flag bits in the KEY RR are not assigned by IANA and there is no 804 IANA registry for these flags. All changes to the meaning of the KEY 805 RR Flag bits require a standards action. 807 7. Security Considerations 809 This document describes the format of four DNS resource records used 810 by the DNS security extensions and presents an algorithm for 811 calculating a key tag for a public key. Other than the items 812 desribed below, the resource records themselves introduce no security 813 considerations. The use of these records is specified in a seperate 814 document and security considerations related to the use these 815 resource records are discussed in that document. 817 The DS record points to a KEY RR using a cryptographic digest, the 818 key algorithm type and a key tag. The DS record is intended to 819 identify an existing KEY RR, but it is theoretically possibile for an 820 attacker to generate a KEY that matches all the DS fields. The 821 probability of constructing such a matching KEY depends on the type 822 of digest algorithm in use and the only currently defined digest 823 algorithm is SHA1. It is considered very difficult to constuct a 824 public key that matches the algorithm, key tag, and SHA1 digest given 825 in a DS record. 827 The key tag is used to help efficiently select KEY resource records, 828 but it does not uniquely identify a KEY resource record. It is 829 possible that two distinct KEY RRs could have the same owner name, 830 same algorithm type and same key tag. An implementation that used 831 only the key tag to select a KEY RR may select the wrong public key 832 for a given scenario. Implementations MUST NOT assume the key tag is 833 unique public key identifier and this is clearly stated in the text. 835 8. Acknowledgements 837 This document was created from the input and ideas of several members 838 of the DNS Extensions Working Group and working group mailing list. 839 The co-authors of this draft would like to express their thanks for 840 the comments and suggestions received during the revision of these 841 security extension specifications. 843 References 845 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 846 13, RFC 1034, November 1987. 848 [2] Mockapetris, P., "Domain names - implementation and 849 specification", STD 13, RFC 1035, November 1987. 851 [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 852 August 1996. 854 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 855 Levels", BCP 14, RFC 2119, March 1997. 857 [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 858 RFC 2181, July 1997. 860 [6] Eastlake, D., "Domain Name System Security Extensions", RFC 861 2535, March 1999. 863 [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 864 (DNS)", RFC 2536, March 1999. 866 [8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 867 August 1999. 869 [9] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 870 2930, September 2000. 872 [10] Eastlake, D., "DNS Request and Transaction Signatures ( 873 SIG(0)s)", RFC 2931, September 2000. 875 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 876 Update", RFC 3007, November 2000. 878 [12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 879 System (DNS)", RFC 3110, May 2001. 881 [13] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC Intro", 882 October 2002. 884 [14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC 885 Protocol", October 2002. 887 [15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 888 Record", draft-ietf-dnsext-restrict-key-for-dnssec-02 (work in 889 progress), March 2002. 891 Authors' Addresses 893 Roy Arends 894 Bankastraat 41-E 895 1094 EB Amsterdam 896 NL 898 EMail: roy@logmess.com 900 Matt Larson 901 VeriSign, Inc. 902 21345 Ridgetop Circle 903 Dulles, VA 20166-6503 904 USA 906 EMail: mlarson@verisign.com 908 Dan Massey 909 USC Information Sciences Institute 910 3811 N. Fairfax Drive 911 Arlington, VA 22203 912 USA 914 EMail: masseyd@isi.edu 916 Scott Rose 917 National Institute for Standards and Technology 918 100 Bureau Drive 919 Gaithersburg, MD 20899-8920 920 USA 922 EMail: scott.rose@nist.gov 924 Appendix A. DNSSEC Algorithm and Digest Types 926 The DNS security exstentions are designed to be independent of the 927 underlying cryptographic algorithms. The KEY, SIG, and DS resource 928 records all use a DNSSEC Algorithm Number to identify the 929 crytographic algorithm in use by the resource record. The DS 930 resource record also specifies a Digest Algorithm Number to identify 931 the digest algorithm used to construct the DS record. The currently 932 defined Algorithm and Digest Types are listed below. Additional 933 Algorithm or Digest Types could be added as advances in cryptography 934 warrant. 936 A DNSSEC aware resolver or name server MUST implement all MANDATORY 937 algorithms. 939 A.1 DNSSEC Algorithm Types 941 An "Algorithm Number" field in the KEY, SIG, and DS resource record 942 types identifies the cryptographic algorithm used by the resource 943 record. Algorithm specific formats are described in separate 944 documents. The following table lists the currently defined algorithm 945 types and provides references to their supporting documents: 947 VALUE Algorithm RFC STATUS 948 0 Reserved - - 949 1 RSA/MD5 RFC 2537 NOT RECOMMENDED 950 2 Diffie-Hellman RFC 2539 OPTIONAL 951 3 DSA RFC 2536 OPTIONAL 952 4 elliptic curve TBA OPTIONAL 953 5 RSA/SHA1 RFC 3110 MANDATORY 954 6-251 available for assignment - 955 252 indirect see below OPTIONAL 956 253 private see below OPTIONAL 957 254 private see below OPTIONAL 958 255 reserved - - 960 A.1.1 Indiret and Private Algorithm Types 962 RFC 2535 describes Algorithm number 252 as an indirect key format 963 where the actual key material is elsewhere. This format was to be 964 defined in a separate document. In the years between RFC 2535 and 965 this document, no indirect key document has been prodcued. 967 Algorithm number 253 is reserved for private use and will never be 968 assigned to a specific algorithm. The public key area in the KEY RR 969 and the signature area in the SIG RR begin with a wire encoded domain 970 name. Only local domain name compression is permitted. The domain 971 name indicates the private algorithm to use and the remainder of the 972 public key area is determined by that algorithm. Entities should 973 only use domain names they control to designate their private 974 algorithms. 976 Algorithm number 254 is reserved for private use and will never be 977 assigned to a specific algorithm. The public key area in the KEY RR 978 and the signature area in the SIG RR begin with an unsigned length 979 byte followed by a BER encoded Object Identifier (ISO OID) of that 980 length. The OID indicates the private algorithm in use and the 981 remainder of the area is whatever is required by that algorithm. 982 Entities should only use OIDs they control to designate their private 983 algorithms. 985 Editors Note: There is currently no use of or operational experience 986 with these algorithms. The editors (at least Dan!) recommend that 987 these algorithm types be eliminated. We don't need this in the base 988 spec and every other algorithm type requires a seperate document to 989 describe it in detail. Note eliminating these from the base spec 990 would not elminate any future functionality since there are 200+ 991 available algorithm numbers. Anyone who feels they need this type of 992 algorithm (or a similar algorithm) can write the document clearly 993 describing it. 995 A.2 DNSSEC Digest Types 997 A "Digest Type" field in the DS resource record types identifies the 998 cryptographic digest algorithm used by the resource record. The 999 following table lists the currently defined digest algorithm types. 1001 VALUE Algorithm STATUS 1002 0 Reserved - 1003 1 RSA/SHA-1 MANDATORY 1004 2-255 Unassigned - 1006 Appendix B. Key Tag Calculation 1008 The key tag field provides a mechanism for efficiently selecting a 1009 public key. In most cases, a combination of owner name, algorithm, 1010 and key tag can efficiently identify a KEY record. For example, 1011 both the SIG and DS resource records have corresponding KEY records. 1012 A Key Tag field in the SIG and DS records can be used to help 1013 efficiently select the corresponding KEY RR when there is more than 1014 one candidate KEY RR available. 1016 However, it is essential to note that the key tag is not a unique 1017 identifier. It is theoretically possible for two distinct KEY RRs to 1018 have the same owner name, same algorithm, and same key tag. The key 1019 tag is used to efficiently limit the possible candidate keys but it 1020 does not uniquely identify a KEY record. Implementations MUST NOT 1021 assume the key tag uniquely idenifies a KEY RR. 1023 The following ANSI C reference implementation is provided for 1024 calculating a Key Tag. This reference implementation applies to all 1025 algorithm types except algorithm 1 (see Appendix B.1). The input is 1026 the public key material in base 64, not the entire RDATA of the KEY 1027 record that contains the public key. The code is written for 1028 clarity, not efficiency. 1030 /* assumes int is at least 16 bits 1031 first byte of the key tag is the most significant byte of return 1032 value 1033 second byte of the key tag is the least significant byte of 1034 return value 1035 */ 1037 int keytag ( 1039 unsigned char key[], /* the RDATA part of the KEY RR */ 1040 unsigned int keysize, /* the RDLENGTH */ 1041 ) 1042 { 1043 long int ac; /* assumed to be 32 bits or larger */ 1045 for ( ac = 0, i = 0; i < keysize; ++i ) 1046 ac += (i&1) ? key[i] : key[i]<<8; 1047 ac += (ac>>16) & 0xFFFF; 1048 return ac & 0xFFFF; 1049 } 1051 B.1 Key Tag for Algorithm 1 - RSA/MD5 1053 Algorithm 1 - RSA/MD5 key tag is the only algoritm that does not use 1054 the key tag defined above. For a KEY RR with algorithm 1, the key 1055 tag is the most signifigant 16 bits of the least signifigant 24 bits 1056 in the public key modulus. In others, the 4th to last and 3rd to 1057 last octets in the key modulus. Note that Algorithm 1 is NOT 1058 RECOMMENDED. 1060 Appendix C. Canonical Form and Order of Resource Records 1062 This section defines a canonical form for resource records (RRs) and 1063 defines a name order and overall order. A canonical name order is 1064 required to construct the NXT name chain. A canonical RR form and 1065 ordering within an RRset is required to construct and verify SIG RRs. 1067 C.1 Canonical DNS Name Order 1069 For purposes of DNS security, owner names are sorted by treating 1070 individual labels as unsigned left justified octet strings. The 1071 absence of a octet sorts before a zero value octet and upper case 1072 letters are treated as lower case letters. 1074 To sort names in a zone, first sort all names based on only the 1075 highest level label. Next if multiple names appear within a level, 1076 sort based on the next highest level label. Repeat until all names 1077 have been sorted down to leaf node labels. 1079 For example, the following names are sorted in canonical DNS name 1080 order. The highest label is label level is foo.example. At this 1081 level, foo.example sorts first, followed by all names ending in 1082 a.foo.example and then all names ending z.foo.example. The names 1083 withing the a.foo.example level and z.foo.example level are sorted. 1085 foo.example 1086 a.foo.example 1087 yljkjljk.a.foo.example 1088 Z.a.foo.example 1089 zABC.a.FOO.EXAMPLE 1090 z.foo.example 1091 *.z.foo.example 1092 \200.z.foo.example 1094 C.2 Canonical RR Form 1096 For purposes of DNS security, the canonical form for an RR is the 1097 wire format of the RR with 1099 (1) all domain names fully expanded 1100 (no name compression via pointers) 1101 (2) all domain name letters set to lower case 1102 (3) any owner name wild cards in master file form 1103 (no substitution made for *) 1104 (4) the original TTL substituted for the current TTL. 1106 C.3 Canonical RR Ordering Within An RRset 1108 For purposes of DNS security, RRs with same owner name and same type 1109 are sorted by treating the RDATA as a left justified unsigned octet 1110 sequence. The absence of an octet sorts before the zero octet. 1112 C.4 Canonical Ordering of RR Types 1114 RRs with the same owner name but different types are sorted based on 1115 the RR type number. The exception to this rule are SIG RRs, which 1116 are placed immediately after the type they cover. 1118 For example, an A record would be put before an MX record because 1119 type 1 (A) and is lower than type 15 (MX). If the A and MX records 1120 were both signed, the order would be A < SIG(A) < MX < SIG(MX). 1122 Full Copyright Statement 1124 Copyright (C) The Internet Society (2002). All Rights Reserved. 1126 This document and translations of it may be copied and furnished to 1127 others, and derivative works that comment on or otherwise explain it 1128 or assist in its implementation may be prepared, copied, published 1129 and distributed, in whole or in part, without restriction of any 1130 kind, provided that the above copyright notice and this paragraph are 1131 included on all such copies and derivative works. However, this 1132 document itself may not be modified in any way, such as by removing 1133 the copyright notice or references to the Internet Society or other 1134 Internet organizations, except as needed for the purpose of 1135 developing Internet standards in which case the procedures for 1136 copyrights defined in the Internet Standards process must be 1137 followed, or as required to translate it into languages other than 1138 English. 1140 The limited permissions granted above are perpetual and will not be 1141 revoked by the Internet Society or its successors or assigns. 1143 This document and the information contained herein is provided on an 1144 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1145 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1146 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1147 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1148 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1150 Acknowledgement 1152 Funding for the RFC Editor function is currently provided by the 1153 Internet Society.