]> RIPE NCC

fobser@ripe.net

RIPE NCC

mpels@ripe.net

Operations and Management Domain Name System Operations DNSSEC disaster recovery backup and restore This document describes the issues surrounding the handling of DNSSEC private keys in a DNSSEC signer. It presents operational guidance in case a DNSSEC private key becoming inoperable. Discussion Venues Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (dnsop@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction DNSSEC uses public key cryptography to provide integrity protection of DNS data. From an operational point of view, it is critically important to keep the private key secret under all circumstances. The private key is typically kept secret by using Hardware Security Modules (HSMs). HSMs are designed to perform cryptographic operations such as creating keys and signing messages without disclosing the private key. Alternatively the DNSSEC signer is an appliance or commodity server hardware and operational policy stipulates that the private key must not leave the signer. Operationally this is a risk because only a single key exists. The key could become inoperable at any point due to hardware failure, natural disaster, operator error, or malicious action. It is difficult to create backups of the private key. After all, the system is designed to prevent backups. A compromise is usually reached by using a secret sharing scheme, e.g. . The private key is split into n pieces inside of the HSM, which are then distributed to key share holders. In case the private key becomes inoperable, m out of the n key share holders need to come together to restore the secret key. A key sharing scheme does not mitigate all risk. When more than n-m key shares become unavailable a restore cannot be performed, because not enough key shares are available. This is particularly challenging in small to medium sized teams. Unlike the private key, a DNSSEC signed zone can be considered public data with its integrity protected by signatures. Signed zones can be added to the normal, established backup procedures. The rest of the document describes procedures on how to restore DNSSEC signing functionality with only a backup of the signed zone available.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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. This document uses DNS terminology from . DNSSEC key states and timeline related abbreviations are defined in . The following additional definitions are used within this document.

Inoperable (private key):

The private part of a DNSKEY appearing in the chain of trust of the zone that can no longer be used for signing. Causes include hardware failure, natural disaster, operator error, or malicious action. A compromised key is not an inoperable private key since it can still be used for signing.

Operable (private key):

The opposite of an inoperable private key. A key that can be used for signing.

Scope The procedures described in this document pertain to DNSSEC architectures with pre-signed records. Online signing, such as described in , is out of scope since it requires that each server carrying the zone holds a copy of the signing key(s). Thus, the operational challenges are different than described in the introduction. The root zone is out of scope since the distribution of a new trust anchor takes considerably longer than the RRSIG lifetime . Algorithm Rollovers as described in , section 4.1.4 are out of scope as well. They are already complicated enough and trying to recover from an inoperable DNSSEC private key while an algorithm rollover is being performed is unlikely to be successful. If a new algorithm is required, the procedures defined in this document SHOULD be followed to first restore signing with the old algorithm. Once this has been completed a regular algorithm rollover can be performed. Regular key rollovers are in scope, since they do not pose extra challenges. The procedures described in this document effectively cancel a potentially ongoing key rollover and perform a new one.

DNSSEC Key Restore In case of a catastrophe where the DNSSEC private key becomes inoperable and no functioning backups of the private key are available, it is desirable to recover from this situation with DNS resolution continuing to work for the effected zone(s) while performing DNSSEC key restore operations. This is possible because the moment the DNSSEC private key becomes inoperable, the zone is still correctly signed and served by the authoritative name servers. Signatures typically have a lifetime of many days. That means that the operator has a lot of time to recover from this situation without the zone becoming bogus and no longer validating. Hasty and inappropriate action on the other hand could lead to outages. While the DNSSEC private key cannot be restored because no functioning backups exist, the function of the zone can be restored. The restore process uses slightly modified key rollover procedures from . During the restore process, the signing software operates on a pre-signed zone. That is, the zone already contains a DNSKEY RRset and RRSIG RRsets. The signing software might try to remove these records because the accompanying private key is no longer present. The operator MUST prevent this, otherwise the zone will become bogus. The signing software MUST NOT remove DNSKEYs until instructed to do so and SHOULD NOT remove old RRSIGs. If a signer implementation does not support keeping the old RRSIG records in place these records, excluding the RRSIG for the old DNSKEY RRset, MUST be manually added back to the zone before publication. The exact process depends on which key(s) are inoperable and if the zone is signed with a split KSK / ZSK key pair or a Combined Signing Key (CSK).

KSK / ZSK split, KSK operable, ZSK inoperable Since the old ZSK is inoperable, it cannot be used to create new RRSIGs. Therefore the zone cannot be changed and only the Pre-Publication method can be used. See section 2.1. Section 3.2.1 of documents the timeline for this method. The following diagram shows the timeline of the restoration. Time increases along the horizontal scale from left to right and the vertical lines indicate events in the process. Significant times and time intervals are marked. |<-Iret->| | | | | Key N+1 |<-Ipub->|<--->|<----- - - | | | | Key N Trem Key N+1 Tpub Trdy Tact ---- Time ----> ]]> Event 1: The new ZSK is added to the DNSKEY RRset at its publication time (Tpub). The inoperable ZSK and all RRSIGs it created MUST remain in the zone. The new ZSK must be published long enough to guarantee that any cached DNSKEY RRset contains the new ZSK. This interval is the publication interval (Ipub), given by Dprp is the propagation delay, the time it takes for changes to propagate to all authoritative nameserver instances. TTLkey is the TTL of the DNSKEY RRset. Event 2: The new ZSK can be used when it becomes ready at Trdy. At this point the zone can be changed again. Event 3: At some later time, the zone is signed with the new ZSK. At this point RRSIGs from the inoperable ZSK can be removed. The inoperable ZSK MUST be retained in the DNSKEY RRset. Event 4: The inoperable ZSK can be removed after the retire interval (Iret). Dsgn is the delay needed to ensure that all existing RRsets are signed with the new ZSK, Dprp is the propagation delay and TTLsig is the maximum TTL of all RRSIG records. Theoretically the Double-Signature method could be used as well. In this case records in the zone can only be changed after the retire interval, which is at least as long as the publication interval of the Pre-Publication method. The Double-Signature retire interval is given by:

