



Domain Name System Operations                                   F. Obser
Internet-Draft                                                   M. Pels
Intended status: Informational                                  RIPE NCC
Expires: 15 April 2026                                   12 October 2025


                           DNSSEC Key Restore
                draft-fobser-dnsop-dnssec-keyrestore-00

Abstract

   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

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Domain Name System
   Operations Working Group mailing list (dnsop@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/dnsop/.

   Source for this draft and an issue tracker can be found at
   https://github.com/fobser/draft-fobser-dnsop-dnssec-keyrecovery.

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.




Obser & Pels              Expires 15 April 2026                 [Page 1]

Internet-Draft             DNSSEC Key Restore               October 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  DNSSEC Key Restore  . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  KSK / ZSK split, KSK operable, ZSK inoperable . . . . . .   5
     4.2.  KSK / ZSK split, KSK inoperable . . . . . . . . . . . . .   6
     4.3.  CSK inoperable  . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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



Obser & Pels              Expires 15 April 2026                 [Page 2]

Internet-Draft             DNSSEC Key Restore               October 2025


   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.




Obser & Pels              Expires 15 April 2026                 [Page 3]

Internet-Draft             DNSSEC Key Restore               October 2025


   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.








Obser & Pels              Expires 15 April 2026                 [Page 4]

Internet-Draft             DNSSEC Key Restore               October 2025


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

4.1.  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 [RFC7583] section 2.1.

   Section 3.2.1 of [RFC7583] 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.

                 |1|      |2|   |3|      |4|
                  |        |     |        |
   Key N         - - ----------->|<-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

   Ipub = Dprp + TTLkey

   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.



Obser & Pels              Expires 15 April 2026                 [Page 5]

Internet-Draft             DNSSEC Key Restore               October 2025


   Event 2: The new ZSK can be used when it becomes ready at Trdy.

   Trdy = Tpub + Ipub.

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

   Iret = Dsgn + Dprp + TTLsig

   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:

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

4.2.  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 [RFC7583]
   section 2.2.

   If the ZSK is inoperable as well, it MUST NOT be restored yet.

   Section 3.3.2 of [RFC7583] 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.












Obser & Pels              Expires 15 April 2026                 [Page 6]

Internet-Draft             DNSSEC Key Restore               October 2025


               |1|      |2|       |3|  |4|      |5|
                |        |         |    |        |
   Key N       - ---------------------->|<-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).

   Tpub = Tsbm + Dreg.

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

   IpubP = DprpP + TTLds

   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.

   Trdy = Tpub + IpubP

   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:

   Iret = DprpC + TTLkey






Obser & Pels              Expires 15 April 2026                 [Page 7]

Internet-Draft             DNSSEC Key Restore               October 2025


   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.

   Trem = Tact + Iret

4.3.  CSK inoperable

   Since the old CSK is inoperable, the DNSKEY RRset cannot be changed.
   Therefore, only the Double-DS method can be used.  See [RFC7583]
   section 2.2.

   Section 3.3.2 of [RFC7583] 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.

               |1|      |2|       |3|  |4|      |5|
                |        |         |    |        |
   Key N       - ---------------------->|<-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).

   Tpub = Tsbm + Dreg.

   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




Obser & Pels              Expires 15 April 2026                 [Page 8]

Internet-Draft             DNSSEC Key Restore               October 2025


   IpubP = DprpP + TTLds

   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.

   Trdy = Tpub + IpubP

   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:

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

   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.

   Trem = Tact + Iret

   At the same time the old, inoperable CSK and all its signatures can
   be removed as well.

5.  Security Considerations

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

6.  IANA Considerations

   This document has no IANA actions.

7.  References

7.1.  Normative References




Obser & Pels              Expires 15 April 2026                 [Page 9]

Internet-Draft             DNSSEC Key Restore               October 2025


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/rfc/rfc9364>.

7.2.  Informative References

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,
              <https://www.rfc-editor.org/rfc/rfc6781>.

   [RFC7583]  Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
              "DNSSEC Key Rollover Timing Considerations", RFC 7583,
              DOI 10.17487/RFC7583, October 2015,
              <https://www.rfc-editor.org/rfc/rfc7583>.

   [RFC7958]  Abley, J., Schlyter, J., Bailey, G., and P. Hoffman,
              "DNSSEC Trust Anchor Publication for the Root Zone",
              RFC 7958, DOI 10.17487/RFC7958, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7958>.

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9499>.

   [RFC9824]  Huque, S., Elmerot, C., and O. Gudmundsson, "Compact
              Denial of Existence in DNSSEC", RFC 9824,
              DOI 10.17487/RFC9824, September 2025,
              <https://www.rfc-editor.org/rfc/rfc9824>.

   [Shamir]   Shamir, A., "How to Share a Secret", ACM
              Press Communications of the ACM, Vol. 22, No. 11, pp.
              612-613, DOI 10.1145/359168.359176, November 1979,
              <https://doi.org/10.1145/359168.359176>.

Acknowledgments

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



Obser & Pels              Expires 15 April 2026                [Page 10]

Internet-Draft             DNSSEC Key Restore               October 2025


   *  Stephen Morris

   *  Johan Ihren

   *  John Dickinson

   *  W.  (Matthijs) Mekking

Authors' Addresses

   Florian Obser
   RIPE NCC
   Email: fobser@ripe.net


   Martin Pels
   RIPE NCC
   Email: mpels@ripe.net

































Obser & Pels              Expires 15 April 2026                [Page 11]
