idnits 2.17.1 draft-kumari-ogud-dnsop-cds-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 422 has weird spacing: '... full i.e. ...' == Line 425 has weird spacing: '...augment i.e. ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Continuity: "SHOULD not break the current delegation if applied to DS RRset" -- The document date (July 09, 2013) is 3944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5734' is defined on line 551, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-dnssec-key-timing-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop W. Kumari 3 Internet-Draft Google 4 Intended status: Informational O. Gudmundsson 5 Expires: January 10, 2014 Shinkuro Inc. 6 G. Barwood 8 July 09, 2013 10 Automating DNSSEC delegation trust maintenance 11 draft-kumari-ogud-dnsop-cds-03 13 Abstract 15 This document describes a method to allow DNS operators to more 16 easily update DNSSEC Key Signing Keys using DNS as communication 17 channel. This document does not address the initial configuration of 18 trust anchors for a domain. The technique described is aimed at 19 delegations in which it is currently hard to move information from 20 the child to parent. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 10, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. DNS delegations . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Relationship between Parent and Child DNS operator . . . 5 62 2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6 63 2.2.2. DNSSEC key change process . . . . . . . . . . . . . . 6 64 3. CDS (Child DS) record definition . . . . . . . . . . . . . . 6 65 3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 7 66 4. Automating DS maintainance with CDS records . . . . . . . . . 7 67 4.1. CDS processing rules . . . . . . . . . . . . . . . . . . 7 68 5. Child's CDS Publication . . . . . . . . . . . . . . . . . . . 7 69 6. Parent side CDS Consumption . . . . . . . . . . . . . . . . . 8 70 6.1. Detecting a changed CDS . . . . . . . . . . . . . . . . . 8 71 6.1.1. CDS Polling . . . . . . . . . . . . . . . . . . . . . 8 72 6.2. Usign the new CDS . . . . . . . . . . . . . . . . . . . . 8 73 6.2.1. Parent calculates DS . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 10.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 12 81 Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 When a DNS operator first signs their zone, they need to communicate 87 their DS record(s) (or DNSKEY(s)) to their parent through some out- 88 of-band method to complete the chain of trust. 90 Each time the child changes/rolls the key that is represented in the 91 parent, the new and/or deleted key information has to be communicated 92 to the parent and published there. How this information is sent to 93 the parent depends on the relationship the child has with the parent. 94 In many cases this is a manual process, and not an easy one. For 95 each key roll, there may be two interactions with the parent. Any 96 manual process is susceptible to mistakes and/or errors. In 97 addition, due to the annoyance factor of the process, operators may 98 avoid performing key rollovers or skip needed steps to publish the 99 new DS at the parent. 101 DNSSEC provides data integrity to information published in DNS; thus 102 DNS publication can be used to automate maintenance of delegation 103 information. This document describes a method to automate 104 publication of subsequent DS records, after the initial one has been 105 published. 107 Readers are expected to be familiar with DNSSEC, including [RFC4033], 108 [RFC4034], [RFC4035], [RFC5011] and [RFC6781]. 110 This document is a compilation of two earlier drafts: draft-barwood- 111 dnsop-ds-publish[I-D.ds-publish] and draft-wkumari-dnsop-ezkeyroll 113 This document outlines a technique in which the parent periodically 114 (or upon request) polls its signed children and automatically publish 115 new DS records. To a large extent, the procedures this document 116 follows are as described in [RFC6781] section 4.1.2 118 This technique is in some ways similar to RFC 5011 style rollovers, 119 but for sub-domains DS records, instead of trust anchors 121 This technique is designed to be friendly both to fully automated 122 tools and humans. Fully automated tools can perform all the actions 123 needed without human intervention, and thus can monitor when it is 124 safe to move to the next step. Humans can look at the CDS and DS 125 records and easily see if there is a difference. 127 1.1. Terminology 129 There terminology we use is defined in this section 131 Highlighted roles 133 o Child: "The entity on record that has the delegation of the domain 134 from the parent" 136 o Parent: "The domain in which the child is registered" 138 o Child DNS operator: "The entity that maintains and publishes the 139 zone information for the child DNS" 141 o Parent DNS operator: "The entity that maintains and publishes the 142 zone information for the parent DNS" 144 o Parental Agent: "The entity that the child has relationship with, 145 to change its delegation information." 147 o Provisioning system: "A system that the operator of the master DNS 148 server operates to maintain the information published in the DNS. 149 This includes the systems that sign the DNS data." 151 RRR is our shorthand for Registry/Registrar/Registrant model of 152 parent child relationship see Appendix A for more. 154 1.2. Requirements notation 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2. Background 162 2.1. DNS delegations 164 DNS operation consists of delegations of authority. For each 165 delegation there are (most of the time) two parties the parent and 166 child. 168 In DNS, the parent publishes information about the delegations to the 169 child; for the name-servers it publishes an NS RRset that lists a 170 hint for name-servers that are authoritative for the child. The 171 child also publishes a NS RRset, and this set is the authoritative 172 list of name-servers to the child zone. 174 The second RRset the parent sometimes publishes is the DS set. The 175 DS RRset provides information about the key(s) that the child has 176 told the parent it will use to sign its DNSKEY RRset. In DNSSEC 177 trust relationship between zones is provided by the following chain: 179 parent DNSKEY --> DS --> child DNSKEY. 181 A prior proposal [I-D.auto-cpsync] suggested that the child send an 182 "update" to the parent via a mechanism similar to Dynamic Update. 183 The main issue became: How does the child find the actual parental 184 agent/server to send the update to? While that could have been 185 solved via technical means, the proposal died. 187 As the DS record can only be present at the parent RFC4034 [RFC4034], 188 some other record/method is needed to automate the expression of what 189 the parental zone DS records contents ought to be. One possibility 190 is to use flags in the DNSKEY record. If the SEP bit is set, this 191 indicates that the DNSKEY is intended for use as a secure entry 192 point. This DNSKEY signs the DNSKEY RRset, and the Parental Agent 193 can calculate DS records based on that. But this fails to meet some 194 operating needs, including the child having no influence what DS 195 digest algorithms are used and DS records can only be published for 196 keys that are in the DNSKEY RRset. 198 2.2. Relationship between Parent and Child DNS operator 200 In the real world, there are many different relationships between the 201 parent and child DNS operators. The type of relationship affects how 202 the child operator communicates with the parent. This section will 203 highlight some of the different situations, but is by no means a 204 complete list. 206 Different communication paths: 208 o Direct/API: The child can change the delegation information via 209 automated/scripted means EPP[RFC5730] used by many TLDs is an 210 example of this. Another example is the web service's 211 programmatic interfaces that Registrars make available to their 212 Reseller's. 214 o User Interface: The Child uses a (web) site set up by the Parental 215 Agent for updating delegation information. 217 o Indirect: The communication has to be transmitted via out-of-band 218 between two parties, such as email, telephone etc.. This is common 219 when the Child's DNS operator is neither the child itself nor the 220 Registrar for the domain but a third party. 222 o Multi-step Combinations: The information flows through an 223 intermediary. It is possible, but unlikely, that all the steps 224 are automated via API's and there are no humans are involved. 226 A domain name holder (Child) may operate its own DNS servers or 227 outsource the operation. While we use the word parent as a singular, 228 parent can consist of single entity or a composite of many discrete 229 parts that have rules and roles. We refer to the entity that the 230 child corresponds with as the Parent. 232 Another common case is the enterprise case in which an organization 233 may delegate parts of its name-space to be operated by a group that 234 is not the same as that which operates the enterprise's DNS servers. 235 In this case the flow of information is frequently handled in either 236 an ad hoc manner or via some corporate mechanism; this can range from 237 email to fully-automated operation. The word enterprise above covers 238 all organizations where the domains are not sold on the open market 239 and there is some relationship between the entities. 241 2.2.1. Solution Space 243 This document is aimed at the cases in which there is an 244 organizational separation of the child and parent. 246 A further complication is when the Child DNS Operation is not the 247 Child. There are two common cases of this, 249 a) The Parental Agent (e.g. registrar) handles the DNS operation 251 b) A third party takes care of the DNS operation. 253 If the Parental Agent is the DNS operator, life is much easier, as 254 the Parental Agent can inject any delegation changes directly into 255 the Parents Provisioning system. The techniques described below are 256 not needed in the case when Parental Agent is the DNS operator. 258 In the case of a third party DNS operator, the Child either needs to 259 relay changes in DNS delegation or give the Child Operator access to 260 its delegation/registration account. 262 Some parents want the child to express the changes in trust anchors 263 via DS records, while others want to receive DNSKEY records and 264 calculate the DS records themselves. There is no consensus on which 265 method is better; both have good reasons to exist. The proposal 266 below can operate with both models, but the child needs to be aware 267 of the parental policies. 269 2.2.2. DNSSEC key change process 271 After a Child DNS operator first signs the zone, there is a need to 272 interact with the Parent, for example via the delegation account 273 interface, to "upload/paste-in the zone's DS information". The 274 action of logging in through the delegation account user interface 275 authenticates that the user is authorized to change delegation 276 information published in the parent zone. In the case where "Child 277 DNS Operator" does not have access to the registration account, the 278 Child needs to perform the action. 280 At a later date, the Child Operator may want to publish a new DS 281 record in the parent, either because they are rolling keys, or 282 because they want to publish a stand-by key. This involves 283 performing the same process as before. Furthermore when this is a 284 manual process with cut and paste; operational mistakes will happen. 285 Or worse the update action in not performed at all. 287 3. CDS (Child DS) record definition 288 This document specifies a new DNS RRtype CDS that indicates what the 289 Child wants to be in the parents DS RRset. 291 The CDS record can be published in the child zone and gives the child 292 more control of what is published for it in the parental zone. The 293 CDS RRset expresses what the DS RRset SHOULD look like after the 294 change; it is a "replace" operation, and it is up to the consumer of 295 the records to translate that into the appropriate add/delete 296 operations in the registration systems. 298 3.1. CDS Resource Record Format 300 The wire and presentation format of the CDS ("Child DS") record is 301 identical to the DS record [RFC4034]. IANA has allocated RR code 59 302 for the CDS record via expert review [I-D.ds-publish]. 304 No special processing is performed by authoritative servers or by 305 revolvers, when serving or resolving. For all practical purposes CDS 306 is a regular RR type. 308 4. Automating DS maintainance with CDS records 310 CDS records are intended to be "consumed" by delegation trust 311 maintainers. The use of CDS is optional. 313 4.1. CDS processing rules 315 Absence of CDS in child signals "No change" to the current DS set. 316 Following acceptance rules are placed on the CDS record as follows: 318 o Location: "the CDS record MUST be at the child zone apex". Q: is 319 "_cds.example. a better location for .example? 321 o Signer: "MUST be signed with a key that is represented in both the 322 current DNSKEY and DS RRset's." 324 o Continuity: "SHOULD not break the current delegation if applied to 325 DS RRset" 327 If any these conditions fail the CDS record MUST be ignored. 329 5. Child's CDS Publication 331 Child DNS Operator SHOULD only publish a CDS RRset when it wants to 332 make a change to the DS RRset in the Parent. The CDS RRset SHOULD be 333 compliant with the rules in Section 4.1. When the Parent DS is "in- 334 sync" with the CDS, the Child DNS Operator SHOULD/MUST delete the CDS 335 RRset. 337 6. Parent side CDS Consumption 339 The CDS RRset MAY be used by the Parental Agent to update the DS 340 RRset in the parent zone. The Parental Agent for this uses a tool 341 that understands the CDS signing rules from Section 4.1 so it may not 342 be able to use a standard validator. Parent SHOULD treat the 343 Continuity rule as "MUST". 345 6.1. Detecting a changed CDS 347 How the Parental Agent gets the CDS record may differ, below are two 348 examples as how this can take place. 350 Polling The Parental Agent operates a tool that periodically checks 351 each of the children that has a DS record to see if there is a 352 CDS record. 354 Pushing The delegation user interface has a button {Fetch DS} when 355 pushed preforms the CDS processing. If the Parent zone does 356 not contain DS for this delegation then the "push" MUST be 357 ignored. 359 In either case the Parental Agent MAY apply additional rules that 360 defer the acceptance of a CDS change, these rules may include a 361 condition that the CDS remains in place and valid for some time 362 period before it is accepted. It may be appropriate in the "Pushing" 363 case to assume that the Child is ready and thus accept changes 364 without delay. 366 6.1.1. CDS Polling 368 This is the only defined use of CDS in this document. There are 369 limits to the scalabilty of polling techniques, thus some other 370 mechanism is likely to be specified later that addresses CDS usage in 371 the situation where polling does not scale to. Having said that 372 Polling will work in many important cases like enterprises, 373 universities, small TLD's etc. 375 If the CDS RRset does not exist, the Parental Agent MUST take no 376 action. Specifically it MUST NOT delete or alter the existing DS 377 RRset. 379 6.2. Usign the new CDS 381 Regardless of how the Parent DNS operator detected changes to a CDS 382 RR, the Parent DNS operator MUST use a DNSSEC validator to obtain a 383 validated CDS RRset from the Child zone. It would be a good idea if 384 the Parent DNS operator checked all NS RRs listed at the delegation. 386 However, due to the use of technologies such as load balancing and 387 anycast, this should not be taken as proof that the new CDS is 388 present on all nodes serving the Child zone. 390 The Parent DNS operator MUST ensure that old versions of the CDS 391 RRset do not overwrite newer versions. This MAY be accomplished by 392 checking that the signature inception in the RRSIG for CDS is newer 393 and/or the serial number on the child's SOA is greater. This may 394 require the Parent DNS operator to maintain some state information. 396 The Parent DNS operator MAY take extra security measures. For 397 example, to mitigate the possibility that a Child's key signing key 398 has been compromised, the Parent DNS operator may, for example, 399 inform ( by email or other methods ) the Child DNS operator of the 400 change. However the precise out-of-band measures that a parent zone 401 SHOULD take are outside the scope of this document. 403 Once the Parent DNS operator has obtained a valid CDS it MAY double 404 check the publication rules from section 4.1. In particular the 405 Parent DNS operator MUST double check the Continuity rule and do its 406 best not to invalidate the Child zone. Once checked and if the CDS 407 and DS ``differ'' it may apply the changes to the parent zone. 409 6.2.1. Parent calculates DS 411 There are cases where the Parent wants to calculate the DS record due 412 to policy reasons. In this case, the Child can still publish a CDS 413 records instructing the parent which DNSKEY's to represent in the DS 414 RRset. This requires publication of future keys in the DNSKEY RRset 415 for the parent to be able to calculate the DS record. The DNS Parent 416 needs to publish guidelines for the children as to what digest 417 algorithms are acceptable in the CDS record. 419 When a Parent operates in "calculate DS" mode it can operate in one 420 of two sub-modes 422 full i.e. it only publishes DS records it calculates from DNSKEY 423 records, 425 augment i.e. it will make sure there are DS records for the digest 426 algorithm(s) it requires(s). 428 Implications on Parental Agent are that the CDS and DS are not 429 exactly the same after update thus it needs to take that into 430 consideration when checking CDS records. Same goes for the Child 431 Operator, it needs to be able to detect that the new DS RRset is 432 "equivalent" to the current CDS RRset, thus it can remove the CDS 433 RRset. 435 7. IANA Considerations 437 IANA has assigned RR Type code 59 for CDS. This was done for an 438 earlier version of this document[I-D.ds-publish] This document is to 439 become the reference for CDS RRtype. 441 8. Security Considerations 443 [ This needs more work, suggestions welcome.] 445 This work is for the normal case, when things go wrong there is only 446 so much that automation can fix. 448 If child breaks DNSSEC validation by removing all the DNSKEYs that 449 are represented in the DS set its only repair actions are to contact 450 the parent or restore the DNSKEYs in the DS set. 452 In the event of a compromise of the server or system generating 453 signatures for a zone, an attacker might be able to generate and 454 publish new CDS records. The modified CDS records will be picked up 455 by this technique and so may allow the attacker to extend the 456 effective time of his attack. If there a delay in accepting changes 457 to DS, as in RFC5011, then the attacker needs to hope his activity is 458 not detected before the DS in parent is changed. If this type of 459 change takes place, the child need to contact the parent (possibly 460 via a registrar web interface) and remove any compromised DS keys. 462 A compromise of the account with the parent (e.g. registrar) will not 463 be mitigated by this technique, as the "new registrant" can delete/ 464 modify the DS records at will. 466 While it may be tempting, this SHOULD NOT be used for initial 467 enrollment of keys since there is no way to ensure that the initial 468 key is the correct one. If is used, strict rules for inclusion of 469 keys like hold down times, challenge data inclusion etc., ought to be 470 used, along with some kind of challenge mechanism. 472 The CDS RR type should allow for enhanced security by simplifying 473 process. Since rollover is automated, updating a DS RRset by other 474 means may be regarded as unusual and subject to extra security 475 checks. 477 If there is a failure in applying changes in child zone to all DNS 478 servers listed in either parent or child NS set it is possible that 479 the Parental agent may get confused either not perform action because 480 it gets different answers on different checks or CDS validation 481 fails. In the worst case Parental Agent performs an action reversing 482 a prior action but after the child signing system decides to take the 483 next step in rollover, resulting in a broken delegation. 485 DNS is a loosely coherent distributed database with local caching; 486 therefore it is important to allow old information to expire from 487 caches before deleting DS or DNSKEY records. Similarly, it is 488 important to allow new records to propagate through the DNS before 489 use, see [RFC6781] and [I-D.key-time] 491 9. Acknowledgements 493 This is by no means the invention of the authors. This idea has been 494 floating around for a long time. This simply documents it for 495 discussion. 497 We would like to thank: Joe Abley, Roy Arends, Jim Galvin, Cricket 498 Liu, Stephan Lagerholm, Matt Larson, Olaf Kolkman, Suzanne Woolf, 499 Paul Wouters, Wes Hardaker, Doug Barton, Brian Dickinson, Marco Sanz, 500 Tony Finch, Antoin Verschuren, Edward Lewis Matthijs Meeking, John 501 Dickinson. 503 There were a large number of other folk with whom we discussed this, 504 apologies for not remembering everyone. 506 10. References 508 10.1. Normative References 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 514 Rose, "DNS Security Introduction and Requirements", RFC 515 4033, March 2005. 517 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 518 Rose, "Resource Records for the DNS Security Extensions", 519 RFC 4034, March 2005. 521 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 522 Rose, "Protocol Modifications for the DNS Security 523 Extensions", RFC 4035, March 2005. 525 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 526 Trust Anchors", STD 74, RFC 5011, September 2007. 528 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 529 Operational Practices, Version 2", RFC 6781, December 530 2012. 532 10.2. Informative References 534 [I-D.auto-cpsync] 535 Mekking, W., "Automated (DNSSEC) Child Parent 536 Synchronization using DNS UPDATE", draft-mekking-dnsop- 537 auto-cpsync-01 (work in progress), December 2010. 539 [I-D.ds-publish] 540 Barwood, G., "DNS Transport", draft-barwood-dnsop-ds- 541 publish-02 (work in progress), June 2011. 543 [I-D.key-time] 544 Mekking, W., "DNSSEC Key Timing Considerations", draft- 545 ietf-dnsop-dnssec-key-timing-03 (work in progress), July 546 2012. 548 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 549 STD 69, RFC 5730, August 2009. 551 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 552 Transport over TCP", STD 69, RFC 5734, August 2009. 554 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 555 Security Extensions Mapping for the Extensible 556 Provisioning Protocol (EPP)", RFC 5910, May 2010. 558 Appendix A. RRR background 560 In the RRR world, the different parties are frequently from different 561 organizations. In the single enterprise world there are also 562 organizational/geographical/cultural separations that affect how 563 information flows from a Child to the parent. 565 Due to the complexity of the different roles and interconnections, 566 automation of delegation information has been punted in the past. 567 There have been some proposals to automate this, in order to improve 568 the reliability of the DNS. These proposals have not gained enough 569 traction to become standards. 571 For example in many of the TLD cases there is the RRR model 572 (Registry, Registrar and Registrant). The Registry operates DNS for 573 the TLD, the Registrars accept registrations and place information 574 into the Registries database. The Registrant only communicates with 575 the Registrar; frequently the Registry is not allowed to communicate 576 with the Registrant. In that case as far as the registrant is 577 concerned the Registrar == Parent. 579 In many RRR cases the Registrar and Registry communicate via 580 EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number 581 of ccTLDs there are other mechanisms in use as well as EPP, but in 582 general there seems to be a movement towards EPP usage when DNSSEC is 583 enabled in the TLD. 585 Appendix B. Changes / Author Notes. 587 [RFC Editor: Please remove this section before publication ] 589 From 02 to 03 591 o Applied comments by Matthijs Mekking 593 o Incorporated suggestions from Edward Lewis about structure 595 o Reworked structure to be easier for implementors to follow 597 o Applied many suggestions from a wonderful thorough review by John 598 Dickinson 600 o Removed the going Unsigned option 602 From 01 to 02 604 o Major restructuring to facilitate easier discussion 606 o Lots of comments from DNSOP mailing list incorporated, including 607 making draft DNSKEY/DS neutral, explain different relationships 608 that exists, 610 o added more people to acks. 612 o added description of enterprise situations 614 o Unified on using Parental Agent over Parental Representative 616 o Removed redundant text when possible 618 o Added text to explain what can go wrong if not all child DNS 619 servers are in sync. 621 o Reference prior work by Matthijs Mekking 623 o Added text when parent calculates DS from DNSKEY 625 From - to -1. 627 o Removed from section .1: "If a child zone has gone unsigned, i.e. 628 no DNSKEY and no RRSIG in the zone, the parental representative 629 MAY treat that as intent to go unsigned. (NEEDS DISCUSSION)." 630 Added new text at end. -- suggestion by Scott Rose 20/Feb/13. 632 o Added some background on the different DNS Delegation operating 633 situations and how they affect interaction of parties. This moved 634 some blocks of text from later sections into here. 636 o Number of textual improvements from Stephan Lagerholm 638 o Added motivation why CDS is needed in CDS definition section 640 o Unified terminology in the document. 642 o Much more background 644 Authors' Addresses 646 Warren Kumari 647 Google 648 1600 Amphitheatre Parkway 649 Mountain View, CA 94043 650 US 652 Email: warren@kumari.net 654 Olafur Gudmundsson 655 Shinkuro Inc. 656 4922 Fairmont Av, Suite 250 657 Bethesda, MD 20814 658 USA 660 Email: ogud@ogud.com 661 George Barwood 662 33 Sandpiper Close 663 Gloucester GL2 4LZ 664 United Kingdom 666 Email: george.barwood@blueyonder.co.uk