idnits 2.17.1 draft-ietf-dnsext-dnssec-trans-02.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 654. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 250: '... 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 == Line 234 has weird spacing: '...ailable as we...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2005) is 7003 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: 'I-D.ietf-dnsext-dnssec-intro' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dnsext-dnssec-protocol' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dnsext-dnssec-records' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC2931' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 597, 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) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Extensions Working Group R. Arends 2 Internet-Draft Telematica Instituut 3 Expires: August 25, 2005 P. Koch 4 DENIC eG 5 J. Schlyter 6 NIC-SE 7 February 21, 2005 9 Evaluating DNSSEC Transition Mechanisms 10 draft-ietf-dnsext-dnssec-trans-02.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 25, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document collects and summarizes different proposals for 46 alternative and additional strategies for authenticated denial in DNS 47 responses, evaluates these proposals and gives a recommendation for a 48 way forward. 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 . . . . . . . . . . . . . . . . . . . . 6 59 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 60 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 61 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 62 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9 63 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 64 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10 65 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11 66 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11 67 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 71 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . 15 75 1. Introduction 77 This report shall document the process of dealing with the NSEC 78 walking problem late in the Last Call for 79 [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol, 80 I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion 81 that took place in the DNSEXT WG during the first half of June 2004 82 as well as some additional ideas that came up subsequently. 84 This is an edited excerpt of the chairs' mail to the WG: 85 The working group consents on not including NSEC-alt in the 86 DNSSEC-bis documents. The working group considers to take up 87 "prevention of zone enumeration" as a work item. 88 There may be multiple mechanisms to allow for co-existence with 89 DNSSEC-bis. The chairs allow the working group a little over a 90 week (up to June 12, 2004) to come to consensus on a possible 91 modification to the document to enable gentle rollover. If that 92 consensus cannot be reached the DNSSEC-bis documents will go out 93 as-is. 95 To ease the process of getting consensus, a summary of the proposed 96 solutions and analysis of the pros and cons were written during the 97 weekend. 99 This summary includes: 101 An inventory of the proposed mechanisms to make a transition to 102 future work on authenticated denial of existence. 103 List the known Pros and Cons, possibly provide new arguments, and 104 possible security considerations of these mechanisms. 105 Provide a recommendation on a way forward that is least disruptive 106 to the DNSSEC-bis specifications as they stand and keep an open 107 path to other methods for authenticated denial of existence. 109 The descriptions of the proposals in this document are coarse and do 110 not cover every detail necessary for implementation. In any case, 111 documentation and further study is needed before implementaion and/or 112 deployment, including those which seem to be solely operational in 113 nature. 115 2. Transition Mechanisms 117 In the light of recent discussions and past proposals, we have found 118 several ways to allow for transition to future expansion of 119 authenticated denial. We tried to illuminate the paths and pitfalls 120 in these ways forward. Some proposals lead to a versioning of 121 DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other 122 proposals are 'clean' but may cause delay, while again others may be 123 plain hacks. 125 Some paths do not introduce versioning, and might require the current 126 DNSSEC-bis documents to be fully updated to allow for extensions to 127 authenticated denial mechanisms. Other paths introduce versioning 128 and do not (or minimally) require DNSSEC-bis documents to be updated, 129 allowing DNSSEC-bis to be deployed, while future versions can be 130 drafted independent from or partially depending on DNSSEC-bis. 132 2.1 Mechanisms With Need of Updating DNSSEC-bis 134 Mechanisms in this category demand updates to the DNSSEC-bis document 135 set. 137 2.1.1 Dynamic NSEC Synthesis 139 This proposal assumes that NSEC RRs and the authenticating RRSIG will 140 be generated dynamically to just cover the (non existent) query name. 141 The owner name is (the) one preceding the name queried for, the Next 142 Owner Name Field has the value of the Query Name Field + 1 (first 143 successor in canonical ordering). A separate key (the normal ZSK or 144 a separate ZSK per authoritative server) would be used for RRSIGs on 145 NSEC RRs. This is a defense against enumeration, though it has the 146 presumption of online signing. 148 2.1.1.1 Coexistence and Migration 150 There is no change in interpretation other then that the next owner 151 name might or might not exist. 153 2.1.1.2 Limitations 155 This introduces an unbalanced cost between query and response 156 generation due to dynamic generation of signatures. 158 2.1.1.3 Amendments to DNSSEC-bis 160 The current DNSSEC-bis documents might need to be updated to indicate 161 that the next owner name might not be an existing name in the zone. 162 This is not a real change to the spec since implementers have been 163 warned not to synthesize with previously cached NSEC records. A 164 specific bit to identify the dynamic signature generating key might 165 be useful as well, to prevent it from being used to fake positive 166 data. 168 2.1.1.4 Cons 170 Unbalanced cost is a ground for DDoS. Though this protects against 171 enumeration, it is not really a path for versioning. 173 2.1.1.5 Pros 175 Hardly any amendments to DNSSEC-bis. 177 2.1.2 Add Versioning/Subtyping to Current NSEC 179 This proposal introduces versioning for the NSEC RR type (a.k.a. 180 subtyping) by adding a (one octet) version field to the NSEC RDATA. 181 Version number 0 is assigned to the current (DNSSEC-bis) meaning, 182 making this an 'Must Be Zero' (MBZ) for the to be published docset. 184 2.1.2.1 Coexistence and Migration 186 Since the versioning is done inside the NSEC RR, different versions 187 may coexist. However, depending on future methods, that may or may 188 not be useful inside a single zone. Resolvers cannot ask for 189 specific NSEC versions but may be able to indicate version support by 190 means of a to be defined EDNS option bit. 192 2.1.2.2 Limitations 194 There are no technical limitations, though it will cause delay to 195 allow testing of the (currently unknown) new NSEC interpretation. 197 Since the versioning and signaling is done inside the NSEC RR, future 198 methods will likely be restricted to a single RR type authenticated 199 denial (as opposed to e.g. NSEC-alt, which currently proposes three 200 RR types). 202 2.1.2.3 Amendments to DNSSEC-bis 204 Full Update of the current DNSSEC-bis documents to provide for new 205 fields in NSEC, while specifying behavior in case of unknown field 206 values. 208 2.1.2.4 Cons 210 Though this is a clean and clear path without versioning DNSSEC, it 211 takes some time to design, gain consensus, update the current 212 dnssec-bis document, test and implement a new authenticated denial 213 record. 215 2.1.2.5 Pros 217 Does not introduce an iteration to DNSSEC while providing a clear and 218 clean migration strategy. 220 2.1.3 Type Bit Map NSEC Indicator 222 Bits in the type-bit-map are reused or allocated to signify the 223 interpretation of NSEC. 225 This proposal assumes that future extensions make use of the existing 226 NSEC RDATA syntax, while it may need to change the interpretation of 227 the RDATA or introduce an alternative denial mechanism, invoked by 228 the specific type-bit-map-bits. 230 2.1.3.1 Coexistence and migration 232 Old and new NSEC meaning could coexist, depending how the signaling 233 would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR 234 types are available as well as those covering meta/query types or 235 types to be specifically allocated. 237 2.1.3.2 Limitations 239 This mechanism uses an NSEC field that was not designed for that 240 purpose. Similar methods were discussed during the Opt-In discussion 241 and the Silly-State discussion. 243 2.1.3.3 Amendments to DNSSEC-bis 245 The specific type-bit-map-bits must be allocated and they need to be 246 specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) 247 interpretation. Also, behaviour of the resolver and validator must 248 be documented in case unknown values are encountered for the MBZ 249 field. Currently the protocol document specifies that the validator 250 MUST ignore the setting of the NSEC and the RRSIG bits, while other 251 bits are only used for the specific purpose of the type-bit-map field 253 2.1.3.4 Cons 255 The type-bit-map was not designed for this purpose. It is a 256 straightforward hack. Text in protocol section 5.4 was put in 257 specially to defend against this usage. 259 2.1.3.5 Pros 261 No change needed to the on-the-wire protocol as specified in the 262 current docset. 264 2.1.4 New Apex Type 266 This introduces a new Apex type (parallel to the zone's SOA) 267 indicating the DNSSEC version (or authenticated denial) used in or 268 for this zone. 270 2.1.4.1 Coexistence and Migration 272 Depending on the design of this new RR type multiple denial 273 mechanisms may coexist in a zone. Old validators will not understand 274 and thus ignore the new type, so interpretation of the new NSEC 275 scheme may fail, negative responses may appear 'bogus'. 277 2.1.4.2 Limitations 279 A record of this kind is likely to carry additional 280 feature/versioning indications unrelated to the current question of 281 authenticated denial. 283 2.1.4.3 Amendments to DNSSEC-bis 285 The current DNSSEC-bis documents need to be updated to indicate that 286 the absence of this type indicates dnssec-bis, and that the (mere) 287 presence of this type indicated unknown versions. 289 2.1.4.4 Cons 291 The only other 'zone' or 'apex' record is the SOA record. Though 292 this proposal is not new, it is yet unknown how it might fulfill 293 authenticated denial extensions. This new RR type would only provide 294 for a generalized signaling mechanism, not the new authenticated 295 denial scheme. Since it is likely to be general in nature, due to 296 this generality consensus is not to be reached soon. 298 2.1.4.5 Pros 300 This approach would allow for a lot of other per zone information to 301 be transported or signaled to both (slave) servers and resolvers. 303 2.1.5 NSEC White Lies 305 This proposal disables one part of NSEC (the pointer part) by means 306 of a special target (root, apex, owner, ...), leaving intact only the 307 ability to authenticate denial of existence of RR sets, not denial of 308 existence of domain names (NXDOMAIN). It may be necessary to have 309 one working NSEC to prove the absence of a wildcard. 311 2.1.5.1 Coexistence and Migration 313 The NSEC target can be specified per RR, so standard NSEC and 'white 314 lie' NSEC can coexist in a zone. There is no need for migration 315 because no versioning is introduced or intended. 317 2.1.5.2 Limitations 319 This proposal breaks the protocol and is applicable to certain types 320 of zones only (no wildcard, no deep names, delegation only). Most of 321 the burden is put on the resolver side and operational consequences 322 are yet to be studied. 324 2.1.5.3 Amendments to DNSSEC-bis 326 The current DNSSEC-bis documents need to be updated to indicate that 327 the NXDOMAIN responses may be insecure. 329 2.1.5.4 Cons 331 Strictly speaking this breaks the protocol and doesn't fully fulfill 332 the requirements for authenticated denial of existence. Security 333 implications need to be carefully documented: search path problems 334 (forged denial of existence may lead to wrong expansion of non-FQDNs 335 [RFC1535]) and replay attacks to deny existence of records. 337 2.1.5.5 Pros 339 Hardly any amendments to DNSSEC-bis. Operational "trick" that is 340 available anyway. 342 2.1.6 NSEC Optional via DNSSKEY Flag 344 A new DNSKEY may be defined to declare NSEC optional per zone. 346 2.1.6.1 Coexistence and Migration 348 Current resolvers/validators will not understand the Flag bit and 349 will have to treat negative responses as bogus. Otherwise, no 350 migration path is needed since NSEC is simply turned off. 352 2.1.6.2 Limitations 354 NSEC can only be made completely optional at the cost of being unable 355 to prove unsecure delegations (absence of a DS RR [RFC3658]). A next 356 to this approach would just disable authenticated denial for 357 non-existence of nodes. 359 2.1.6.3 Amendments to DNSSEC-bis 361 New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to 362 be specified in the light of absence of authenticated denial. 364 2.1.6.4 Cons 366 Doesn't fully meet requirements. Operational consequences to be 367 studied. 369 2.1.6.5 Pros 371 Official version of the "trick" presented in (8). Operational 372 problems can be addressed during future work on validators. 374 2.1.7 New Answer Pseudo RR Type 376 A new pseudo RR type may be defined that will be dynamically created 377 (and signed) by the responding authoritative server. The RR in the 378 response will cover the QNAME, QCLASS and QTYPE and will authenticate 379 both denial of existence of name (NXDOMAIN) or RRset. 381 2.1.7.1 Coexistence and Migration 383 Current resolvers/validators will not understand the pseudo RR and 384 will thus not be able to process negative responses so testified. A 385 signaling or solicitation method would have to be specified. 387 2.1.7.2 Limitations 389 This method can only be used with online keys and online signing 390 capacity. 392 2.1.7.3 Amendments to DNSSEC-bis 394 Signaling method needs to be defined. 396 2.1.7.4 Cons 398 Keys have to be held and processed online with all security 399 implications. An additional flag for those keys identifying them as 400 online or negative answer only keys should be considered. 402 2.1.7.5 Pros 404 Expands DNSSEC authentication to the RCODE. 406 2.1.8 SIG(0) Based Authenticated Denial 408 2.1.8.1 Coexistence and Migration 409 2.1.8.2 Limitations 411 2.1.8.3 Amendments to DNSSEC-bis 413 2.1.8.4 Cons 415 2.1.8.5 Pros 417 2.2 Mechanisms Without Need of Updating DNSSEC-bis 419 2.2.1 Partial Type-code and Signal Rollover 421 Carefully crafted type code/signal rollover to define a new 422 authenticated denial space that extends/replaces DNSSEC-bis 423 authenticated denial space. This particular path is illuminated by 424 Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> 425 posted to 2004-06-02. 427 2.2.1.1 Coexistence and Migration 429 To protect the current resolver for future versions, a new DNSSEC-OK 430 bit must be allocated to make clear it does or does not understand 431 the future version. Also, a new DS type needs to be allocated to 432 allow differentiation between a current signed delegation and a 433 'future' signed delegation. Also, current NSEC needs to be rolled 434 into a new authenticated denial type. 436 2.2.1.2 Limitations 438 None. 440 2.2.1.3 Amendments to DNSSEC-bis 442 None. 444 2.2.1.4 Cons 446 It is cumbersome to carefully craft an TCR that 'just fits'. The 447 DNSSEC-bis protocol has many 'borderline' cases that needs special 448 consideration. It might be easier to do a full TCR, since a few of 449 the types and signals need upgrading anyway. 451 2.2.1.5 Pros 453 Graceful adoption of future versions of NSEC, while there are no 454 amendments to DNSSEC-bis. 456 2.2.2 A Complete Type-code and Signal Rollover 458 A new DNSSEC space is defined which can exist independent of current 459 DNSSEC-bis space. 461 This proposal assumes that all current DNSSEC type-codes 462 (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any 463 future versions of DNSSEC. Any future version of DNSSEC has its own 464 types to allow for keys, signatures, authenticated denial, etcetera. 466 2.2.2.1 Coexistence and Migration 468 Both spaces can co-exist. They can be made completely orthogonal. 470 2.2.2.2 Limitations 472 None. 474 2.2.2.3 Amendments to DNSSEC-bis 476 None. 478 2.2.2.4 Cons 480 With this path we abandon the current DNSSEC-bis. Though it is easy 481 to role specific well-known and well-tested parts into the re-write, 482 once deployment has started this path is very expensive for 483 implementers, registries, registrars and registrants as well as 484 resolvers/users. A TCR is not to be expected to occur frequently, so 485 while a next generation authenticated denial may be enabled by a TCR, 486 it is likely that that TCR will only be agreed upon if it serves a 487 whole basket of changes or additions. A quick introduction of 488 NSEC-ng should not be expected from this path. 490 2.2.2.5 Pros 492 No amendments/changes to current DNSSEC-bis docset needed. It is 493 always there as last resort. 495 2.2.3 Unknown Algorithm in RRSIG 497 This proposal assumes that future extensions make use of the existing 498 NSEC RDATA syntax, while it may need to change the interpretation of 499 the RDATA or introduce an alternative denial mechanism, invoked by 500 the specific unknown signing algorithm. The different interpretation 501 would be signaled by use of different signature algorithms in the 502 RRSIG records covering the NSEC RRs. 504 When an entire zone is signed with a single unknown algorithm, it 505 will cause implementations that follow current dnssec-bis documents 506 to treat individual RRsets as unsigned. 508 2.2.3.1 Coexistence and migration 510 Old and new NSEC RDATA interpretation or known and unknown Signatures 511 can NOT coexist in a zone since signatures cover complete (NSEC) 512 RRSets. 514 2.2.3.2 Limitations 516 Validating resolvers agnostic of new interpretation will treat the 517 NSEC RRset as "not signed". This affects wildcard and non-existence 518 proof, as well as proof for (un)secured delegations. Also, all 519 positive signatures (RRSIGs on RRSets other than DS, NSEC) appear 520 insecure/bogus to an old validator. 522 The algorithm version space is split for each future version of 523 DNSSEC. Violation of the 'modular components' concept. We use the 524 'validator' to protect the 'resolver' from unknown interpretations. 526 2.2.3.3 Amendments to DNSSEC-bis 528 None. 530 2.2.3.4 Cons 532 The algorithm field was not designed for this purpose. This is a 533 straightforward hack. 535 2.2.3.5 Pros 537 No amendments/changes to current DNSSEC-bis docset needed. 539 3. Recommendation 541 The authors recommend that the working group commits to and starts 542 work on a partial TCR, allowing graceful transition towards a future 543 version of NSEC. Meanwhile, to accomodate the need for an 544 immediately, temporary, solution against zone-traversal, we recommend 545 On-Demand NSEC synthesis. 547 This approach does not require any mandatory changes to DNSSEC-bis, 548 does not violate the protocol and fulfills the requirements. As a 549 side effect, it moves the cost of implementation and deployment to 550 the users (zone owners) of this mechanism. 552 4. Acknowledgements 554 The authors would like to thank Sam Weiler and Mark Andrews for their 555 input and constructive comments. 557 5. References 559 5.1 Normative References 561 [I-D.ietf-dnsext-dnssec-intro] 562 Arends, R., Austein, R., Massey, D., Larson, M. and S. 563 Rose, "DNS Security Introduction and Requirements", 564 Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October 565 2004. 567 [I-D.ietf-dnsext-dnssec-protocol] 568 Arends, R., "Protocol Modifications for the DNS Security 569 Extensions", 570 Internet-Draft draft-ietf-dnsext-dnssec-protocol-09, 571 October 2004. 573 [I-D.ietf-dnsext-dnssec-records] 574 Arends, R., "Resource Records for the DNS Security 575 Extensions", 576 Internet-Draft draft-ietf-dnsext-dnssec-records-11, 577 October 2004. 579 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 580 STD 13, RFC 1034, November 1987. 582 [RFC1035] Mockapetris, P., "Domain names - implementation and 583 specification", STD 13, RFC 1035, November 1987. 585 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 586 SIG(0)s)", RFC 2931, September 2000. 588 5.2 Informative References 590 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 591 With Widely Deployed DNS Software", RFC 1535, October 592 1993. 594 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 595 RFC 2535, March 1999. 597 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 598 June 1999. 600 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 601 (RR)", RFC 3658, December 2003. 603 Authors' Addresses 605 Roy Arends 606 Telematica Instituut 607 Brouwerijstraat 1 608 Enschede 7523 XC 609 The Netherlands 611 Phone: +31 53 4850485 612 Email: roy.arends@telin.nl 614 Peter Koch 615 DENIC eG 616 Wiesenh"uttenplatz 26 617 Frankfurt 60329 618 Germany 620 Phone: +49 69 27235 0 621 Email: pk@DENIC.DE 623 Jakob Schlyter 624 NIC-SE 625 Box 5774 626 Stockholm SE-114 87 627 Sweden 629 Email: jakob@nic.se 630 URI: http://www.nic.se/ 632 Intellectual Property Statement 634 The IETF takes no position regarding the validity or scope of any 635 Intellectual Property Rights or other rights that might be claimed to 636 pertain to the implementation or use of the technology described in 637 this document or the extent to which any license under such rights 638 might or might not be available; nor does it represent that it has 639 made any independent effort to identify any such rights. Information 640 on the procedures with respect to rights in RFC documents can be 641 found in BCP 78 and BCP 79. 643 Copies of IPR disclosures made to the IETF Secretariat and any 644 assurances of licenses to be made available, or the result of an 645 attempt made to obtain a general license or permission for the use of 646 such proprietary rights by implementers or users of this 647 specification can be obtained from the IETF on-line IPR repository at 648 http://www.ietf.org/ipr. 650 The IETF invites any interested party to bring to its attention any 651 copyrights, patents or patent applications, or other proprietary 652 rights that may cover technology that may be required to implement 653 this standard. Please address the information to the IETF at 654 ietf-ipr@ietf.org. 656 Disclaimer of Validity 658 This document and the information contained herein are provided on an 659 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 660 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 661 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 662 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 663 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 Copyright Statement 668 Copyright (C) The Internet Society (2005). This document is subject 669 to the rights, licenses and restrictions contained in BCP 78, and 670 except as set forth therein, the authors retain all their rights. 672 Acknowledgment 674 Funding for the RFC Editor function is currently provided by the 675 Internet Society.