idnits 2.17.1 draft-ietf-dnsext-dnssec-opt-in-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 693. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 22, 2006) is 6511 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3655 (ref. '2') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-04) exists of draft-ietf-dnsext-dnssec-experiments-01 -- Obsolete informational reference (is this intentional?): RFC 2137 (ref. '9') (Obsoleted by RFC 3007) -- Obsolete informational reference (is this intentional?): RFC 3090 (ref. '10') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT R. Arends 3 Internet-Draft Nominet 4 Intended status: Experimental M. Kosters 5 Expires: December 24, 2006 D. Blacka 6 VeriSign, Inc. 7 June 22, 2006 9 DNSSEC Opt-In 10 draft-ietf-dnsext-dnssec-opt-in-09 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 30 http://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 December 24, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 In the DNS security extensions (DNSSEC), delegations to unsigned 44 subzones are cryptographically secured. Maintaining this 45 cryptography is not always practical or necessary. This document 46 describes an experimental "Opt-In" model that allows administrators 47 to omit this cryptography and manage the cost of adopting DNSSEC with 48 large zones. 50 Table of Contents 52 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4 55 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Server Considerations . . . . . . . . . . . . . . . . . . 5 57 4.1.1. Delegations Only . . . . . . . . . . . . . . . . . . . 6 58 4.1.2. Insecure Delegation Responses . . . . . . . . . . . . 6 59 4.1.3. Dynamic Update . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Client Considerations . . . . . . . . . . . . . . . . . . 6 61 4.2.1. Delegations Only . . . . . . . . . . . . . . . . . . . 6 62 4.2.2. Validation Process Changes . . . . . . . . . . . . . . 6 63 4.2.3. NSEC Record Caching . . . . . . . . . . . . . . . . . 7 64 4.2.4. Use of the AD bit . . . . . . . . . . . . . . . . . . 8 65 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Implementing Opt-In using "Views" . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . . . 16 78 1. Definitions and Terminology 80 Throughout this document, familiarity with the DNS system (RFC 1035 81 [1]), DNS security extensions ([3], [4], and [5], referred to in this 82 document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090 83 [10]) is assumed. 85 The following abbreviations and terms are used in this document: 87 RR: is used to refer to a DNS resource record. 88 RRset: refers to a Resource Record Set, as defined by [8]. In this 89 document, the RRset is also defined to include the covering RRSIG 90 records, if any exist. 91 signed name: refers to a DNS name that has, at minimum, a (signed) 92 NSEC record. 93 unsigned name: refers to a DNS name that does not (at least) have a 94 NSEC record. 95 covering NSEC record/RRset: is the NSEC record used to prove 96 (non)existence of a particular name or RRset. This means that for 97 a RRset or name 'N', the covering NSEC record has the name 'N', or 98 has an owner name less than 'N' and "next" name greater than 'N'. 99 delegation: refers to a NS RRset with a name different from the 100 current zone apex (non-zone-apex), signifying a delegation to a 101 subzone. 102 secure delegation: refers to a signed name containing a delegation 103 (NS RRset), and a signed DS RRset, signifying a delegation to a 104 signed subzone. 105 insecure delegation: refers to a signed name containing a delegation 106 (NS RRset), but lacking a DS RRset, signifying a delegation to an 107 unsigned subzone. 108 Opt-In insecure delegation: refers to an unsigned name containing 109 only a delegation NS RRset. The covering NSEC record uses the 110 Opt-In methodology described in this document. 112 The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [7]. 116 2. Overview 118 The cost to cryptographically secure delegations to unsigned zones is 119 high for large delegation-centric zones and zones where insecure 120 delegations will be updated rapidly. For these zones, the costs of 121 maintaining the NSEC record chain may be extremely high relative to 122 the gain of cryptographically authenticating existence of unsecured 123 zones. 125 This document describes an experimental method of eliminating the 126 superfluous cryptography present in secure delegations to unsigned 127 zones. Using "Opt-In", a zone administrator can choose to remove 128 insecure delegations from the NSEC chain. This is accomplished by 129 extending the semantics of the NSEC record by using a redundant bit 130 in the type map. 132 3. Experimental Status 134 This document describes an EXPERIMENTAL extension to DNSSEC. It 135 interoperates with non-experimental DNSSEC using the technique 136 described in [6]. This experiment is identified with the following 137 private algorithms (using algorithm 253): 139 "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, 140 and 141 "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, 142 RSASHA1. 144 Servers wishing to sign and serve zones that utilize Opt-In MUST sign 145 the zone with only one or more of these private algorithms and MUST 146 NOT use any other algorithms. 148 Resolvers MUST NOT apply the opt-in validation rules described in 149 this document unless a zone is signed using one or more of these 150 private algorithms. 152 This experimental protocol relaxes the restriction that validators 153 MUST ignore the setting of the NSEC bit in the type map as specified 154 in RFC 4035 [5] section 5.4. 156 The remainder of this document assumes that the servers and resolvers 157 involved are aware of and are involved in this experiment. 159 4. Protocol Additions 161 In DNSSEC, delegation NS RRsets are not signed, but are instead 162 accompanied by a NSEC RRset of the same name and (possibly) a DS 163 record. The security status of the subzone is determined by the 164 presence or absence of the DS RRset, cryptographically proven by the 165 NSEC record. Opt-In expands this definition by allowing insecure 166 delegations to exist within an otherwise signed zone without the 167 corresponding NSEC record at the delegation's owner name. These 168 insecure delegations are proven insecure by using a covering NSEC 169 record. 171 Since this represents a change of the interpretation of NSEC records, 172 resolvers must be able to distinguish between RFC standard DNSSEC 173 NSEC records and Opt-In NSEC records. This is accomplished by 174 "tagging" the NSEC records that cover (or potentially cover) insecure 175 delegation nodes. This tag is indicated by the absence of the NSEC 176 bit in the type map. Since the NSEC bit in the type map merely 177 indicates the existence of the record itself, this bit is redundant 178 and safe for use as a tag. 180 An Opt-In tagged NSEC record does not assert the (non)existence of 181 the delegations that it covers (except for a delegation with the same 182 name). This allows for the addition or removal of these delegations 183 without recalculating or resigning records in the NSEC chain. 184 However, Opt-In tagged NSEC records do assert the (non)existence of 185 other RRsets. 187 An Opt-In NSEC record MAY have the same name as an insecure 188 delegation. In this case, the delegation is proven insecure by the 189 lack of a DS bit in type map and the signed NSEC record does assert 190 the existence of the delegation. 192 Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC 193 records and standard DNSSEC NSEC records. If a NSEC record is not 194 Opt-In, there MUST NOT be any insecure delegations (or any other 195 records) between it and the RRsets indicated by the 'next domain 196 name' in the NSEC RDATA. If it is Opt-In, there MUST only be 197 insecure delegations between it and the next node indicated by the 198 'next domain name' in the NSEC RDATA. 200 In summary, 202 o An Opt-In NSEC type is identified by a zero-valued (or not- 203 specified) NSEC bit in the type bit map of the NSEC record. 204 o A standard DNSSEC NSEC type is identified by a one-valued NSEC bit 205 in the type bit map of the NSEC record. 207 and, 209 o An Opt-In NSEC record does not assert the non-existence of a name 210 between its owner name and "next" name, although it does assert 211 that any name in this span MUST be an insecure delegation. 212 o An Opt-In NSEC record does assert the (non)existence of RRsets 213 with the same owner name. 215 4.1. Server Considerations 217 Opt-In imposes some new requirements on authoritative DNS servers. 219 4.1.1. Delegations Only 221 This specification dictates that only insecure delegations may exist 222 between the owner and "next" names of an Opt-In tagged NSEC record. 223 Signing tools MUST NOT generate signed zones that violate this 224 restriction. Servers MUST refuse to load and/or serve zones that 225 violate this restriction. Servers also MUST reject AXFR or IXFR 226 responses that violate this restriction. 228 4.1.2. Insecure Delegation Responses 230 When returning an Opt-In insecure delegation, the server MUST return 231 the covering NSEC RRset in the Authority section. 233 In standard DNSSEC, NSEC records already must be returned along with 234 the insecure delegation. The primary difference that this proposal 235 introduces is that the Opt-In tagged NSEC record will have a 236 different owner name from the delegation RRset. This may require 237 implementations to search for the covering NSEC RRset. 239 4.1.3. Dynamic Update 241 Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In 242 particular, it introduces the need for rules that describe when to 243 add or remove a delegation name from the NSEC chain. This document 244 does not attempt to define these rules. Until these rules are 245 defined, servers MUST NOT process DNS Dynamic Update requests against 246 zones that use Opt-In NSEC records. Servers SHOULD return responses 247 to update requests with RCODE=REFUSED. 249 4.2. Client Considerations 251 Opt-In imposes some new requirements on security-aware resolvers 252 (caching or otherwise). 254 4.2.1. Delegations Only 256 As stated in Section 4.1 above, this specification restricts the 257 namespace covered by Opt-In tagged NSEC records to insecure 258 delegations only. Clients are not expected to take any special 259 measures to enforce this restriction; instead, it forms an underlying 260 assumption that clients may rely on. 262 4.2.2. Validation Process Changes 264 This specification does not change the resolver's resolution 265 algorithm. However, it does change the DNSSEC validation process. 267 4.2.2.1. Referrals 269 Resolvers MUST be able to use Opt-In tagged NSEC records to 270 cryptographically prove the validity and security status (as 271 insecure) of a referral. Resolvers determine the security status of 272 the referred-to zone as follows: 274 o In standard DNSSEC, the security status is proven by the existence 275 or absence of a DS RRset at the same name as the delegation. The 276 existence of the DS RRset indicates that the referred-to zone is 277 signed. The absence of the DS RRset is proven using a verified 278 NSEC record of the same name that does not have the DS bit set in 279 the type map. This NSEC record MAY also be tagged as Opt-In. 280 o Using Opt-In, the security status is proven by the existence of a 281 DS record (for signed) or the presence of a verified Opt-In tagged 282 NSEC record that covers the delegation name. That is, the NSEC 283 record does not have the NSEC bit set in the type map, and the 284 delegation name falls between the NSEC's owner and "next" name. 286 Using Opt-In does not substantially change the nature of following 287 referrals within DNSSEC. At every delegation point, the resolver 288 will have cryptographic proof that the referred-to subzone is signed 289 or unsigned. 291 4.2.2.2. Queries for DS Resource Records 293 Since queries for DS records are directed to the parent side of a 294 zone cut (see [4], section 5), negative responses to these queries 295 may be covered by an Opt-In flagged NSEC record. 297 Resolvers MUST be able to use Opt-In tagged NSEC records to 298 cryptographically prove the validity and security status of negative 299 responses to queries for DS records. In particular, a NOERROR/NODATA 300 (i.e., RCODE=3, but the answer section is empty) response to a DS 301 query may be proven by an Opt-In flagged covering NSEC record, rather 302 than an NSEC record matching the query name. 304 4.2.3. NSEC Record Caching 306 Caching resolvers MUST be able to retrieve the appropriate covering 307 Opt-In NSEC record when returning referrals that need them. This 308 requirement differs from standard DNSSEC in that the covering NSEC 309 will not have the same owner name as the delegation. Some 310 implementations may have to use new methods for finding these NSEC 311 records. 313 4.2.4. Use of the AD bit 315 The AD bit, as defined by [2] and [5], MUST NOT be set when: 317 o sending a Name Error (RCODE=3) response where the covering NSEC is 318 tagged as Opt-In. 319 o sending an Opt-In insecure delegation response, unless the 320 covering (Opt-In) NSEC record's owner name equals the delegation 321 name. 322 o sending an NOERROR/NODATA response when query type is DS and the 323 covering NSEC is tagged as Opt-In, unless NSEC record's owner name 324 matches the query name. 326 This rule is based on what the Opt-In NSEC record actually proves: 327 for names that exist between the Opt-In NSEC record's owner and 328 "next" names, the Opt-In NSEC record cannot prove the non-existence 329 or existence of the name. As such, not all data in the response has 330 been cryptographically verified, so the AD bit cannot be set. 332 5. Benefits 334 Using Opt-In allows administrators of large and/or changing 335 delegation-centric zones to minimize the overhead involved in 336 maintaining the security of the zone. 338 Opt-In accomplishes this by eliminating the need for NSEC records for 339 insecure delegations. This, in a zone with a large number of 340 delegations to unsigned subzones, can lead to substantial space 341 savings (both in memory and on disk). Additionally, Opt-In allows 342 for the addition or removal of insecure delegations without modifying 343 the NSEC record chain. Zones that are frequently updating insecure 344 delegations (e.g., TLDs) can avoid the substantial overhead of 345 modifying and resigning the affected NSEC records. 347 6. Example 349 Consider the zone EXAMPLE, shown below. This is a zone where all of 350 the NSEC records are tagged as Opt-In. 352 Example A: Fully Opt-In Zone. 354 EXAMPLE. SOA ... 355 EXAMPLE. RRSIG SOA ... 356 EXAMPLE. NS FIRST-SECURE.EXAMPLE. 357 EXAMPLE. RRSIG NS ... 358 EXAMPLE. DNSKEY ... 359 EXAMPLE. RRSIG DNSKEY ... 360 EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. ( 361 SOA NS RRSIG DNSKEY ) 362 EXAMPLE. RRSIG NSEC ... 364 FIRST-SECURE.EXAMPLE. A ... 365 FIRST-SECURE.EXAMPLE. RRSIG A ... 366 FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG 367 FIRST-SECURE.EXAMPLE. RRSIG NSEC ... 369 NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. 370 NS.NOT-SECURE.EXAMPLE. A ... 372 NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. 373 NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG 374 NOT-SECURE-2.EXAMPLE RRSIG NSEC ... 376 SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. 377 SECOND-SECURE.EXAMPLE. DS ... 378 SECOND-SECURE.EXAMPLE. RRSIG DS ... 379 SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY 380 SECOND-SECURE.EXAMPLE. RRSIG NSEC ... 382 UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. 383 NS.UNSIGNED.EXAMPLE. A ... 385 Example A. 387 In this example, a query for a signed RRset (e.g., "FIRST- 388 SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- 389 SECURE.EXAMPLE A") will result in a standard DNSSEC response. 391 A query for a nonexistent RRset will result in a response that 392 differs from standard DNSSEC by: the NSEC record will be tagged as 393 Opt-In, there may be no NSEC record proving the non-existence of a 394 matching wildcard record, and the AD bit will not be set. 396 A query for an insecure delegation RRset (or a referral) will return 397 both the answer (in the Authority section) and the corresponding 398 Opt-In NSEC record to prove that it is not secure. 400 Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A 402 RCODE=NOERROR, AD=0 404 Answer Section: 406 Authority Section: 407 UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE 408 SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS 409 SECOND-SECURE.EXAMPLE. RRSIG NSEC ... 411 Additional Section: 412 NS.UNSIGNED.EXAMPLE. A ... 414 Example A.1 416 In the Example A.1 zone, the EXAMPLE. node MAY use either style of 417 NSEC record, because there are no insecure delegations that occur 418 between it and the next node, FIRST-SECURE.EXAMPLE. In other words, 419 Example A would still be a valid zone if the NSEC record for EXAMPLE. 420 was changed to the following RR: 422 EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS 423 RRSIG DNSKEY NSEC ) 425 However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND- 426 SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure 427 delegations in the range they define. (NOT-SECURE.EXAMPLE. and 428 UNSIGNED.EXAMPLE., respectively). 430 NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is 431 part of the NSEC chain and also covered by an Opt-In tagged NSEC 432 record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be 433 removed from the zone without modifying and resigning the prior NSEC 434 record. Delegations with names that fall between NOT-SECURE- 435 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without 436 resigning any NSEC records. 438 7. Transition Issues 440 Opt-In is not backwards compatible with standard DNSSEC and is 441 considered experimental. Standard DNSSEC compliant implementations 442 would not recognize Opt-In tagged NSEC records as different from 443 standard NSEC records. Because of this, standard DNSSEC 444 implementations, if they were to validate Opt-In style responses, 445 would reject all Opt-In insecure delegations within a zone as 446 invalid. However, by only signing with private algorithms, standard 447 DNSSEC implementations will treat Opt-In responses as unsigned. 449 It should be noted that all elements in the resolution path between 450 (and including) the validator and the authoritative name server must 451 be aware of the Opt-In experiment and implement the Opt-In semantics 452 for successful validation to be possible. In particular, this 453 includes any caching middleboxes between the validator and 454 authoritative name server. 456 8. Security Considerations 458 Opt-In allows for unsigned names, in the form of delegations to 459 unsigned subzones, to exist within an otherwise signed zone. All 460 unsigned names are, by definition, insecure, and their validity or 461 existence cannot by cryptographically proven. 463 In general: 465 o Records with unsigned names (whether existing or not) suffer from 466 the same vulnerabilities as records in an unsigned zone. These 467 vulnerabilities are described in more detail in [12] (note in 468 particular sections 2.3, "Name Games" and 2.6, "Authenticated 469 Denial"). 470 o Records with signed names have the same security whether or not 471 Opt-In is used. 473 Note that with or without Opt-In, an insecure delegation may have its 474 contents undetectably altered by an attacker. Because of this, the 475 primary difference in security that Opt-In introduces is the loss of 476 the ability to prove the existence or nonexistence of an insecure 477 delegation within the span of an Opt-In NSEC record. 479 In particular, this means that a malicious entity may be able to 480 insert or delete records with unsigned names. These records are 481 normally NS records, but this also includes signed wildcard 482 expansions (while the wildcard record itself is signed, its expanded 483 name is an unsigned name), which can be undetectably removed or used 484 to replace an existing unsigned delegation. 486 For example, if a resolver received the following response from the 487 example zone above: 489 Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A 491 RCODE=NOERROR 493 Answer Section: 495 Authority Section: 496 DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. 497 EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ 498 RRSIG DNSKEY 499 EXAMPLE. RRSIG NSEC ... 501 Additional Section: 503 Attacker has forged a name 505 The resolver would have no choice but to believe that the referral to 506 NS.FORGED. is valid. If a wildcard existed that would have been 507 expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could 508 have undetectably removed it and replaced it with the forged 509 delegation. 511 Note that being able to add a delegation is functionally equivalent 512 to being able to add any record type: an attacker merely has to forge 513 a delegation to nameserver under his/her control and place whatever 514 records needed at the subzone apex. 516 While in particular cases, this issue may not present a significant 517 security problem, in general it should not be lightly dismissed. 518 Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. 519 In particular, zone signing tools SHOULD NOT default to Opt-In, and 520 MAY choose to not support Opt-In at all. 522 9. IANA Considerations 524 None. 526 10. Acknowledgments 528 The contributions, suggestions and remarks of the following persons 529 (in alphabetic order) to this draft are acknowledged: 531 Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf 532 Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning, 533 Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian 534 Wellington. 536 11. References 538 11.1. Normative References 540 [1] Mockapetris, P., "Domain names - implementation and 541 specification", STD 13, RFC 1035, November 1987. 543 [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 544 Authenticated Data (AD) bit", RFC 3655, November 2003. 546 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 547 "DNS Security Introduction and Requirements", RFC 4033, 548 March 2005. 550 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 551 "Resource Records for the DNS Security Extensions", RFC 4034, 552 March 2005. 554 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 555 "Protocol Modifications for the DNS Security Extensions", 556 RFC 4035, March 2005. 558 [6] Blacka, D., "DNSSEC Experiments", 559 draft-ietf-dnsext-dnssec-experiments-01 (work in progress), 560 July 2005. 562 11.2. Informative References 564 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 565 Levels", BCP 14, RFC 2119, March 1997. 567 [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 568 RFC 2181, July 1997. 570 [9] Eastlake, D., "Secure Domain Name System Dynamic Update", 571 RFC 2137, April 1997. 573 [10] Lewis, E., "DNS Security Extension Clarification on Zone 574 Status", RFC 3090, March 2001. 576 [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, 577 December 2001. 579 [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 580 System (DNS)", RFC 3833, August 2004. 582 Appendix A. Implementing Opt-In using "Views" 584 In many cases, it may be convenient to implement an Opt-In zone by 585 combining two separately maintained "views" of a zone at request 586 time. In this context, "view" refers to a particular version of a 587 zone, not to any specific DNS implementation feature. 589 In this scenario, one view is the secure view, the other is the 590 insecure (or legacy) view. The secure view consists of an entirely 591 signed zone using Opt-In tagged NSEC records. The insecure view 592 contains no DNSSEC information. It is helpful, although not 593 necessary, for the secure view to be a subset (minus DNSSEC records) 594 of the insecure view. 596 In addition, the only RRsets that may solely exist in the insecure 597 view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and 598 the zone apex NS RRset) MUST be signed and in the secure view. 600 These two views may be combined at request time to provide a virtual, 601 single Opt-In zone. The following algorithm is used when responding 602 to each query: 603 V_A is the secure view as described above. 604 V_B is the insecure view as described above. 605 R_A is a response generated from V_A, following standard DNSSEC. 606 R_B is a response generated from V_B, following DNS resolution as 607 per RFC 1035 [1]. 608 R_C is the response generated by combining R_A with R_B, as 609 described below. 610 A query is DNSSEC-aware if it either has the DO bit [11] turned 611 on, or is for a DNSSEC-specific record type. 613 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, 614 generate and return R_B, otherwise 615 2. Generate R_A. 616 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise 617 4. Generate R_B and combine it with R_A to form R_C: 618 For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the 619 records from R_A into R_B, EXCEPT the AUTHORITY section SOA 620 record, if R_B's RCODE = NOERROR. 621 5. Return R_C. 623 Authors' Addresses 625 Roy Arends 626 Nominet 627 Sandford Gate 628 Sandy Lane West 629 Oxford OX4 6LB 630 UNITED KINGDOM 632 Phone: +44 1865 332211 633 Email: roy@nominet.org.uk 635 Mark Kosters 636 VeriSign, Inc. 637 21355 Ridgetop Circle 638 Dulles, VA 20166 639 US 641 Phone: +1 703 948 3200 642 Email: markk@verisign.com 643 URI: http://www.verisignlabs.com 645 David Blacka 646 VeriSign, Inc. 647 21355 Ridgetop Circle 648 Dulles, VA 20166 649 US 651 Phone: +1 703 948 3200 652 Email: davidb@verisign.com 653 URI: http://www.verisignlabs.com 655 Full Copyright Statement 657 Copyright (C) The Internet Society (2006). 659 This document is subject to the rights, licenses and restrictions 660 contained in BCP 78, and except as set forth therein, the authors 661 retain all their rights. 663 This document and the information contained herein are provided on an 664 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 665 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 666 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 667 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 668 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 669 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 671 Intellectual Property 673 The IETF takes no position regarding the validity or scope of any 674 Intellectual Property Rights or other rights that might be claimed to 675 pertain to the implementation or use of the technology described in 676 this document or the extent to which any license under such rights 677 might or might not be available; nor does it represent that it has 678 made any independent effort to identify any such rights. Information 679 on the procedures with respect to rights in RFC documents can be 680 found in BCP 78 and BCP 79. 682 Copies of IPR disclosures made to the IETF Secretariat and any 683 assurances of licenses to be made available, or the result of an 684 attempt made to obtain a general license or permission for the use of 685 such proprietary rights by implementers or users of this 686 specification can be obtained from the IETF on-line IPR repository at 687 http://www.ietf.org/ipr. 689 The IETF invites any interested party to bring to its attention any 690 copyrights, patents or patent applications, or other proprietary 691 rights that may cover technology that may be required to implement 692 this standard. Please address the information to the IETF at 693 ietf-ipr@ietf.org. 695 Acknowledgment 697 Funding for the RFC Editor function is provided by the IETF 698 Administrative Support Activity (IASA).