idnits 2.17.1 draft-kumari-ogud-dnsop-cds-02.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 == 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 'MUST not' in this paragraph: o Continuity: "MUST not break the current delegation if applied" -- The document date (June 17, 2013) is 3965 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5734' is defined on line 547, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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: December 19, 2013 Shinkuro Inc. 6 G. Barwood 8 June 17, 2013 10 Automating DNSSEC delegation trust maintenance 11 draft-kumari-ogud-dnsop-cds-02 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. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 19, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. DNS delegations . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Relationship between Parent and Child DNS operator . . . 4 60 2.2.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Solution Space . . . . . . . . . . . . . . . . . . . . . 6 62 2.4. DNSSEC key change process . . . . . . . . . . . . . . . . 6 63 3. CDS (Child DS) record definition . . . . . . . . . . . . . . 7 64 3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 7 65 3.1.1. Going unsigned . . . . . . . . . . . . . . . . . . . 7 66 4. Automating DS maintainance with CDS records . . . . . . . . . 8 67 4.1. CDS Publication . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. CDS Consumption . . . . . . . . . . . . . . . . . . . . . 8 69 4.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4. Parent calculates DS . . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 8.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 When a DNS operator first signs their zone, they need to communicate 83 their DS record(s) (or DNSKEY(s)) to their parent through some out- 84 of-band method to complete the chain of trust. 86 Each time the child changes/rolls the key that is represented in the 87 parent, the new and/or deleted key information has to be communicated 88 to the parent and published there. How this information is sent to 89 the parent depends on the relationship the child has with the parent. 90 In many cases this is a manual process, and not an easy one. For 91 each key roll, there may be two interactions with the parent. Any 92 manual process is susceptible to mistakes and/or errors. In 93 addition, due to the annoyance factor of the process, operators may 94 avoid performing key rollovers or skip needed steps to publish the 95 new DS at the parent. 97 DNSSEC provides data integrity to information published in DNS; thus 98 DNS publication can be used to automate maintenance of delegation 99 information. This document describes a method to automate 100 publication of subsequent DS records, after the initial one has been 101 published. 103 Readers are expected to be familiar with DNSSEC, including [RFC4033], 104 [RFC4034], [RFC4035], [RFC5011] and [RFC6781]. 106 This document is a compilation of two earlier drafts, draft-barwood- 107 dnsop-ds-publish and draft-wkumari-dnsop-ezkeyroll 109 This document outlines a technique in which the parent (frequently 110 registrar / registry) periodically (or upon request) polls its signed 111 children and automatically publish new DS records. To a large 112 extent, the procedures this document follows are in [RFC6781] section 113 4.1.2 115 This technique is in some ways similar to RFC 5011 style rollovers, 116 but for sub-domains DS records, instead of trust anchors 118 This technique is designed to be friendly to automated tools, that 119 the tools can perform all the actions needed w/o human intervention, 120 and monitor when it is save to move to next step. 122 1.1. Requirements notation 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 1.2. Terminology 130 In this section we define terms used in the document. There are also 131 definitions we use in section Section 2.2.1. 133 RRR: This is our shorthand for the common registration model used in 134 many delegation mainly zones, this stands for Registry/ 135 Registrar/Registrant. Registry = the domain the registration 136 takes place in, and also refers to the operator of said 137 registry. Registrar on the other hand deals with "customers", 138 "sells'' registrations and provides support. Registrant is the 139 party "buying'' the registration. In some cases there is the 140 4th R in this -- Reseller which is under contract with a 141 Registrar allowing it to sell registrations and record them via 142 the Registrar's systems. 144 2. Background 146 2.1. DNS delegations 148 DNS operation consists of delegations of authority. For each 149 delegation there are (most of the time) two parties the parent and 150 child. 152 In DNS, the parent publishes information about the delegations to the 153 child; for the name-servers it publishes an NS RRset that lists a 154 hint for name-servers that are authoritative for the child. The 155 child also publishes a NS RRset and this set is the authoritative 156 list of name-servers to the child zone. 158 The second RRset the parent sometime publishes is the DS set. The DS 159 RRset provides information about the key(s) that the child has told 160 the parent it will use to sign its DNSKEY RRset. In DNSSEC trust 161 relationship between zones is provided by the following chain: 163 parent DNSKEY --> DS --> child DNSKEY. 165 2.2. Relationship between Parent and Child DNS operator 167 In the real world, there are many different relationships between the 168 parent and child DNS operators. The type of relationship affects how 169 the child operator communicates with the parent. This section will 170 highlight some of the different situations, but is by no means a 171 complete list. 173 A domain name holder (child) may operate its own DNS servers or out 174 source the operation. While we use the word parent as a singular, 175 parent can consist of single entity or a composite of many discrete 176 parts that have rules and roles. For example in many of the TLD 177 cases there is the RRR model (Registry, Registrar and Registrant). 178 The Registry operates DNS for the TLD, the Registrars accept 179 registrations and place information into the Registries' database. 180 The Registrant only communicates with the Registrar; frequently the 181 Registry is not allowed to communicate with the Registrant. In that 182 case as far as the registrant is concerned the Registrar == Parent. 184 Another common case is the enterprise case where an organization may 185 delegate parts of its namespace to be operated by a group that is not 186 the same as operates the enterprises DNS servers. In this case the 187 flow of information is frequently handled in either an ad hoc manner 188 or via some corporate mechanism, this can range from email to fully- 189 automated operation. The word enterprise above is supposed to cover 190 all organization where the domains are not sold on the open market 191 and there is some relationship between the entities. 193 2.2.1. Roles 195 Highlighted roles 197 o Child: "The entity on record that has the delegation of the domain 198 from the parent" 200 o Parent: "The domain in which the child is registered" 202 o Child DNS operator: "The entity that maintains and publishes the 203 zone information for the child DNS" 205 o Parent DNS operator: "The entity that maintains and publishes the 206 zone information for the parent DNS" 208 o Parental Agent: "The entity that the child has relationship with, 209 to change its delegation information." 211 Different communication paths: 213 o Direct/API: The child can change the delegation information via 214 automated/scripted means EPP[RFC5730] used by many TLDs is an 215 example of this. Another example is the web services' 216 programmatic interfaces that Registrars make available to their 217 Resellers. 219 o User Interface: The Child uses a (web) site set up by the Parental 220 Agent for updating delegation information. 222 o Indirect: The communication has to be transmitted via out-of-band 223 between two parties, such as email, telephone etc.. This is common 224 when the Child's DNS operator is neither the child itself nor the 225 Registrar for the domain but a third party. 227 o Multi-step Combinations: The information flows through an 228 intermediary. It is possible, but unlikely, that all the steps 229 are automated via APIs and there are no humans are involved. 231 In the RRR world, the different parties are frequently from different 232 organizations. In the single enterprise world there are also 233 organizational/geographical/clutural seperations that affect how 234 information flows from a child delegation to the parent. 236 Due to the complexity of the different roles and interconnections, 237 automation of delegation information has been punted in the past. 238 There have been some proposals to automate this, in order to improve 239 the reliability of the DNS. These proposals have not gained enough 240 traction to become standards. 242 A prior proposal [cite] suggested that the child send an "update" to 243 the parent via a mechanism similar to Dynamic Update 244 [I-D.auto-cpsync]. . The main issue became: How does the child find 245 the actual parental agent/server to send the update to? While that 246 could have been solved via technical means, the proposal died. 248 2.3. Solution Space 250 This document is aimed at the cases in which there is an 251 organizational separation of the child and parent. 253 In many RRR cases the Registrar and Registry communicate via 254 EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In number 255 of ccTLDs there are other mechanisms in use as well as EPP, but in 256 general there seems to be a movement towards EPP usage when DNSSEC is 257 enabled in the TLD. 259 A further complication is when the DNS Operation is separate from the 260 Registrant. There are two common cases of this, registrar handles 261 the DNS operation and a third party takes care of the DNS operation. 262 In the case of a third party DNS operator, the Registrant either 263 needs to relay changes in DNS delegation or give the operator access 264 to its registration account. If the Registrar is the DNS operator, 265 life is much easier, as it can inject any delegation changes directly 266 into the Registry data bases. The techniques described below are not 267 needed in the case when Registrar is the DNS operator. To reflect 268 that the Registrant is not always the DNS Operator we will use the 269 word "Child Operator" to describe the party that makes changes in the 270 child zone. 272 Some parents want the child to express the changes in trust anchors 273 via DS records, while others want to receive DNSKEY records and 274 calculate the DS records themselves. There is no consensus on which 275 method is better; both have good reasons to exist. The proposal 276 below can operate with both models, but the child needs to be aware 277 of the parental policies. 279 2.4. DNSSEC key change process 281 After a DNS operator first signs its zone, there is a need to 282 interact with the parent via the registration interface to "upload/ 283 paste-in the zone's DS information". The action of logging in 284 through the registration interface authenticates that the user is 285 authorized to change delegation information published in the parent 286 zone. In the case where "Child Operator" does not have access to the 287 registration account, the Registrant needs to perform the action. 289 At a later date, the Child Operator may want to publish a new DS 290 record in the parent, either because they are rolling keys, or 291 because they want to publish a stand-by key. This involves 292 performing the same process as before. Furthermore this is a manual 293 process with cut and paste; operational mistakes will happen. 295 3. CDS (Child DS) record definition 297 The DS record can only be present at the parent RFC4034 [RFC4034] 298 some other method is needed to automate the expression of what the 299 parental zone DS records contents ought to be. One possibility is to 300 use flags in the DNSKEY record. The SEP bit is an optional bit to 301 indicate that the key is allowed to sign the DNSKEY RRset, and the 302 Parental Agent can calculate DS records based on that. But this 303 fails to meet some operating needs, including the child having no 304 influence what DS digest algorithms are used and DS records can only 305 be published for keys that are in the DNSKEY RRset. 307 The CDS record can be published in the child zone and gives the child 308 more control of what is published for it in the parental zone. The 309 CDS RRset expresses what the DS RRset SHOULD look like after the 310 change thus it is a "replace" operation, it is up to the consumer of 311 the records to translate that into the appropriate add/delete 312 operations in the registration systems. 314 3.1. CDS Resource Record Format 316 The wire and presentation format of the CDS ("Child DS") record is 317 identical to the DS record. IANA has allocated RR code 59 for the 318 CDS record. 320 No special processing is performed by authoritative servers or by 321 revolvers, when serving or resolving. For all practical purposes CDS 322 is a regular RR type. 324 3.1.1. Going unsigned 326 In theory the child can use the CDS to reflect to the parent that it 327 wants DS records removed. This can be accomplished by publishing CDS 328 record with the following contents: 330 @ IN CDS 0 0 0 332 This is a suggestion and its security implications have not been 333 fully examined but if like process like [RFC5011] should be used 334 before this is accepted. It is important that the Child remain 335 signed until the DS record has been removed from the parent and the 336 DS has timed out from all caches. 338 Note: maybe it is better to register a special DS digest algorithm 339 number for this ? 341 If the child zone does go unsigned, the Parental Agent should not 342 treat that as intent to go unsigned since that could be an attack. 343 An attacker could spoof unsigned responses to queries from the 344 Parental Agent in an attempt to force a break in the DNSSEC chain. 346 4. Automating DS maintainance with CDS records 348 4.1. CDS Publication 350 CDS records are intended to be "consumed" by delegation trust 351 maintainers, to enable this constraints are placed on how the CDS 352 record as follows: 354 o Location: "the CDS record MUST be at the child zone apex" 356 o Signer: "MUST be signed with a key that is represented in both the 357 current DNSKEY and DS RR-set's." 359 o Continuity: "MUST not break the current delegation if applied" 361 If any these conditions fail the CDS record MUST be ignored, 362 similarly the absence of CDS record signals "No change" in the 363 current DS set. The use of CDS is optional. 365 4.2. CDS Consumption 367 The CDS RRset MAY be used by the Parental Agent to update the DS 368 RRset in the parent zone. The Parental Agent for this uses a tool 369 that understands the CDS signing rules from Section 4.1 thus it is 370 not be able to use a standard validator. 372 How the Parental Agent gets the CDS record may differ, below are two 373 examples as how this can take place. 375 Polling The Parental Agent operates a tool that periodically checks 376 each of the children that has a DS record to see if there is a 377 CDS record. If one exits it applies the checks from section X 378 and if the CDS and DS ``differ'' it applies the changes. 380 Pushing The Parental Agent in its user interface has a button {Fetch 381 DS} when pushed preforms the CDS processing. 383 In the "Polling" case the Parental Agent may apply additional rules 384 that defer the acceptance of CDS information, these rules include CDS 385 remain in place for some time. For example RFC 5011 [RFC5011] uses 386 hold down timers that require new keying information to be published 387 for a month before acceptance as new trust anchor. It is up to each 388 "Parent" and "Parental Agent" to publish minimal rules they apply for 389 child to follow in these cases. The rules SHOULD also include the 390 list of understood digest algorithms. 392 If at least one DS and one CDS records exist, the Parental Agent 393 validates and then copies the contents of the CDS RRset and replaces 394 the entire existing DS set with the new one. 396 When using CDS to publish its key rollover information it is the 397 child's responsibility to monitor the parent for changes to the DS 398 RRset before performing the next action in the key rollover sequence. 399 What this implies is that the child MUST NOT follow a strict time- 400 line but rather strict sequence of steps with time checks. 402 4.3. Usage 404 The Parental Agent SHOULD ensure that old versions of the CDS RRset 405 do not overwrite newer versions, which could occur if the parent 406 performs the checks too frequently. In that case when there is a 407 delay updating the secondary name servers for the child zone. This 408 MAY be accomplished by checking that the signature inception in the 409 RRSIG for CDS is newer and/or the serial number on the child's SOA is 410 greater. 412 If the CDS RRset does not exist, the parent MUST take no action. 413 Specifically it MUST NOT delete the existing DS RRset. 415 If the child zone loses the secret key(s) for the zone, and needs to 416 reset the parent DS RRset, this can only be accomplished by an out- 417 of-band mechanism not defined here. 419 To mitigate situations where a key signing key has been compromised, 420 the Parental Agent MAY take extra security measures, for example 421 informing ( by email or other methods ) the child zone administrator 422 of the change, or by delaying the acceptance of the new DS RRset for 423 some period of time. However the precise out-of-band measures that a 424 parent zone SHOULD take are outside the scope of this document. 426 4.4. Parent calculates DS 427 There are cases where the Parent wants to calculate the DS record for 428 them self due to policy reasons. In this case the Child can still 429 publish a CDS records instructing the parent which DNSKEY's to 430 represent in the DS RRset. This requires publication of future keys 431 in the DNSKEY RRset for the parent to be able to calculate the DS 432 record. The DNS Parent needs to publish guidelines for the children 433 as to what digest algorithms are acceptable in the CDS record. 435 When the Parent operates in "calculate DS" mode it can operate in one 436 of two modes "full" i.e. it only publishes DS records it calculates 437 from DNSKEY records, and "augment" i.e. it will make sure there are 438 DS records for the digest algorithm(s) it requires(s). 440 Implications on Parental Agent are that the CDS and DS are not 441 exactly the same after update thus it needs to take that into 442 consideration when checking CDS records. In the RRR case this 443 calculation can take place either at the Registry or the Registrar 444 (as Parental Agent). If the Registry performs the calculation 445 Parental Agent needs to submit DNSKEY records and possibly (C)DS 446 records as well. 448 5. IANA Considerations 450 IANA has assigned RR Type code 59 for CDS. This was done for an 451 earlier version of this document (draft-barwood-dnsop-ds-publish). 453 6. Security Considerations 455 [ This needs more work, suggestions welcome.] 457 This work is for the normal case, when things go wrong there is only 458 so much that automation can fix. 460 If child breaks DNSSEC validation by removing all the DNSKEYS that 461 are represented in the DS set its only repair actions are to contact 462 the parent or restore the DNSKEY's in the DS set. 464 In the event of a compromise of the server or system generating 465 signatures for a zone, an attacker might be able to generate and 466 publish new CDS records. The modified CDS records will be picked up 467 by this technique and so may allow the attacker to extend the 468 effective time of his attack. If there a delay in accepting changes 469 to DS, as in RFC5011, then the attacker needs to hope his activity is 470 not detected before the DS in parent is changed. If this type of 471 change takes place, the child need to contact the parent (possibly 472 via a registrar web interface) and remove any compromised DS keys. 474 A compromise of the registrar will not be mitigated by this 475 technique, as the "new registrant" can delete/modify the DS records 476 at will. 478 While it may be tempting, this SHOULD NOT be used for initial 479 enrollment of keys since there is no way to ensure that the initial 480 key is the correct one. If is used, strict rules for inclusion of 481 keys like hold down times, challenge data inclusion etc., ought to be 482 used, along with some kind of challenge mechanism. 484 The CDS RR type should allow for enhanced security by simplifying 485 process. Since rollover is automated, updating a DS RRset by other 486 means may be regarded as unusual and subject to extra security 487 checks. 489 If there is a failure in applying changes in child zone to all DNS 490 servers listed in either parent or child NS set it is possible that 491 the Parental agent may get confused either not perform action because 492 it gets different answers on different checks or CDS validation 493 fails. In the worst case Parental Agent performs an action reversing 494 a prior action but after the child signing system decides to take the 495 next step in rollover, resulting in a broken delegation. 497 7. Acknowledgements 499 This is by no means the invention of the authors. This idea has been 500 floating around for a long time. This simply documents it for 501 discussion. 503 We would like to thank: Joe Abley, Roy Arends, Jim Galvin, Cricket 504 Liu, Stephan Lagerholm, Matt Larson, Olaf Kolkman, Suzanne Woolf, 505 Paul Wouters, Wes Hardaker, Doug Barton, Brian Dickinson, Marco Sanz, 506 Tony Finch, Antoin Verschuren, Edward Lewis. 508 There were a large number of other folk with whom we discussed this, 509 apologies for not remembering everyone. 511 8. References 513 8.1. Normative References 515 [IANA.AS_Numbers] 516 IANA, "Autonomous System (AS) Numbers", , 517 . 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 8.2. Informative References 524 [I-D.auto-cpsync] 525 Mekking, W., "Automated (DNSSEC) Child Parent 526 Synchronization using DNS UPDATE", draft-mekking-dnsop- 527 auto-cpsync-01 (work in progress), December 2010. 529 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 530 Rose, "DNS Security Introduction and Requirements", RFC 531 4033, March 2005. 533 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 534 Rose, "Resource Records for the DNS Security Extensions", 535 RFC 4034, March 2005. 537 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 538 Rose, "Protocol Modifications for the DNS Security 539 Extensions", RFC 4035, March 2005. 541 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 542 Trust Anchors", STD 74, RFC 5011, September 2007. 544 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 545 STD 69, RFC 5730, August 2009. 547 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 548 Transport over TCP", STD 69, RFC 5734, August 2009. 550 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 551 Security Extensions Mapping for the Extensible 552 Provisioning Protocol (EPP)", RFC 5910, May 2010. 554 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 555 Operational Practices, Version 2", RFC 6781, December 556 2012. 558 Appendix A. Changes / Author Notes. 560 [RFC Editor: Please remove this section before publication ] 562 From 01 to 02 564 o Major restructuring to facilitate easier discussion 566 o Lots of comments from DNSOP mailing list incorporated, including 567 making draft DNSKEY/DS neutral, explain different relationships 568 that exists, 570 o added more people to acks. 572 o added description of enterprise situations 574 o Unified on usign Parental Agent over Parental Representative 576 o Removed redundant text when possible 578 o Added text to explain what can go wrong if not all child DNS 579 servers are in sync. 581 o Reference prior work by Matthijs Mekking 583 o Added text when parent calculates DS from DNSKEY 585 From - to -1. 587 o Removed from section .1: "If a child zone has gone unsigned, i.e. 588 no DNSKEY and no RRSIG in the zone, the parental representative 589 MAY treat that as intent to go unsigned. (NEEDS DISCUSSION)." 590 Added new text at end. -- suggestion by Scott Rose 20/Feb/13. 592 o Added some background on the different DNS Delegation operating 593 situations and how they affect interaction of parties. This moved 594 some blocks of text from later sections into here. 596 o Number of textual improvements from Stephan Lagerholm 598 o Added motivation why CDS is needed in CDS definition section 600 o Unified terminology in the document. 602 o Much more background 604 Authors' Addresses 606 Warren Kumari 607 Google 608 1600 Amphitheatre Parkway 609 Mountain View, CA 94043 610 US 612 Email: warren@kumari.net 613 Olafur Gudmundsson 614 Shinkuro Inc. 615 4922 Fairmont Av, Suite 250 616 Bethesda, MD 20814 617 USA 619 Email: ogud@ogud.com 621 George Barwood 622 33 Sandpiper Close 623 Gloucester GL2 4LZ 624 United Kingdom 626 Email: george.barwood@blueyonder.co.uk