idnits 2.17.1 draft-wouters-dnsop-secure-update-use-cases-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2136]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 9, 2012) is 4302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4033' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 508, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Informational July 9, 2012 5 Expires: January 10, 2013 7 Secure parent-child DNS update use cases 8 draft-wouters-dnsop-secure-update-use-cases-00.txt 10 Abstract 12 DNS zone administrators occasionally need to update data published by 13 a parent zone, such as NS and DS records. Traditionally these 14 updates have happened out-of-band: through DNS registrar interfaces, 15 EPP, websites, or manually by operators. Some updates could also be 16 done using DNS Dynamic Update [RFC2136]. 18 The IETF's DNSOP working group is considering proposing additional 19 mechanisms for such updates, possibly leveraging DNSSEC for 20 authentication. 22 This document presents some use cases to drive this design work. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 10, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. DNS records with use cases for automated updates . . . . . . . 4 61 3.1. The DS RRset . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. The NS RRset . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Glue records . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. DNSSEC use cases in the Registant, Registrar, Registry 66 model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1.1. Registrar has not adopted DNSSEC . . . . . . . . . . . 5 68 4.1.2. Registrar supports DNSSEC tediously . . . . . . . . . 5 69 4.1.3. sub-Registrar supports DNSSEC but Registrar does 70 not . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1.4. Registrant not setup to talk EPP to Registrar . . . . 6 72 4.2. DNSSEC use cases with direct parent-child DNS server 73 communication . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2.1. DNS management solution of different vendors 75 cannot communicate . . . . . . . . . . . . . . . . . . 6 76 4.2.2. DNS management solution requires non-DNS traffic 77 and new Authentication method . . . . . . . . . . . . 6 78 4.2.3. DNS Management GUI tools are lacking DNSSEC support . 6 79 4.2.4. DNS management solution does not handle when being 80 both child and parent . . . . . . . . . . . . . . . . 7 81 4.3. Non-DNSSEC related DNS record updates . . . . . . . . . . 7 82 4.3.1. NS record and glue updates for the parent . . . . . . 7 83 4.3.2. Parent changes its infrastructure . . . . . . . . . . 7 84 5. Relationships of zones and name servers . . . . . . . . . . . 7 85 5.1. Hidden primary servers . . . . . . . . . . . . . . . . . . 8 86 5.2. Offline private keys . . . . . . . . . . . . . . . . . . . 8 87 5.3. Parent infrastructure . . . . . . . . . . . . . . . . . . 8 88 5.4. Update capability indicator . . . . . . . . . . . . . . . 8 89 5.5. Legalities . . . . . . . . . . . . . . . . . . . . . . . . 8 90 6. The in-band update process . . . . . . . . . . . . . . . . . . 8 91 6.1. No automatic updates . . . . . . . . . . . . . . . . . . . 8 92 6.2. Automatic child to parent updates for the DS record 93 only . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 6.3. Fully-automatic child to parent updates . . . . . . . . . 9 95 6.4. Automatic parent to child updates . . . . . . . . . . . . 9 96 6.5. Fully-automatic child and parent synchronization . . . . . 9 97 6.6. Semi-automatic update . . . . . . . . . . . . . . . . . . 9 98 7. Applicability of automated updates to DNS infrastructure 99 records . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 100 7.1. Administrative Criteria . . . . . . . . . . . . . . . . . 9 101 7.1.1. Contractual obligations . . . . . . . . . . . . . . . 9 102 7.1.2. Company policy . . . . . . . . . . . . . . . . . . . . 10 103 7.1.3. Separation of roles . . . . . . . . . . . . . . . . . 10 104 7.2. Content criteria . . . . . . . . . . . . . . . . . . . . . 10 105 7.2.1. DS update changing a secure zone to become insecure . 10 106 7.2.2. DS update changing a zone to become bogus . . . . . . 10 107 7.2.3. DS update changing a zone to become secure . . . . . . 11 108 7.2.4. NS update causing an outage . . . . . . . . . . . . . 11 109 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 111 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 112 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 113 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 114 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 117 1. Introduction 119 Existing mechanisms for child-to-parent communication in DNS have 120 some constraints that limit their utility. In particular, they 121 require an authentication, which typically requires an extra 122 credential to be exchanged between parent and child. With the advent 123 of DNSSEC, it might be possible to use DNSSEC to authenticate these 124 updates. 126 Furthermore, current mechanisms such as dynamic update also require 127 that the child zone be able to reach the master server for the parent 128 zone. In environments with hidden masters, offline DNSSEC signers or 129 other network architecture constraints, this is not always be 130 feasible. 132 This document identifies the main targets and use cases for automated 133 updates and the concerns related to such automation. 135 [Note: While the document describes the use-cases with the zone, not 136 the name server, as actor, this should not be taken to mean the 137 signaling must be within the zone ] 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 3. DNS records with use cases for automated updates 147 This document limits the scope of use cases to those DNS records that 148 relate to the parent-child relationship itself. Policies for the TTL 149 could be dictated by the parent or the child, depending on the 150 relationship. 152 3.1. The DS RRset 154 The DS record needs to be updated when the child zone performs a Key 155 Signing Key rollover. The parent name server cannot necessarily 156 confirm the updated information by looking into the child zone, for 157 example when the child zone has a spare, unpublished, DNSKEY record. 158 Some parents want to receive DNSKEYs and create the DS record based 159 on the received record. Other parents do not want to be responsible 160 for creating any data for the child, and want to receive ready-made 161 DS records, optionally restrained by the parent's choices of valid 162 algorithms. 164 3.2. The NS RRset 166 Both the child and the parent have a copy of the NS RRset. These 167 RRsets are supposed to be identical. If they differ, it is referred 168 as a "Lame Delegation". Keeping these sets synchronized would result 169 in fewer lame delegations. Modifying the NS RRset is more 170 complicated, as it could involve talking to name servers who do not 171 yet know about the zone. 173 3.3. Glue records 175 Glue records are A or AAAA records that are needed to resolve an NS 176 record that has a recursive relationship. For example, if the NS 177 record for example.com points to ns.example.com, then a glue record 178 is added to the parent zone (.com) for ns.example.com. Note that 179 ns.example.com could be used in NS records for other zones as well. 181 4. Use cases 183 There are different kind of parent-child relationships. A very 184 common relationship is the TLD registry using a Registry-Registrar- 185 Registrant model. In this model, the child dictates the content to 186 the parent. Another common parent-child relationship is the 187 corporate relationship where the head office dictates some parent 188 zone content to the child. 190 4.1. DNSSEC use cases in the Registant, Registrar, Registry model 192 4.1.1. Registrar has not adopted DNSSEC 194 Registrant running the child zone needs to convey their DS record to 195 the Registry running the parent zone. Registrant can only 196 communicate to the Registry using a Registrar. This Registrar does 197 not support the EPP option to convey the DS record from Registrant to 198 Registry. By sending an update via DNS to the Registry, Registrant 199 bypasses the limitations of the Registrar. This use case would 200 require some kind of boot-strap. 202 4.1.2. Registrar supports DNSSEC tediously 204 Registrar supports sending a DS record to the Registry via EPP. 205 Registrant needs to use a human-oriented website interface of 206 Registrar, which is very hard to automate and would break every time 207 Registrar modifies their website for Registrants. By sending an 208 update via DNS to the Registry, Registrant bypasses the limitations 209 of the Registrar. 211 4.1.3. sub-Registrar supports DNSSEC but Registrar does not 213 Registrant can send DNSSEC updates to their (sub)Registrar, but the 214 Registrar does not support receiving updates from sub-Registrar and 215 sub-Registrar cannot communicate to Registry directly. The 216 Registrant or sub-Registrar could bypass the limitations of the 217 Registrar by sending DNSSEC updates directly to the Registry. 219 4.1.4. Registrant not setup to talk EPP to Registrar 221 Registrant is a lightweight entity using an off-the-shelve DNSSEC 222 management solution. They have no technical expertise to communicate 223 using EPP to the Registrar or Registry. Their DNS software could 224 automate sending DNSSEC updates to the Registrar or Registry. 226 4.2. DNSSEC use cases with direct parent-child DNS server communication 228 4.2.1. DNS management solution of different vendors cannot communicate 230 Two different vendors have implemented non-standard, vendor-specific 231 methods for non-DNS parent-child interaction. The DNS 232 administrator(s) have different devices that cannot communicate with 233 each other. If a generic DNS method was standardized, devices could 234 implement this method and inter-operate with each other. 236 4.2.2. DNS management solution requires non-DNS traffic and new 237 Authentication method 239 A non-DNS method for updating DS records between parent and child has 240 been implemented. This method requires a lot of overhead to deploy. 241 A new authentication method between parent and child is needed, for 242 which there is no standard, causing potential interoperability 243 issues. Firewall zones for DNS servers need to be updated to allow 244 non-DNS traffic. If a generic DNS method was standardized, devices 245 could implement this method and inter-operate with each other. 247 4.2.3. DNS Management GUI tools are lacking DNSSEC support 249 The DNS administrator is both administrating parent and child zone 250 using one or more DNS management solutions. These solutions are 251 running known up to date name server software but the vendor has not 252 yet adopted DNSSEC in their GUI. A standardized solution not 253 requiring additional GUI components could support updates more 254 readily. 256 4.2.4. DNS management solution does not handle when being both child 257 and parent 259 The DNS administrator uses a vendor product that does not automate 260 adding the DS in the parent zone, despite the child DNSKEY being 261 available to it. The DNS administrator needs to manually calculate 262 the DS record and add it to the parent. They can no longer run 263 automated rollovers due to this required action that can only be 264 performed manually. If a generic DNS method was standardized, the 265 device could send updates irrespective of whether it also manages the 266 parent zone without additional effort. 268 4.3. Non-DNSSEC related DNS record updates 270 4.3.1. NS record and glue updates for the parent 272 Registrant has a difficult time keeping parent glue and NS RRsets up 273 to date due to using a manual process. After establishing an 274 authenticated relationship between parent and child using the 275 DNSKEY/DS records, the parent could update its glue records based on 276 the child zone content, either by regular polling, or by receiving a 277 notification of the child to update. The parent could distribute 278 such a notification to its siblings. 280 4.3.2. Parent changes its infrastructure 282 Parent name servers are pulling zones from different hidden primaries 283 run by different departments with hundreds of zones. The parent name 284 server infrastructure changes, and it wants to all its hidden 285 primaries to use a different NS RRset. The parent sends an update to 286 the hidden primaries to update the NS RRset for their zones. This 287 category would also cover dyndns solutions where clients send 288 individual host record updates to a parent that might change its 289 location. 291 5. Relationships of zones and name servers 293 While the relationship between child zone and parent zone are well 294 defined, in practice the chain of DNS servers involved is more 295 complicated. Often the authoritative servers for the child zone do 296 not communicate directly with the authoritative servers of the parent 297 zone. Any methods for signaling between the child and parent zone 298 should attempt to accommodate the listed infrastructure. 300 5.1. Hidden primary servers 302 Zones could be updated with IXFR/AXFR using hidden primary servers. 303 DNSSEC signers often work this way. These primary name servers are 304 usually restricted via dedicated VPN links or firewalls, and may not 305 be able to determine or communicate with the required parent server 306 for sending or receiving updates. 308 5.2. Offline private keys 310 Some DNSSEC signing solutions keep the private key inside an HSM or 311 otherwise keep the private keys offline. Updates would need to be 312 able to be generated offline, transported to an internet connected 313 machine, and then transmitted to the parent zone. 315 5.3. Parent infrastructure 317 Some parent zones will require receiving updates for child zones 318 directly from the child name servers, facilitating their current use 319 of firewalls to restrict communication within the network. Other 320 parent zones, such as TLDs, will want to leave their current name 321 server structure unchanged and prefer updates for the child to a 322 special name server dedicated to receive these updates. 324 5.4. Update capability indicator 326 Servers or zones that do not support or allow secure updates should 327 not be sent repetitive update requests. 329 5.5. Legalities 331 Some deployments need to take legal restrictions into account. One 332 such example is the Registry, Registrar, Registrant model, where the 333 Registrant and Registry have no formal relationship with each other 334 or are prohibited from communicating directly with each other. In 335 such situations, secure automated updates should not be attempted. 337 6. The in-band update process 339 Depending on the appropriate process and relationship between parent 340 and child zone, there could be different requirements for the update 341 process. 343 6.1. No automatic updates 345 Records must be added or modified by the administrator of the zone 346 using an out-of-band method. 348 6.2. Automatic child to parent updates for the DS record only 350 The child can send updates of its DS record to the parent, but cannot 351 request updates to the NS RRset or glue records. The parent must be 352 able to reject DS records that do not comply to its allowed selection 353 of valid DNSKEY algorithms. 355 6.3. Fully-automatic child to parent updates 357 The child can send updates of all its records hosted at the parent, 358 including DS records, NS records and glue records. The parent must 359 be able to reject certain updates based on local policy 361 6.4. Automatic parent to child updates 363 The parent can send updates to the child for the NS records and glue 364 records. 366 6.5. Fully-automatic child and parent synchronization 368 Parent and child automatically synchronize with no interaction on the 369 part of the operators. This could be uni-directional of bi- 370 directional. 372 6.6. Semi-automatic update 374 Parent and child synchronize, but only on the request of the parent 375 or child administrator. 377 7. Applicability of automated updates to DNS infrastructure records 379 Automation and direct communication might not be appropriate in all 380 scenarios. Implementations should take note of the considerations in 381 this section. 383 7.1. Administrative Criteria 385 There are many situations where automated updates would not be 386 allowed, or in practice could not be deployed in certain 387 jurisdictions or corporate structures. Automatic update solutions 388 should allow for disabling any such updates to support these 389 restricted deployments. 391 7.1.1. Contractual obligations 393 Some DNS deployments have contractual restrictions that prevents 394 certain parties from directly communicating with each other. For 395 example, some TLDs using the RRR model do not allow the Registry to 396 talk to Registrants directly. 398 7.1.2. Company policy 400 Corporations often separate duties to different individuals or 401 departments, sometimes across different jurisdictions . For example, 402 a DNS officer in one country might not have the authorization of the 403 company to update a DNS zone run by a subsidiary in other country. 404 However, the reverse policy could also be true, where a DNS officer 405 in one country running the parent zone must be able to update any 406 child zone record of a subsidiary in another country. 408 7.1.3. Separation of roles 410 A Registrant (or "owner") of a zone might use a subcontractor to run 411 the infrastructure of its zone. It might not be appropriate for the 412 subcontractor to make any changes in the infrastructure of the zone, 413 despite being in possession of required private keys to send changes 414 to the parent. Similarly, a DNS administrator might be using a 415 DNSSEC signing service, but would not want to allow this signing 416 service to make any changes to the zone content other then signing 417 the zone. 419 7.2. Content criteria 421 [ Note: With NS records, are there any cases where the NS and glue 422 records in the parent zone should not be identical to those in the 423 child zone? What if the child name servers report different NS 424 RRsets?] 426 When a DNS update is requested by the child zone, the parent zone 427 could check and see if such an update would cause (significant?) harm 428 to the child zone, and potentially refuse such an update. 430 7.2.1. DS update changing a secure zone to become insecure 432 If a DS record deletion request would cause the last DS record in the 433 parent for that zone to be deleted, DNSSEC validation for the child 434 zone would change from secure to insecure. A parent zone might wish 435 to refuse such an update or require an additional confirmation. 437 7.2.2. DS update changing a zone to become bogus 439 The parent zone has two DS records for a child zone. Only one of 440 these matches a DNSKEY record in the child zone. If a DS record 441 deletion request would cause the valid DS record in the parent zone 442 to be deleted, DNSSEC validation for the child zone would change from 443 secure to bogus. Similarly, if a child zone is is currently not 444 signed, and the parent zone receives a DS record addition request, 445 DNSSEC validation for the child zone would switch from insecure to 446 bogus. A parent zone might wish to refuse such an update or require 447 an additional confirmation. 449 7.2.3. DS update changing a zone to become secure 451 If a child zone becomes signed and automatically sends a DS addition 452 request to the parent zone, the child zone would change from insecure 453 to secure. This requires a sustained commitment by the child to 454 maintain its DNSSEC status by regularly resigning its RRSIG records. 455 The operators of the child zone might not be ready for such 456 commitment, resulting in the zone becoming bogus at a later state. A 457 parent zone might wish to refuse such an update or require an 458 additional confirmation. 460 7.2.4. NS update causing an outage 462 If a child zone sends an NS update to the parent, the parent zone 463 could check if the new NS records are properly configured to serve 464 the child zone, guaranteeing that no service interruption would be 465 caused by this update. A parent zone might wish to ignore such an 466 update without an explicit override flag. This might be especially 467 important to DNS operators that are unaware of these new DNS update 468 mechanism and believe that changing zone content on the child would 469 never cause any impacts to the parents. 471 8. Security Considerations 473 [Note: This currently overlaps with the section above] 475 An update of a DS record could change the authentication state of the 476 parent-child relationship and should be handled with care. [ Note: or 477 require out-of-band signaling?] 479 9. IANA Considerations 481 This Internet Draft includes no request to IANA. 483 10. Acknowledgements 485 [ Note: none yet ] 487 11. References 489 11.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 11.2. Informative References 496 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 497 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 498 RFC 2136, April 1997. 500 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 501 Rose, "DNS Security Introduction and Requirements", 502 RFC 4033, March 2005. 504 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 505 Rose, "Resource Records for the DNS Security Extensions", 506 RFC 4034, March 2005. 508 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 509 Rose, "Protocol Modifications for the DNS Security 510 Extensions", RFC 4035, March 2005. 512 Author's Address 514 Paul Wouters 515 Red Hat 517 Email: pwouters@redhat.com