idnits 2.17.1 draft-ietf-dnsop-dnssec-bootstrapping-01.txt: -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8078]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC7344, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 5 has weird spacing: '...s Track deS...' -- The document date (17 June 2022) is 669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6781 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group P. Thomassen 3 Internet-Draft deSEC, Secure Systems Engineering 4 Updates: 7344, 8078 (if approved) N. Wisiol 5 Intended status: Standards Track deSEC, Technische Universität Berlin 6 Expires: 19 December 2022 17 June 2022 8 Automatic DNSSEC Bootstrapping using Authenticated Signals from the 9 Zone's Operator 10 draft-ietf-dnsop-dnssec-bootstrapping-01 12 Abstract 14 This document introduces an in-band method for DNS operators to 15 publish arbitrary information about the zones they are authoritative 16 for, in an authenticated fashion and on a per-zone basis. The 17 mechanism allows managed DNS operators to securely announce DNSSEC 18 key parameters for zones under their management, including for zones 19 that are not currently securely delegated. 21 Whenever DS records are absent for a zone's delegation, this signal 22 enables the parent's registry or registrar to cryptographically 23 validate the CDS/CDNSKEY records found at the child's apex. The 24 parent can then provision DS records for the delegation without 25 resorting to out-of-band validation or weaker types of cross-checks 26 such as "Accept after Delay" ([RFC8078]). 28 This document updates [RFC8078] and replaces its Section 3 with 29 Section 3.2 of this document. 31 [ Ed note: This document is being collaborated on at 32 https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ 33 (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). 34 The authors gratefully accept pull requests. ] 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 19 December 2022. 53 Copyright Notice 55 Copyright (c) 2022 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Revised BSD License text as 64 described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Revised BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 72 2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.1. Chain of Trust . . . . . . . . . . . . . . . . . . . . . 5 74 2.2. Signaling Names . . . . . . . . . . . . . . . . . . . . . 5 75 3. Bootstrapping a DNSSEC Delegation . . . . . . . . . . . . . . 6 76 3.1. Signaling Consent to Act as the Child's Signer . . . . . 6 77 3.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.2. Validating CDS/CDNSKEY Records for DNSSEC 79 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 7 80 3.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.3. Triggers . . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 9 83 4. Operational Recommendations . . . . . . . . . . . . . . . . . 9 84 4.1. Child DNS Operator . . . . . . . . . . . . . . . . . . . 9 85 4.2. Parental Agent . . . . . . . . . . . . . . . . . . . . . 10 86 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 87 5.1. Child DNS Operator-side . . . . . . . . . . . . . . . . . 10 88 5.2. Parental Agent-side . . . . . . . . . . . . . . . . . . . 10 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 92 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 93 Appendix A. Change History (to be removed before publication) . 12 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 Securing a DNS delegation for the first time requires that the 99 Child's DNSSEC parameters be conveyed to the Parent through some 100 trusted channel. While the communication conceptually has to occur 101 between the Parent registry and the DNSSEC key holder, what exactly 102 that means and how the communication is coordinated traditionally 103 depends on the relationship the Child has with the Parent. 105 A typical situation is that the key is held by the Child DNS 106 Operator; the communication thus often involes this entity. In 107 addition, depending on the circumstances, it may also involve the 108 Registrar, possibly via the Registrant (for details, see [RFC7344], 109 Appendix A). 111 As observed in [RFC7344], these dependencies often result in a manual 112 process that is susceptible to mistakes and/or errors. In addition, 113 due to the annoyance factor of the process, involved parties may 114 avoid the process of getting a DS record set published in the first 115 place. 117 To alleviate these problems, automated provisioning of DS records has 118 been specified in ([RFC8078]). It is based on the Parental Agent 119 (registry or registrar) fetching DNSSEC key parameters in the form of 120 CDS and CDNSKEY records ([RFC7344]) from the Child zone's apex, and 121 validating them somehow. This validation can be done using DNSSEC 122 itself if the objective is to update an existing DS record set (such 123 as during key rollover). However, when bootstrapping a DNSSEC 124 delegation, the Child zone has no existing DNSSEC validation path, 125 and other means to ensure the CDS/CDNSKEY records' legitimacy must be 126 found. 128 For lack of a comprehensive DNS-innate solution, either out-of-band 129 methods have been used so far to complete the chain of trust, or 130 cryptographic validation has been entirely dispensed with, in 131 exchange for weaker types of cross-checks such as "Accept after 132 Delay" ([RFC8078] Section 3.3). [RFC8078] does not define an in-band 133 validation method for enabling DNSSEC. 135 This document aims to close this gap by introducing an in-band method 136 for DNS Operators to publish arbitrary information about the zones 137 they are authoritative for, in an authenticated manner and on a per- 138 zone basis. The mechanism allows managed DNS Operators to securely 139 announce DNSSEC key parameters for zones under their management. The 140 Parent can then use this signal to cryptographically validate the 141 CDS/CDNSKEY records found at an insecure Child zone's apex, and upon 142 success secure the delegation. 144 While applicable to the vast majority of domains, the protocol does 145 not support certain edge cases, such as excessively long Child zone 146 names, or DNSSEC bootstrapping for domains with in-bailick 147 nameservers only (see Section 3.4). 149 Readers are expected to be familiar with DNSSEC, including [RFC4033], 150 [RFC4034], [RFC4035], [RFC6781], [RFC7344], and [RFC8078]. 152 1.1. Terminology 154 This section defines the terminology used in this document. 156 CDS/CDNSKEY This notation refers to CDS and/or CDNSKEY, i.e., one or 157 both. 159 Child The entity on record that has the delegation of the domain 160 from the Parent. 162 Child DNS Operator The entity that maintains and publishes the zone 163 information for the Child DNS. 165 Parent The domain in which the Child is registered. 167 Parental Agent The entity that has the authority to insert DS 168 records into the Parent zone on behalf of the Child. (It could 169 the the registry, registrar, a reseller, or some other authorized 170 entity.) 172 Signaling Domain A hostname from the Child's NS record set, prefixed 173 with the label _signal. There are as many Signaling Domains as 174 there are distinct NS targets. 176 Signaling Name The labels that are prefixed to a Signaling Domain in 177 order to identify a Signaling Type and a Child zone's name (see 178 Section 2.2). 180 Signaling Record A DNS record located at a Signaling Name under a 181 Signaling Domain. Signaling Records are used by the Child DNS 182 Operator to publish information about the Child. 184 Signaling Type A signal type identifier, such as _dsboot for DNSSEC 185 bootstrapping. 187 Signaling Zone The zone which is authoritative for a given Signaling 188 Record. 190 1.2. Requirements Notation 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119] [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 2. Signaling 200 This section describes the general mechanism by which a Child DNS 201 Operator can publish an authenticated signal about a Child zone. 202 Parental Agents (or any other party) can then discover and process 203 the signal. Authenticity is ensured through standard DNSSEC 204 validation. 206 2.1. Chain of Trust 208 If a Child DNS Operator implements the protocol, each Signaling Zone 209 MUST be signed and securely delegated, i.e. have a valid DNSSEC chain 210 of trust. 212 For example, when publishing a signal that relates to a Child zone 213 with NS records ns1.example.net and ns2.example.org, the Child DNS 214 Operator needs to ensure that a valid DNSSEC chain of trust exists 215 for the zone(s) that are authoritative for the Signaling Domains 216 _signal.ns1.example.net and _signal.ns2.example.org. 218 2.2. Signaling Names 220 To publish a piece of information about the Child zone in an 221 authenticated fashion, the Child DNS Operator MUST publish one or 222 more Signaling Records at a Signaling Name under each Signaling 223 Domain. 225 Signaling Records MUST be accompanied by RRSIG records created with 226 the corresponding Signaling Zone's key(s). The type and contents of 227 these Signaling Records depend on the type of signal. 229 The Signaling Name identifies the Child and the Signaling Type. It 230 is identical to the Child name (but with the final root label 231 removed), prefixed with a label containing the Signaling Type. 233 3. Bootstrapping a DNSSEC Delegation 235 When the Child zone's CDS/CDNSKEY RRsets are used for setting up 236 initial trust, they need to be authenticated. This is achieved by 237 co-publishing the Child's CDS/CDNSKEY records as an authenticated 238 signal from the Child DNS Operator. The Parent can discover and 239 validate this signal, thus transferring trust from the Child DNS 240 Operator to the Child zone. 242 Child DNS Operators and Parental Agents who wish to use CDS/CDNSKEY 243 records for DNSSEC bootstrapping SHOULD support the authentication 244 protocol described in this section. 246 3.1. Signaling Consent to Act as the Child's Signer 248 To confirm its willingness to act as the Child's delegated signer and 249 authenticate the Child's CDS/CDNSKEY RRsets, the Child DNS Operator 250 MUST co-publish them at the corresponding Signaling Name under each 251 out-of-bailiwick Signaling Domain (Section 2.2). For simplicity, the 252 Child DNS Operator MAY also co-publish the Child's CDS/CDNSKEY RRsets 253 under Signaling Domains that are in bailiwick, although those 254 Signaling Domains are not used for validation (Section 3.2). 256 Unlike the CDS/CDNSKEY records at the Child's apex, Signaling Records 257 MUST be signed with the corresponding Signaling Zone's key(s). Their 258 contents MUST be identical to the corresponding records published at 259 the Child's apex. 261 Existing use of CDS/CDNSKEY records is specified at the Child apex 262 only ([RFC7344], Section 4.1). This protocol extends the use of 263 these record types to non-apex owner names for the purpose of DNSSEC 264 bootstrapping. To exclude the possibility of semantic collision, 265 there MUST NOT be a zone cut at a Signaling Name. 267 3.1.1. Example 269 For the purposes of bootstrapping the Child zone example.co.uk with 270 NS records ns1.example.net, ns2.example.org, and ns3.example.co.uk, 271 the required Signaling Domains are _signal.ns1.example.net and 272 _signal.ns2.example.org. 274 In the zones containing these domains, the Child DNS Operator 275 authenticates the CDS/CDNSKEY records found at the Child's apex by 276 co-publishing them at the names: 278 _dsboot.example.co.uk._signal.ns1.example.net 279 _dsboot.example.co.uk._signal.ns2.example.org 280 The records are accompanied by RRSIG records created using the key(s) 281 of the respective Signaling Zone. 283 Publication of Signaling Records under the in-bailiwick domain 284 _signal.ns3.example.co.uk is not required. 286 3.2. Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping 288 This section replaces Section 3 of [RFC8078]. 290 To validate a Child's CDS/CDNSKEY RRset for DNSSEC bootstrapping, the 291 Parental Agent, knowing both the Child zone name and its NS 292 hostnames, MUST execute the following steps: 294 1. verify that the Child is not currently securely delegated and 295 that at least one of its nameservers is out of bailiwick; 297 2. query the CDS/CDNSKEY records at the Child zone apex directly 298 from each of the authoritative servers as determined by the 299 delegation's NS record set (without caching); 301 3. query the CDS/CDNSKEY records located at the Signaling Name under 302 each out-of-bailiwick Signaling Domain using a trusted DNS 303 resolver and enforce DNSSEC validation; 305 4. check (separately by record type) that all record sets retrieved 306 in Steps 2 and 3 have equal contents; 308 If the above steps succeed without error, the CDS/CDNSKEY records are 309 successfully validated, and the Parental Agent can proceed with the 310 publication of the DS record set under the precautions described in 311 [RFC8078], Section 5. 313 If, however, an error condition occurs, in particular: 315 * in Step 1: the Child is already securely delegated or has in- 316 bailiwick nameservers only; 318 * in Step 2: any failure during the retrieval of the CDS/CDNSKEY 319 records located at the Child apex from any of the authoritative 320 nameservers; 322 * in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets located 323 at the Signaling Name under any Signaling Domain, including 324 failure of DNSSEC validation, or unauthenticated data (AD bit not 325 set); 327 * in Step 4: inconsistent responses (for at least one of the types), 328 including a record set that is empty in one of Steps 2 or 3, but 329 non-empty in the other; 331 the Parental Agent MUST abort the procedure. 333 3.2.1. Example 335 To verify the CDS/CDNSKEY records for the Child example.co.uk, the 336 Parental Agent (assuming that the Child delegation's NS records are 337 ns1.example.net, ns2.example.org, and ns3.example.co.uk) 339 1. checks that the Child domain is not yet securely delegated; 341 2. queries CDS/CDNSKEY records for example.co.uk directly from 342 ns1.example.net, ns2.example.org, and ns3.example.co.uk (without 343 caching); 345 3. queries and validates the CDS/CDNSKEY records located at (see 346 Section 2.2; ns3.example.co.uk is ignored because it is in 347 bailiwick) 349 _dsboot.example.co.uk._signal.ns1.example.net 350 _dsboot.example.co.uk._signal.ns2.example.org 352 4. checks that the CDS/CDNSKEY record sets retrieved in Steps 2 and 353 3 agree across responses. 355 If all these steps succeed, the Parental Agent can proceed to publish 356 a DS record set as indicated by the validated CDS/CDNSKEY records. 358 The Parental Agent does not use in-bailiwick Signaling Names during 359 validation because they cannot have a pre-established chain of trust 360 at bootstrapping time, so are not useful for bootstrapping. 361 Consequently, if all NS hostnames are in bailiwick, validation cannot 362 be completed, and DS records are not published. 364 3.3. Triggers 366 Parental Agents SHOULD trigger the procedure described in Section 3.2 367 once one of the following conditions is fulfilled: 369 * The Parental Agent receives a new or updated NS record set for a 370 Child; 372 * The Parental Agent encounters Signaling Records during a 373 proactive, opportunistic scan (e.g. daily queries for the 374 Signaling Records of some or all of its delegations); 376 * Any other condition as deemed appropriate by local policy. 378 Most types of discovery (such as daily scans of delegations) are 379 based directly on the delegation's NS record set. In this case, 380 these NS names can be used as is by the bootstrapping algorithm 381 (Section 3.2) for querying Signaling Records. 383 Some discovery methods, however, do not imply reliable knowledge of 384 the Child's NS record set. For example, when discovering Signaling 385 Names by performing an NSEC walk or zone transfer for a Signaling 386 Domain, the Parental Agent MUST NOT assume that the nameserver(s) 387 under whose Signaling Domain(s) a Signaling Name appears is in fact 388 authoritative for the corresponding Child. 390 In this case (and in other cases alike where some list of 391 "bootstrappable domains" is retrieved elsewhere), the Parental Agent 392 MUST ascertain that the Child's delegation actually contains the 393 nameserver hostname seen during discovery, and ensure that Signaling 394 Record queries are only made against the proper set of nameservers as 395 listed in the Child's delegation from the Parent. 397 3.4. Limitations 399 As a consequence of Step 3 in Section 3.2, DS bootstrapping does not 400 work for fully in-bailiwick delegations, as no pre-existing chain of 401 trust to the Child domain is available during bootstrapping. 403 The protocol is further restricted by the fact that the fully 404 qualified Signaling Names fit within the general limits that apply to 405 DNS names (such as their length and label count). 407 4. Operational Recommendations 409 4.1. Child DNS Operator 411 Signaling Domains SHOULD be delegated as zones of their own, so that 412 the Signaling Zone's apex coincides with the Signaling Domain (such 413 as _signal.ns1.example.net). While it is permissible for the 414 Signaling Domain to be contained in a Signaling Zone of fewer labels 415 (such as example.net), a zone cut ensures that bootstrapping 416 activities do not require modifications of the zone containing the 417 nameserver hostname. 419 To keep the size of the Signaling Zones minimal and bulk processing 420 efficient (such as via zone transfers), Child DNS Operators SHOULD 421 remove Signaling Records which are found to have been acted upon. 423 4.2. Parental Agent 425 It is RECOMMENDED to perform queries within Signaling Domains 426 (Section 3.2) with an (initially) cold resolver cache or to limit the 427 TTL of cached records to the interval between scans, as to retrieve 428 the most current information regardless of TTL. (When a batch job is 429 used to attempt bootstrapping for a large number of delegations, the 430 cache does not need to get cleared in between.) 432 5. Implementation Status 434 *Note to the RFC Editor*: please remove this entire section before 435 publication. 437 5.1. Child DNS Operator-side 439 * Knot DNS supports manual creation of non-apex CDS/CDNSKEY records. 441 * PowerDNS supports manual creation of non-apex CDS/CDNSKEY records. 443 * Proof-of-concept Signaling Domains with several thousand Signaling 444 Names exist at _signal.ns1.desec.io and _signal.ns2.desec.org. 446 * Another DNS operator has implemented the protocol (synthesizing 447 Signaling Records for a significant number of domains). 449 * The authors are planning to develop a tool for automatic 450 generation of signaling records. 452 5.2. Parental Agent-side 454 * A tool to retrieve and process Signaling Records for bootstrapping 455 purposes, either directly or via zone walking, is available at 456 https://github.com/desec-io/dsbootstrap (https://github.com/desec- 457 io/dsbootstrap). The tool outputs the validated DS records which 458 then can be added to the Parent zone. 460 * Some registries/registrars (e.g. .cl, GoDaddy) are working on 461 implementations of the protocol. 463 6. Security Considerations 465 The protocol adds authentication to the CDS/CDNSKEY-based 466 bootstrapping concept of [RFC8078], while removing nothing. Its 467 security level is therefore strictly higher than that of existing 468 approaches described in that document (e.g. "Accept after Delay"). 469 Apart from this general improvement, the same Security Considerations 470 apply as in [RFC8078]. 472 The level of rigor in Section 3.2 is needed to prevent publication of 473 a half-baked DS RRset (authorized only under a subset of NS 474 hostnames). This ensures, for example, that an operator in a multi- 475 homed setup cannot enable DNSSEC unless all other operators agree. 477 Because the parents of a Signaling Domain (such as the corresponding 478 TLD registry) are in control of its chain of trust, they are also 479 able to undermine the signal's authenticity. To mitigate this risk, 480 it is RECOMMENDED to increase the effort required to collude for 481 taking control of all Signaling Domains, by diversifying the path 482 from the root to each nameserver. This is best achieved by using 483 different and independently operated TLDs for each one. (TLD- 484 independent NS hostnames are advisable anyways in DNS operations, in 485 order to prevent the TLD from becoming a single point of failure.) 486 Furthermore, as the Child DNS Operator has authoritative knowledge of 487 the Child's CDS/CDNSKEY records, it can readily detect fraudulent 488 provisioning of DS records. 490 7. IANA Considerations 492 Per [RFC8552], IANA is requested to add the following entries to the 493 "Underscored and Globally Scoped DNS Node Names" registry: 495 +---------+------------+-----------------------------------------+ 496 | RR Type | _NODE NAME | Reference | 497 +---------+------------+-----------------------------------------+ 498 | CDS | _signal | [draft-ietf-dnsop-dnssec-bootstrapping] | 499 | CDNSKEY | _signal | [draft-ietf-dnsop-dnssec-bootstrapping] | 500 +---------+------------+-----------------------------------------+ 502 8. Acknowledgements 504 Thanks to Brian Dickson, Ondřej Caletka, John R. Levine, 505 Christian Elmerot, Oli Schacher, Donald Eastlake, and Libor Peltan 506 for reviewing draft proposals and offering comments and suggestions. 508 Thanks also to Steve Crocker, Hugo Salgado, and Ulrich Wisser for 509 early-stage brainstorming. 511 9. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, 515 DOI 10.17487/RFC2119, March 1997, 516 . 518 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 519 Rose, "DNS Security Introduction and Requirements", 520 RFC 4033, DOI 10.17487/RFC4033, March 2005, 521 . 523 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 524 Rose, "Resource Records for the DNS Security Extensions", 525 RFC 4034, DOI 10.17487/RFC4034, March 2005, 526 . 528 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 529 Rose, "Protocol Modifications for the DNS Security 530 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 531 . 533 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 534 Operational Practices, Version 2", RFC 6781, 535 DOI 10.17487/RFC6781, December 2012, 536 . 538 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 539 DNSSEC Delegation Trust Maintenance", RFC 7344, 540 DOI 10.17487/RFC7344, September 2014, 541 . 543 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 544 the Parent via CDS/CDNSKEY", RFC 8078, 545 DOI 10.17487/RFC8078, March 2017, 546 . 548 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 549 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 550 May 2017, . 552 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 553 Records through "Underscored" Naming of Attribute Leaves", 554 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 555 . 557 Appendix A. Change History (to be removed before publication) 559 * draft-ietf-dnsop-dnssec-bootstrapping-01 561 | Allow bootstrapping when some (not all) NS hostnames are in 562 | bailiwick. 563 | 564 | Clarified Operational Recommendations according to operator 565 | feedback. 567 | 568 | Turn loose Security Considerations points into coherent text. 569 | 570 | Do no longer suggest NSEC-walking Signaling Domains. (It does not 571 | work well due to the Signaling Type prefix. What's more, it's 572 | unclear who would do this: Parents know there delegations and can 573 | do a targeted scan; others are not interested.) 574 | 575 | Editorial changes. 576 | 577 | Added IANA request. 578 | 579 | Introduced Signaling Type prefix (_dsboot), renamed Signaling Name 580 | infix from _dsauth to _signal. 582 * draft-ietf-dnsop-dnssec-bootstrapping-00 584 | Editorial changes. 586 * draft-thomassen-dnsop-dnssec-bootstrapping-03 588 | Clarified importance of record cleanup by moving paragraph up. 589 | 590 | Pointed out limitations. 591 | 592 | Replace [RFC8078] Section 3 with our Section 3.2. 593 | 594 | Changed _boot label to _dsauth. 595 | 596 | Removed hashing of Child name components in Signaling Names. 597 | 598 | Editorial changes. 600 * draft-thomassen-dnsop-dnssec-bootstrapping-02 602 | Reframed as an authentication mechanism for RFC 8078. 603 | 604 | Removed multi-signer use case (focus on RFC 8078 authentication). 605 | 606 | Triggers need to fetch NS records (if not implicit from context). 607 | 608 | Improved title. 609 | 610 | Recognized that hash collisions are dealt with by Child apex 611 | check. 613 * draft-thomassen-dnsop-dnssec-bootstrapping-01 614 | Add section on Triggers. 615 | 616 | Clarified title. 617 | 618 | Improved abstract. 619 | 620 | Require CDS/CDNSKEY records at the Child. 621 | 622 | Reworked Signaling Name scheme. 623 | 624 | Recommend using cold cache for consumption. 625 | 626 | Updated terminology (replace "Bootstrapping" by "Signaling"). 627 | 628 | Added NSEC recommendation for Bootstrapping Zones. 629 | 630 | Added multi-signer use case. 631 | 632 | Editorial changes. 634 * draft-thomassen-dnsop-dnssec-bootstrapping-00 636 | Initial public draft. 638 Authors' Addresses 640 Peter Thomassen 641 deSEC, Secure Systems Engineering 642 Berlin 643 Germany 644 Email: peter@desec.io 646 Nils Wisiol 647 deSEC, Technische Universität Berlin 648 Berlin 649 Germany 650 Email: nils@desec.io