DNSSEC Key Restore

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 15 April 2026.¶

Copyright Notice

Copyright (c) 2025 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

DNSSEC [RFC9364] 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. [Shamir]. 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses DNS terminology from [RFC9499]. DNSSEC key states and timeline related abbreviations are defined in [RFC7583].¶

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.¶

3. Scope

The procedures described in this document pertain to DNSSEC architectures with pre-signed records. Online signing, such as described in [RFC9824], 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 [RFC7958].¶

Algorithm Rollovers as described in [RFC6781], 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.¶

4. 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 [RFC7583].¶

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).¶

              |1|      |2|   |3|      |4|
               |        |     |        |
Key N         - - ----------->|<-Iret->|
               |        |     |        |
Key N+1        |<-Ipub->|<--->|<----- - -
               |        |     |        |
Key N                                 Trem
Key N+1        Tpub    Trdy  Tact

                  ---- Time ---->

Ipub = Dprp + TTLkey

Trdy = Tpub + Ipub.

Iret = Dsgn + Dprp + TTLsig

Iret = Dsgn + Dprp + max(TTLkey, TTLsig)

            |1|      |2|       |3|  |4|      |5|
             |        |         |    |        |
Key N       - ---------------------->|<-Iret->|
             |        |         |    |        |
Key N+1      |<-Dreg->|<-IpubP->|<-->|<------- -
             |        |         |    |        |
Key N                                        Trem
Key N+1     Tsbm     Tpub      Trdy Tact

                 ---- Time ---->

Tpub = Tsbm + Dreg.

IpubP = DprpP + TTLds

Trdy = Tpub + IpubP

Iret = DprpC + TTLkey

Trem = Tact + Iret

            |1|      |2|       |3|  |4|      |5|
             |        |         |    |        |
Key N       - ---------------------->|<-Iret->|
             |        |         |    |        |
Key N+1      |<-Dreg->|<-IpubP->|<-->|<------- -
             |        |         |    |        |
Key N                                        Trem
Key N+1     Tsbm     Tpub      Trdy Tact

                 ---- Time ---->

Tpub = Tsbm + Dreg.

IpubP = DprpP + TTLds

Trdy = Tpub + IpubP

Iret = Dsgn + DprpC + max(TTLkey, TTLsig)

Trem = Tact + Iret

5. Security Considerations

All security considerations of [RFC9364] apply to this document.¶

6. IANA Considerations

This document has no IANA actions.¶

7. References

Acknowledgments

The document draws heavily from the work in [RFC7583] and we thank the authors for their work:¶

• Stephen Morris¶

• Johan Ihren¶

• John Dickinson¶

• W. (Matthijs) Mekking¶

Authors' Addresses