ICANN

ulrich@wisser.se

Salesforce

shuque@gmail.com

The Swedish Internet Foundation

johan.stenstam@internetstiftelsen.se

Operations and Management Area Domain Name System Operations (dnsop) DNS DNSSEC Multi-Signer Automation This document describes an algorithm and protocol to automate the setup, operations, and decommissioning of Multi-Signer DNSSEC configurations. To accomplish this, it employs Model 2 of the multi-signer specification (where each operator has their own distinct KSK and ZSK sets, or CSK sets), management of DS records from the parent via CDS/CDNSKEY, and Child-to-Parent Synchronization in DNS. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction describes the necessary steps and API for a multi-signer DNSSEC configuration. In this document we will combine Model 2 of with and to define an automatable algorithm for setting up, operating, and decommissioning a multi-signer DNSSEC configuration. Besides steady state multi-signer operation, one of the special use cases of this protocol is to enable non-disruptive migration of a signed DNS zone from one provider to another, which employs a transitory state of a multi-signer configuration.

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.

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 when, and only when, they appear in all capitals, as shown here. KSK Key Signing Key: a DNSSEC key used to sign the DNSKEY RRset. ZSK Zone Signing Key: a DNSSEC key used to sign the other RRsets in a zone. CSK Combined Signing Key: a single key serving both the KSK and ZSK roles. DNSKEY The DNS public key record (). DS The Delegation Signer record published by the parent (). CDS/CDNSKEY Child-published records signaling the desired DS state to the parent (, ). CSYNC The Child-to-Parent Synchronization record (). 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 centralized model. Parent See Trust mechanism An authenticated channel used to apply control-plane changes (DNSKEY, CDS/CDNSKEY, CSYNC, NS) on each signer, possibly mediated by the zone owner or a controller. The detailed mechanism is out of scope for this document. DS-Wait-Time Once the parent has picked up and published the new DS record set, any further changes MUST 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 be delayed until the new DNSKEY set has propagated. The minimum DNSKEY-Wait-Time is the maximum of all DNSKEY 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. RRSIG-Wait-Time Once a signer stops signing zone data with a key, that key MUST remain published in the DNSKEY RRsets of all signers until the signatures it generated have expired from resolver caches. Only then can the key be removed. The minimum RRSIG-Wait-Time is the time it takes to publish the zone on all secondaries plus the maximum TTL of any zone data signed by that key.

Use Cases In this document we describe, except for the initial trust, how the steps in the multi-signer DNSSEC setup can be automated. The following two use cases are in the scope of this document.

Permanent Multi-Signer Operation This is the typical use case described in , where multiple DNS providers are used to cooperatively serve a DNS zone, each signing independently with their own keys, in a steady state configuration to increase availability.

Secure DNS 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 , 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.

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.

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, many service providers offer access through a REST API. Another possibility is access through Dynamic Update with TSIG authentication.

Decentralized In the decentralized model all signers communicate with each other and execute the necessary steps on their own instance. For this, signers need a specialized protocol to communicate configuration details that are not part of the zone data.

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

Algorithms In a centralized model it is the controller's 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, some of the timing restrictions must be specified as part of the configuration data.

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 algorithms 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 other 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. Typically automated updates to the DS and NS records in the parent zone require the parent zone to employ scanning of the CDS/CDNSKEY/CSYNC records in its child zones. Alternatively, the use of the Generalized NOTIFY mechanism could be employed. If neither of these options is available, updates to the parent zone need to be made manually.

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 can be viewed as an initial state where the multi-signer group has only one signer. The group is then grown to its intended size by applying the procedure in to add each additional signer.

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.
3. Add the zone-data-signing key (ZSK, or CSK) of each signer to the DNSKEY RRsets of all the 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, based on observation of the CDS/CDNSKEY RRsets.
7. Remove CDS/CDNSKEY Records from all signers. (optional)
8. Wait for the 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 a CSYNC record with the NS bit set on all signers. The A and AAAA bits are also set if any of the nameservers are in-domain and thus require glue address records at the Parent.
12. Wait for Parent to publish updates to the delegating NS RRset based on observation of the CSYNC RRsets.
13. Remove CSYNC record from all signers. (optional)

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 a CSYNC record with the NS bit set on the remaining signers. The A and AAAA bits are also set if any of the nameservers are in-domain and thus require glue address records at the Parent.
3. Wait for Parent to publish NS RRset.
4. Remove CSYNC record from all signers. (optional)
5. Wait for 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. Wait for RRSIG-Wait-Time, measured from when the exiting signer stopped answering queries, so that any zone data it signed has expired from resolver caches.
10. Remove ZSK/CSK of the exiting signer from remaining signers.
11. Wait for Parent to publish the updated DS RRset.
12. Remove CDS/CDNSKEY set from all signers. (Optional)

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 for DNSKEY-Wait-Time.
4. Signer can start using the new ZSK, and stops signing with the old ZSK.
5. Wait for RRSIG-Wait-Time, so that data signed with the old ZSK has expired from resolver caches. The old ZSK MUST remain published in the DNSKEY RRsets of all signers until then.
6. Remove the old ZSK from the signer's own DNSKEY RRset, and from the DNSKEY RRsets of all other signers.

