idnits 2.17.1 draft-ietf-dnsext-dnssec-protocol-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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. == There is 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document obsoletes RFC2535, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to 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 (March 3, 2003) is 7724 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 1433, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1439, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1464, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1467, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1470, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1473, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (ref. '6') (Obsoleted by RFC 6891) == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-dnssec-intro-05 == Outdated reference: A later version (-11) exists of draft-ietf-dnsext-dnssec-records-04 == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-opt-in-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-dnsext-dnssec-opt-in (ref. '11') -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '12') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-15) exists of draft-ietf-dnsext-delegation-signer-12 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions R. Arends 3 Internet-Draft Telematica Instituut 4 Expires: September 1, 2003 M. Larson 5 VeriSign 6 R. Austein 7 ISC 8 D. Massey 9 USC/ISI 10 S. Rose 11 NIST 12 March 3, 2003 14 Protocol Modifications for the DNS Security Extensions 15 draft-ietf-dnsext-dnssec-protocol-01 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at http:// 33 www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 1, 2003. 40 Copyright Notice 42 Copyright (C) The Internet Society (2003). All Rights Reserved. 44 Abstract 46 This document is part of a family of documents which describes the 47 DNS Security Extensions (DNSSEC). The DNS Security Extensions are a 48 collection of new resource records and protocol modifications which 49 add data origin authentication and data integrity to the DNS. This 50 document describes the DNSSEC protocol modifications. This document 51 defines the concept of a signed zone, along with the requirements for 52 serving and resolving using DNSSEC. These techniques allow a 53 security-aware resolver to authenticate both DNS resource records and 54 authoritative DNS error indications. 56 This document obsoletes RFC 2535 and incorporates changes from all 57 updates to RFC 2535. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 63 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 66 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 67 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 68 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1 Including KEY RRs in a Zone . . . . . . . . . . . . . . . . 6 70 2.2 Including SIG RRs in a Zone . . . . . . . . . . . . . . . . 7 71 2.3 Including NXT RRs in a Zone . . . . . . . . . . . . . . . . 8 72 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 73 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 74 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8 75 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1 Including SIG RRs in a Response . . . . . . . . . . . . . . 10 77 3.2 Including KEY RRs In a Response . . . . . . . . . . . . . . 11 78 3.3 Including NXT RRs In a Response . . . . . . . . . . . . . . 11 79 3.3.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12 80 3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches . 12 81 3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches . . 13 82 3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13 83 3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 13 84 3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 15 85 3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 15 86 3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16 87 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 23 89 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24 90 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25 91 5.1 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26 92 5.2 Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 27 93 5.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 27 94 5.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28 95 5.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30 96 5.2.4 Authenticating A Wildcard Expanded RRset Positive Response . 31 97 5.3 Authenticated Denial of Existence . . . . . . . . . . . . . 31 98 5.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 5.4.1 Example of Re-Constructing the Original Owner Name . . . . . 32 100 5.4.2 Examples of Authenticating a Response . . . . . . . . . . . 33 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 102 7. Security Considerations . . . . . . . . . . . . . . . . . . 35 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 104 Normative References . . . . . . . . . . . . . . . . . . . . 37 105 Informative References . . . . . . . . . . . . . . . . . . . 38 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 107 A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 40 108 Full Copyright Statement . . . . . . . . . . . . . . . . . . 41 110 1. Introduction 112 The DNS Security Extensions (DNSSEC) modify several aspects of the 113 DNS protocol. Section 2 defines the concept of a signed zone and 114 lists the requirements for zone signing. Section 3 describes the 115 modifications to authoritative name server behavior necessary to 116 handle signed zones. Section 4 describes the behavior of entities 117 which include security-aware resolver functions Finally, Section 5 118 defines how to use DNSSEC RRs to authenticate a response. 120 1.1 Background and Related Documents 122 The reader is assumed to be familiar with the basic DNS concepts 123 described in RFC1034 [1] and RFC1035 [2]. 125 This document is part of a family of documents which define the DNS 126 security extensions (DNSSEC). The DNS Security Extensions are a 127 collection of new resource records and protocol modifications which 128 add data origin authentication and data integrity to the DNS. An 129 introduction to DNSSEC and definition of common terms can be found in 130 [9]. A definition of the DNSSEC resource records can be found in 131 [10]. This document defines the DNSSEC protocol modifications. 133 1.2 Reserved Words 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119. [4]. 139 1.3 Editors' Notes 141 1.3.1 Open Technical Issues 143 Use of NXT RRs throughout this document set will have to be modified 144 if DNSSEC-Opt-In [11] becomes part of DNSSEC. The use of the NXT 145 record requires input from the working group. This text describes 146 the NXT record as it was defined in RFC 2535, and substantial 147 portions of this document would need to be updated to incorporate 148 opt-in. The updates will be made if the WG adopts opt-in. 150 Use of the AD bit requires input from the working group. Since the 151 AD bit usage is not resolved, this text attempts to capture current 152 ideas and drafts, but further input from the working group is 153 required. 155 1.3.2 Technical Changes or Corrections 157 Please report technical corrections to dnssec-editors@east.isi.edu. 159 To assist the editors, please indicate the text in error and point 160 out the RFC that defines the correct behavior. For a technical 161 change where no RFC that defines the correct behavior, or if there's 162 more than one applicable RFC and the definitions conflict, please 163 post the issue to namedroppers. 165 An example correction to dnssec-editors might be: Page X says 166 "DNSSEC RRs SHOULD be automatically returned in responses." This was 167 true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the 168 DNSSEC RR types MUST NOT be included in responses unless the resolver 169 indicated support for DNSSEC. 171 1.3.3 Typos and Minor Corrections 173 Please report any typos corrections to dnssec-editors@east.isi.edu. 174 To assist the editors, please provide enough context for us to find 175 the incorrect text quickly. 177 An example message to dnssec-editors might be: page X says "the 178 DNSSEC standard has been in development for over 1 years". It 179 should read "over 10 years". 181 2. Zone Signing 183 DNSSEC defines the concept of a signed zone. A signed zone includes 184 KEY, SIG, NXT and (optionally) DS records according to the rules 185 specified in Section 2.1, Section 2.2, Section 2.3 and Section 2.4, 186 respectively. Any zone which does not include these records 187 according to the rules in this section must be considered unsigned. 189 Editors' note: Should this be "MUST be considered unsigned"? 191 DNSSEC requires a change to the definition of the CNAME resource 192 record. Section 2.5 changes the CNAME RR to allow SIG and NXT RRs to 193 appear at the same owner name as a CNAME RR. 195 Section 2.6 shows a sample signed zone. 197 2.1 Including KEY RRs in a Zone 199 Editors' note: Unresolved inconsistency between paragraphs in this 200 section, regarding non-zone KEY RRs at the zone apex. SHOULD NOT, 201 or MUST NOT? 203 To sign a zone, the zone's administrator generates one or more 204 public/private key pairs and uses the private key(s) to sign 205 authoritative RRsets in the zone. For each private key used to 206 create SIG RRs, there SHOULD be a corresponding KEY RR stored at the 207 zone apex. All KEY RRs at the zone apex MUST be zone keys. (A zone 208 key KEY RR has the Zone Key bit of the Flags RDATA field set to one. 209 See Section 2.1.1 of [10].) Zone key KEY RRs MUST appear only at the 210 zone apex. 212 A signed zone MUST have at least one zone key KEY RR in its apex KEY 213 RRset. The KEY RRset at the zone apex MUST be self-signed by at 214 least one private key whose corresponding public key is a zone key 215 stored in the apex KEY RRset. 217 Editors' note: The requirement listed in this paragraph may not be 218 necessary anymore, since the KEY RRset is self-signed anyway 219 (because the whole zone is signed). This is probably a pre-DS 220 relic, but we spotted this a few hours before the I-D deadline and 221 were too chicken to remove it on such short notice.... 223 Other public keys associated with other DNS operations can be stored 224 in KEY RRs that are not marked as zone keys. Non-zone key KEY RRs 225 MUST NOT appear at delegation names. Non-zone key KEY RRs also 226 SHOULD NOT appear at the zone apex, because large KEY RRsets add 227 processing time at resolvers. Non-zone key KEY RRs MAY appear at any 228 other name in the zone. 230 2.2 Including SIG RRs in a Zone 232 For each authoritative RRset in the zone (which excludes NS RRsets at 233 delegation points and glue RRsets), there MUST be at least one SIG 234 record that meets all of the following requirements: 236 o The SIG owner name is equal to the RRset owner name; 238 o The SIG class is equal to the RRset class; 240 o The SIG Type Covered field is equal to the RRset type; 242 o The SIG Original TTL field is equal to the TTL of the RRset; 244 o The SIG RR's TTL is equal to the TTL of the RRset; 246 o The SIG Labels field is equal to the number of labels in the RRset 247 owner name, not counting the null root label or any wildcard 248 label; 250 o The SIG Signer's Name field is equal to the name of the zone 251 containing the RRset; and 253 o The SIG Algorithm, Signer's Name, and Key Tag fields identify a 254 zone key KEY record at the zone apex. 256 The process for constructing the SIG RR for a given RRset is 257 described in [10]. An RRset MAY have multiple SIG RRs associated 258 with it. 260 A SIG RR itself MUST NOT be signed, since signing a SIG RRset would 261 add no value and would create an unterminated dependency loop in the 262 signing process. 264 The NS RRset which appears at the zone apex name MUST be signed, but 265 the NS RRsets which appear at delegation points (that is, the NS 266 RRsets in the parent zone which delegate the name to the child zone's 267 name servers) MUST NOT be signed. Glue address RRsets associated 268 with delegations MUST NOT be signed. 270 The difference between the set of owner names which require SIG 271 records and the set of owner names which require NXT records is 272 subtle and worth highlighting. SIG records are present at the owner 273 names of all authoritative RRsets. NXT records are present at the 274 owner names of all names for which the signed zone is authoritative 275 and also at the owner names of delegations from the signed zone to 276 its children. Neither NXT nor SIG records are present (in the parent 277 zone) at the owner names of glue address RRsets. Note, however, that 278 this distinction is for the most part only visible during the zone 279 signing process, because NXT RRsets are authoritative data, and 280 therefore are signed, thus any owner name which has an NXT RRset will 281 have SIG RRs as well in the signed zone. 283 2.3 Including NXT RRs in a Zone 285 Each owner name in the zone MUST have an NXT resource record, except 286 for the owner names of any glue address RRsets. The process for 287 constructing the NXT RR for a given name is described in [10]. 289 2.4 Including DS RRs in a Zone 291 The DS resource record establishes authentication chains between DNS 292 zones. A DS RRset SHOULD be present at a delegation point when the 293 child zone is signed. The DS RRset MAY contain multiple records, 294 each referencing a key used by the child zone to sign its apex KEY 295 RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT 296 appear at non-delegation points nor at a zone's apex. 298 A DS RR SHOULD point to a KEY RR which is present in the child's apex 299 KEY RRset, and the child's apex KEY RRset SHOULD be signed by the 300 corresponding private key. 302 Construction of a DS RR requires knowledge of the corresponding KEY 303 RR in the child zone, which implies communication between the child 304 and parent zones. This communication is an operational matter not 305 covered by this document. 307 2.5 Changes to the CNAME Resource Record. 309 If a CNAME RRset is present at a name in a signed zone, appropriate 310 SIG and NXT RRsets are REQUIRED at that name. Other types MUST NOT 311 be present at that name. 313 This is a modification to the original CNAME definition given in [1]. 314 The original definition of the CNAME RR did not allow any other types 315 to co-exist with a CNAME record, but a signed zone requires NXT and 316 SIG RRsets for every authoritative name. To resolve this conflict, 317 the definition of the CNAME resource record is hereby modified to 318 allow for the co-existence of NXT and SIG RRsets. 320 2.6 Example of a Secure Zone 322 {{secure zone here}} 324 Editors' note: Zone file example deferred pending hackery to add 325 zone files in a format usable by xml2rfc. Goal here is to show a 326 (small) complete signed zone. 328 The apex KEY set includes two KEY RRs, and the KEY RDATA Flags 329 indicate that each of these KEY RRs is a zone key. The first zone 330 KEY is used to sign the apex KEY RRset, and a DS record for this key 331 is provided to the parent zone. The second zone KEY is used to sign 332 all the other RRsets in the zone. A non-zone KEY RR is also stored 333 at "host1.example.com"; this KEY might be used by SIG(0) to 334 authenticate transactions from this host. 336 The zone includes a wildcard entry "*.a.example.com". Note that the 337 "*.a.example.com" name is used in constructing NXT chains, and that 338 the SIG covering the "*.a.example.com" MX RRset has a label count of 339 3. 341 The zone also includes two delegations. The delegation to 342 "insecure.example.com" includes an NS RRset, glue address records, 343 and an NXT RR, but note that only the NXT RRset is signed. The 344 "secure.example.com" delegation provides a DS RR, and note that only 345 NXT and DS RRsets are signed. 347 3. Serving 349 This section describes the behavior of a security-aware authoritative 350 name server. A security-aware authoritative name server MUST support 351 the EDNS0 [6] message size extension, MUST support a message size of 352 at least 1220 octets, and SHOULD support a message size of 4000 353 octets [8]. Since functions specific to security-aware recursive 354 name servers included components of both resolving and serving, 355 issues specific to security-aware recursive name servers are 356 described in Section 4. 358 Upon receiving a relevant query which has the EDNS [6] OPT pseudo-RR 359 DO [7] bit set to one, a security-aware authoritative name server for 360 a signed zone MUST include additional SIG, NXT, and DS RRs according 361 to the following rules: 363 o SIG RRs which can be used to authenticate a response MUST be 364 included in the response automatically according to the rules in 365 Section 3.1; 367 o NXT RRs which can be used to provide authenticated denial of 368 existence MUST be included in the response automatically according 369 to the rules in Section 3.3; 371 o Either DS RRs or an NXT RR proving that no DS RRs exist MUST be 372 included in referrals automatically according to the rules in 373 Section 3.4. 375 DNSSEC does not change the DNS zone transfer protocol. Zone transfer 376 requirements are reviewed in Section 3.6. 378 A security-aware name server which receives a DNS query which does 379 not include the EDNS OPT pseudo-RR, or which has the DO bit set to 380 zero, MUST treat the SIG, KEY, and NXT RRs as it would any other 381 RRset, and MUST NOT perform any of the additional processing 382 described above. Since the DS RR type has the peculiar property of 383 only existing in the parent zone at delegation points, DS RRs always 384 require some special processing, as described in Section 3.5. 386 3.1 Including SIG RRs in a Response 388 When a query has the DO bit set to one, the authoritative name server 389 SHOULD attempt to send SIG RRs which can be used to authenticate the 390 RRsets in the response. Inclusion of SIG RRs in a response is 391 subject to the following rules: 393 o When a signed RRset is placed in the Answer section, its SIG RRs 394 are also placed in the Answer section. The SIG RRs have a higher 395 priority for inclusion than any other RRsets which may need to be 396 included. If space does not permit the inclusion of these SIG 397 RRs, the response MUST be considered truncated, and the TC bit 398 MUST be set. 400 o When a signed RRset is placed in the Authority section, its SIG 401 RRs are also placed in the Authority section. The SIG RRs have a 402 higher priority for inclusion than any other RRsets that may need 403 to be included. If space does not permit the inclusion of these 404 SIG RRs, the response MUST be considered truncated, and the TC bit 405 MUST be set. 407 o When a signed RRset is placed in the Additional section, its SIG 408 RRs are also placed in the Additional section. If space does not 409 permit the inclusion of these SIG RRs, the response MUST NOT be 410 considered truncated just because these SIG RRs didn't fit. 412 3.2 Including KEY RRs In a Response 414 When a query has the DO bit set to one and requests the SOA or NS RRs 415 at the apex of a signed zone, then a security-aware authoritative 416 name server for that zone SHOULD return the KEY RRset with the same 417 name in the Additional section. If Additional section processing 418 results in more data than will fit in the response message, address 419 glue RRs have higher priority than KEY RRs. SIG RR(s) associated 420 with the KEY RRset SHOULD also be included in the Additional section 421 (see Section 3.1). 423 Editors' note: Didn't the WG decide that DS RR removes the need 424 for Additional section processing for KEY RRs? If so, this 425 subsection should be deleted. 427 3.3 Including NXT RRs In a Response 429 Editors' note: This whole section uses the phrase "query name 430 exists", which is somewhat ambiguous when discussing internal 431 nodes with no RRs. We are reasonably certain that, as used here, 432 the phrase only refers to names which are the owner name for least 433 one RR. Better phrasing needed. 435 When a query has the DO bit set to one, security-aware authoritative 436 name servers for a signed zone MUST include NXT RRs in each of the 437 following cases: 439 Case 1: The query name exists, but the requested RR type does not 440 exist. 442 Case 2: The query name does not exist, and no wildcard can be 443 expanded to answer the query. 445 Case 3: The query name does not exist, but a wildcard can be expanded 446 to positively answer the query. 448 Note that, in each case, a set of NXT RRs is included to provide 449 authenticated denial of existence. 451 NXT RRs are also included in a referral response when no DS RR is 452 present; in this case, the NXT RR proves that no DS RR exists for the 453 delegation. Referrals are discussed in more detail in Section 3.4. 455 3.3.1 Case 1: Query Name Exists, but RR Type Not Present 457 If the query name exists but the requested RR type is not present at 458 the name, then the NXT RR associated with the query name MUST be 459 included in the Authority section. Any SIG(s) associated with the 460 NXT RRset are also included in the Authority section (see Section 461 3.1) If space does not permit the inclusion of the NXT RR (or its 462 associate SIG RRs), the response MUST be considered truncated and the 463 TC bit MUST be set. 465 Note that, since the query name exists, no wildcard expansion applies 466 to this query, and a single NXT RR suffices to prove the requested 467 type does not exist. 469 3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches 471 If the query name does not exist, and no wildcard expansion matches 472 the query, then the Authority section of the response MUST include 473 the following NXT RRs: 475 o An NXT RR proving that there was no exact match for the name; and 477 o An NXT RR proving that there was no wildcard which would have 478 matched the query. 480 If space does not permit the inclusion of these NXT RRs, the response 481 MUST be considered truncated, and the TC bit MUST be set. Any SIG(s) 482 associated with the NXT RRsets MUST also be included in the Authority 483 section (see Section 3.1). 485 Editors' note: Should lack of space to include the SIGs cause the 486 packet to be considered truncated? 488 Appendix A provides an algorithm which computes the appropriate NXT 489 RRs to prove that no wildcard matches a given query name. 491 3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches 493 If the query name does not exist, but a wildcard expansion can be 494 used to return a positive match to the query, then the wildcard- 495 expanded answer and any SIG RRs associated with the wildcard RR MUST 496 be returned in the Answer section. The Authority section of the 497 response MUST include the following NXT RRs: 499 o An NXT RR which proves that there were no exact matches for the 500 QNAME and QTYPE; and 502 o An NXT RR which proves that there are no closer wildcard entries 503 which could have been expanded to match the query. 505 If space does not permit inclusion of these NXT RRs, the response 506 MUST be considered truncated, and the TC bit MUST be set. Any SIG 507 RRs associated with the NXT RRsets MUST also be included in the 508 response. 510 Editors' note: Should lack of space to include the SIGs cause the 511 packet to be considered truncated? 513 Appendix A provides an algorithm which computes the appropriate NXT 514 RRs to prove that no closer wildcard matches the query name. 516 3.4 Including DS RRs In a Response 518 When a query has the DO bit set to one, and a DS RR exists at the 519 query name, an authoritative security-aware name server returning a 520 referral for the delegation MUST include both the NS RRset and also 521 the DS RRset and its associated SIG RR(s). The NS RRset MUST be 522 placed before the DS RRset and its associated SIG RRs. 524 When a query has the DO bit set to one, and no DS RR exists at the 525 query name, an authoritative security-aware name server returning a 526 referral for the delegation MUST include both the NS RRset and also 527 the NXT RR and associated SIG RR(s) which proves that the DS RRset 528 does not exist. The NS RRset MUST be placed before the NXT RRset and 529 its associated SIG RR(s). 531 This increases the size of referral messages, and may cause some or 532 all glue RRs to be omitted. If space does not permit the inclusion 533 of the DS or NXT RRset and associated SIG RRs, the response MUST be 534 considered truncated, and the TC bit MUST be set. 536 3.5 Responding to Queries for DS RRs 538 The DS record is the first resource record type which appears only on 539 the parent zone's side of a zone cut. In other words, the DS record 540 for the delegation of "example.com" is only stored in the "com" zone. 541 This introduces novel name server behavior, since the name server for 542 the child zone is authoritative for the name by the normal DNS rules 543 but the child zone does not contain the DS RR. A name server's 544 response to a DS query depends on whether the name server is 545 authoritative for the parent zone, the child zone, or both, as 546 described below. 548 If a name server is authoritative for the parent zone, and receives a 549 query for the DS record at the delegated name, then the name server 550 MUST return the DS RRset from the parent zone. This rule applies 551 regardless of whether or not the name server is also authoritative 552 for the child zone. 554 If the name server is authoritative for the child zone, is not 555 authoritative for the parent zone, and receives a query for the DS 556 record at the delegated name, there is no obvious response, because 557 the child zone is not authoritative for the DS record at the child 558 zone's apex, and the authoritative DS RR is only stored at the 559 parent. 561 If the name server allows recursion, and the RD bit is set in the 562 query, the name server MAY perform recursion to find the DS record 563 for the delegated name from the parent zone, and MAY return the DS 564 record from its cache. In this case, the AA bit MUST NOT be set in 565 the response. 567 If the name server does not perform recursion to find the DS RR, the 568 name server MUST reply with: 570 RCODE: NOERROR 571 AA bit: set 572 Answer Section: Empty 573 Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] 575 In other words, a name server which is authoritative for the child 576 zone but not for the parent zone answers as if the DS record does not 577 exist. Note that security-aware resolvers will query the parent zone 578 at delegation points, and thus will not be affected by this behavior. 580 For example, suppose that "example.com" is a delegation point, and a 581 name server receives a query for the "example.com" DS RRset. 583 o If the name server is authoritative for "com", the name server 584 MUST reply with the "example.com" DS RRset from the "com" zone. 586 o If the name server is authoritative for "example.com", is not 587 authoritative for "com", and the RD bit is set to one in the 588 query, the name server MAY perform recursion to find the 589 "example.com" DS record. If the name server does not use 590 recursion to obtain the DS RR, the name server MUST reply as 591 though the DS RR did not exist: 593 RCODE: NOERROR 594 AA bit: set 595 Answer Section: Empty 596 Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] 598 3.6 Responding to Queries for Type AXFR or IXFR 600 DNSSEC does not change the DNS zone transfer process. A signed zone 601 will contain SIG, KEY, NXT, and DS resource records, but these 602 records have no special meaning with respect to a zone transfer 603 operation, and these RRs are treated as any other resource record 604 type. 606 An authoritative name server is not required to verify that a zone is 607 properly signed before sending or accepting a zone transfer. 608 However, an authoritative name server MAY choose to reject the entire 609 zone transfer if the zone fails meets any of the signing requirements 610 described in Section Section 2. The primary objective of a zone 611 transfer to ensure that all authoritative name servers have identical 612 copies of the zone. An authoritative name server which chooses to 613 perform its own zone validation MUST NOT selectively reject some RRs 614 and accept others. 616 Note that the DS RR appears only in the parental side of a 617 delegation, and is authoritative data in the parent zone. For 618 example, the DS RR for "example.com" is stored in the "com" zone (the 619 parent zone) rather than in the "example.com" zone (the child zone). 620 As with any other authoritative RRset, the "example.com" DS RR MUST 621 be included the "com" zone transfer. 623 Note that authoritative NXT RRs appear in both the parent and child 624 zones at a delegated name, and that the NXT RRs for the delegated 625 name in the parent and child zones are never identical to each other. 626 As with any other authoritative RRset, the parental NXT RR at a 627 delegated name MUST be included zone transfers of the parent zone, 628 while the NXT at the zone apex of the child zone MUST be included in 629 zone transfers of the child zone. 631 3.7 Setting the AD and CD Bits in a Response 633 Editors' note: This section seems a little lost here. Perhaps we 634 should rearrange the section ordering slightly, or provide a 635 pointer to this subsection at the beginning of Section 3. 637 DNSSEC allocates two new bits in the DNS message header: The CD 638 (Checking Disabled) bit and the AD (Authentic Data) bit. 640 The CD bit is set in query messages by the resolver, and MUST be 641 copied into the response. If the CD bit is set to one, it indicates 642 that the resolver is willing to perform authentication, and thus that 643 the name server need not perform authentication on the RRsets in the 644 response. 646 Regardless of the setting of the CD bit, the name server MAY choose 647 whether or not to perform authentication according to the local name 648 server policy. The CD bit MAY be used in constructing the local name 649 server policy. If local name server policy does perform 650 authentication, any RRsets rejected by the local authentication 651 policy MUST NOT be returned in a response (regardless of the CD bit). 653 The AD bit is set by name servers, and indicates the data in the 654 response has been authenticated by the name server, according to the 655 local name server policy. The AD bit MUST NOT be set on a response 656 unless all of the RRsets in the Answer and Authority sections have 657 met the name server's local authentication policy. A resolver MUST 658 NOT trust the AD bit unless it communicates with the name server over 659 a secure transport mechanism and is explicitly configured to trust 660 the name server's policy. 662 3.8 Example DNSSEC Responses 664 The examples in this section use the following example zone to 665 demonstrate the formation of replies by an authoritative name server. 666 The zone has two name servers, a single child, and a wildcard MX RR. 667 The zone is completely signed and has a full NXT chain. 669 example.com. SOA (...) 670 SIG SOA ... 671 NS a.example.com. 672 NS b.example.com. 673 SIG NS ... 674 MX 10 a.example.com 675 SIG MX ... 676 KEY ... 677 SIG KEY ... 678 NXT *.example.com. 679 * MX 10 a.example.com. 680 SIG MX ... 681 NXT a.example.com. 682 a A 10.10.10.1 683 SIG A ... 684 NXT b.example.com. 685 b A 10.10.10.2 686 SIG A ... 687 NXT c.example.com. 688 c CNAME a.example.com. 689 SIG CNAME 690 NXT sub.example.com. 691 sub NS ns.sub.example.com. 692 SIG NS 693 DS ... 694 SIG DS 695 NXT *.example.com. 696 ns.sub A 10.10.10.3 697 sub-nosig NS ns.sub-nosig.example.com. 698 NXT example.com. 699 ns.sub-nosig A 10.10.10.4 701 A query to the authoritative name server for this zone for 702 QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce: 704 Flags: QR=1, AA=1, RCODE=0 (NOERROR) 705 EDNS: DO=1, size=4000 706 QUERY: 707 c.example.com. IN A 708 ANSWER: 709 c.example.com. IN A a.example.com 710 IN SIG CNAME 711 a.example.com. IN A 10.10.10.1 712 IN SIG A 713 AUTHORITY: 714 example.com. IN NS a.example.com. 715 IN NS b.example.com. 716 IN SIG NS ... 717 ADDITIONAL: 718 a.example.com. IN A 10.10.10.1 719 IN SIG A ... 720 b.example.com. IN A 10.10.10.2 721 IN SIG A ... 722 example.com. IN KEY ... 723 IN SIG KEY ... 725 A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would 726 results in a referral to a signed zone. The resolver can determine 727 that "sub.example.com" is signed because of the presence of the DS RR 728 with the hash of the "sub.example.com" zone key. 730 Flags: QR=1, AA=1, RCODE=0 (NOERROR) 731 EDNS: DO=1, size=4000 732 QUERY: 733 www.sub.example.com. IN A 734 ANSWER: 735 ;; empty 736 AUTHORITY: 737 sub.example.com. IN NS ns.sub.example.com. 738 IN DS ... 739 IN SIG DS ... 740 ADDITIONAL: 741 ns.sub.example.com. IN A 10.10.10.3 743 A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A 744 would result in a referral to an unsigned zone. The resolver knows 745 not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS 746 bit in the NXT RR bitmap in the referral is not set. Even if DNSSEC 747 RRs are present in responses from "sub-nosig.example.com" name 748 servers, the resolver will not be able to construct a authentication 749 chain, since there is a break between "sub-nosig.example.com" and its 750 delegating parent zone. 752 Flags: QR=1, AA=1, RCODE=0 (NOERROR) 753 EDNS: DO=1, size=4000 754 QUERY: 755 www.sub-nosig.example.com. IN A 756 ANSWER: 757 ;; empty 758 AUTHORITY: 759 sub-nosig.example.com. IN NS ns.sub-nosig.example.com. 760 IN NXT ;; (DS bit not set) 761 IN SIG NXT ... 762 ADDITIONAL: 763 ns.sub-nosig.example.com. IN A 10.10.10.4 765 A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name 766 error, because the name does not exist and is not covered by wildcard 767 expansion. Therefore, the name server must present proof that the 768 name does not exist, and that no wildcard expansion is present which 769 could have been used to answer the query. 771 Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN) 772 EDNS: DO=1, size=4000 773 QUERY: 774 f.example.com. IN A 775 ANSWER: 776 ;; empty 777 AUTHORITY: 778 example.com. IN SOA ... 779 IN SIG SOA ... 780 c.example.com. IN NXT sub.example.com. ... 781 IN SIG NXT ... 782 *.example.com. IN NXT a.example.com. ... 783 IN SIG NXT ... 784 ADDITIONAL: 785 example.com. IN KEY ... 786 IN SIG KEY ... 788 A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX 789 RR synthesized via wildcard expansion. The name server must prove 790 that no exact match exists. 792 Flags: QR=1, AA=1, RCODE=0 (NOERROR) 793 EDNS: DO=1, size=4000 794 QUERY: 795 f.example.com. IN MX 796 ANSWER: 797 f.example.com. IN MX 10 a.example.com. 798 IN SIG MX ... 799 AUTHORITY: 800 example.com. IN NS a.example.com. 801 IN NS b.example.com. 802 IN SIG NS ... 803 c.example.com. IN NXT sub.example.com. 804 IN SIG NXT ... 805 ADDITIONAL: 806 a.example.com. IN A 10.10.10.1 807 IN SIG A ... 808 b.example.com. IN A 10.10.10.2 809 IN SIG A ... 810 example.com. IN KEY ... 811 IN SIG KEY ... 813 If these responses came from a recursive name server which had all of 814 the necessary RRsets in its cache instead of from an authoritative 815 server, the only differences would be the TTLs and the header flags. 816 The AA bit would not be set, and the AD bit would be set if (and only 817 if) all the RRsets in a response passed the security policy checks of 818 the recursive name server. 820 4. Resolving 822 Editors' note: This section is still very rough, and some of the 823 text here duplicates text from other portions of this document. 824 This needs to be fixed (one way or another) during final editing. 825 Suggestions for better text would be welcome. 827 This section describes the behavior of entities which include 828 security-aware resolver functions. In many cases such functions will 829 be part of a security-aware recursive name server, but a stand-alone 830 security-aware resolver has many of the same requirements. Functions 831 specific to security-aware recursive name servers are described in a 832 separate subsection. 834 A security-aware resolver MUST include an EDNS [6] OPT pseudo-RR with 835 the DO [7] bit set to one when sending queries. 837 A security-aware resolver MUST support a message size of at least 838 1220 octets, SHOULD support a message size of 4000 octets, and MUST 839 advertise the supported message size using the "sender's UDP payload 840 size" field in the EDNS OPT pseudo-RR. A security-aware resolver 841 MUST handle fragmented UDP packets correctly regardless of whether 842 any such fragmented packets were received via IPv4 or IPv6. Please 843 see [8] for discussion of these requirements. 845 A security-aware resolver MUST support the signature verification 846 mechanisms described in Section 5, and MUST apply them to every 847 received response except when: 849 o The security-aware resolver is part of a security-aware recursive 850 name server, and the response is the result of recursion on behalf 851 of a query received with the CD bit set; 853 o The response is the result of a query generated directly via some 854 form of application interface which instructed the security-aware 855 resolver not to perform validation for this query; or 857 o Validation for this query has been disabled by local policy. 859 A security-aware resolver's support for signature verification MUST 860 include support for verification of wildcard owner names. 862 A security-aware resolver MUST attempt to retrieve missing DS, KEY, 863 or SIG RRs via explicit queries if the resolver needs these RRs in 864 order to perform signature verification. 866 A security-aware resolver MUST attempt to retrieve missing a NXT RR 867 which the resolver needs to authenticate a NODATA response. In 868 general it is not possible for a resolver to retrieve missing NXT 869 RRs, since the resolver will have no way of knowing the owner name of 870 the missing NXT RR, but in the specific case of a NODATA response, 871 the resolver does know the name of the missing NXT RR, and must 872 therefore attempt to retrieve it. 874 A security-aware resolver MUST be able to determine whether or not it 875 should expect a particular RRset to be signed. More precisely, a 876 security-aware resolver must be able to distinguish between three 877 cases: 879 1. An RRset for which the resolver is able to build a chain of 880 signed KEY and DS RRs from a trusted starting point to the RRset. 881 In this case, the RRset should be signed, and is subject to 882 signature validation as described above. 884 2. An RRset for which the resolver knows that it has no chain of 885 signed KEY and DS RRs from any trusted starting point to the 886 RRset. This can occur when the target RRset lies in an unsigned 887 zone or in a descendent of an unsigned zone. In this case, the 888 RRset may or may not be signed, but the resolver will not be able 889 to verify the signature. 891 3. An RRset for which the resolver is not able to determine whether 892 or not the RRset should be signed, because the resolver is not 893 able to obtain the necessary DNSSEC RRs. This can occur due when 894 the security-aware resolver is not able to contact security-aware 895 name servers for the relevant zones. 897 A security-aware resolver MUST be capable of being preconfigured with 898 at least one trusted public key, and SHOULD be capable of being 899 preconfigured with multiple trusted public keys. Since a security- 900 aware resolver will not be able to validate signatures without such a 901 preconfigured trusted key, the resolver SHOULD have some reasonably 902 robust mechanism for obtaining such keys when it boots. 904 Editors' note: Should support for multiple public keys be a MUST 905 rather than a SHOULD? 907 A security-aware resolver SHOULD cache each response as a single 908 atomic entry, indexed by the triple , with the 909 single atomic entry containing the entire answer, including the named 910 RRset and any associated DNSSEC RRs. The resolver SHOULD discard the 911 entire atomic entry when any of the RRs contained in it expire. 913 Editors' note: This is implementation advice which came out of 914 discussions at various workshops and investigations into possible 915 implementation issues with the (as yet unsettled) opt-in proposal. 917 All of this advice has been discussed in WG meetings, and as far 918 as the editors know these recommendations are not controversial, 919 but it is up to the WG to decide whether this sort of 920 implementation advice belongs in this document. 922 4.1 Recursive Name Servers 924 As explained in [9], a security-aware recursive name server is an 925 entity which acts in both the security-aware name server and 926 security-aware resolver roles. This section uses the terms "name 927 server side" and "resolver side" to refer to the code within a 928 security-aware recursive name server which implements the security- 929 aware name server role and the code which implements the security- 930 aware resolver role, respectively. 932 The resolver side of a security-aware recursive name server MUST set 933 the DO bit when sending requests, regardless of the state of the DO 934 bit in the initiating request received by the name server side. If 935 the initiating request does not have the DO bit set, the name server 936 side MUST remove any DNSSEC RRs from the response sent to the 937 initiating resolver, but the resolver side MUST follow the usual 938 rules for caching which would apply to any security-aware resolver. 940 A security-aware recursive name server SHOULD NOT attempt to answer a 941 query by piecing together cached data it received in response to 942 previous queries that requested different QNAMEs, QTYPEs, or 943 QCLASSes. A security-aware recursive name server SHOULD NOT use NXT 944 RRs from one negative response to synthesize a response for a 945 different query. A security-aware recursive name server SHOULD NOT 946 use a previous wildcard expansion to generate a response to a 947 different query. 949 Editors' note: Should any of the SHOULD NOTs in this paragraph be 950 MUST NOTs instead? 952 The name server side of a security-aware recursive name server MUST 953 pass the sense of the CD bit to the resolver side along with the rest 954 of an initiating query, so that the resolver side will know whether 955 whether or not it is required to verify the response data it returns 956 to the name server side. 958 Editors' note: What should a security-aware recursive name server 959 do if it receives a query with CD=1 and DO=0? 961 4.2 Stub resolvers 963 A security-aware stub resolver MUST include an EDNS [6] OPT pseudo-RR 964 with the DO [7] bit set to one when sending queries. 966 A security-aware stub resolver MUST support a message size of at 967 least 1220 octets, SHOULD support a message size of 4000 octets, and 968 MUST advertise the supported message size using the "sender's UDP 969 payload size" field in the EDNS OPT pseudo-RR. A security-aware stub 970 resolver MUST handle fragmented UDP packets correctly regardless of 971 whether any such fragmented packets were received via IPv4 or IPv6. 972 Please see [8] for discussion of these requirements. 974 A security-aware stub resolver MUST support the DNSSEC RR types, at 975 least to the extent of not mishandling responses just because they 976 contain DNSSEC RRs. A security-aware stub resolver MAY include the 977 DNSSEC RRs returned by a security-aware recursive name server as part 978 of the data that it the stub resolver hands back to the application 979 which invoked it, but is not required to do so. 981 A security-aware stub resolver SHOULD NOT set the CD bit when sending 982 queries, since, by definition, a security-aware stub resolver does 983 not validate signatures and thus depends on the security-aware 984 recursive name server to perform validation on its behalf. 986 Editors' note: Should this SHOULD NOT be a MUST NOT? 988 A security-aware stub resolver MUST NOT place any reliance on 989 signature validation allegedly performed on its behalf except when 990 the security-aware stub resolver obtained the data in question from a 991 trusted security-aware recursive name server via a secure channel. 993 5. Authenticating DNS Responses 995 In order to use DNSSEC RRs for authentication, a security-aware 996 resolver requires preconfigured knowledge of at least one 997 authenticated KEY RR. The process for obtaining and authenticating 998 this initial KEY RR is achieved via some external mechanism. For 999 example, a resolver could use some off-line authenticated exchange to 1000 obtain a zone's KEY RR or obtain a DS RR that identifies and 1001 authenticates a zone's KEY RR. The remainder of this section assumes 1002 that the resolver has somehow obtained an initial set of 1003 authenticated KEY RRs. 1005 An initial KEY RR can be used to authenticate a zone's apex KEY 1006 RRset. To authenticate an apex KEY RRset using an initial key, the 1007 resolver MUST: 1009 1. Verify that the initial KEY RR appears in the apex KEY RRset, and 1010 verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7) 1011 set to one. 1013 2. Verify that there is some SIG RR which covers the apex KEY RRset, 1014 and that the combination of the SIG RR and the initial KEY RR 1015 authenticates the KEY RRset. The process for using a SIG RR to 1016 authenticate an RRset is described in Section 5.2. 1018 Once the resolver has authenticated the apex KEY RRset using an 1019 initial KEY RR, delegations from that zone can be authenticated using 1020 DS RRs. This allows a resolver to start from an initial key, and use 1021 DS RRsets to proceed recursively down the DNS tree obtaining other 1022 apex KEY RRsets. If the resolver were preconfigured with a root KEY 1023 RR, and if every delegation had a DS RR associated with it, then the 1024 resolver could obtain any apex KEY RRset. The process of using DS 1025 RRs to authenticate referrals is described in Section 5.1. 1027 Once the resolver has authenticated a zone's apex KEY RRset, Section 1028 5.2 shows how the resolver can use KEY RRs in the apex KEY RRset and 1029 SIG RRs from the zone to authenticate any other RRsets in the zone. 1030 Section 5.3 shows how the resolver can use authenticated NXT RRsets 1031 from the zone to prove that an RRset is not present in the zone. 1033 When a resolver indicates support for DNSSEC, a security-aware name 1034 server should attempt to provide the necessary KEY, SIG, NXT, and DS 1035 RRsets in a response (see Section 3). However, a security-aware 1036 resolver may still receive a response which that lacks the 1037 appropriate DNSSEC RRs, whether due to configuration issues such as a 1038 security-oblivious recursive name server which accidently interfere 1039 with DNSSEC RRs or due to a deliberate attack in which an adversary 1040 forges a response, strips DNSSEC RRs from a response, or modifies a 1041 query so that DNSSEC RRs appear not to be requested. The absence of 1042 DNSSEC data in a response MUST NOT by itself be taken as an 1043 indication that no authentication information exists. 1045 A resolver SHOULD expect authentication information from signed 1046 zones. A resolver SHOULD believe that a zone is signed if the 1047 resolver has been configured with public key information for the 1048 zone, or if the zone's parent is signed and the delegation from the 1049 parent contains a DS RRset. 1051 5.1 Authenticating Referrals 1053 Once the apex KEY RRset for a signed parent zone has been 1054 authenticated, DS RRsets can be used to authenticate the delegation 1055 to a signed child zone. A DS RR identifies a KEY RR in the child 1056 zone's apex KEY RRset, and contains a cryptographic digest of the 1057 child zone's KEY RR. A strong cryptographic digest algorithm ensures 1058 that an adversary can not easily generate a KEY RR that matches the 1059 digest. Thus, authenticating the digest allows a resolver to 1060 authenticate the matching KEY RR. The resolver can then use this 1061 child KEY RR to authenticate the entire child apex KEY RRset. 1063 Given a DS RR for a delegation, the child zone's apex KEY RRset can 1064 be authenticated if all of the following hold: 1066 o The DS RR has been authenticated using some KEY RR in the parent's 1067 apex KEY RRset (see Section 5.2); 1069 o The Algorithm and Key Tag in the DS RR match the Algorithm field 1070 and the key tag of a KEY RR in the child zone's apex KEY RRset 1071 which, when hashed using the digest algorithm specified in the DS 1072 RR's Digest Type field, results in a digest value which matches 1073 the Digest field of the DS RR; and 1075 o The matching KEY RR in the child zone has the Zone Flag bit set to 1076 one, the corresponding private key has signed the child zone's 1077 apex KEY RRset, and the resulting SIG RR authenticates the child 1078 zone's apex KEY RRset. 1080 If the referral from the parent zone did not contain a DS RRset, the 1081 response should have included a signed NXT RRset proving that no DS 1082 RRset exists for the delegated name (see Section 3.4). A security- 1083 aware resolver MUST send the parent a query for the DS RRset if the 1084 referral includes neither a DS RRset nor a NXT RRset proving the 1085 nonexistence of the DS RRset (see Section 4). 1087 If the resolver authenticates an NXT RRset which proves that no DS 1088 RRset is present for this zone, then there is no authentication path 1089 leading from the parent to the child. If the resolver has an initial 1090 KEY RR which belongs to the child zone or to any delegation below the 1091 child zone, this initial KEY RR MAY be used to re-establish an 1092 authentication path. If no such initial KEY RR exists, the resolver 1093 can not authenticate RRsets at or below the child zone. 1095 Note that, for a signed delegation, there are two NXT RRs associated 1096 with the delegated name. One NXT RR resides in the parent zone, and 1097 can be used to prove whether a DS RRset exists for the delegated 1098 name. The second NXT RR resides in the child zone, and identifies 1099 which RRsets are present at the apex of the child zone. The parent 1100 NXT RR and child NXT RR can always be distinguished, since the SOA 1101 bit will be set in the child NXT RR and clear in the parent NXT RR. 1102 A security-aware resolver MUST use the parent NXT RR when attempting 1103 to prove that a DS RRset does not exist. 1105 5.2 Authenticating an RRSet Using a SIG RR 1107 A resolver can use a SIG RR and its corresponding KEY RR to attempt 1108 to authenticate RRsets. The resolver first checks the SIG RR to 1109 verify that it covers the RRset, has a valid time interval, and 1110 identifies a valid KEY RR. The resolver then constructs the 1111 canonical form of the signed data by appending the SIG RDATA 1112 (excluding the Signature Field) with the canonical form of the 1113 covered RRset. Finally, resolver uses the public key and signature 1114 to authenticate the signed data. Section 5.2.1, Section 5.2.2, and 1115 Section 5.2.3 describe each step in detail. 1117 5.2.1 Checking the SIG RR Validity 1119 A security-aware resolver can use a SIG RR to authenticate an RRset 1120 if all of the following conditions hold: 1122 o The SIG RR and the RRset MUST have the same owner name and the 1123 same class; 1125 o The SIG RR's Signer's Name field MUST be the name of the zone that 1126 contains the RRset; 1128 o The SIG RR's Type Covered field MUST equal the RRset's type; 1130 o The number of labels in the RRset owner name MUST be greater than 1131 or equal to the value in the SIG RR's Labels field; 1133 o The resolver's notion of the current time MUST be less than or 1134 equal to the time listed in the SIG RR's Expiration field; 1136 o The resolver's notion of the current time MUST be greater than or 1137 equal to the time listed in the SIG RR's Inception field; 1139 o The SIG RR's Signer's Name, Algorithm, and Key Tag fields MUST 1140 match the owner name, algorithm, and key tag for some KEY RR in 1141 the zone's apex KEY RRset; 1143 o The matching KEY RR MUST be present in the zone's apex KEY RRset, 1144 and MUST have the Zone Flag bit (KEY RDATA Flag bit 7) set to one. 1146 It is possible for more than one KEY RR to match the conditions 1147 above. In this case, the resolver can not predetermine which KEY RR 1148 to use to authenticate the signature, MUST try each matching KEY RR 1149 until the resolver has either validated the signature or has run out 1150 of matching keys to try. 1152 Note that this authentication process is only meaningful if the 1153 resolver authenticates the KEY RR before using it to validate 1154 signatures. The matching KEY RR is considered to be authentic if: 1156 o The apex KEY RRset containing the KEY RR is considered authentic; 1157 or 1159 o The RRset covered by the SIG RR is the apex KEY RRset itself, and 1160 the KEY RR either matches an authenticated DS RR from the parent 1161 zone or matches a DS RR or KEY RR which the resolver has been 1162 preconfigured to believe to be authentic. 1164 5.2.2 Reconstructing the Signed Data 1166 Once the SIG RR has met the validity requirements described in 1167 Section 5.2.1, the resolver needs to reconstruct the original signed 1168 data. The original signed data includes SIG RDATA (excluding the 1169 Signature field) and the canonical form of the RRset. Aside from 1170 being ordered, the canonical form of the RRset might also differ from 1171 the received RRset due to DNS name compression, decremented TTLs, or 1172 wildcard expansion. The resolver should use the following to 1173 reconstruct the original signed data: 1175 signed_data = SIG_RDATA | RR(1) | RR(2)... where 1177 "|" denotes concatenation 1179 SIG_RDATA is the wire format of the SIG RDATA fields with 1180 the Signature field excluded and the Signer's Name in 1181 canonical form. 1183 RR(i) = name | class | type | OrigTTL | RDATA length | RDATA 1184 name is calculated according to the function below 1186 class is the RRset's class 1188 type is the RRset type and all RRs in the class 1190 OrigTTL is the value from the SIG Original TTL field 1192 All names in the RDATA field are in canonical form 1194 The set of all RR(i) is sorted into canonical order. 1196 To calculate the name: 1197 let sig_labels = the value of the SIG Labels field 1199 let fqdn = RRset's fully qualified domain name in 1200 canonical form 1202 let fqdn_labels = RRset's fully qualified domain name in 1203 canonical form 1205 if sig_labels = fqdn_labels, 1206 name = fqdn 1208 if sig_labels < fqdn_labels, 1209 name = "*." | the leftmost sig_label labels of the 1210 fqdn 1212 if sig_labels > fqdn 1213 the SIG RR did not pass the necessary validation 1214 checks and MUST NOT be used to authenticate this 1215 RRset. 1217 Editors' note: The algorithm above needs to be cross-checked very 1218 carefully against the definitions in [10]. 1220 Section 5.4.1 gives an example of original name calculation. The 1221 canonical forms for names and RRsets are defined in [10]. 1223 NXT RRsets at a delegation boundary require special processing. 1224 There are two distinct NXT RRsets associated with a signed delegated 1225 name. One NXT RRset resides in the parent zone, and specifies which 1226 RRset are present at the parent zone. The second NXT RRset resides 1227 at the child zone, and identifies which RRsets are present at the 1228 apex in the child zone. The parent NXT RRset and child NXT RRset can 1229 always be distinguished since only the child NXT RRs will specify an 1230 SOA RRset exists at the name. When reconstructing the original NXT 1231 RRset for the delegation from the parent zone, the NXT RRs MUST NOT 1232 be combined with NXT RRs from the child zone, and when reconstructing 1233 the original NXT RRset for the apex of the child zone, the NXT RRs 1234 MUST NOT be combined with NXT RRs from the parent zone. 1236 Note also that each of the two NXT RRsets at a delegation point has a 1237 corresponding SIG RR with an owner name matching the delegated name, 1238 and each of these SIG RRs is authoritative data associated with the 1239 same zone which contains the corresponding NXT RRset. If necessary, 1240 a resolver can tell these SIG RRs apart by checking the Signer's Name 1241 field. 1243 5.2.3 Checking the Signature 1245 Once the resolver has validated the SIG RR as described in Section 1246 5.2.1 and reconstructed the original signed data as described in 1247 Section 5.2.2, the resolver can attempt to use the cryptographic 1248 signature to authenticate the signed data, and thus (finally!) 1249 authenticate the RRset. 1251 The Algorithm field in the SIG RR identifies the cryptographic 1252 algorithm to generate the signature. The signature itself is 1253 contained in the Signature field of the SIG RDATA, and the public key 1254 to used generate the signature is contained in the Public Key field 1255 of the matching KEY RR(s) (found in Section 5.2.1). [10] provides a 1256 list of algorithm types, and provides pointers to the documents that 1257 define each algorithm's use. 1259 Note that it is possible for more than one KEY RR to match the 1260 conditions in Section 5.2.1. In this case, the resolver can only 1261 determine which KEY RR by trying each matching key until the resolver 1262 either succeeds in validating the signature or runs out of keys to 1263 try. 1265 If the Labels field of the SIG RR is not equal to the number of 1266 labels in the RRset's fully qualified owner name, then the RRset is 1267 either invalid or the result of wildcard expansion. The resolver 1268 MUST verify that wildcard expansion was applied properly before 1269 considering the RRset to be authentic. Section 5.2.4 describes how 1270 to determine whether a wildcard was applied properly. 1272 If other SIG RRs also cover this SIG RR, the local resolver security 1273 policy determines whether the resolver also needs to test these SIG 1274 RRs, and determines how to resolve conflicts if these SIG RRs lead to 1275 differing results. 1277 If the resolver accepts the RRset as authentic, the resolver MUST set 1278 the SIG RR's TTL and the TTL of each RR in the authenticated RRset to 1279 the minimum of: 1281 o The RRset's TTL as received in the response; 1283 o The SIG RR's TTL as received in the response; and 1285 o The value in the SIG RR's Original TTL field. 1287 5.2.4 Authenticating A Wildcard Expanded RRset Positive Response 1289 If the number of labels in an RRset's fully qualified domain name is 1290 greater than the Labels field in the covering SIG RDATA, then the 1291 RRset and its covering SIG RR were created as a result of wildcard 1292 expansion. Once the resolver has verified the signature as described 1293 in Section 5.2, the resolver must take additional steps to verify the 1294 non-existence of an exact match or closer wildcard match for the 1295 query. Section 5.3 discusses these steps. 1297 Note that the response received by the resolver should include all 1298 NXT RRs needed to authenticate the response (see Section 3.3). 1300 5.3 Authenticated Denial of Existence 1302 A resolver can use authenticated NXT RRs to prove that an RRset is 1303 not present in a signed zone. Security-aware name servers should 1304 automatically include any necessary NXT RRs for signed zones in their 1305 responses to security-aware resolvers. 1307 Security-aware resolvers MUST first authenticate NXT RRsets according 1308 to the standard RRset authentication rules described in Section 5.2, 1309 then apply the NXT RRsets as follows: 1311 o If the requested RR name matches the owner name of an 1312 authenticated NXT RR, then the NXT RR's type bit map field lists 1313 all RR types present at that owner name, and a resolver can prove 1314 that the requested RR type does not exist by checking for the RR 1315 type in the bit map. Since the existence of the authenticated NXT 1316 RR proves that the owner name exists in the zone, wildcard 1317 expansion could not have been used to match the requested RR owner 1318 name and type. 1320 o If the requested RR name would appear after an authenticated NXT 1321 RR owner name and before the name listed in that NXT RR's Next 1322 Domain Name field according to the canonical DNS name order 1323 defined in [10], then no exact match for the requested RR name 1324 exists in the zone. However, it is possible that a wildcard could 1325 be used to match the requested RR owner name and type, so proving 1326 that the requested RRset does not exist also requires proving that 1327 no possible wildcard exists which could have been used to generate 1328 a positive response. 1330 To prove non-existence of an RRset, the resolver must be able to 1331 verify both that the queried RRset does not exist and that no 1332 relevant wildcard RRset exists. Proving this may require more than 1333 one NXT RRset from the zone. If the complete set of necessary NXT 1334 RRsets is not present in a response (perhaps due to truncation), then 1335 a security-aware resolver MUST resend the query in order to attempt 1336 to obtain the full collection of NXT RRs necessary to verify non- 1337 existence of the requested RRset. As with all DNS operations, 1338 however, the resolver MUST bound the work it puts into answering any 1339 particular query. 1341 5.4 Example 1343 5.4.1 Example of Re-Constructing the Original Owner Name 1345 Suppose that a security-aware resolver receives a response containing 1346 an answer RRset with an owner name of is "www.a.b.c.example.com". 1347 This fully qualified domain name has 6 labels: "www", "a", "b", "c", 1348 "example", and "com". What name the resolver should use when 1349 reconstructing the original signed data depends on the value of the 1350 SIG RR's Labels field. 1352 If the value of the SIG RR's Labels field is 6, then the SIG RR's 1353 Labels field matches the number of labels in the owner name, and the 1354 resolver should assume that this RRset is not the result of wildcard 1355 expansion. The resolver should therefore use "www.a.b.c.example.com" 1356 as the owner name when reconstructing the original signed data for 1357 the signature check. 1359 If the value of the SIG RR's Labels field is less than 6, then the 1360 SIG RR's Labels count is less than the number of labels in the 1361 RRset's owner name, and the resolver should assume that this RRset is 1362 the result of wildcard expansion. The resolver should therefore 1363 reconstruct the original owner name by replacing the labels which 1364 appear to be the result of wildcard expansion with a single "*." 1365 label. For example, if the SIG RR's Labels field is 3, the resolver 1366 should reconstruct the original owner name by prepending "*." to the 1367 last 3 labels of the owner name of the answer RRset. Thus, the 1368 resolver should use "*.c.example.com" as the owner name when 1369 reconstructing the original signed data. 1371 If the value of the SIG RR's Labels field is greater than 6, then 1372 this SIG RR cannot possibly be valid for the answer RRset, and there 1373 is no point in attempting to validate the signature. 1375 5.4.2 Examples of Authenticating a Response 1377 Editors' note: Eventually this will be an example of the 1378 authentication process for "www.example.com", starting from an 1379 initial root key. 1381 Editors' note: Eventually this will be an example of the 1382 authentication process for non-existent "www.a.b.c.example.com", 1383 starting from an initial root key. 1385 6. IANA Considerations 1387 This document introduces no IANA considerations. 1389 [10] contains a complete review of the IANA considerations introduced 1390 by DNSSEC. 1392 Editors' note: This may not be true anymore, since the AD and CD 1393 bit definitions are now in this document rather than in [10]. 1395 7. Security Considerations 1397 This document describes how the DNS security extensions use public 1398 key cryptography to sign and authenticate DNS resource record sets. 1400 At this time, at least two substantial elements of the DNSSEC 1401 specification have yet to be decided by the working group. The open 1402 opt-in issue would change elements such as what RRsets must be 1403 signed, would impact how wildcards are used, and would replace 1404 authenticated denial of existence with authenticated denial of 1405 security. Handling of the AD bit is also undecided. The AD bit (as 1406 currently defined) is used to indicate the security status of RRsets 1407 in the response. These items clearly raise security considerations 1408 and will be addressed here as these issues are resolved in the 1409 working group. 1411 DNSSEC introduces a number of denial of service issues. These issues 1412 will also be addressed in a future version of these security 1413 considerations. 1415 Please see [9] for general security considerations related to DNSSEC. 1417 8. Acknowledgements 1419 This document was created from the input and ideas of several members 1420 of the DNS Extensions Working Group and working group mailing list. 1421 The co-authors of this draft would like to express their thanks for 1422 the comments and suggestions received during the revision of these 1423 security extension specifications. 1425 Normative References 1427 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 1428 13, RFC 1034, November 1987. 1430 [2] Mockapetris, P., "Domain names - implementation and 1431 specification", STD 13, RFC 1035, November 1987. 1433 [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1434 August 1996. 1436 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1437 Levels", BCP 14, RFC 2119, March 1997. 1439 [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 1440 RFC 2181, July 1997. 1442 [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 1443 August 1999. 1445 [7] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, 1446 December 2001. 1448 [8] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 1449 message size requirements", RFC 3226, December 2001. 1451 [9] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, 1452 "DNS Security Introduction and Requirements", draft-ietf- 1453 dnsext-dnssec-intro-05 (work in progress), February 2003. 1455 [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, 1456 "Resource Records for DNS Security Extensions", draft-ietf- 1457 dnsext-dnssec-records-04 (work in progress), February 2003. 1459 [11] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft- 1460 ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003. 1462 Informative References 1464 [12] Eastlake, D., "Domain Name System Security Extensions", RFC 1465 2535, March 1999. 1467 [13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 1468 2930, September 2000. 1470 [14] Eastlake, D., "DNS Request and Transaction Signatures ( 1471 SIG(0)s)", RFC 2931, September 2000. 1473 [15] Gudmundsson, O., "Delegation Signer Resource Record", draft- 1474 ietf-dnsext-delegation-signer-12 (work in progress), December 1475 2002. 1477 Authors' Addresses 1479 Roy Arends 1480 Telematica Instituut 1481 Drienerlolaan 5 1482 7522 NB Enschede 1483 NL 1485 EMail: roy.arends@telin.nl 1487 Matt Larson 1488 VeriSign, Inc. 1489 21345 Ridgetop Circle 1490 Dulles, VA 20166-6503 1491 USA 1493 EMail: mlarson@verisign.com 1495 Rob Austein 1496 Internet Software Consortium 1497 40 Gavin Circle 1498 Reading, MA 01867 1499 USA 1501 EMail: sra@isc.org 1502 Dan Massey 1503 USC Information Sciences Institute 1504 3811 N. Fairfax Drive 1505 Arlington, VA 22203 1506 USA 1508 EMail: masseyd@isi.edu 1510 Scott Rose 1511 National Institute for Standards and Technology 1512 100 Bureau Drive 1513 Gaithersburg, MD 20899-8920 1514 USA 1516 EMail: scott.rose@nist.gov 1518 Appendix A. Algorithm For Handling Wildcard Expansion 1520 For zone (Z) and a name (N) that may occur in Z, the following 1521 algorithm finds all wildcard RRsets that match N or returns an NXT 1522 RRset that proves no wildcard expansion matches N. The algorithm was 1523 written for clarity, not efficiency: 1525 0. INPUT: a name (N) and a zone (Z). 1526 INIT: NXT_SET = NULL 1528 1. Construct S = sequence of all names in Z, sorted 1529 into canonical order. 1531 2. If N exists in S 1532 There is an exact match for N. 1533 Return all RRsets associated with N 1534 Else 1535 Add the name that would immediately 1536 precede N in S to NXT_SET. 1537 EndIf 1539 3. Replace the leftmost label of N with * 1541 4. If N exists in S 1542 There is a positive wildcard match for N. 1543 Return all RRsets associated with N 1544 Else 1545 Add the NXT for name that would immediately 1546 precede N in S to NXT_SET. 1547 EndIf 1549 5. Remove the leading * from N. 1551 6. If N exists in S 1552 There is a name that terminates the wildcard search. 1553 Add the NXT for N to NXT_SET and return NXT_SET. 1554 Else 1555 Goto Step 3 1556 EndIf 1558 Note: the algorithm is guaranteed to terminate since 1559 eventually there will be a match or N will be 1560 reduced to zone name itself and the zone name 1561 must exist in S. 1563 Full Copyright Statement 1565 Copyright (C) The Internet Society (2003). All Rights Reserved. 1567 This document and translations of it may be copied and furnished to 1568 others, and derivative works that comment on or otherwise explain it 1569 or assist in its implementation may be prepared, copied, published 1570 and distributed, in whole or in part, without restriction of any 1571 kind, provided that the above copyright notice and this paragraph are 1572 included on all such copies and derivative works. However, this 1573 document itself may not be modified in any way, such as by removing 1574 the copyright notice or references to the Internet Society or other 1575 Internet organizations, except as needed for the purpose of 1576 developing Internet standards in which case the procedures for 1577 copyrights defined in the Internet Standards process must be 1578 followed, or as required to translate it into languages other than 1579 English. 1581 The limited permissions granted above are perpetual and will not be 1582 revoked by the Internet Society or its successors or assigns. 1584 This document and the information contained herein is provided on an 1585 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1586 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1587 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1588 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1589 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1591 Acknowledgement 1593 Funding for the RFC Editor function is currently provided by the 1594 Internet Society.