Domain Name System Operations (dnsop) U. Wisser Internet-Draft Intended status: Standards Track S. Huque Expires: 22 April 2025 Salesforce J. Stenstam The Swedish Internet Foundation 19 October 2024 DNSSEC automation draft-ietf-dnsop-dnssec-automation-03 Abstract This document describes an algorithm and protocol to automate the setup, operations, and decomissioning of Multi-Signer DNSSEC [RFC8901] configurations. It employs Model 2 of the multi-signer specification, where each operator has their own distinct KSK and ZSK sets (or CSK sets), Managing DS Records from the Parent via CDS/ CDNSKEY [RFC8078], and Child-to-Parent Synchronization in DNS [RFC7477] to accomplish this. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-dnssec-automation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 April 2025. Wisser, et al. Expires 22 April 2025 [Page 1] Internet-Draft DNSSEC automation October 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Out-Of-Scope . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Secure Nameserver Operator Transition . . . . . . . . . . 4 3.2. Permanent multi-signer Operations . . . . . . . . . . . . 5 4. Automation Models . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Centralized . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Decentralized . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 5 5. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Setting up a new multi-signer group . . . . . . . . . . . 6 5.3. A signer joins the multi-signer group . . . . . . . . . . 6 5.4. A signer leaves the multi-signer group . . . . . . . . . 7 5.5. A signer performs a ZSK rollover . . . . . . . . . . . . 8 5.6. A Signer performs a CSK or KSK rollover . . . . . . . . . 8 5.7. Algorithm rollover for the whole multi-signer group . . . 9 5.8. Timing Considerations . . . . . . . . . . . . . . . . . . 9 6. Signers with different algorithms in a multi-signer group . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 11. Informative References . . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Wisser, et al. Expires 22 April 2025 [Page 2] Internet-Draft DNSSEC automation October 2024 1. Introduction [RFC8901] describes the necessary steps and API for a multi-signer DNSSEC configuration. In this document we will combine [RFC8901] with [RFC8078] and [RFC7477] to define an automatable algorithm for setting up, operating and decomissioning of a multi-signer DNSSEC configuration. One of the special cases of multi-signer DNSSEC is the secure change of DNS operator. Using multi-signer Model 2 the secure change of DNS operator can be accomplished. 1.1. Out-Of-Scope In order for any multi-signer group to give consistent answers across all nameservers, the data contents of the zone also have to be synchronized (in addition to infrastructure records like NS, DNSKEY, CDS etc). This content synchronization is out-of-scope for this document. 2. Terminology The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. *Signer* An entity signing a zone *Multi-signer Group* A group of signers that sign the same zone *Controller* An entity controlling the multi-signer group. Used in the decentralized model. *Parent* See [RFC9499] *Trust mechanism* *DS-Wait-Time* Wisser, et al. Expires 22 April 2025 [Page 3] Internet-Draft DNSSEC automation October 2024 Once the parent has picked up and published the new DS record set, the any further changes MUST to be delayed until the new DS set has propagated. The minimum DS-Wait-Time is the TTL of the DS RRset. *DNSKEY-Wait-Time* Once the DNSKEY sets of all signers are updated, any further changes MUST to be delayed until the new DNSKEY set has propagated. The minimum DNSKEY-Wait-Time is the maximum of all DNSKEYS TTL values from all signers plus the time it takes to publish the zone on all secondaries. *NS-Wait-Time* Once the parent has picked up and published the new NS record set, any further changes MUST be delayed until the new NS set has propagated. The minimum NS-Wait-Time is the maximum of the TTL value of the NS set in the parent zone and all NS sets from all signers. 3. Use Cases As described in [RFC8901] a multi-signer DNSSEC configuration has some challenges that can be overcome with the right infrastructure and following a number of steps for setup and operation. In this document we describe, except for the initial trust, how the steps in the multi-migner DNSSEC setup can be automated. 3.1. Secure Nameserver Operator Transition Changing the nameserver operator of a DNSSEC signed zone can be challenging. Currently the most common method is temporarily "going insecure". This is poor for security, and for users relying on the security of the zone. Furthermore, when DNSSEC is being used for application security functions like DANE [RFC6698], it is critical that the DNSSEC chain of trust remain unbroken during the transfer. Multi-signer DNSSEC Model 2 provides a mechanism for transitioning from one nameserver operator to another without "going insecure". A new operator joins the current operator in a temporary multi-signer group. Once that is accomplished and stable the old operator leaves the multi-signer group completing the transition. Wisser, et al. Expires 22 April 2025 [Page 4] Internet-Draft DNSSEC automation October 2024 3.2. Permanent multi-signer Operations Using multiple DNS providers to distribute authoritative DNS service with each provider signing independendly and with their own key set. This use-case is described in [RFC8901]. 4. Automation Models Automation of the necessary steps can be categorized into two main models, centralized and decentralized. Both have pros and cons, and a zone owner should carefully choose the model that works best. 4.1. Centralized In a centralized model a controller executes all steps necessary and controls all signers. The controller needs to have authorized access to all signers. This can be achieved in a variety of different ways. For example will many service providers offer access through a REST API. Another possibility is access through Dynamic Update [RFC2136] with TSIG authentication. 4.2. Decentralized In the decentralized models all signers will communicate with each other and execute the necessary steps on their instance only. For this signers need a specialized protocol to communicate configuration details that are not part of the zone data. 4.3. Capabilities In order for any of the models to work the signer must support the following capabilities. 1. Add DNSKEY records (without the private key) 2. Remove (previously added) DNSKEY record(s) 3. Add CDS and CDNSKEY records for keys not in the DNSKEY set 4. Remove (previously added) CDS and CDNSKEY records 5. Add CSYNC record 6. Remove CSYNC record Wisser, et al. Expires 22 April 2025 [Page 5] Internet-Draft DNSSEC automation October 2024 5. Algorithms In a centralized model it is the controllers task to compute all waiting times and control the zone in a way that all timing restrictions are met. In the decentralized model every signer must compute all waiting times and adhere to all timing restrictions. In both methods it will be necessary that some of the timing restrictions must be given as part of the configuration data. 5.1. Prerequisites Each signer to be added, including the initial signer, must meet the following prerequisites before joining the multi-signer Group 1. A working setup of the zone, including DNSSEC signing. 2. Uses the same algorithm for DNSSEC signing as the multi-signer group uses or will use. 3. Signer or controller must be able to differentiate between its own keys and keys from others signers. 4. Signer or controller must be able to differentiate between NS records that are updated by itself and NS records that receive updates from other signers. 5. If the domain is not covered by a CDS/CDNSKEY scanner and a CSYNC scanner updates to the parent zone have to be made manually. 5.2. Setting up a new multi-signer group The zone is already authoritatively served by one DNS operator and is DNSSEC signed. For full automation both the KSK and ZSK or CSK must be online. This would be a special case, a multi-signer group with only one signer. 5.3. A signer joins the multi-signer group 1. Confirm that the incoming signer meets the prerequisites. 2. Establish a trust mechanism between the multi-signer group and the signer. Wisser, et al. Expires 22 April 2025 [Page 6] Internet-Draft DNSSEC automation October 2024 3. Add ZSK for each signer to all other signers. 4. Calculate CDS/CDNSKEY Records for all KSKs/CSKs represented in the multi-signer group. 5. Configure all signers with the compiled CDS/CDNSKEY RRSET. 6. Wait for Parent to publish the combined DS RRset. 7. Remove CDS/CDNSKEY Records from all signers. (optional) 8. Wait maximum of DS-Wait-Time and DNSKEY-Wait-Time 9. Compile NS RRSET including all NS records from all signers. 10. Configure all signers with the compiled NS RRSET. 11. Compare NS RRSET of the signers to the Parent, if there is a difference publish CSYNC record with NS and A and AAAA bit set on all signers. 12. Wait for Parent to publish NS. 13. Remove CSYNC record from all signers. (optional) 5.4. A signer leaves the multi-signer group 1. Remove exiting signer's NS records from remaining signers 2. Compare NS RRSET of the signers to the Parent, if there is a difference publish CSYNC record with NS and A and AAAA bit set on remaining signers. 3. Wait for Parent to publish NS RRSET. 4. Remove CSYNC record from all signers. (optional) 5. Wait NS-Wait-Time 6. Stop the exiting signer from answering queries. 7. Calculate CDS/CDNSKEY Records for KSKs/CSKs published by the remaining signers. 8. Configure remaining signers with the compiled CDS/CDNSKEY RRSET. 9. Remove ZSK/CSK of the exiting signer from remaining signers. Wisser, et al. Expires 22 April 2025 [Page 7] Internet-Draft DNSSEC automation October 2024 10. Wait for Parent to publish the updated DS RRset. 11. Remove CDS/CDNSKEY set from all signers. (Optional) 5.5. A signer performs a ZSK rollover 1. The signer introduces the new ZSK in its own DNSKEY RRset. 2. Update all signers with the new ZSK. 3. Wait DNSKEY-Wait-Time 4. Signer can start using the new ZSK. 5. When the old ZSK is not used in any signatures by the signer, the signer can remove the old ZSK from its DNSKEY RRset. 6. Remove ZSK from DNSKEY RRset of all signers. 5.6. A Signer performs a CSK or KSK rollover 1. Signer publishes new CSK / KSK in its own DNSKEY RRset. 2. In case of CSK, add CSK to DNSKEY set of all other signers. 3. Signer signs DNSKEY RRset with old and new CSK / KSK. 4. Calculate new CDS/CDNSKEY RRset and publish on all signers. 5. Wait for parent to pickup and publish new DS RR set. 6. Wait DS-Wait-Time + DNSKEY-Wait-Time 7. Signer removes old CSK/KSK from its DNSKEY RR set. And removes all signatures done with this key. 8. In case of CSK, remove old CSK from DNSKEY set of all other signers. 9. Calculate new CDS/CDNSKEY RRset and publish on all signers. 10. Wait for parent to pickup and publish new DS RR set. 11. Remove CDS/CDNSKEY RR sets from all signers. Wisser, et al. Expires 22 April 2025 [Page 8] Internet-Draft DNSSEC automation October 2024 5.7. Algorithm rollover for the whole multi-signer group 1. All signers publish KSK and ZSK or CSK using the new algorithm. 2. All signers sign all zone data with the new keys. 3. Wait until all signers have signed all data with the new key(s). 4. Add new ZSK of each signer to all other signers. 5. Calculate new CDS/CDNSKEY RRset and publish on all signers. 6. Wait for parent to pickup and publish new DS RR set. 7. Wait DS-Wait-Time + DNSKEY-Wait-Time 8. Removes all keys and signatures which are using the old algorithm. 9. Calculate new CDS/CDNSKEY RRset and publish on all signers. 10. Wait for parent to pickup and publish new DS RR set. 11. Remove CDS/CDNSKEY RR sets from all signers. 5.8. Timing Considerations 6. Signers with different algorithms in a multi-signer group Only when all signers use the same algorithm(s) can all resolvers validate zone data with consistency. This section tries to summarize why that is the case and what trade- offs can be made in situations where using the same algorithm isn't possible. Section 2.2 of [RFC4035] states that a signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. A setup where different signers use different key algorithms therefore violates [RFC4035]. According to Section 5.11 of [RFC6840] validators SHOULD NOT insist that all algorithms signaled in the DS RRset work, and they MUST NOT insist that all algorithms signaled in the DNSKEY RRset work. So a multi-signer setup where different signers use different key algorithms should still validate. Wisser, et al. Expires 22 April 2025 [Page 9] Internet-Draft DNSSEC automation October 2024 This could be an acceptable risk in a situation where going insecure is not desirable or impossible and name servers have to be changed between operators which only support distinct set of key algorithms. We have to consider the following scenarios: *Validator supports both algorithms* Validation should be stable through all stages of the multi-signer algorithms. *Validator supports none of the algorithms* The validator will treat the zone as unsigned. Resolution should work through all stages of the multi-signer algorithms. *Validator supports only one of the algorithms* The validator will not be able to validate the DNSKEY RR set or any data from one of the signers. So in some cases the validator will consider the zone bogus and reply with a SERVFAIL response code. The later scenario can be mitigated, but not fully eliminated, by selecting two well-supported algorithms. 7. IANA Considerations This document has no IANA actions. 8. Security Considerations multi-signer DNSSEC inherits the security considerations of [RFC7477], [RFC8078] and [RFC8901]. Every step of the multi-signer algorithms has to be carefully executed at the right time. Any failure could result in the loss of resolution for the domain. Independent of the chosen model, it is crucial that only authorized entities will be able to change the zone data. Some providers or software installation allow to make more specific configuration on the allowed changes. All extra steps to allow as little access to change zone data as possible should be taken. If used correctly, the multi-signer algorithm will strengthen the DNS security by avoiding "going insecure" at any stage of the domain life cycle. Wisser, et al. Expires 22 April 2025 [Page 10] Internet-Draft DNSSEC automation October 2024 9. Implementation Status One implementation of a centralized controller which supports updates through Dynamic DNS or REST API's of several vendors has been implemented by the Swedish Internet Foundation. The code can be found as part of the multi-signer project on Github https://github.com/DNSSEC-Provisioning/multi-signer-controller 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", RFC 7477, DOI 10.17487/RFC7477, March 2015, . [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . Wisser, et al. Expires 22 April 2025 [Page 11] Internet-Draft DNSSEC automation October 2024 11. Informative References [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. Blacka, "Multi-Signer DNSSEC Models", RFC 8901, DOI 10.17487/RFC8901, September 2020, . Appendix A. Acknowledgements The authors would like to thank the following for their review of this work and their valuable comments: Steve Crocker, Eric Osterweil, Roger Murray, Jonas Andersson, Peter Thomassen. Authors' Addresses Ulrich Wisser Email: ulrich@wisser.se Shumon Huque Salesforce Email: shuque@gmail.com Johan Stenstam The Swedish Internet Foundation Email: johan.stenstam@internetstiftelsen.se Wisser, et al. Expires 22 April 2025 [Page 12]