A signer performs a CSK or KSK rollover

1. Signer publishes new CSK / KSK in its own DNSKEY RRset.
2. In the case of a 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 pick up and publish the new DS RRset.
6. Wait for DS-Wait-Time + DNSKEY-Wait-Time.
7. In the case of a CSK, additionally wait for RRSIG-Wait-Time, so that zone data signed with the old CSK has expired from resolver caches. (This is not required for a KSK-only rollover, since a KSK signs only the DNSKEY RRset, which is covered by DNSKEY-Wait-Time.)
8. Signer removes old CSK/KSK from its DNSKEY RRset, and removes all signatures made with this key.
9. In the case of a CSK, remove old CSK from DNSKEY set of all other signers.
10. Calculate new CDS/CDNSKEY RRset and publish on all signers.
11. Wait for Parent to pick up and publish the new DS RRset.
12. Remove CDS/CDNSKEY RRsets from all signers.

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, while retaining the signatures made with the old-algorithm keys, so that the zone data is signed with both algorithms throughout the rollover (as required by ).
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 pick up and publish the new DS RRset.
7. Wait for DS-Wait-Time + DNSKEY-Wait-Time.
8. Wait for RRSIG-Wait-Time, so that any data signed only with the old-algorithm keys has expired from resolver caches.
9. Remove all keys and signatures that use the old algorithm.
10. Calculate new CDS/CDNSKEY RRset and publish on all signers.
11. Wait for Parent to pick up and publish the new DS RRset.
12. Remove CDS/CDNSKEY RRsets from all signers.

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. requires that there be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset, and that the apex DNSKEY RRset itself be signed by each algorithm appearing in the DS RRset at the delegating parent. A setup where different signers use different key algorithms, each signing only with its own algorithm, therefore violates . According to 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. This could be an acceptable risk in situations where going insecure is undesirable or impossible, and nameservers must be changed between operators that only support disjoint sets 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 RRset or any data from one of the signers, and will typically retry other nameservers for the zone until it can find another signer that it does recognize, or return a SERVFAIL response code otherwise. The latter scenario can be mitigated by selecting only well-supported algorithms. proposes to formally define such "universal" algorithms and sanction such configurations.

Operational Considerations Full automation of the procedures described in this document depends on all of the relevant parties -- the signers, the zone owner or controller, and the Parent -- supporting the protocol mechanisms these procedures rely on. Several of these mechanisms are not yet universally implemented or deployed. On the Parent side, automated management of DS records requires the Parent to perform CDS/CDNSKEY scanning (or to accept Generalized NOTIFY signaling), and automated updates of the delegation's NS records require CSYNC scanning; neither is offered by every registry or registrar today. On the signer side, not all DNS providers support the ability to import and publish the DNSKEY and CDS/CDNSKEY records of the other signers in the group, as required by the capabilities in . Where a required mechanism is unavailable, the corresponding step must be performed by other means, typically a manual update, until support becomes available. A multi-signer group can still operate in such an environment, but with manual steps interposed where automation is not yet possible. Several steps require waiting for the Parent to publish updated DS or NS RRsets in response to CDS/CDNSKEY or CSYNC records (or Generalized NOTIFY signaling). The timing of this publication is controlled by the Parent, not by the multi-signer group, and depends on the Parent's scanning cadence or notification handling. The Parent MAY also decline to act, for example if the CDS/CDNSKEY records do not satisfy the Parent's acceptance policy (see ). Implementations MUST NOT proceed to subsequent steps until the expected DS or NS RRset change is observed at the Parent, and SHOULD bound each such wait with a timeout after which the operation is flagged for operator attention rather than continuing. A premature transition to a later step, particularly one that removes a key or signature, while the Parent still publishes the old delegation can break the chain of trust and cause resolution failures.

IANA Considerations This document has no IANA actions.

Security Considerations Multi-signer DNSSEC inherits the security considerations of , and . Every step of the multi-signer algorithms has to be carefully executed at the right time. Failures could result in the loss of resolution for the domain. Independent of the chosen model, it is crucial that only authorized entities are able to change the zone data. Some providers or software installations allow finer-grained configuration of which changes are permitted. Access to modify zone data should be restricted as much as possible. Multi-signer configurations can strengthen DNS security by avoiding a DNS zone "going insecure" during a DNS operator transition. A steady state multi-signer configuration can also greatly strengthen availability by having multiple distinct DNS providers cooperatively serving the same signed zone. A catastrophic failure of any single provider then cannot take down the zone.

Implementation Status The Swedish Internet Foundation has implemented a centralized controller that supports updates via Dynamic DNS or the REST APIs of several vendors. The code can be found as part of the multi-signer project on GitHub

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.