KSK / ZSK split, KSK inoperable Since the old KSK is inoperable, the DNSKEY RRset cannot be changed. Therefore, only the Double-DS method can be used. See section 2.2. If the ZSK is inoperable as well, it MUST NOT be restored yet. Section 3.3.2 of documents the timeline for this method. The following diagram shows the timeline of the restoration. The diagram follows the convention described in Section 4.1. |<-Iret->| | | | | | Key N+1 |<-Dreg->|<-IpubP->|<-->|<------- - | | | | | Key N Trem Key N+1 Tsbm Tpub Trdy Tact ---- Time ----> ]]> Event 1: A new DS record is added to the DS RRset in the parent zone, this is the submission time, Tsbm. Event 2: After the registration delay, Dreg, the DS record is published in the parent zone. This is the publication time (Tpub). The DS record must be published long enough to guarantee that any cached DS RRset contains the new DS record. This is the parent publication interval (IpubP). DprpP is the propagation delay of the parent zone, i.e. the time it takes for changes to propagate to all authoritative servers of the parent zone. TTLds is the TTL of the DS RRset at the parent. Event 3: The new KSK can be used when it becomes ready at Trdy. Event 4: At this point, Tact, the new KSK is added to the DNSKEY RRset and used to generate the DNSKEY RRsig. The old, inoperable KSK can be removed. The ZSK MUST remain in the DNSKEY RRset. If the ZSK is inoperable, the ZSK signing function can be now be restored using the procedure in the previous section. To ensure that no caches have DNSKEY RRset with the old KSK, the old DS record MUST remain in the parent zone for the duration of the retire interval (Iret), given by: DprpC is the child propagation delay, the time it takes for changes to propagate to all authoritative nameserver instances of the child zone. TTLkey is the TTL of the DNSKEY RRset. Event 5: The old DS record can be removed from the parent zone at Trem.

CSK inoperable Since the old CSK is inoperable, the DNSKEY RRset cannot be changed. Therefore, only the Double-DS method can be used. See section 2.2. Section 3.3.2 of documents the timeline for this method. Since the CSK is also used to sign the zone, the timing of the Double-DS method needs to be adjusted. The inoperable CSK and all RRSIGs it created MUST remain in the zone. The following diagram shows the timeline of the restoration. The diagram follows the convention described in Section 4.1. |<-Iret->| | | | | | Key N+1 |<-Dreg->|<-IpubP->|<-->|<------- - | | | | | Key N Trem Key N+1 Tsbm Tpub Trdy Tact ---- Time ----> ]]> Event 1: A new DS record is added to the DS RRset in the parent zone, this is the submission time, Tsbm. Event 2: After the registration delay, Dreg, the DS record is published in the parent zone. This is the publication time (Tpub). The DS record must be published long enough to guarantee that any cached DS RRset contains the new DS record. This is the parent publication interval (IpubP) given by DprpP is the propagation delay of the parent zone, i.e. the time it takes for changes to propagate to all authoritative servers of the parent zone. TTLds is the TTL of the DS RRset at the parent. Event 3: The new CSK can be used when it becomes ready at Trdy. Event 4: At this point the new CSK is added to the DNSKEY RRset and used to generate the DNSKEY RRsig. The old, inoperable CSK MUST remain in the DNSKEY RRset. The new CSK can be used to generate the RRsigs for the rest of the zone. The RRSIGs generated by the inoperable CSK MUST remain in the zone. To ensure that no caches have DNSKEY RRset with the old CSK, the old DS record MUST remain in the parent zone for the duration of the retire interval (Iret), given by: Dsgn is the delay needed to ensure that all existing RRsets are signed with the new CSK. DprpC is the child propagation delay, the time it takes for changes to propagate to all authoritative nameserver instances of the child zone. TTLkey is the TTL of the DNSKEY RRset and TTLsig is the maximum TTL of all RRSIG records. Event 5: The old DS record can be removed from the parent zone at Trem. At the same time the old, inoperable CSK and all its signatures can be removed as well.

Security Considerations All security considerations of apply to this document.

IANA Considerations This document has no IANA actions.

References Normative References This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process. The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document describes a technique to generate a signed DNS response on demand for a nonexistent name by claiming that the name exists but doesn't have any data for the queried record type. Such responses require only one minimally covering NSEC or NSEC3 record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. This document updates RFCs 4034 and 4035.

Acknowledgments The document draws heavily from the work in and we thank the authors for their work:

• Stephen Morris
• Johan Ihren
• John Dickinson
• W. (Matthijs) Mekking