idnits 2.17.1 draft-ietf-dnsext-dnssec-trans-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 716. 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 IETF Trust 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 (July 9, 2007) is 6129 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group R. Arends 3 Internet-Draft Nominet 4 Intended status: Informational P. Koch 5 Expires: January 10, 2008 DENIC eG 6 J. Schlyter 7 Kirei AB 8 July 9, 2007 10 Evaluating DNSSEC Transition Mechanisms 11 draft-ietf-dnsext-dnssec-trans-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 10, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document collects and summarizes different proposals for 45 alternative and additional strategies for authenticated denial in DNS 46 responses, evaluates these proposals and gives a recommendation for a 47 way forward. It is a snapshot of the DNSEXT working group discussion 48 of June 2004. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 55 2.1.1. Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 56 2.1.2. Add Versioning/Subtyping to Current NSEC . . . . . . . 5 57 2.1.3. Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 58 2.1.4. New Apex Type . . . . . . . . . . . . . . . . . . . . 7 59 2.1.5. NSEC White Lies . . . . . . . . . . . . . . . . . . . 8 60 2.1.6. NSEC Optional via DNSKEY Flag . . . . . . . . . . . . 9 61 2.1.7. New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 62 2.2. Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 63 2.2.1. Partial Type-code and Signal Rollover . . . . . . . . 10 64 2.2.2. A Complete Type-code and Signal Rollover . . . . . . . 11 65 2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG . . . 12 66 2.2.4. Unknown (New) Hash Algorithm in DS . . . . . . . . . . 13 67 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 Intellectual Property and Copyright Statements . . . . . . . . . . 16 77 1. Introduction 79 This report shall document the process of dealing with the NSEC zone 80 walking problem late in the Last Call for [RFC4033], [RFC4034], and 81 [RFC4035] (further referred to as DNSSEC-bis, with the obsoleted 82 [RFC2535] representing DNSSEC). It preserves some of the discussion 83 that took place in the DNSEXT WG during the first half of June 2004 84 as well as some additional ideas that came up subsequently. 86 This is an edited excerpt of the chairs' mail to the WG: 87 The working group consents on not including NSEC-alt in the 88 DNSSEC-bis documents. The working group considers to take up 89 "prevention of zone enumeration" as a work item. 90 There may be multiple mechanisms to allow for co-existence with 91 DNSSEC-bis. The chairs allow the working group a little over a 92 week (up to June 12, 2004) to come to consensus on a possible 93 modification to the document to enable gentle rollover. If that 94 consensus cannot be reached the DNSSEC-bis documents will go out 95 as-is. 97 To ease the process of getting consensus, a summary of the proposed 98 solutions and analysis of the pros and cons were written during the 99 weekend. 101 This summary includes: 103 An inventory of the proposed mechanisms to make a transition to 104 future work on authenticated denial of existence. 105 List the known Pros and Cons, possibly provide new arguments, and 106 possible security considerations of these mechanisms. 107 Provide a recommendation on a way forward that is least disruptive 108 to the DNSSEC-bis specifications as they stand and keep an open 109 path to other methods for authenticated denial of existence. 111 The descriptions of the proposals in this document are coarse and do 112 not cover every detail necessary for implementation. In any case, 113 documentation and further study is needed before implementation 114 and/or deployment, including those which seem to be solely 115 operational in nature. 117 2. Transition Mechanisms 119 In the light of earlier discussions and past proposals, we have found 120 several ways to allow for transition to future expansion of 121 authenticated denial. We tried to illuminate the paths and pitfalls 122 in these ways forward. Some proposals lead to a versioning of 123 DNSSEC, where DNSSEC-bis may co-exist with a future DNSSEC-ter, other 124 proposals are 'clean' but may cause delay, while again others may be 125 plain hacks. 127 Some paths do not introduce versioning, and might require the current 128 DNSSEC-bis documents to be fully updated to allow for extensions to 129 authenticated denial mechanisms. Other paths introduce versioning 130 and do not (or minimally) require DNSSEC-bis documents to be updated, 131 allowing DNSSEC-bis to be deployed, while future versions can be 132 drafted independent from or partially depending on DNSSEC-bis. 134 2.1. Mechanisms With Need of Updating DNSSEC-bis 136 Mechanisms in this category demand updates to the DNSSEC-bis document 137 set. 139 2.1.1. Dynamic NSEC Synthesis 141 This proposal assumes that NSEC RRs and the authenticating RRSIG will 142 be generated dynamically to just cover the (non existent) query name. 143 The owner name is (the) one preceding the name queried for, the Next 144 Owner Name Field has the value of the Query Name Field + 1 (first 145 successor in canonical ordering). A separate key (the normal ZSK or 146 a separate ZSK per authoritative server) would be used for RRSIGs on 147 NSEC RRs. This is a defense against enumeration, though it has the 148 presumption of online signing. 150 2.1.1.1. Coexistence and Migration 152 There is no change in interpretation other than that the next owner 153 name might or might not exist. 155 2.1.1.2. Limitations 157 This introduces an unbalanced cost between query and response 158 generation due to dynamic generation of signatures. 160 2.1.1.3. Amendments to DNSSEC-bis 162 The current DNSSEC-bis documents might need to be updated to indicate 163 that the next owner name might not be an existing name in the zone. 164 This is not a real change to the spec since implementers have been 165 warned not to synthesize negative responses with previously cached 166 NSEC records. A specific bit to identify the dynamic signature 167 generating key might be useful as well, to prevent it from being used 168 to fake positive data, i.e., to limit the damage of a compromise of 169 the online key. 171 2.1.1.4. Cons 173 Unbalanced cost may be abused for Denial of Service (DoS) attacks on 174 the synthesizing name servers. Also, this method requires all 175 authoritative servers to have access to a private key. While dynamic 176 synthesis protects against enumeration, it is not really a path for 177 versioning. 179 2.1.1.5. Pros 181 Only a minimal amendment to DNSSEC-bis is needed to allow "dangling" 182 pointers in an NSEC RR. However, implementations are not allowed to 183 exploit the additional knowledge that NSEC RRs provide anyway, so 184 this amendment is more formal in nature than actually having an 185 influence on complying implementations. 187 2.1.2. Add Versioning/Subtyping to Current NSEC 189 This proposal introduces versioning for the NSEC RR type (a.k.a. 190 subtyping) by adding a (one octet) version field to the NSEC RDATA. 191 Version number 0 is assigned to the current (DNSSEC-bis) meaning, 192 making this a 'Must Be Zero' (MBZ) for the to-be-published document 193 set. 195 2.1.2.1. Coexistence and Migration 197 Since the versioning is done inside the NSEC RR, different versions 198 may coexist in a zone. However, depending on future methods, that 199 may or may not be useful. Resolvers cannot ask for specific NSEC 200 versions but may be able to indicate version support by means of a 201 to-be-defined EDNS option bit. 203 2.1.2.2. Limitations 205 There are no technical limitations, though introducing this method 206 will cause delay to allow testing of the (currently unknown) new NSEC 207 interpretation. 209 Since the versioning and signaling is done inside the NSEC RR, future 210 methods will likely be restricted to a single RR type for 211 authenticated denial (as opposed to, e.g., NSEC-alt, which currently 212 proposes three RR types). 214 2.1.2.3. Amendments to DNSSEC-bis 216 Versioning or subtyping would require a full update of the current 217 DNSSEC-bis documents to provide for new fields in NSEC, including the 218 need to specify client behavior in response to unknown field values. 220 2.1.2.4. Cons 222 Although this is a clear and clean path without versioning DNSSEC as 223 a whole, it would take some time to design, gain consensus, update 224 the current DNSSEC-bis document set, test and implement a new DNS 225 record type for authenticated denial. 227 2.1.2.5. Pros 229 NSEC versioning does not introduce an iteration to DNSSEC while 230 providing a clear and clean migration strategy. 232 2.1.3. Type Bit Map NSEC Indicator 234 Bits in the type-bit-map are reused or allocated to signify the 235 interpretation of NSEC. 237 This proposal assumes that future extensions make use of the existing 238 NSEC RDATA syntax, while it may need to change the interpretation of 239 the RDATA or introduce an alternative denial mechanism, invoked by 240 the specific type-bit-map-bits. 242 2.1.3.1. Coexistence and migration 244 Old and new NSEC meaning could coexist, depending how the signaling 245 would be defined. The bits for NXT, KEY, SIG or other outdated RR 246 types are available as well as those covering meta/query types or 247 types to be specifically allocated. 249 2.1.3.2. Limitations 251 This mechanism uses an NSEC field that was not designed for that 252 purpose. Similar methods were discussed during the Opt-In discussion 253 and the Silly-State discussion. 255 2.1.3.3. Amendments to DNSSEC-bis 257 The specific type-bit-map-bits must be allocated and they need to be 258 specified as 'Must Be Zero' (MBZ) when used for standard (DNSSEC-bis) 259 interpretation. Also, behaviour of the resolver and validator must 260 be specified in case unknown values are encountered for the MBZ 261 field. Currently the protocol document specifies that the validator 262 must ignore the setting of the NSEC and the RRSIG bits, while other 263 bits are only used for the specific purpose of the type-bit-map 264 field. 266 2.1.3.4. Cons 268 Overloading the meaning of the type-bit-map is a straightforward 269 hack. The type-bit-map was not only not designed for this purpose, 270 but the text in section 5.4 of [RFC4035] was put in place to 271 explicitly prevent this usage. 273 2.1.3.5. Pros 275 No change is needed to the on-the-wire protocol as specified in the 276 current DNSSEC-bis document set. 278 2.1.4. New Apex Type 280 This introduces a new Apex type (parallel to the zone's SOA) 281 indicating the DNSSEC version (or authenticated denial) used in or 282 for this zone. 284 2.1.4.1. Coexistence and Migration 286 Depending on the design of this new RR type multiple denial 287 mechanisms may coexist in a zone. Old validators will not understand 288 and thus ignore the new type, so interpretation of the new NSEC 289 scheme may fail, negative responses may appear 'bogus'. 291 2.1.4.2. Limitations 293 A record of this kind is likely to carry additional feature/ 294 versioning indications unrelated to the current question of 295 authenticated denial. 297 2.1.4.3. Amendments to DNSSEC-bis 299 The current DNSSEC-bis documents need to be updated to indicate that 300 the absence of this type indicates DNSSEC-bis, and that the (mere) 301 presence of this type indicated unknown versions. 303 2.1.4.4. Cons 305 The only other 'zone' or 'apex' record is the SOA record. Adding 306 more RRs to the zone apex bloats QTYPE ANY responses for this apex. 307 Even though the proposal is not new, it is yet unknown how it might 308 fulfill authenticated denial extensions. This new RR type would only 309 provide for a generalized signaling mechanism, not the new 310 authenticated denial scheme. Since it is likely to be general in 311 nature, due to this generality consensus is not to be reached soon. 313 2.1.4.5. Pros 315 This approach would allow for a lot of other per zone information to 316 be transported or signaled in band to both (slave) servers and 317 resolvers. 319 2.1.5. NSEC White Lies 321 This proposal disables one part of NSEC (the pointer part) by means 322 of a special target (root, apex, owner, ...), leaving intact only the 323 ability to authenticate denial of existence of RR sets, not denial of 324 existence of domain names (NXDOMAIN). It may be necessary to have 325 one working NSEC to prove the absence of a wildcard. 327 2.1.5.1. Coexistence and Migration 329 The NSEC target can be specified per RR, so standard NSEC and 'white 330 lie' NSEC can coexist in a zone. There is no need for migration 331 because no versioning is introduced or intended. 333 2.1.5.2. Limitations 335 This proposal breaks the protocol and is applicable to certain types 336 of zones only (no wildcard, no multi-label names, delegation only). 337 Most of the burden is put on the resolver side and operational 338 consequences are yet to be studied. 340 2.1.5.3. Amendments to DNSSEC-bis 342 The current DNSSEC-bis documents need to be updated to indicate that 343 the NXDOMAIN responses may be insecure. 345 2.1.5.4. Cons 347 Strictly speaking this breaks the protocol and doesn't really satisfy 348 the requirements for authenticated denial of existence. Security 349 implications need to be carefully documented: search path problems 350 (forged denial of existence may lead to wrong expansion of non-FQDNs 351 [RFC1535]) and replay attacks to deny existence of records. In 352 addition, this does not provide for a versioning or signalling 353 scheme. 355 2.1.5.5. Pros 357 Solves the enumeration problem without the need of additional RR 358 types. 360 2.1.6. NSEC Optional via DNSKEY Flag 362 A new DNSKEY Flag may be defined to declare NSEC optional per zone. 364 2.1.6.1. Coexistence and Migration 366 Current resolvers/validators will not understand the Flag bit and 367 will have to treat negative responses as bogus. Otherwise, no 368 migration path is needed since NSEC is simply turned off. 370 2.1.6.2. Limitations 372 NSEC can only be made completely optional at the cost of being unable 373 to prove unsecure delegations (absence of a DS RR). An almost 374 identical approach would just disable authenticated denial for non- 375 existence of nodes. 377 2.1.6.3. Amendments to DNSSEC-bis 379 New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to 380 be specified in the light of absence of authenticated denial. 382 2.1.6.4. Cons 384 DNSSEC-bis less authenticated denial doesn't fully meet the 385 requirements and breaks the DNSSEC protocol by not fully covering the 386 threat model. Existing implementations will be confused. 387 Operational consequences need to be studied. 389 2.1.6.5. Pros 391 Positive responses can still be validated. 393 2.1.7. New Answer Pseudo RR Type 395 A new pseudo RR type may be defined that will be dynamically created 396 (and signed) by the responding authoritative server. The RR in the 397 response will cover the QNAME, QCLASS and QTYPE and will authenticate 398 both denial of existence of name (NXDOMAIN) or RRset. 400 2.1.7.1. Coexistence and Migration 402 Current resolvers/validators will not understand the pseudo RR and 403 will thus not be able to process negative responses so testified. A 404 signaling or solicitation method would have to be specified. 406 2.1.7.2. Limitations 408 This method can only be used with online keys and online signing 409 capacity. 411 2.1.7.3. Amendments to DNSSEC-bis 413 Signaling method needs to be defined. 415 2.1.7.4. Cons 417 Keys have to be held and processed online with all security 418 implications. An additional flag for those keys identifying them as 419 online or negative answer only keys should be considered, for the 420 same reasons given in Section 2.1.1. 422 2.1.7.5. Pros 424 Expands DNSSEC authentication to the RCODE. 426 2.2. Mechanisms Without Need of Updating DNSSEC-bis 428 2.2.1. Partial Type-code and Signal Rollover 430 Carefully crafted type code/signal rollover to define a new 431 authenticated denial space that extends/replaces DNSSEC-bis 432 authenticated denial space. This particular path is illuminated by 433 Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> 434 posted to 2004-06-02. 436 2.2.1.1. Coexistence and Migration 438 To protect the current resolver for future versions, a new DNSSEC-OK 439 bit must be allocated to make clear it does or does not understand 440 the future version. Also, a new DS type needs to be allocated to 441 allow differentiation between a current signed delegation and a 442 'future' signed delegation. Also, current NSEC needs to be rolled 443 into a new authenticated denial type. 445 2.2.1.2. Limitations 447 None. 449 2.2.1.3. Amendments to DNSSEC-bis 451 None. 453 2.2.1.4. Cons 455 It is cumbersome to carefully craft a type code roll (TCR) that 'just 456 fits'. The DNSSEC-bis protocol has many 'borderline' cases that need 457 special consideration. It might be easier to do a full TCR, since a 458 few of the types and signals need upgrading anyway. 460 2.2.1.5. Pros 462 Graceful adoption of future versions of NSEC, while there are no 463 amendments to DNSSEC-bis. 465 2.2.2. A Complete Type-code and Signal Rollover 467 A new DNSSEC type code space is defined which can exist independent 468 of the current DNSSEC-bis type code space. 470 This proposal assumes that all current DNSSEC type-codes (RRSIG/ 471 DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future 472 versions of DNSSEC. Any future version of DNSSEC has its own types 473 to allow for keys, signatures, authenticated denial, etcetera. 475 2.2.2.1. Coexistence and Migration 477 Both spaces can co-exist. They can be made completely orthogonal. 479 2.2.2.2. Limitations 481 None. 483 2.2.2.3. Amendments to DNSSEC-bis 485 None. 487 2.2.2.4. Cons 489 With this path we abandon the current DNSSEC-bis. Although it is 490 easy to roll specific well-known and well-tested parts into the re- 491 write, once deployment has started, this path is very expensive for 492 implementers, registries, registrars and registrants as well as 493 resolver operators and users. A TCR is not to be expected to occur 494 frequently, so while a next generation authenticated denial may be 495 enabled by a TCR, it is likely that that TCR will only be agreed upon 496 if it serves a whole basket of changes or additions. A quick 497 introduction of NSEC-ng should not be expected from this path. 499 2.2.2.5. Pros 501 No amendments/changes to current DNSSEC-bis docset needed. It is 502 always there as last resort. 504 2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG 506 This proposal assumes that future extensions make use of the existing 507 NSEC RDATA syntax, while they may need to change the interpretation 508 of the RDATA or introduce an alternative denial mechanism, invoked by 509 the specific unknown (new) signing algorithm. The different 510 interpretation would be signaled by use of different signature 511 algorithms in the DS RR at the parent. Consequently, the DNSKEY RR 512 for the child zone's KSK would contain a matching algorithm field. 514 2.2.3.1. Coexistence and migration 516 Old and new NSEC RDATA interpretation or known and unknown signatures 517 cannot coexist in a zone. While DS RRs with both new and well known 518 algorithm designation could both exist at the parent, that would not 519 lead to an unambiguous interpretation of the NSEC RRs in the zone. 520 RRSIG RRs need to cover complete RRSets, so it is not possible to 521 sign an 'old' NSEC RR with an RRSIG using an 'old' algorithm and 522 then, at the same owner, sign another 'new' NSEC RR with an RRSIG of 523 the 'new' algorithm type. A similar approach was subsequently 524 standardized in [I-D.ietf-dnsext-dnssec-experiments]. 526 2.2.3.2. Limitations 528 Validating resolvers agnostic of the 'new' signing algorithm (which 529 may be a well known algorithm, but might not be recognized due to the 530 new code) will treat the entire zone as insecure. 532 The algorithm number space might be split for each future version of 533 DNSSEC. Violation of the 'modular components' concept. We use the 534 'validator' to protect the 'resolver' from unknown interpretations. 536 2.2.3.3. Amendments to DNSSEC-bis 538 None. 540 2.2.3.4. Cons 542 The algorithm field was not designed for this purpose. This is a 543 straightforward hack. 545 2.2.3.5. Pros 547 No amendments/changes to current DNSSEC-bis docset needed. 549 2.2.4. Unknown (New) Hash Algorithm in DS 551 Similar to the previous method this one uses the DS RR at the parent 552 to signal child zone properties. Here, the digest type field of the 553 DS RR would be used to signal presence of a different (than DNSSEC- 554 bis) authenticated denial scheme at the child. 556 2.2.4.1. Coexistence and migration 558 Old and new NSEC RDATA interpretation or known and unknown signatures 559 can NOT coexist in a zone. 561 2.2.4.2. Limitations 563 Validating resolvers agnostic of the 'new' hashing algorithm (which 564 may be a well known algorithm, but might not be recognized due to the 565 new code) will treat the entire zone as insecure. 567 The digest type space might be split for each future version of 568 DNSSEC. Violation of the 'modular components' concept. We use the 569 'validator' to protect the 'resolver' from unknown interpretations. 571 2.2.4.3. Amendments to DNSSEC-bis 573 None. 575 2.2.4.4. Cons 577 The digest type field was not designed for this purpose. This is a 578 straightforward hack. 580 2.2.4.5. Pros 582 No amendments/changes to current DNSSEC-bis docset needed. 584 3. Recommendation 586 The authors recommend that the working group commits to and starts 587 work on a partial TCR, allowing graceful transition towards a future 588 version of NSEC. Meanwhile, to accomodate the need for an 589 immediately, temporary, solution against zone-traversal, we recommend 590 On-Demand NSEC synthesis. 592 This approach does not require any mandatory changes to DNSSEC-bis, 593 does not violate the protocol and fulfills the requirements. As a 594 side effect, it moves the cost of implementation and deployment to 595 the users (zone owners) of this mechanism. 597 4. Security Considerations 599 This document deals with transition mechanisms for new versions of 600 the DNS Security Extensions. The particular considerations for the 601 methods studied are listed in the respective sections, most 602 importantly the requirement for keeping private keys online in 603 Section 2.1.1 and Section 2.1.7 and the full or partial abandoning of 604 authenticated denial in Section 2.1.5 and Section 2.1.6. 606 5. IANA Considerations 608 [[Note to the RFC Editor: This section may be removed prior to 609 publication.]] 611 This document does not create any new IANA registry nor does it ask 612 for any allocation from an existing IANA registry. 614 6. Acknowledgements 616 The authors would like to thank Sam Weiler, Mark Andrews, and Stuart 617 Schechter for their input and constructive comments. 619 7. References 621 7.1. Normative References 623 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 624 Rose, "DNS Security Introduction and Requirements", 625 RFC 4033, March 2005. 627 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 628 Rose, "Resource Records for the DNS Security Extensions", 629 RFC 4034, March 2005. 631 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 632 Rose, "Protocol Modifications for the DNS Security 633 Extensions", RFC 4035, March 2005. 635 7.2. Informative References 637 [I-D.ietf-dnsext-dnssec-experiments] 638 Blacka, D., "DNSSEC Experiments", 639 draft-ietf-dnsext-dnssec-experiments-04 (work in 640 progress), March 2007. 642 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 643 With Widely Deployed DNS Software", RFC 1535, 644 October 1993. 646 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 647 RFC 2535, March 1999. 649 Authors' Addresses 651 Roy Arends 652 Nominet 653 Sandford Gate 654 Sandy Lane West 655 Oxford OX4 6LB 656 United Kingdom 658 Email: roy@nominet.org.uk 660 Peter Koch 661 DENIC eG 662 Wiesenhuettenplatz 26 663 Frankfurt 60329 664 Germany 666 Phone: +49 69 27235 0 667 Email: pk@DENIC.DE 669 Jakob Schlyter 670 Kirei AB 671 P.O. Box 53204 672 Goteborg SE-400 16 673 Sweden 675 Email: jakob@kirei.se 676 URI: http://www.kirei.se/ 678 Full Copyright Statement 680 Copyright (C) The IETF Trust (2007). 682 This document is subject to the rights, licenses and restrictions 683 contained in BCP 78, and except as set forth therein, the authors 684 retain all their rights. 686 This document and the information contained herein are provided on an 687 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 688 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 689 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 690 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 691 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 692 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 694 Intellectual Property 696 The IETF takes no position regarding the validity or scope of any 697 Intellectual Property Rights or other rights that might be claimed to 698 pertain to the implementation or use of the technology described in 699 this document or the extent to which any license under such rights 700 might or might not be available; nor does it represent that it has 701 made any independent effort to identify any such rights. Information 702 on the procedures with respect to rights in RFC documents can be 703 found in BCP 78 and BCP 79. 705 Copies of IPR disclosures made to the IETF Secretariat and any 706 assurances of licenses to be made available, or the result of an 707 attempt made to obtain a general license or permission for the use of 708 such proprietary rights by implementers or users of this 709 specification can be obtained from the IETF on-line IPR repository at 710 http://www.ietf.org/ipr. 712 The IETF invites any interested party to bring to its attention any 713 copyrights, patents or patent applications, or other proprietary 714 rights that may cover technology that may be required to implement 715 this standard. Please address the information to the IETF at 716 ietf-ipr@ietf.org. 718 Acknowledgment 720 Funding for the RFC Editor function is provided by the IETF 721 Administrative Support Activity (IASA).