idnits 2.17.1 draft-ietf-dnsext-dnssec-trans-04.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 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 678. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 252: '... MUST ignore the setting of the NSEC...' 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 (June 26, 2006) is 6507 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: 'RFC1034' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 628, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 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 UK 4 Expires: December 28, 2006 P. Koch 5 DENIC eG 6 J. Schlyter 7 Kirei AB 8 June 26, 2006 10 Evaluating DNSSEC Transition Mechanisms 11 draft-ietf-dnsext-dnssec-trans-04.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 December 28, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . 7 60 2.1.6. NSEC Optional via DNSKEY Flag . . . . . . . . . . . . 8 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 . . . . . . . 10 65 2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG . . . 11 66 2.2.4. Unknown (New) Hash Algorithm in DS . . . . . . . . . . 12 67 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 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). It preserves some of 82 the discussion that took place in the DNSEXT WG during the first half 83 of June 2004 as well as some additional ideas that came up 84 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 implementaion and/or 114 deployment, including those which seem to be solely operational in 115 nature. 117 2. Transition Mechanisms 119 In the light of recent 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 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 then 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 with previously cached NSEC records. A 166 specific bit to identify the dynamic signature generating key might 167 be useful as well, to prevent it from being used to fake positive 168 data. 170 2.1.1.4. Cons 172 Unbalanced cost may be abused for Denial of Service (DoS) attacks on 173 the synthesizing name servers. While dynamic synthesis protects 174 against enumeration, it is not really a path for versioning. 176 2.1.1.5. Pros 178 Hardly any amendments to DNSSEC-bis. 180 2.1.2. Add Versioning/Subtyping to Current NSEC 182 This proposal introduces versioning for the NSEC RR type (a.k.a. 183 subtyping) by adding a (one octet) version field to the NSEC RDATA. 184 Version number 0 is assigned to the current (DNSSEC-bis) meaning, 185 making this an 'Must Be Zero' (MBZ) for the to be published docset. 187 2.1.2.1. Coexistence and Migration 189 Since the versioning is done inside the NSEC RR, different versions 190 may coexist. However, depending on future methods, that may or may 191 not be useful inside a single zone. Resolvers cannot ask for 192 specific NSEC versions but may be able to indicate version support by 193 means of a to be defined EDNS option bit. 195 2.1.2.2. Limitations 197 There are no technical limitations, though it will cause delay to 198 allow testing of the (currently unknown) new NSEC interpretation. 200 Since the versioning and signaling is done inside the NSEC RR, future 201 methods will likely be restricted to a single RR type authenticated 202 denial (as opposed to e.g. NSEC-alt, which currently proposes three 203 RR types). 205 2.1.2.3. Amendments to DNSSEC-bis 207 Full Update of the current DNSSEC-bis documents to provide for new 208 fields in NSEC, while specifying behavior in case of unknown field 209 values. 211 2.1.2.4. Cons 213 Though this is a clean and clear path without versioning DNSSEC, it 214 takes some time to design, gain consensus, update the current DNSSEC- 215 bis document, test and implement a new authenticated denial record. 217 2.1.2.5. Pros 219 Does not introduce an iteration to DNSSEC while providing a clear and 220 clean migration strategy. 222 2.1.3. Type Bit Map NSEC Indicator 224 Bits in the type-bit-map are reused or allocated to signify the 225 interpretation of NSEC. 227 This proposal assumes that future extensions make use of the existing 228 NSEC RDATA syntax, while it may need to change the interpretation of 229 the RDATA or introduce an alternative denial mechanism, invoked by 230 the specific type-bit-map-bits. 232 2.1.3.1. Coexistence and migration 234 Old and new NSEC meaning could coexist, depending how the signaling 235 would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR 236 types are available as well as those covering meta/query types or 237 types to be specifically allocated. 239 2.1.3.2. Limitations 241 This mechanism uses an NSEC field that was not designed for that 242 purpose. Similar methods were discussed during the Opt-In discussion 243 and the Silly-State discussion. 245 2.1.3.3. Amendments to DNSSEC-bis 247 The specific type-bit-map-bits must be allocated and they need to be 248 specified as 'Must Be Zero' (MBZ) when used for standard (DNSSEC-bis) 249 interpretation. Also, behaviour of the resolver and validator must 250 be documented in case unknown values are encountered for the MBZ 251 field. Currently the protocol document specifies that the validator 252 MUST ignore the setting of the NSEC and the RRSIG bits, while other 253 bits are only used for the specific purpose of the type-bit-map field 255 2.1.3.4. Cons 257 The type-bit-map was not designed for this purpose. It is a 258 straightforward hack. Text in protocol section 5.4 was put in 259 specially to defend against this usage. 261 2.1.3.5. Pros 263 No change needed to the on-the-wire protocol as specified in the 264 current docset. 266 2.1.4. New Apex Type 268 This introduces a new Apex type (parallel to the zone's SOA) 269 indicating the DNSSEC version (or authenticated denial) used in or 270 for this zone. 272 2.1.4.1. Coexistence and Migration 274 Depending on the design of this new RR type multiple denial 275 mechanisms may coexist in a zone. Old validators will not understand 276 and thus ignore the new type, so interpretation of the new NSEC 277 scheme may fail, negative responses may appear 'bogus'. 279 2.1.4.2. Limitations 281 A record of this kind is likely to carry additional feature/ 282 versioning indications unrelated to the current question of 283 authenticated denial. 285 2.1.4.3. Amendments to DNSSEC-bis 287 The current DNSSEC-bis documents need to be updated to indicate that 288 the absence of this type indicates DNSSEC-bis, and that the (mere) 289 presence of this type indicated unknown versions. 291 2.1.4.4. Cons 293 The only other 'zone' or 'apex' record is the SOA record. Adding 294 more RRs to the zone apex bloats QTYPE ANY responses for this apex. 295 Even though the proposal is not new, it is yet unknown how it might 296 fulfill authenticated denial extensions. This new RR type would only 297 provide for a generalized signaling mechanism, not the new 298 authenticated denial scheme. Since it is likely to be general in 299 nature, due to this generality consensus is not to be reached soon. 301 2.1.4.5. Pros 303 This approach would allow for a lot of other per zone information to 304 be transported or signaled in band to both (slave) servers and 305 resolvers. 307 2.1.5. NSEC White Lies 309 This proposal disables one part of NSEC (the pointer part) by means 310 of a special target (root, apex, owner, ...), leaving intact only the 311 ability to authenticate denial of existence of RR sets, not denial of 312 existence of domain names (NXDOMAIN). It may be necessary to have 313 one working NSEC to prove the absence of a wildcard. 315 2.1.5.1. Coexistence and Migration 317 The NSEC target can be specified per RR, so standard NSEC and 'white 318 lie' NSEC can coexist in a zone. There is no need for migration 319 because no versioning is introduced or intended. 321 2.1.5.2. Limitations 323 This proposal breaks the protocol and is applicable to certain types 324 of zones only (no wildcard, no deep names, delegation only). Most of 325 the burden is put on the resolver side and operational consequences 326 are yet to be studied. 328 2.1.5.3. Amendments to DNSSEC-bis 330 The current DNSSEC-bis documents need to be updated to indicate that 331 the NXDOMAIN responses may be insecure. 333 2.1.5.4. Cons 335 Strictly speaking this breaks the protocol and doesn't fully fulfill 336 the requirements for authenticated denial of existence. Security 337 implications need to be carefully documented: search path problems 338 (forged denial of existence may lead to wrong expansion of non-FQDNs 339 [RFC1535]) and replay attacks to deny existence of records. 341 2.1.5.5. Pros 343 Hardly any amendments to DNSSEC-bis. Operational "trick" that is 344 available anyway. 346 2.1.6. NSEC Optional via DNSKEY Flag 348 A new DNSKEY may be defined to declare NSEC optional per zone. 350 2.1.6.1. Coexistence and Migration 352 Current resolvers/validators will not understand the Flag bit and 353 will have to treat negative responses as bogus. Otherwise, no 354 migration path is needed since NSEC is simply turned off. 356 2.1.6.2. Limitations 358 NSEC can only be made completely optional at the cost of being unable 359 to prove unsecure delegations (absence of a DS RR). A next to this 360 approach would just disable authenticated denial for non-existence of 361 nodes. 363 2.1.6.3. Amendments to DNSSEC-bis 365 New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to 366 be specified in the light of absence of authenticated denial. 368 2.1.6.4. Cons 370 Doesn't fully meet requirements. Operational consequences to be 371 studied. 373 2.1.6.5. Pros 375 Official version of the "trick" presented in Section 2.1.5. 376 Operational problems can be addressed during future work on 377 validators. 379 2.1.7. New Answer Pseudo RR Type 381 A new pseudo RR type may be defined that will be dynamically created 382 (and signed) by the responding authoritative server. The RR in the 383 response will cover the QNAME, QCLASS and QTYPE and will authenticate 384 both denial of existence of name (NXDOMAIN) or RRset. 386 2.1.7.1. Coexistence and Migration 388 Current resolvers/validators will not understand the pseudo RR and 389 will thus not be able to process negative responses so testified. A 390 signaling or solicitation method would have to be specified. 392 2.1.7.2. Limitations 394 This method can only be used with online keys and online signing 395 capacity. 397 2.1.7.3. Amendments to DNSSEC-bis 399 Signaling method needs to be defined. 401 2.1.7.4. Cons 403 Keys have to be held and processed online with all security 404 implications. An additional flag for those keys identifying them as 405 online or negative answer only keys should be considered. 407 2.1.7.5. Pros 409 Expands DNSSEC authentication to the RCODE. 411 2.2. Mechanisms Without Need of Updating DNSSEC-bis 413 2.2.1. Partial Type-code and Signal Rollover 415 Carefully crafted type code/signal rollover to define a new 416 authenticated denial space that extends/replaces DNSSEC-bis 417 authenticated denial space. This particular path is illuminated by 418 Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> 419 posted to 2004-06-02. 421 2.2.1.1. Coexistence and Migration 423 To protect the current resolver for future versions, a new DNSSEC-OK 424 bit must be allocated to make clear it does or does not understand 425 the future version. Also, a new DS type needs to be allocated to 426 allow differentiation between a current signed delegation and a 427 'future' signed delegation. Also, current NSEC needs to be rolled 428 into a new authenticated denial type. 430 2.2.1.2. Limitations 432 None. 434 2.2.1.3. Amendments to DNSSEC-bis 436 None. 438 2.2.1.4. Cons 440 It is cumbersome to carefully craft a type code roll (TCR) that 'just 441 fits'. The DNSSEC-bis protocol has many 'borderline' cases that need 442 special consideration. It might be easier to do a full TCR, since a 443 few of the types and signals need upgrading anyway. 445 2.2.1.5. Pros 447 Graceful adoption of future versions of NSEC, while there are no 448 amendments to DNSSEC-bis. 450 2.2.2. A Complete Type-code and Signal Rollover 452 A new DNSSEC space is defined which can exist independent of current 453 DNSSEC-bis space. 455 This proposal assumes that all current DNSSEC type-codes (RRSIG/ 456 DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future 457 versions of DNSSEC. Any future version of DNSSEC has its own types 458 to allow for keys, signatures, authenticated denial, etcetera. 460 2.2.2.1. Coexistence and Migration 462 Both spaces can co-exist. They can be made completely orthogonal. 464 2.2.2.2. Limitations 466 None. 468 2.2.2.3. Amendments to DNSSEC-bis 470 None. 472 2.2.2.4. Cons 474 With this path we abandon the current DNSSEC-bis. Though it is easy 475 to role specific well-known and well-tested parts into the re-write, 476 once deployment has started this path is very expensive for 477 implementers, registries, registrars and registrants as well as 478 resolvers/users. A TCR is not to be expected to occur frequently, so 479 while a next generation authenticated denial may be enabled by a TCR, 480 it is likely that that TCR will only be agreed upon if it serves a 481 whole basket of changes or additions. A quick introduction of 482 NSEC-ng should not be expected from this path. 484 2.2.2.5. Pros 486 No amendments/changes to current DNSSEC-bis docset needed. It is 487 always there as last resort. 489 2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG 491 This proposal assumes that future extensions make use of the existing 492 NSEC RDATA syntax, while they may need to change the interpretation 493 of the RDATA or introduce an alternative denial mechanism, invoked by 494 the specific unknown (new) signing algorithm. The different 495 interpretation would be signaled by use of different signature 496 algorithms in the DS RR at the parent. Consequently, the DNSKEY RR 497 for the child zone's KSK would contain a matching algorithm field. 499 2.2.3.1. Coexistence and migration 501 Old and new NSEC RDATA interpretation or known and unknown signatures 502 can NOT coexist in a zone since. While DS RRs with both new and well 503 known algorithm designation could both exist at the parent, that 504 would not lead to an unambiguous interpretation of the NSEC RRs in 505 the zone. RRSIG RRs need to cover complete RRSets, so it is not 506 possible to sign an 'old' NSEC RR with an RRSIG using an 'old' 507 algorithm and then, at the same owner, sign another 'new' NSEC RR 508 with an RRSIG of the 'new' algorithm type. 510 2.2.3.2. Limitations 512 Validating resolvers agnostic of the 'new' signing algorithm (which 513 may be a well known algorithm, but might not be recognized due to the 514 new code) will treat the entire zone as insecure. 516 The algorithm version space is split for each future version of 517 DNSSEC. Violation of the 'modular components' concept. We use the 518 'validator' to protect the 'resolver' from unknown interpretations. 520 2.2.3.3. Amendments to DNSSEC-bis 522 None. 524 2.2.3.4. Cons 526 The algorithm field was not designed for this purpose. This is a 527 straightforward hack. 529 2.2.3.5. Pros 531 No amendments/changes to current DNSSEC-bis docset needed. 533 2.2.4. Unknown (New) Hash Algorithm in DS 535 Similar to the previous method this one uses the DS RR at the parent 536 to signal child zone properties. Here, the digest type field of the 537 DS RR would be used to signal presence of a different (than DNSSEC- 538 bis) authenticated denial scheme at the child. 540 2.2.4.1. Coexistence and migration 542 Old and new NSEC RDATA interpretation or known and unknown signatures 543 can NOT coexist in a zone. 545 2.2.4.2. Limitations 547 Validating resolvers agnostic of the 'new' hashing algorithm (which 548 may be a well known algorithm, but might not be recognized due to the 549 new code) will treat the entire zone as insecure. 551 The digest type space is split for each future version of DNSSEC. 552 Violation of the 'modular components' concept. We use the 553 'validator' to protect the 'resolver' from unknown interpretations. 555 2.2.4.3. Amendments to DNSSEC-bis 557 None. 559 2.2.4.4. Cons 561 The digest type field was not designed for this purpose. This is a 562 straightforward hack. 564 2.2.4.5. Pros 566 No amendments/changes to current DNSSEC-bis docset needed. 568 3. Recommendation 570 The authors recommend that the working group commits to and starts 571 work on a partial TCR, allowing graceful transition towards a future 572 version of NSEC. Meanwhile, to accomodate the need for an 573 immediately, temporary, solution against zone-traversal, we recommend 574 On-Demand NSEC synthesis. 576 This approach does not require any mandatory changes to DNSSEC-bis, 577 does not violate the protocol and fulfills the requirements. As a 578 side effect, it moves the cost of implementation and deployment to 579 the users (zone owners) of this mechanism. 581 4. Security Considerations 583 This document deals with transition mechanisms for new versions of 584 the DNS Security Extensions. The particular considerations for the 585 methods studied are listed in the respective sections, most 586 importantly the requirement for keeping private keys online in 587 Section 2.1.1 and Section 2.1.7 and the full or partial abandoning of 588 authenticated denial in Section 2.1.5 and Section 2.1.6. 590 5. IANA Considerations 592 This document does not create any new IANA registry nor does it ask 593 for any allocation from an existing IANA registry. 595 6. Acknowledgements 597 The authors would like to thank Sam Weiler and Mark Andrews for their 598 input and constructive comments. 600 7. References 602 7.1. Normative References 604 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 605 STD 13, RFC 1034, November 1987. 607 [RFC1035] Mockapetris, P., "Domain names - implementation and 608 specification", STD 13, RFC 1035, November 1987. 610 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 611 Rose, "DNS Security Introduction and Requirements", 612 RFC 4033, March 2005. 614 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 615 Rose, "Resource Records for the DNS Security Extensions", 616 RFC 4034, March 2005. 618 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 619 Rose, "Protocol Modifications for the DNS Security 620 Extensions", RFC 4035, March 2005. 622 7.2. Informative References 624 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 625 With Widely Deployed DNS Software", RFC 1535, 626 October 1993. 628 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 629 RFC 2535, March 1999. 631 Authors' Addresses 633 Roy Arends 634 Nominet UK 636 Email: roy@nominet.org.uk 638 Peter Koch 639 DENIC eG 640 Wiesenhuettenplatz 26 641 Frankfurt 60329 642 Germany 644 Phone: +49 69 27235 0 645 Email: pk@DENIC.DE 647 Jakob Schlyter 648 Kirei AB 649 P.O. Box 53204 650 Goteborg SE-400 16 651 Sweden 653 Email: jakob@kirei.se 654 URI: http://www.kirei.se/ 656 Intellectual Property Statement 658 The IETF takes no position regarding the validity or scope of any 659 Intellectual Property Rights or other rights that might be claimed to 660 pertain to the implementation or use of the technology described in 661 this document or the extent to which any license under such rights 662 might or might not be available; nor does it represent that it has 663 made any independent effort to identify any such rights. Information 664 on the procedures with respect to rights in RFC documents can be 665 found in BCP 78 and BCP 79. 667 Copies of IPR disclosures made to the IETF Secretariat and any 668 assurances of licenses to be made available, or the result of an 669 attempt made to obtain a general license or permission for the use of 670 such proprietary rights by implementers or users of this 671 specification can be obtained from the IETF on-line IPR repository at 672 http://www.ietf.org/ipr. 674 The IETF invites any interested party to bring to its attention any 675 copyrights, patents or patent applications, or other proprietary 676 rights that may cover technology that may be required to implement 677 this standard. Please address the information to the IETF at 678 ietf-ipr@ietf.org. 680 Disclaimer of Validity 682 This document and the information contained herein are provided on an 683 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 684 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 685 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 686 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 687 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 688 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 690 Copyright Statement 692 Copyright (C) The Internet Society (2006). This document is subject 693 to the rights, licenses and restrictions contained in BCP 78, and 694 except as set forth therein, the authors retain all their rights. 696 Acknowledgment 698 Funding for the RFC Editor function is currently provided by the 699 Internet Society.