DNSSEC Key Restore

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.

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). Performing an Algorithm Rollover as described in using the procedures defined in this document is NOT RECOMMENDED. If an algorithm rollover is not already in progress, signing using the currently used algorithm should be restored first using the procedures defined in this document. Once this has been completed a regular algorithm rollover can be performed.

Key Rollover Considerations If a regular key rollover is in progress, the procedures described in this document can be followed. They effectively cancel the ongoing key rollover and perform a new one. If an algorithm rollover is in progress, the procedures described in this document can be followed with the exception that two new keys MUST be added to the zone. One with the old algorithm and one with the new algorithm.

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.