idnits 2.17.00 (12 Aug 2021) /tmp/idnits16938/draft-ietf-dnsext-dnssec-records-00.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 306 has weird spacing: '... key tag ...' == Line 679 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 22, 2002) is 7392 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: 6 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Arends 2 Internet-Draft Nominum 3 Expires: August 23, 2002 M. Larson 4 VeriSign 5 D. Massey 6 USC/ISI 7 S. Rose 8 NIST 9 February 22, 2002 11 Resource Records for DNS Security Extensions 12 draft-ietf-dnsext-dnssec-records-00 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 23, 2002. 37 Copyright Notice 39 Copyright (C) The Internet Society (2002). All Rights Reserved. 41 Abstract 43 The DNS Security Extensions (DNSSEC) introduce four resource records: 44 the KEY, DS, SIG, and NXT resource records. This document defines 45 the purpose and the RDATA format for each of these records. This 46 document is part of a family of documents that describe the DNS 47 Security Extensions (DNSSEC). The DNS Security Extensions are a 48 collection of new resource records and protocol modifications that 49 provide source authentication for the DNS. This document obsoletes 50 RFC 2535 and incorporates changes from all updates to RFC 2535. 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [4]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 DNSSEC Document Family . . . . . . . . . . . . . . . . . . 4 60 2. The Key Resource Record . . . . . . . . . . . . . . . . . 5 61 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 62 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 63 2.1.1.1 Explanation for Choice of Bit 7 . . . . . . . . . . . . . 6 64 2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 6 65 2.1.2.1 Explanation for a Fixed Value Protocol Octet Field . . . . 6 66 2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 6 67 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7 68 2.3 KEY RR Examples . . . . . . . . . . . . . . . . . . . . . 7 69 2.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 70 2.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9 72 3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10 74 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10 75 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10 76 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10 77 3.1.5 Signature Expiration and Inception Fields . . . . . . . . 10 78 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 10 79 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11 80 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11 81 3.2 The NXT RR Presentation Format (placeholder) . . . . . . . 11 82 3.3 Calculating the signature . . . . . . . . . . . . . . . . 11 83 4. The NXT Resource Record . . . . . . . . . . . . . . . . . 13 84 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 13 85 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 13 86 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 13 87 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 14 88 5. The DS Resource Record (placeholder) . . . . . . . . . . . 15 89 6. DNSSEC message bits . . . . . . . . . . . . . . . . . . . 16 90 6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 16 91 6.2 The DO Extended Flags Field Bit . . . . . . . . . . . . . 16 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 93 8. Security Considerations . . . . . . . . . . . . . . . . . 19 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20 95 References . . . . . . . . . . . . . . . . . . . . . . . . 21 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 22 98 A. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 23 99 Full Copyright Statement . . . . . . . . . . . . . . . . . 24 101 1. Introduction 103 The reader to assumed to be familiar with common DNSSEC terminology 104 as defined in [13] and familiar with the basic DNS concepts described 105 in RFC1034 [1] and RFC1035 [2]. 107 The DNS Security Extensions (DNSSEC) introduce four resource records: 108 KEY, DS, SIG, and NXT resource records. This document defines the 109 purpose of each resource record, the RDATA format, the ASCII 110 representation, and an example of each RR type is given. Sections 2- 111 5 describe the KEY, DS, SIG, and NXT records. Section 6 describe the 112 DNSSEC header bits. 114 1.1 DNSSEC Document Family 116 This document is part of a family of documents that define the DNS 117 security extensions. The DNS security extensions (DNSSEC) are a 118 collection of resource records and DNS protocol modifications that 119 add source authentication the Domain Name System (DNS). An 120 introduction to DNSSEC and definition of common terms can be found in 121 (RFC TBA). A description of DNS protocol modifications can be found 122 in (RFC TBA). This document defines the DNSSEC resource records. 124 2. The Key Resource Record 126 Public keys used by the DNS infrastructure are stored in KEY resource 127 records. A secure DNS zone will store its public key in a KEY RR and 128 this KEY RR can be used to authenticate other RR sets in the zone. 129 The KEY RR MAY also be used to store other types of DNS public keys, 130 such as the keys used by SIG(0) [10] or TKEY [9]. These public keys 131 are used to authenticate DNS messages such as a request to 132 dynamically update a DNS zone. 134 The KEY RR MUST only be used for public keys used for DNS purposes, 135 all other uses are obsolete. The KEY RR plays an essential role in 136 the secure processing of DNS messages and is included in various 137 responses. The KEY RR MUST NOT be used to store certificates or 138 public keys that do not directly relate to the DNS infrastructure. 139 Examples of certificates and public keys that MUST NOT be stored in 140 the KEY RR include X.509 certificates, IPSEC public keys, and SSH 141 public keys. 143 The type number for the KEY RR is 25. 145 The KEY RR is class independent. 147 2.1 KEY RDATA Wire Format 149 The RDATA for a KEY RR consists of a 2 octet Flags Fields, a Protocol 150 Octet, a one octet Algorithm number, and the public key. 152 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | flags | protocol | algorithm | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | / 158 / public key / 159 / / 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 162 2.1.1 The Flags Field 164 Bit 7 of the Flags Field is the "zone key flag". Bits 0-6 and 8-15 165 are reserved for future use. Bits 0-6 and 8-15 MUST be set to 0 and 166 MUST be ignored during processing. 168 The zone key flag (bit 7) determines whether the KEY holds a DNS zone 169 key. If bit 7 is 1, then the KEY record holds a DNS zone key. If 170 bit 7 is 0, then the KEY record holds some other type of DNSSEC 171 infrastructure public key, such as a public key used by SIG(0) or 172 TKEY. Resolvers MUST check the zone key flag in order to determine 173 if the KEY record holds a DNS zone key. 175 2.1.1.1 Explanation for Choice of Bit 7 177 The choice of bit 7 as the zone key flag was made in order to provide 178 backwards compatibility with an earlier version of the KEY record. 179 This earlier version was defined in [6] and [15] eliminated all flags 180 except the bit 7 zone key flag. 182 2.1.2 The Protocol Octet Field 184 The Protocol Octet value MUST be 3. Name servers and resolvers 185 SHOULD reject KEY records with a Protocol Octet value other than 3. 187 2.1.2.1 Explanation for a Fixed Value Protocol Octet Field 189 The Protocol Octet field is included for backwards compatibility with 190 an earlier version of the KEY record. This earlier version of the 191 KEY record was defined in [6] and [15] restricted the possible 192 Protocol Octet values to 3. 194 2.1.3 The Algorithm and Public Key Fields 196 The Algorithm Field identifies the public key's cryptographic 197 algorithm and determines the format of the Public Key Field. 199 Algorithm values are defined in separate documents. The following 200 table shows the currently defined Algorithm formats: 202 VALUE Algorithm RFC STATUS 203 0 Reserved - - 204 1 RSA/MD5 RFC 2536 NOT RECOMMENDED 205 2 Diffie-Hellman RFC 2539 OPTIONAL 206 3 DSA RFC 2536 MANDATORY 207 4 elliptic curve - reserved 208 5 RSA/SHA1 RFC 3110 MANDATORY 209 6-251 available for assignment - 210 252 reserved - indirect keys 211 253 private - domain name 212 254 private - OID 213 255 reserved - - 215 EDITORS NOTE: indirect keys (252), private keys 253/254 and the 216 implication of making a key MANDATORY need further clarification. 217 This clarification will be in the next version of this document. 219 2.2 The KEY RR Presentation Format 221 A KEY RR may appear as a single line. The presentation format of the 222 RDATA portion is as follows: 224 The Flag field is represented as an unsigned integer. 226 The Protocol Octet field is represented as the unsigned integer 3. 228 The Algorithm Field is represented as an unsigned integer or as 229 mnemonic specified. The mnemonic is listed in the document defining 230 the algorithm. 232 The Public Key Field is a Base 64 encoding of the Public Key Field. 234 2.3 KEY RR Examples 236 2.3.1 Example 1 238 The following KEY RR stores a DNS zone key for isi.edu. 240 isi.edu. 86400 IN KEY 256 3 5 ( AQPT0sh3WjVeRY3WqpBjtf 241 242 xxDw==) 244 256 indicates the flags field has the zone key bit is set. 3 is the 245 fixed Protocol Octet value. 5 indicates the public key algorithm is 246 RSA/SHA1 RFC 3110]. The remaining text is base 64 encoding of the 247 public key and the format of the public key is defined in [12]. 249 Resolvers might use this public key to authenticate signed RR sets 250 such as the A RR set for www.isi.edu. The authentication process 251 used by resolvers is described in [14]. 253 2.3.2 Example 2 255 The following KEY RR stores a public key used by SIG(0) 257 ddnskey.isi.edu. 86400 IN KEY 0 3 3 ( AQPT0sh3WjVeRY3WqpBjtf 258 259 xxDw==) 261 0 indicates the flags field does not have the zone key bit is not 262 set. 3 is the fixed Protocol Octet value. 5 indicates the public 263 key algorithm is DSA [7]. The remaining text is base 64 encoding of 264 the public key and the format of the public key is defined in [7]. 266 This public key can be used to sign dynamic DNS updates for the 267 isi.edu zone. The process is for signing the dynamic DNS updates is 268 described in [11]. 270 3. The SIG Resource Record 272 The SIG or "signature" resource record (RR) is the fundamental way 273 that data is authenticated in the secure Domain Name System (DNS). 274 As such it is the heart of the security provided. 276 The SIG RR authenticates an RRset [5] of a particular type, class, 277 and name and binds it to a time interval and the signer's name. The 278 signer is the key (and associated KEY record) from which the RR 279 originated. A SIG record can also be used for transaction security 280 [transaction ref/section]. This type of SIG is known as SIG(0) and 281 its RDATA is in the same format, with some values loosing their 282 meaning and given default values. The variations are mentioned in 283 [10]. 285 The type number for the SIG RR type is 24. 287 The SIG RR is class independent, but MUST have the same class as the 288 RRset it covers. The TTL for the SIG RR SHOULD be the same as the 289 RRset it covers. 291 3.1 The SIG RDATA 293 The RDATA portion of a SIG RR is as shown below: 295 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | type covered | algorithm | labels | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | original TTL | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | signature expiration | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | signature inception | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | key tag | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + 308 | / 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 310 / / 311 / signature / 312 / / 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 3.1.1 The Type Covered Field 317 For RRset SIGs, the type covered MUST be the same as the type of data 318 in the associated RRset. For SIG(0), this field MUST be zero [10] 320 3.1.2 The Algorithm Number Field 322 The Algorithm Number field in the RDATA is the same field as found in 323 the algorithm field of the KEY record RDATA [section 2.2.3]. 325 3.1.3 The Labels Field 327 The "labels" octet is an unsigned count of how many labels there are 328 in the original SIG RR owner name. This does not count null labels 329 for root and any initial "*" for a wildcard. The labels count MUST 330 be less than or equal to the number of labels in the SIG owner name. 332 3.1.4 Original TTL Field 334 The "original TTL" field is included in the RDATA portion to avoid 335 authentication problems caused by caching servers decrementing the 336 real TTL field. The signatures covers this field (as part of the SIG 337 RDATA) while the TTL field is not. In a SIG(0), the Original TTL 338 field (and the TTL field) MUST be zero. 340 The "original TTL" value MUST be greater than or equal to the TTL of 341 the SIG record itself. 343 3.1.5 Signature Expiration and Inception Fields 345 The SIG is valid from the "signature inception" time until the 346 "signature expiration" time. Both are unsigned numbers of seconds 347 since the start of 1 January 1970, GMT, ignoring leap seconds. Ring 348 arithmetic is used as for DNS SOA serial numbers [3], which means 349 that these times can never be more than about 68 years in the past or 350 the future. This means that these times are ambiguous modulo ~136.09 351 years. 353 A SIG RR may have an expiration time numerically less than the 354 inception time if the expiration time is near the 32-bit wrap around 355 point and/or the signature is long lived. 357 3.1.6 The Key Tag Field 359 The "Key Tag" is a two-octet quantity that is used to efficiently 360 select between multiple keys that may be applicable. The Key Tag 361 value may differ depending on the key algorithm in use, as described 362 in Appendix (A). 364 3.1.7 The Signer's Name Field 366 The signer's name field MUST contain the name of the zone to which 367 the data and signature belong. The combination of signer's name, key 368 tag, and algorithm MUST identify a zone key if the SIG is to be 369 considered material. In a SIG(0), the signer's name MUST be the 370 originating host of the DNS message [10]. 372 3.1.8 The Signature Field 374 The actual signature portion of the SIG RR binds the other RDATA 375 fields to the RRset of the "type covered" RRs with that owner name 376 and class. 378 3.2 The NXT RR Presentation Format (placeholder) 380 This section will be here in the next revision. 382 3.3 Calculating the signature 384 To generate the signature over an RRset, a data sequence is 385 constructed as follows (where "|" is concatenation): 387 signature = sign(RDATA | RR(1) | RR(2)... ) 389 RR(N) = name | class | type | original TTL(stored in SIG RDATA) | 390 RDATA 392 To generate a signature over a DNS message (SIG(0)), a data sequence 393 is constructed as follows: 395 If the DNS message is sent via UDP: 397 signature = sign(RDATA | full query | full response - SIG(0)) 399 If the DNS message is sent via TCP, the first packet's SIG(0) is 400 calculated as above, with each additional packet (if any) calculated 401 as follows: 403 signature = sign(RDATA | DNS payload - SIG(0) | previous packet) 405 where "previous packet" is the previous DNS packet with accompanying 406 SIG(0), but without any other headers (i.e. TCP/IP, etc.). 408 In all the examples, 410 RDATA is the wire format of all the RDATA fields in the SIG RR itself 411 (including the canonical form of the signer's name) before but not 412 including the signature, and 414 RR(num) is the RRset with the same owner name and class and type 415 covered as the SIG RR in canonical form. 417 Name is the Fully Qualified Domain Name (FQDN) in canonical form. 419 The canonical form for a Resource Record (RR) is the wire format of 420 the RR. Names MUST be expanded (no name compression allowed). Name 421 characters MUST be set to lower case. Wildcards MUST be unexpanded. 422 The RR MUST have the original TTL. 424 How this data sequence is processed into the signature is algorithm 425 dependent. These algorithm dependent formats and procedures are 426 described in separate documents. 428 SIGs SHOULD NOT be generated for any "meta-type" such as ANY, AXFR, 429 etc. 431 4. The NXT Resource Record 433 The collection of NXT or "next" resource records (RR) is used to 434 indicate what names and RRsets [5] exist in a zone. 436 The NXT RR lists the next canonical name in the zone and lists what 437 RR types are present for the current name of the NXT RR. 439 The set of NXT RRs in a zone is a chain of all authoritative names in 440 that zone. 442 Glue address records MUST NOT be covered by a NXT RR. 444 The type number for the NXT RR is 30. 446 The NXT RR is class independant. 448 The NXT RR TTL SHOULD NOT exceed the zone minimum TTL. 450 4.1 NXT RDATA Wire Format 452 The RDATA of the NXT RR is as shown below: 454 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 / next domain name / 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 / type bit map / 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 4.1.1 The Next Domain Name Field 464 The "next domain name" field contains the next owner name in 465 canonical order. Canonical order means sorted by label, highest 466 level label first. The "next domain name" field of the NXT RR at the 467 last name in the zone contains the zone apex name. 469 Glue address record names MUST NOT be covered by the "next domain 470 name" field. 472 The "next domain name" field allows message compression. 474 4.1.2 The Type Bit Map Field 476 The "type bit map" field format contains a single bit per RR type for 477 RRsets with the same owner name as the NXT RR. A one bit indicates 478 that an RRset of that type exist for the owner name. A zero bit 479 indicates that no RRset of that type exist for the owner name. 481 The first bit represents RR type zero. RR type number zero is not 482 assigned and the corresponding bit MUST be zero. If the zero bit is 483 one, it indicates that an unspecified format is used. This format is 484 not used when there exist an RR type number greater than 127. 486 The OPT RR [8] type MUST NOT be covered by the type bit map field 487 since it is not part of the zone data. The corresponding OPT RR type 488 bit (40) MUST be zero. 490 Trailing zero octets MUST be omitted. Trailing zero octets not 491 specified MUST be interpreted as zero octets. Glue address record 492 types MUST NOT be covered by the type bit map field. 494 4.2 The NXT RR Presentation Format 496 A NXT RR may appear as a single line. The presentation format of the 497 RDATA portion is as follows: 499 The "next domain name" field is represented as a domain name. 501 The "type bit map" field is represented as a sequence of RR type 502 mnemonics or as an unsigned integer. 504 5. The DS Resource Record (placeholder) 506 [This section will be finalised once DS has WG consensus and is 507 proposed standard] 509 6. DNSSEC message bits 511 There are 3 new bits allocated for use with DNSSEC. The DO bit is 512 used to indicate to a server that the resolver is able to accept 513 DNSSEC security RRs (KEY SIG NXT DS). The CD and AD bits are used to 514 indicate if non-authenticated data is accepted, and if data is 515 authenticated. 517 6.1 The AD and CD Header Bits 519 Two bits are allocated in the header section. The CD (checking 520 disabled) bit and the AD (authentic data) bit. 522 The Header contains the following fields: 524 1 1 1 1 1 1 525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 526 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 527 | ID | 528 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 529 |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | 530 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 531 | QDCOUNT | 532 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 533 | ANCOUNT | 534 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 535 | NSCOUNT | 536 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 537 | ARCOUNT | 538 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 540 The usage of the CD and AD bits are defined in [14] 542 6.2 The DO Extended Flags Field Bit 544 The DO (DNSSEC OK) bit is allocated from the EDNS0 [8] extended flags 545 field. In the context of the OPT RR, the DO bit is the most 546 significant bit in the 3rd octet of the TTL field. 548 The TTL field of the OPT RR is defined as follows: 550 1 1 1 1 1 1 551 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 552 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 553 | EXTENDED-RCODE | VERSION | 554 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 555 |DO| Z | 556 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 557 The usage of the DO bit is defined in [14] 559 7. IANA Considerations 561 This document clarifies the use of existing types and introduces no 562 new IANA considerations. 564 8. Security Considerations 566 This document describes the format of resource records used by DNS 567 security. The threats facing DNS are described in a seperate 568 document and these records are used to help counter those threats. 569 The records themselves introduce no new security considerations, but 570 the protocol use of these records is described in a second document. 572 9. Acknowledgements 573 References 575 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 576 13, RFC 1034, November 1987. 578 [2] Mockapetris, P., "Domain names - implementation and 579 specification", STD 13, RFC 1035, November 1987. 581 [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 582 August 1996. 584 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 585 Levels", BCP 14, RFC 2119, March 1997. 587 [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 588 RFC 2181, July 1997. 590 [6] Eastlake, D., "Domain Name System Security Extensions", RFC 591 2535, March 1999. 593 [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 594 (DNS)", RFC 2536, March 1999. 596 [8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 597 August 1999. 599 [9] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 600 2930, September 2000. 602 [10] Eastlake, D., "DNS Request and Transaction Signatures ( 603 SIG(0)s)", RFC 2931, September 2000. 605 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 606 Update", RFC 3007, November 2000. 608 [12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 609 System (DNS)", RFC 3110, May 2001. 611 [13] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC Intro", 612 February 2002. 614 [14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC 615 Protocol", February 2002. 617 [15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 618 Record", draft-ietf-dnsext-restrict-key-for-dnssec-01 (work in 619 progress), January 2002. 621 Authors' Addresses 623 Roy Arends 624 Nominum, Inc. 625 2385 Bay Street 626 Redwood City, CA 94063 627 USA 629 EMail: roy.arends@nominum.com 631 Matt Larson 632 VeriSign, Inc. 633 21345 Ridgetop Circle 634 Dulles, VA 20166-6503 635 USA 637 EMail: mlarson@verisign.com 639 Dan Massey 640 USC Information Sciences Institute 641 3811 N. Fairfax Drive 642 Arlington, VA 22203 643 USA 645 EMail: masseyd@isi.edu 647 Scott Rose 648 National Institute for Standards and Technology 649 100 Bureau Drive 650 Gaithersburg, MD 20899-3460 651 USA 653 EMail: scott.rose@nist.gov 655 Appendix A. Key Tag Calculation 657 The key tag field in the SIG RR is just a means of more efficiently 658 selecting the correct KEY RR to use when there is more than one KEY 659 RR candidate available, for example, in verifying a signature. It is 660 possible for more than one candidate key to have the same tag, in 661 which case each must be tried until one works or all fail. The 662 following reference implementation of how to calculate the Key Tag, 663 for all algorithms other than algorithm 1, is in ANSI C. It is coded 664 for clarity, not efficiency. 666 /* assumes int is at least 16 bits 667 first byte of the key tag is the most significant byte of return 668 value 669 second byte of the key tag is the least significant byte of 670 return value 671 */ 673 int keytag ( 675 unsigned char key[], /* the RDATA part of the KEY RR */ 676 unsigned int keysize, /* the RDLENGTH */ 677 ) 678 { 679 long int ac; /* assumed to be 32 bits or larger */ 681 for ( ac = 0, i = 0; i < keysize; ++i ) 682 ac += (i&1) ? key[i] : key[i]<<8; 683 ac += (ac>>16) & 0xFFFF; 684 return ac & 0xFFFF; 685 } 687 Full Copyright Statement 689 Copyright (C) The Internet Society (2002). All Rights Reserved. 691 This document and translations of it may be copied and furnished to 692 others, and derivative works that comment on or otherwise explain it 693 or assist in its implementation may be prepared, copied, published 694 and distributed, in whole or in part, without restriction of any 695 kind, provided that the above copyright notice and this paragraph are 696 included on all such copies and derivative works. However, this 697 document itself may not be modified in any way, such as by removing 698 the copyright notice or references to the Internet Society or other 699 Internet organizations, except as needed for the purpose of 700 developing Internet standards in which case the procedures for 701 copyrights defined in the Internet Standards process must be 702 followed, or as required to translate it into languages other than 703 English. 705 The limited permissions granted above are perpetual and will not be 706 revoked by the Internet Society or its successors or assigns. 708 This document and the information contained herein is provided on an 709 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 710 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 711 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 712 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 713 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 715 Acknowledgement 717 Funding for the RFC Editor function is currently provided by the 718 Internet Society.