idnits 2.17.1 draft-ietf-dnsext-dnssec-trans-03.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 673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 663. ** 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 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 247: '... 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 (October 23, 2005) is 6752 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 582, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 609, 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) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 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 Telematica Instituut 4 Expires: April 26, 2006 P. Koch 5 DENIC eG 6 J. Schlyter 7 NIC-SE 8 October 23, 2005 10 Evaluating DNSSEC Transition Mechanisms 11 draft-ietf-dnsext-dnssec-trans-03.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 April 26, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 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. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 54 2.1.1. Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 55 2.1.2. Add Versioning/Subtyping to Current NSEC . . . . . . . 5 56 2.1.3. Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 57 2.1.4. New Apex Type . . . . . . . . . . . . . . . . . . . . 6 58 2.1.5. NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 59 2.1.6. NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 60 2.1.7. New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 61 2.2. Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 9 62 2.2.1. Partial Type-code and Signal Rollover . . . . . . . . 9 63 2.2.2. A Complete Type-code and Signal Rollover . . . . . . . 10 64 2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG . . . 11 65 2.2.4. Unknown (New) Hash Algorithm in DS . . . . . . . . . . 12 66 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 5.2. Informative References . . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 72 Intellectual Property and Copyright Statements . . . . . . . . . . 16 74 1. Introduction 76 This report shall document the process of dealing with the NSEC 77 walking problem late in the Last Call for [RFC4033], [RFC4034], and 78 [RFC4035]. It preserves some of the discussion that took place in 79 the DNSEXT WG during the first half of June 2004 as well as some 80 additional ideas that came up subsequently. 82 This is an edited excerpt of the chairs' mail to the WG: 83 The working group consents on not including NSEC-alt in the 84 DNSSEC-bis documents. The working group considers to take up 85 "prevention of zone enumeration" as a work item. 86 There may be multiple mechanisms to allow for co-existence with 87 DNSSEC-bis. The chairs allow the working group a little over a 88 week (up to June 12, 2004) to come to consensus on a possible 89 modification to the document to enable gentle rollover. If that 90 consensus cannot be reached the DNSSEC-bis documents will go out 91 as-is. 93 To ease the process of getting consensus, a summary of the proposed 94 solutions and analysis of the pros and cons were written during the 95 weekend. 97 This summary includes: 99 An inventory of the proposed mechanisms to make a transition to 100 future work on authenticated denial of existence. 101 List the known Pros and Cons, possibly provide new arguments, and 102 possible security considerations of these mechanisms. 103 Provide a recommendation on a way forward that is least disruptive 104 to the DNSSEC-bis specifications as they stand and keep an open 105 path to other methods for authenticated denial of existence. 107 The descriptions of the proposals in this document are coarse and do 108 not cover every detail necessary for implementation. In any case, 109 documentation and further study is needed before implementaion and/or 110 deployment, including those which seem to be solely operational in 111 nature. 113 2. Transition Mechanisms 115 In the light of recent discussions and past proposals, we have found 116 several ways to allow for transition to future expansion of 117 authenticated denial. We tried to illuminate the paths and pitfalls 118 in these ways forward. Some proposals lead to a versioning of 119 DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other 120 proposals are 'clean' but may cause delay, while again others may be 121 plain hacks. 123 Some paths do not introduce versioning, and might require the current 124 DNSSEC-bis documents to be fully updated to allow for extensions to 125 authenticated denial mechanisms. Other paths introduce versioning 126 and do not (or minimally) require DNSSEC-bis documents to be updated, 127 allowing DNSSEC-bis to be deployed, while future versions can be 128 drafted independent from or partially depending on DNSSEC-bis. 130 2.1. Mechanisms With Need of Updating DNSSEC-bis 132 Mechanisms in this category demand updates to the DNSSEC-bis document 133 set. 135 2.1.1. Dynamic NSEC Synthesis 137 This proposal assumes that NSEC RRs and the authenticating RRSIG will 138 be generated dynamically to just cover the (non existent) query name. 139 The owner name is (the) one preceding the name queried for, the Next 140 Owner Name Field has the value of the Query Name Field + 1 (first 141 successor in canonical ordering). A separate key (the normal ZSK or 142 a separate ZSK per authoritative server) would be used for RRSIGs on 143 NSEC RRs. This is a defense against enumeration, though it has the 144 presumption of online signing. 146 2.1.1.1. Coexistence and Migration 148 There is no change in interpretation other then that the next owner 149 name might or might not exist. 151 2.1.1.2. Limitations 153 This introduces an unbalanced cost between query and response 154 generation due to dynamic generation of signatures. 156 2.1.1.3. Amendments to DNSSEC-bis 158 The current DNSSEC-bis documents might need to be updated to indicate 159 that the next owner name might not be an existing name in the zone. 160 This is not a real change to the spec since implementers have been 161 warned not to synthesize with previously cached NSEC records. A 162 specific bit to identify the dynamic signature generating key might 163 be useful as well, to prevent it from being used to fake positive 164 data. 166 2.1.1.4. Cons 168 Unbalanced cost is a ground for DDoS. Though this protects against 169 enumeration, it is not really a path for versioning. 171 2.1.1.5. Pros 173 Hardly any amendments to DNSSEC-bis. 175 2.1.2. Add Versioning/Subtyping to Current NSEC 177 This proposal introduces versioning for the NSEC RR type (a.k.a. 178 subtyping) by adding a (one octet) version field to the NSEC RDATA. 179 Version number 0 is assigned to the current (DNSSEC-bis) meaning, 180 making this an 'Must Be Zero' (MBZ) for the to be published docset. 182 2.1.2.1. Coexistence and Migration 184 Since the versioning is done inside the NSEC RR, different versions 185 may coexist. However, depending on future methods, that may or may 186 not be useful inside a single zone. Resolvers cannot ask for 187 specific NSEC versions but may be able to indicate version support by 188 means of a to be defined EDNS option bit. 190 2.1.2.2. Limitations 192 There are no technical limitations, though it will cause delay to 193 allow testing of the (currently unknown) new NSEC interpretation. 195 Since the versioning and signaling is done inside the NSEC RR, future 196 methods will likely be restricted to a single RR type authenticated 197 denial (as opposed to e.g. NSEC-alt, which currently proposes three 198 RR types). 200 2.1.2.3. Amendments to DNSSEC-bis 202 Full Update of the current DNSSEC-bis documents to provide for new 203 fields in NSEC, while specifying behavior in case of unknown field 204 values. 206 2.1.2.4. Cons 208 Though this is a clean and clear path without versioning DNSSEC, it 209 takes some time to design, gain consensus, update the current dnssec- 210 bis document, test and implement a new authenticated denial record. 212 2.1.2.5. Pros 214 Does not introduce an iteration to DNSSEC while providing a clear and 215 clean migration strategy. 217 2.1.3. Type Bit Map NSEC Indicator 219 Bits in the type-bit-map are reused or allocated to signify the 220 interpretation of NSEC. 222 This proposal assumes that future extensions make use of the existing 223 NSEC RDATA syntax, while it may need to change the interpretation of 224 the RDATA or introduce an alternative denial mechanism, invoked by 225 the specific type-bit-map-bits. 227 2.1.3.1. Coexistence and migration 229 Old and new NSEC meaning could coexist, depending how the signaling 230 would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR 231 types are available as well as those covering meta/query types or 232 types to be specifically allocated. 234 2.1.3.2. Limitations 236 This mechanism uses an NSEC field that was not designed for that 237 purpose. Similar methods were discussed during the Opt-In discussion 238 and the Silly-State discussion. 240 2.1.3.3. Amendments to DNSSEC-bis 242 The specific type-bit-map-bits must be allocated and they need to be 243 specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) 244 interpretation. Also, behaviour of the resolver and validator must 245 be documented in case unknown values are encountered for the MBZ 246 field. Currently the protocol document specifies that the validator 247 MUST ignore the setting of the NSEC and the RRSIG bits, while other 248 bits are only used for the specific purpose of the type-bit-map field 250 2.1.3.4. Cons 252 The type-bit-map was not designed for this purpose. It is a 253 straightforward hack. Text in protocol section 5.4 was put in 254 specially to defend against this usage. 256 2.1.3.5. Pros 258 No change needed to the on-the-wire protocol as specified in the 259 current docset. 261 2.1.4. New Apex Type 263 This introduces a new Apex type (parallel to the zone's SOA) 264 indicating the DNSSEC version (or authenticated denial) used in or 265 for this zone. 267 2.1.4.1. Coexistence and Migration 269 Depending on the design of this new RR type multiple denial 270 mechanisms may coexist in a zone. Old validators will not understand 271 and thus ignore the new type, so interpretation of the new NSEC 272 scheme may fail, negative responses may appear 'bogus'. 274 2.1.4.2. Limitations 276 A record of this kind is likely to carry additional feature/ 277 versioning indications unrelated to the current question of 278 authenticated denial. 280 2.1.4.3. Amendments to DNSSEC-bis 282 The current DNSSEC-bis documents need to be updated to indicate that 283 the absence of this type indicates dnssec-bis, and that the (mere) 284 presence of this type indicated unknown versions. 286 2.1.4.4. Cons 288 The only other 'zone' or 'apex' record is the SOA record. Though 289 this proposal is not new, it is yet unknown how it might fulfill 290 authenticated denial extensions. This new RR type would only provide 291 for a generalized signaling mechanism, not the new authenticated 292 denial scheme. Since it is likely to be general in nature, due to 293 this generality consensus is not to be reached soon. 295 2.1.4.5. Pros 297 This approach would allow for a lot of other per zone information to 298 be transported or signaled to both (slave) servers and resolvers. 300 2.1.5. NSEC White Lies 302 This proposal disables one part of NSEC (the pointer part) by means 303 of a special target (root, apex, owner, ...), leaving intact only the 304 ability to authenticate denial of existence of RR sets, not denial of 305 existence of domain names (NXDOMAIN). It may be necessary to have 306 one working NSEC to prove the absence of a wildcard. 308 2.1.5.1. Coexistence and Migration 310 The NSEC target can be specified per RR, so standard NSEC and 'white 311 lie' NSEC can coexist in a zone. There is no need for migration 312 because no versioning is introduced or intended. 314 2.1.5.2. Limitations 316 This proposal breaks the protocol and is applicable to certain types 317 of zones only (no wildcard, no deep names, delegation only). Most of 318 the burden is put on the resolver side and operational consequences 319 are yet to be studied. 321 2.1.5.3. Amendments to DNSSEC-bis 323 The current DNSSEC-bis documents need to be updated to indicate that 324 the NXDOMAIN responses may be insecure. 326 2.1.5.4. Cons 328 Strictly speaking this breaks the protocol and doesn't fully fulfill 329 the requirements for authenticated denial of existence. Security 330 implications need to be carefully documented: search path problems 331 (forged denial of existence may lead to wrong expansion of non-FQDNs 332 [RFC1535]) and replay attacks to deny existence of records. 334 2.1.5.5. Pros 336 Hardly any amendments to DNSSEC-bis. Operational "trick" that is 337 available anyway. 339 2.1.6. NSEC Optional via DNSSKEY Flag 341 A new DNSKEY may be defined to declare NSEC optional per zone. 343 2.1.6.1. Coexistence and Migration 345 Current resolvers/validators will not understand the Flag bit and 346 will have to treat negative responses as bogus. Otherwise, no 347 migration path is needed since NSEC is simply turned off. 349 2.1.6.2. Limitations 351 NSEC can only be made completely optional at the cost of being unable 352 to prove unsecure delegations (absence of a DS RR). A next to this 353 approach would just disable authenticated denial for non-existence of 354 nodes. 356 2.1.6.3. Amendments to DNSSEC-bis 358 New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to 359 be specified in the light of absence of authenticated denial. 361 2.1.6.4. Cons 363 Doesn't fully meet requirements. Operational consequences to be 364 studied. 366 2.1.6.5. Pros 368 Official version of the "trick" presented in (8). Operational 369 problems can be addressed during future work on validators. 371 2.1.7. New Answer Pseudo RR Type 373 A new pseudo RR type may be defined that will be dynamically created 374 (and signed) by the responding authoritative server. The RR in the 375 response will cover the QNAME, QCLASS and QTYPE and will authenticate 376 both denial of existence of name (NXDOMAIN) or RRset. 378 2.1.7.1. Coexistence and Migration 380 Current resolvers/validators will not understand the pseudo RR and 381 will thus not be able to process negative responses so testified. A 382 signaling or solicitation method would have to be specified. 384 2.1.7.2. Limitations 386 This method can only be used with online keys and online signing 387 capacity. 389 2.1.7.3. Amendments to DNSSEC-bis 391 Signaling method needs to be defined. 393 2.1.7.4. Cons 395 Keys have to be held and processed online with all security 396 implications. An additional flag for those keys identifying them as 397 online or negative answer only keys should be considered. 399 2.1.7.5. Pros 401 Expands DNSSEC authentication to the RCODE. 403 2.2. Mechanisms Without Need of Updating DNSSEC-bis 405 2.2.1. Partial Type-code and Signal Rollover 407 Carefully crafted type code/signal rollover to define a new 408 authenticated denial space that extends/replaces DNSSEC-bis 409 authenticated denial space. This particular path is illuminated by 410 Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> 411 posted to 2004-06-02. 413 2.2.1.1. Coexistence and Migration 415 To protect the current resolver for future versions, a new DNSSEC-OK 416 bit must be allocated to make clear it does or does not understand 417 the future version. Also, a new DS type needs to be allocated to 418 allow differentiation between a current signed delegation and a 419 'future' signed delegation. Also, current NSEC needs to be rolled 420 into a new authenticated denial type. 422 2.2.1.2. Limitations 424 None. 426 2.2.1.3. Amendments to DNSSEC-bis 428 None. 430 2.2.1.4. Cons 432 It is cumbersome to carefully craft an TCR that 'just fits'. The 433 DNSSEC-bis protocol has many 'borderline' cases that needs special 434 consideration. It might be easier to do a full TCR, since a few of 435 the types and signals need upgrading anyway. 437 2.2.1.5. Pros 439 Graceful adoption of future versions of NSEC, while there are no 440 amendments to DNSSEC-bis. 442 2.2.2. A Complete Type-code and Signal Rollover 444 A new DNSSEC space is defined which can exist independent of current 445 DNSSEC-bis space. 447 This proposal assumes that all current DNSSEC type-codes (RRSIG/ 448 DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future 449 versions of DNSSEC. Any future version of DNSSEC has its own types 450 to allow for keys, signatures, authenticated denial, etcetera. 452 2.2.2.1. Coexistence and Migration 454 Both spaces can co-exist. They can be made completely orthogonal. 456 2.2.2.2. Limitations 458 None. 460 2.2.2.3. Amendments to DNSSEC-bis 462 None. 464 2.2.2.4. Cons 466 With this path we abandon the current DNSSEC-bis. Though it is easy 467 to role specific well-known and well-tested parts into the re-write, 468 once deployment has started this path is very expensive for 469 implementers, registries, registrars and registrants as well as 470 resolvers/users. A TCR is not to be expected to occur frequently, so 471 while a next generation authenticated denial may be enabled by a TCR, 472 it is likely that that TCR will only be agreed upon if it serves a 473 whole basket of changes or additions. A quick introduction of 474 NSEC-ng should not be expected from this path. 476 2.2.2.5. Pros 478 No amendments/changes to current DNSSEC-bis docset needed. It is 479 always there as last resort. 481 2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG 483 This proposal assumes that future extensions make use of the existing 484 NSEC RDATA syntax, while they may need to change the interpretation 485 of the RDATA or introduce an alternative denial mechanism, invoked by 486 the specific unknown (new) signing algorithm. The different 487 interpretation would be signaled by use of different signature 488 algorithms in the DS RR at the parent. Consequently, the DNSKEY RR 489 for the child zone's KSK would contain a matching algorithm field. 491 2.2.3.1. Coexistence and migration 493 Old and new NSEC RDATA interpretation or known and unknown signatures 494 can NOT coexist in a zone since. While DS RRs with both new and well 495 known algorithm designation could both exist at the parent, that 496 would not lead to an unambiguous interpretation of the NSEC RRs in 497 the zone. RRSIG RRs need to cover complete RRSets, so it is not 498 possible to sign an 'old' NSEC RR with an RRSIG using an 'old' 499 algorithm and then, at the same owner, sign another 'new' NSEC RR 500 with an RRSIG of the 'new' algorithm type. 502 2.2.3.2. Limitations 504 Validating resolvers agnostic of the 'new' signing algorithm (which 505 may be a well known algorithm, but might not be recognized due to the 506 new code) will treat the entire zone as insecure. 508 The algorithm version space is split for each future version of 509 DNSSEC. Violation of the 'modular components' concept. We use the 510 'validator' to protect the 'resolver' from unknown interpretations. 512 2.2.3.3. Amendments to DNSSEC-bis 514 None. 516 2.2.3.4. Cons 518 The algorithm field was not designed for this purpose. This is a 519 straightforward hack. 521 2.2.3.5. Pros 523 No amendments/changes to current DNSSEC-bis docset needed. 525 2.2.4. Unknown (New) Hash Algorithm in DS 527 Similar to the previous method this one uses the DS RR at the parent 528 to signal child zone properties. Here, the digest type field of the 529 DS RR would be used to signal presence of a different (than DNSSEC- 530 bis) authenticated denial scheme at the child. 532 2.2.4.1. Coexistence and migration 534 Old and new NSEC RDATA interpretation or known and unknown signatures 535 can NOT coexist in a zone. 537 2.2.4.2. Limitations 539 Validating resolvers agnostic of the 'new' hashing algorithm (which 540 may be a well known algorithm, but might not be recognized due to the 541 new code) will treat the entire zone as insecure. 543 The digest type space is split for each future version of DNSSEC. 544 Violation of the 'modular components' concept. We use the 545 'validator' to protect the 'resolver' from unknown interpretations. 547 2.2.4.3. Amendments to DNSSEC-bis 549 None. 551 2.2.4.4. Cons 553 The digest type field was not designed for this purpose. This is a 554 straightforward hack. 556 2.2.4.5. Pros 558 No amendments/changes to current DNSSEC-bis docset needed. 560 3. Recommendation 562 The authors recommend that the working group commits to and starts 563 work on a partial TCR, allowing graceful transition towards a future 564 version of NSEC. Meanwhile, to accomodate the need for an 565 immediately, temporary, solution against zone-traversal, we recommend 566 On-Demand NSEC synthesis. 568 This approach does not require any mandatory changes to DNSSEC-bis, 569 does not violate the protocol and fulfills the requirements. As a 570 side effect, it moves the cost of implementation and deployment to 571 the users (zone owners) of this mechanism. 573 4. Acknowledgements 575 The authors would like to thank Sam Weiler and Mark Andrews for their 576 input and constructive comments. 578 5. References 580 5.1. Normative References 582 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 583 STD 13, RFC 1034, November 1987. 585 [RFC1035] Mockapetris, P., "Domain names - implementation and 586 specification", STD 13, RFC 1035, November 1987. 588 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 589 Rose, "DNS Security Introduction and Requirements", 590 RFC 4033, March 2005. 592 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 593 Rose, "Resource Records for the DNS Security Extensions", 594 RFC 4034, March 2005. 596 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 597 Rose, "Protocol Modifications for the DNS Security 598 Extensions", RFC 4035, March 2005. 600 5.2. Informative References 602 [RFC1535] Gavron, E., "A Security Problem and Proposed Correction 603 With Widely Deployed DNS Software", RFC 1535, 604 October 1993. 606 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 607 RFC 2535, March 1999. 609 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 610 June 1999. 612 Authors' Addresses 614 Roy Arends 615 Telematica Instituut 616 Brouwerijstraat 1 617 Enschede 7523 XC 618 The Netherlands 620 Phone: +31 53 4850485 621 Email: roy.arends@telin.nl 623 Peter Koch 624 DENIC eG 625 Wiesenhuettenplatz 26 626 Frankfurt 60329 627 Germany 629 Phone: +49 69 27235 0 630 Email: pk@DENIC.DE 632 Jakob Schlyter 633 NIC-SE 634 Box 5774 635 Stockholm SE-114 87 636 Sweden 638 Email: jakob@nic.se 639 URI: http://www.nic.se/ 641 Intellectual Property Statement 643 The IETF takes no position regarding the validity or scope of any 644 Intellectual Property Rights or other rights that might be claimed to 645 pertain to the implementation or use of the technology described in 646 this document or the extent to which any license under such rights 647 might or might not be available; nor does it represent that it has 648 made any independent effort to identify any such rights. Information 649 on the procedures with respect to rights in RFC documents can be 650 found in BCP 78 and BCP 79. 652 Copies of IPR disclosures made to the IETF Secretariat and any 653 assurances of licenses to be made available, or the result of an 654 attempt made to obtain a general license or permission for the use of 655 such proprietary rights by implementers or users of this 656 specification can be obtained from the IETF on-line IPR repository at 657 http://www.ietf.org/ipr. 659 The IETF invites any interested party to bring to its attention any 660 copyrights, patents or patent applications, or other proprietary 661 rights that may cover technology that may be required to implement 662 this standard. Please address the information to the IETF at 663 ietf-ipr@ietf.org. 665 Disclaimer of Validity 667 This document and the information contained herein are provided on an 668 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 669 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 670 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 671 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 672 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 673 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 675 Copyright Statement 677 Copyright (C) The Internet Society (2005). This document is subject 678 to the rights, licenses and restrictions contained in BCP 78, and 679 except as set forth therein, the authors retain all their rights. 681 Acknowledgment 683 Funding for the RFC Editor function is currently provided by the 684 Internet Society.