idnits 2.17.1 draft-koch-dnsop-dnssec-operator-change-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 130 has weird spacing: '...perator provi...' == Line 135 has weird spacing: '...perator is th...' == Line 138 has weird spacing: '...perator denot...' -- The document date (March 11, 2012) is 4422 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC5910' is defined on line 499, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-dnsop-rfc4641bis-09 ** Obsolete normative reference: RFC 4641 (Obsoleted by RFC 6781) ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Koch 3 Internet-Draft M. Sanz 4 Intended status: Informational DENIC eG 5 Expires: September 12, 2012 March 11, 2012 7 Changing DNS Operators for DNSSEC signed Zones 8 draft-koch-dnsop-dnssec-operator-change-04 10 Abstract 12 Changing the DNS delegation for a DNS zone is quite involved if done 13 by the books, but most often handled pragmatically in today's 14 operational practice at the top level with registries and registrars. 15 This document describes a delegation change procedure that maintains 16 consistency and validation under DNSSEC. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 12, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Purpose of this Document . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements and Assumptions for Seamless Operator 56 Change . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Requirements for Seamless Operator Change . . . . . . 5 58 2.2. Assumptions for Seamless Operator Change . . . . . . . 5 59 3. Executing the Change . . . . . . . . . . . . . . . . . 7 60 3.1. Changing DNS operator only . . . . . . . . . . . . . . 7 61 3.2. Changing DNS operator and registrar . . . . . . . . . 9 62 3.3. Losing operator not participating . . . . . . . . . . 9 63 4. Security Considerations . . . . . . . . . . . . . . . 10 64 5. IANA Considerations . . . . . . . . . . . . . . . . . 10 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . 10 66 7. References . . . . . . . . . . . . . . . . . . . . . . 11 67 7.1. Normative References . . . . . . . . . . . . . . . . . 11 68 7.2. Informative References . . . . . . . . . . . . . . . . 11 69 Appendix A. Document Revision History . . . . . . . . . . . . . . 12 70 A.1. Changes between -03 and -04 . . . . . . . . . . . . . 12 71 A.2. Changes between -02 and -03 . . . . . . . . . . . . . 12 72 A.3. Changes between -01 and -02 . . . . . . . . . . . . . 12 73 A.4. Changes between -00 and -01 . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 When the NS RRSet in a DNS delegation is to be changed from one to a 79 disjoint other, the most conservative approach would be to add the 80 new servers as (stealth) secondary servers, then add them to the NS 81 RRSet, change the primary master (that is, change the AXFR/IXFR 82 source for all the secondary servers), remove the old name servers' 83 names from the NS RRSet and finally cease service on those former 84 name servers. This would involve two changes to the zone file for 85 the apex NS RRSet and in turn two interactions with the parent zone 86 (the registry) for the delegation NS RRSet. Another procedure would 87 at least see the old name servers acquire the new data by transfer 88 and then publish it until the NS records' time to live (TTL) values 89 expire. 91 Operational practice deviates from this in many cases, especially 92 where there is a combined role of the registrar as registrar, DNS 93 operator and web hoster. Often the new infrastructure is set up 94 independent of and in parallel to the old one and there is only one 95 delegation change. Resolvers will access either version of the DNS 96 zone and the inconsistency in DNS data and even at the application 97 layer will be tolerated as long as the end user gets to see any 98 result at all. 100 DNSSEC [RFC4033][RFC4034][RFC4035] is less tolerant to this 101 inconsistency, and the challenge is that access to and validation of 102 DNS data will involve multiple steps. The resolver might access DNS 103 data through one (say, the old) name server infrastructure and DNS 104 key material (the apex DNSKEY RRSet) through the other. A hard 105 switch would increase the likelyhood of a validation failure, should 106 the signature over some RRSet not match any key in the DNSKEY RRSet. 108 1.1. Purpose of this Document 110 This document attempts to list requirements for a seamless change of 111 DNS operators in a registry/registrar environment. It then suggests 112 a procedure that should work in an automated environment even for 113 large numbers of DNS operator changes. It is meant as a supplement 114 or contribution to the updated version of [RFC4641], as currently 115 expressed in [I-D.ietf-dnsop-rfc4641bis], section 4.3.5. 117 1.2. Terminology 119 The change of DNS infrastructure involves multiple parties. We are 120 using the following terms throughout the document. 122 registrar The entity that can change entries in a DNS registry 123 database, usually, but not restricted to, by means of a realtime 124 provisioning protocol like EPP [RFC5730]. NB: the procedure 125 described in this document does not require a strict registry- 126 registrar-registrant separation. Where the registrant can 127 directly interact with the registry they are considered filling 128 the registrar role. 130 DNS operator provides the DNS infrastructure for a given DNS zone 131 (delegated domain). This party may or may not be identical to the 132 registrant or the registrar. The details of provisioning the DNS 133 data into the DNS zone are beyond the scope of this document. 135 losing DNS operator is the party that controls zone content and DNS 136 infrastructure at the beginning of a DNS operator change. 138 gaining DNS operator denotes the party that will control zone 139 content and DNS infrastructure after the successful DNS operator 140 change. 142 The terms Zone Signing Key (ZSK) and Key Signing Key (KSK) are 143 defined in section 2 of [RFC4033]. 145 Domain names and IP addresses herein are for explanatory purposes 146 only and should not be expected to lead to useful information in real 147 life [RFC2606],[RFC5735]. 149 2. Requirements and Assumptions for Seamless Operator Change 151 Regardless of the the particular registry provisioning protocol 152 (e.g., EPP, [RFC5730], [RFC5731]) DNS registries usually provide for 153 a method to transfer a domain name between different registrars. 154 However, from this angle there is no separate role for the DNS 155 operator, the entity that is responsible for the DNS infrastructure 156 and/or the content of the DNS zone. This entity may be identical to 157 the registrar, the registrant, or neither. From the DNSSEC 158 perspective it is important to consider the entity controlling the 159 ZSK and KSK in any transfer that involves changing the NS RRSet to a 160 disjoint set (as opposed to simple additions to or removals from the 161 NS RRSet). 163 The change of a registrar is of limited effect from the DNSSEC 164 perspective. The discussion of the ability of the gaining registrar 165 to accept DNSSEC information within a domain object is beyond the 166 scope of this document. The focus is kept on the change of the DNS 167 operator. There are two cases: ideally, the losing operator will be 168 able to incorporate data generated by the gaining operator into their 169 version of the DNS zone. However, the proposed solution should also 170 be able to cover the case where this cooperation cannot be relied 171 upon. 173 2.1. Requirements for Seamless Operator Change 175 This is a list of requirements for the operator change: 177 no validation failures During the operator change, as in normal 178 operations, DNSSEC validation failures, resulting from unavailable 179 or outdated key or signature material, must be avoided. 181 validation failures worse than insecure Where there is the choice 182 between DNSSEC validation failures and an insecure state, the 183 latter is to be preferred, although its extent still ought to be 184 kept to a necessary minimum. 186 no private keys Private cryptographic keys will not be exchanged 187 between the losing and the gaining operator. Scenarios in which 188 this would be feasible would not pose the challenges addressed in 189 this document. 191 no use of foreign RRSIG information The process of signing a zone is 192 usually done in one of three ways: The zone is signed completely 193 as a file, then loaded into a name server, the signer is a "bump 194 in the wire" solution or the name server combines signing and 195 serving on the primary master. Adding foreign signatures into a 196 zone is not easily achieved in any of these setups, so it ought to 197 be avoided. It also helps contain the effect of changes to an 198 RRSet locally, as no signatures have to be generated remotely with 199 subsequent re-import. 201 little interaction To ease automation the number of interactions 202 between registry, registrar or registrars and operators should be 203 minimized. 205 little overhead for losing operator Whenever interaction or action 206 cannot be avoided, the losing operator should be involved as 207 little as possible to avoid overhead for the leaving customer. In 208 turn, this suggests the gaining operator should be in control of 209 the process. 211 2.2. Assumptions for Seamless Operator Change 213 This is a list of assumptions for the operator change: 215 no direct communication channel between operators We do not assume 216 the existence of a direct, confidential, authenticated 217 communication channel between the losing and the gaining operator. 218 On an abstract level, the registrant could be viewed as an 219 indirect channel, but involving the registrant is not necessarily 220 easily automated. 222 secure communication channel between operator, registrar, and 223 registry We do, though, assume the existence of a direct, 224 confidential, authenticated communication channel between an 225 operator and their registrar as well as between the registrar and 226 the registry. 228 incorporation of foreign DNSKEY RRs To achieve a symmetric 229 validation chain along the DS/KSK/ZSK of both the losing and the 230 gaining DNS operator it is assumed that either operator can, 231 technically, incorporate DNSKEY RRs into their apex DNSKEY RRSet. 232 This includes the ability to subsequently properly sign the DNSKEY 233 RRSet. 235 ability to store and retrieve DNSKEY RRs We assume that registrars 236 are able to store in and retrieve from the registry DNSKEY RRs or 237 equivalent information. This can be achieved by the registry 238 using DNSKEY RRs as key material (as opposed to or in addition to 239 DS RRs) or by the ability to insert DNSKEY data in free text or 240 remarks fields within or associated with the domain object. 242 no algorithm rollover Current reading is that an algorithm rollover 243 requires a full validation with all algorithms involved, whereas a 244 key rollover will work whenever data can be validated using either 245 key ([RFC4035], section 2.2). Therefore, it is assumed that both 246 operators utilize the same DNSSEC key algorithm during the 247 transfer. This does neither preclude the use of different key 248 sizes nor the change of key algorithms after the DNS operator 249 change. 251 ZSK/KSK separation This document assumes a key separation between 252 Zone Signing Key (ZSK) and Key Signing Key (KSK) as per [RFC4641]. 253 Where a zone maintainer decides to use only a single key 254 [I-D.ietf-dnsop-rfc4641bis] the process layout will remain the 255 same, details of differences to be explored in a future update of 256 this draft. 258 no ZSK/KSK rollover in progress Since no private keys will change 259 hands, the operator change implies a key rollover from the losing 260 to the gaining operator. A progressing rollover of the ZSK or KSK 261 at the losing DNS operator would add complexity due to more 262 possible validation paths. While both a rollover and a DNS 263 operator change can be combined, we will, for the sake of 264 simplicty, assume they will not. How to implement this business 265 constraint is beyond the scope of this document. Since the DNS 266 zone at the gaining DNS operator will be set up from scratch, it 267 is assumed there is no rollover in progress, either. 269 resolver does not indefinitely prolongate retention of cached data 270 Some resolvers are known to refresh the TTL of an NS RRSet of a 271 zone upon every authoritative response they receive that carries 272 this NS RRSet in the authority section. This is partly in the 273 spirit of [RFC2181] in that this source (the authoritative child) 274 is more credible than the NS RRSet in a referral, but independent 275 of DNSSEC this behaviour leads to an undesired side effect. These 276 'sticky' resolvers will never learn of a redelegation if that 277 happens by switching between two non-overlapping sets of name 278 servers, which is current practice in many environments. 279 Therefore the process for operator change does not have to take 280 this behaviour into account but may assume benign resolver 281 operation. 283 3. Executing the Change 285 The challenge to face is that during the DNS operator change 286 resolvers may see an NS RRSet pointing to either the losing or the 287 gaining operator's name servers. They may also have cached DNS data 288 and corresponding signatures from either source and this may in 289 particular mean that the apex DNSKEY RRSet and its signature or 290 signatures have a different origin than some other to-be-validated 291 RRSet. 293 To prevent validation failures, resolvers need, through careful 294 timing, be given the chance to acquire the necessary DNSKEY data that 295 allows them to validate signed DNS data from either source. 296 Therefore the DNSKEY RRSets originating from either infrastructure or 297 a limited time window need to have a non zero intersection set that 298 will be covered by both the old an the new trust anchor (or KSK). 300 Changing the DNS operator will be a three step process involving both 301 the gaining and the losing DNS operator. For the sake of simplicity, 302 the first case will not cover a registrar change. 304 3.1. Changing DNS operator only 306 At the beginning, there is a delegation to the losing operator's name 307 servers and a DS RR pointing to a KSK controlled by that losing 308 registrar in the parent zone. As a first step, the gaining operator 309 will obtain through the DNS the ZSK(!) from the losing operator's 310 version of the zone, validate it using the publicly available DNS 311 information, add it to its apex DNSKEY RRSet and re-sign that RRSet. 312 At this point, the new infrastructure will not yet be queried, but it 313 would provide a validation path through the new KSK for signatures 314 generated with the old ZSK. To achieve symmetry, the new ZSK needs 315 to be incorporated into the old apex DNSKEY RRSet. Since a (trusted, 316 validatable) path to that information is not available in the DNS, 317 yet and no direct communication path between the losing and the 318 gaining operator is assumed, the registry will act as a dropbox. 319 Again, for the sake of simplicity, we assume that the registry 320 accepts key material in the form DNSKEY rather than DS resource 321 records. 323 The first change to the registration data, to be initiated by the 324 gaining operator will add the new KSK and the new ZSK to the domain 325 object. This way, the parent zone can publish two (or three, taking 326 into account the ZSK) DS RRs, one for either KSK. At the same time, 327 the registry can make available the new ZSK to the losing operator. 328 No change is initiated yet to the parent zone NS RRSet. 330 Upon appearance of the gaining operator's ZSK in the registry 331 database the losing operator is supposed to copy this ZSK into its 332 version of the apex DNSKEY RRSet and to re-sign the DNSKEY RRSet with 333 the old KSK. 335 Once that has happened and the TTL value of the (previous, sans new 336 ZSK) DNSKEY RRSet has passed, all resolver caches will either have no 337 DNSKEY RRSet for this zone or they will have acquired one that has a 338 signature made by the old KSK over both the old and the new ZSK. The 339 second precondition for the next step is that no DS RRSets exist 340 without reference to the new KSK that was inserted in the previous, 341 first step. This will be the case after the new DS RRSet will have 342 been visible in the DNS and the TTL of the DS RRSet (actually, that 343 of the previous instance of that DS RRSet) will have expired. Both 344 expiration intervals may and likely will overlap, but may start at 345 different times and are otherwise independent. The termination of 346 the later of the two will determine the earliest point in time for 347 progress. 349 The gaining operator can now initiate the second step, changing the 350 NS RRSet in the parent to the new name server infrastructure. At the 351 same time, the ZSK can be removed from the domain object since the 352 registry has fulfilled its role as a ZSK dropbox. Note that a hard 353 delegation change rather than a multi-step phase-in is part of the 354 design to reflect today's operational practice. 356 After this second step, the parent zone will contain an NS RRSet 357 delegating to the gaining operator's name servers as well as two DS 358 records, one referring to the old KSK, the other referring to the new 359 KSK. Due to the two DS RRs, either DNSKEY RRSet can be validated. 360 Either path will provide validation for both the old and the new ZSK. 361 That enables RRSIG validation on all DNS data independent of its 362 origin at the losing or gaining operator's version of the zone. 364 The final third step can be started after all instances of DNSKEY 365 RRSets containing the old KSK have expired. This also requires that 366 no queries are directed to the name servers of the losing operator. 367 The latter can be assumed after the TTL of the (old) NS RRSet at the 368 parent has passed (no delegations to old infrastructure) and 369 subsequently the TTL of the NS RRSet at the losing operator's zone 370 has also passed (no refresh or overwrite of referral data by 371 authoritative data from the child zone). Since a DNSKEY RRSet might 372 have been sent as part of a DNS response just before this expiry, 373 this DNSKEY RRSet's (originating from the losing operator, containing 374 old KSK and new ZSK) TTL must pass, too. In total, counting from the 375 appearance of the new NS RRSet in the parent zone, the sum of the TTL 376 of the NS RRSet at the parent, the TTL of the NS RRSet at the child 377 (losing operator) and the TTL of the DNSKEY RR at the losing operator 378 determines the earliest point in time for proceeding with the next 379 step. 381 The third step will be removing the old KSK from the domain object as 382 part of the KSK rollover. The parent zone will then publish a single 383 DS RR pointing to the new KSK only. As soon as the new DS RRSet will 384 be the only one present in caches, the losing operator may cease to 385 serve the zone. The gaining operator, in turn, can remove the old 386 ZSK from its apex DNSKEY RRSet, not without re-signing this RRSet 387 afterwards. 389 3.2. Changing DNS operator and registrar 391 Should the DNS operator change involve a registrar change the 392 procedure described in the previous paragraph can be followed with 393 one minor change. The first step, adding the new KSK and the new 394 ZSK, will be immediately preceded by a transfer initiated by the 395 gaining registrar. Until the second step will have been executed, 396 the gaining registrar will be the sponsoring entity for a domain 397 object that continues to refer to the losing operator's 398 infrastructure and therefore probably also the losing registrar's 399 data. 401 3.3. Losing operator not participating 403 The procedure described in the previous sections depends upon the 404 losing DNS operator's participation to incorporate the new ZSK into 405 their DNSKEY RRSet. Should the losing operator not participate, 406 reasons for this being beyond the scope of this document, the gaining 407 operator can notice this after waiting a reasonable amount of time 408 after executing the first step. 410 The only known working way to avoid validation failures in this case 411 is to declare the zone insecure by removing the DS RR from the parent 412 zone. Some timing considerations are still due. After the parent 413 has stopped publishing the DS RRSet, and at least one DS TTL has 414 passed, the registered NS RRSet can be changed from the losing 415 operator's to the gaining operator's infrastructure. The gaining 416 operator's key material can be registered in a second step only after 417 the maximum of the TTL values of the parent's and the (losing 418 operator's) child's NS RRSet has passed, again counting from the 419 appearance of the NS RRSet in the parent zone. At this point, the 420 zone's security status is back to "secure". 422 4. Security Considerations 424 Since the procedure described in this document is incompatible with a 425 DNSKEY algorithm rollover during the operator change, it may 426 encourage the use of the same algorithm across all operators 427 involved. This could essentially limit the algorithm agility from an 428 operational perspective. Concerted action might be advised should 429 that preferred algorithm no longer be appropriate. 431 Preferring insecure state over validation failure is a judgement that 432 should be revisited, especially in the light of emerging application 433 protocols that will ignore unsigned or unvalidated DNS data. 435 As with a regular ZSK key rollover there is an odd chance that RRSets 436 with larger TTL values than the DNSKEY and NS RRSets, which dominate 437 the timing considerations, stay in a validator's cache. Any attempt 438 to revalidate these would lead to validation failures due to the 439 unavailability of the old ZSK. 441 5. IANA Considerations 443 This document does not request any IANA action. 445 6. Acknowledgements 447 The review, comments, and contributions by James Galvin, Antoin 448 Verschuren, and Paul Wouters are much appreciated. Special thanks go 449 to the authors and contributors of [RFC4641] and 450 [I-D.ietf-dnsop-rfc4641bis] for detailed work on key rollovers. 452 7. References 454 7.1. Normative References 456 [I-D.ietf-dnsop-rfc4641bis] 457 Kolkman, O. and M. Mekking, "DNSSEC Operational Practices, 458 Version 2", draft-ietf-dnsop-rfc4641bis-09 (work in 459 progress), February 2012. 461 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 462 Names", BCP 32, RFC 2606, June 1999. 464 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 465 Rose, "DNS Security Introduction and Requirements", 466 RFC 4033, March 2005. 468 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 469 RFC 4641, September 2006. 471 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 472 BCP 153, RFC 5735, January 2010. 474 7.2. Informative References 476 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 477 STD 13, RFC 1034, November 1987. 479 [RFC1035] Mockapetris, P., "Domain names - implementation and 480 specification", STD 13, RFC 1035, November 1987. 482 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 483 Specification", RFC 2181, July 1997. 485 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 486 Rose, "Resource Records for the DNS Security Extensions", 487 RFC 4034, March 2005. 489 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 490 Rose, "Protocol Modifications for the DNS Security 491 Extensions", RFC 4035, March 2005. 493 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 494 STD 69, RFC 5730, August 2009. 496 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 497 Domain Name Mapping", STD 69, RFC 5731, August 2009. 499 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 500 Security Extensions Mapping for the Extensible 501 Provisioning Protocol (EPP)", RFC 5910, May 2010. 503 Appendix A. Document Revision History 505 This section is to be removed should the draft be published. 506 $Id: draft-koch-dnsop-dnssec-operator-change.xml,v 1.7 2012/03/11 11:52:38 pk Exp pk $ 508 A.1. Changes between -03 and -04 510 Clarified operational practice in the introduction. 512 Added timing considerations for going through insecure. 514 Elaborated on combined transfer and operator change. 516 Expanded security considerations section. 518 Elevated 4033, 4641, and 4641bis to normative references; relaxed 519 1034, 1035, and 2181 to informative. 521 A.2. Changes between -02 and -03 523 Removed redundant requirement. 525 Reclassified 'sticky' resolver issue to assumption. 527 Explictly assume secure path between registrar and registry. 529 Clarified rollover in progress. 531 A.3. Changes between -01 and -02 533 Split requirements and assumptions. 535 Declared sticky resolvers a non-issue. 537 Increased level of detail of discussion of TTL expiration between 538 updates. 540 Added early security considerations. 542 A.4. Changes between -00 and -01 544 Expanded on the assumptions and requirements. 546 Added initial version of the process description. 548 Authors' Addresses 550 Peter Koch 551 DENIC eG 552 Kaiserstrasse 75-77 553 Frankfurt 60329 554 DE 556 Phone: +49 69 27235 0 557 Email: pk@DENIC.DE 559 Marcos Sanz 560 DENIC eG 561 Kaiserstrasse 75-77 562 Frankfurt 60329 563 DE 565 Phone: +49 69 27235 0 566 Email: sanz@DENIC.DE