DNSSEC Key Restore
draft-ietf-dnsop-dnssec-keyrestore-01
| Document | Type | Active Internet-Draft (dnsop WG) | |
|---|---|---|---|
| Authors | Florian Obser , Martin Pels | ||
| Last updated | 2026-05-13 | ||
| Replaces | draft-fobser-dnsop-dnssec-keyrestore | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dnsop-dnssec-keyrestore-01
Domain Name System Operations F. Obser
Internet-Draft M. Pels
Intended status: Informational RIPE NCC
Expires: 14 November 2026 13 May 2026
DNSSEC Key Restore
draft-ietf-dnsop-dnssec-keyrestore-01
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 becomes 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 14 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Obser & Pels Expires 14 November 2026 [Page 1]
Internet-Draft DNSSEC Key Restore May 2026
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 . . . . . . . . . . . . . . . . . . . . . 3
4.1. Key Rollover Considerations . . . . . . . . . . . . . . . 4
4.2. SOA considerations . . . . . . . . . . . . . . . . . . . 5
4.3. CDS/CDNSKEY considerations . . . . . . . . . . . . . . . 5
4.4. KSK / ZSK split, KSK operable, ZSK inoperable . . . . . . 5
4.5. KSK / ZSK split, KSK inoperable . . . . . . . . . . . . . 7
4.6. CSK inoperable . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
DNSSEC [RFC9364] uses public key cryptography to provide integrity
protection of DNS data. The private key used for DNSSEC signing
could become inoperable at any point due to hardware failure, natural
disaster, operator error, or malicious action. If no backup of the
private key exist (due to hardware limitations or operational
policies) or if the backup is unusable for some reason, a zone can no
longer be changed or re-signed.
This document describes procedures on how to restore the DNSSEC
signing functionality without rendering a zone temporarily insecure
or bogus. For these procedures, it is assumed a complete copy of the
DNSSEC signed zone is still available. If no (usable) backup exists,
it may be possible to recover the signed zone from one of the zone's
name servers.
Obser & Pels Expires 14 November 2026 [Page 2]
Internet-Draft DNSSEC Key Restore May 2026
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].
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.
Obser & Pels Expires 14 November 2026 [Page 3]
Internet-Draft DNSSEC Key Restore May 2026
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).
Performing an Algorithm Rollover as described in [RFC6781] 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.
4.1. 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 a new key MUST
be added to the zone per algorithm for which there is an inoperable
key.
Obser & Pels Expires 14 November 2026 [Page 4]
Internet-Draft DNSSEC Key Restore May 2026
4.2. SOA considerations
When restoring an inoperable ZSK or CSK, the SOA record of the zone
SHOULD NOT be changed when introducing a new key in the DNSKEY RRset,
because the SOA cannot be re-signed with the inoperable key. In case
the SOA is changed, signed responses for existing records will remain
valid, but denial of existence proofs for non-existent record types
will become bogus.
To ensure the zone is still propagated, any secondary name servers
relying on IXFR/AXFR need to be manually forced to load the new
version of the zone.
4.3. CDS/CDNSKEY considerations
For restoring an inoperable KSK or CSK, a new DS record needs to be
added to the parent zone. For child zones where this update process
is ordinarily handled using CDS/DNSKEY records (see [RFC8078]) the DS
update needs to be performed manually if the ZSK or CSK is
inoperable. This is because CDS/DNSKEY records added to the child
zone cannot be signed with the inoperable key, and thus cannot be
cryptographically validated. Additionally, introducing CDS/CDNSKEY
records in the zone would change the type bitmap of the NSEC or NSEC3
record in the zone apex, which also cannot be re-signed with the
inoperable key.
4.4. 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.
Obser & Pels Expires 14 November 2026 [Page 5]
Internet-Draft DNSSEC Key Restore May 2026
|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 SOA record of the zone SHOULD NOT be changed at this point in
time, because it cannot be re-signed with the inoperable key. Any
secondary name servers relying on IXFR/AXFR need to be manually
forced to load the new version of 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.
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
Obser & Pels Expires 14 November 2026 [Page 6]
Internet-Draft DNSSEC Key Restore May 2026
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.5. 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.
|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).
Obser & Pels Expires 14 November 2026 [Page 7]
Internet-Draft DNSSEC Key Restore May 2026
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 SOA record of the zone SHOULD NOT be
changed at this point in time, because it cannot be re-signed with
the inoperable key. Any secondary name servers relying on IXFR/AXFR
need to be manually forced to load the new version of the zone. The
ZSK signing function can 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
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.6. 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.
Obser & Pels Expires 14 November 2026 [Page 8]
Internet-Draft DNSSEC Key Restore May 2026
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
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 RRSIGs
generated by the inoperable CSK MUST remain in the zone.
The SOA record of the zone SHOULD NOT be changed at this point in
time, because it cannot be re-signed with the inoperable key. Any
secondary name servers relying on IXFR/AXFR need to be manually
forced to load the new version of the zone.
Obser & Pels Expires 14 November 2026 [Page 9]
Internet-Draft DNSSEC Key Restore May 2026
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.
At this point the zone can be changed again.
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
[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
Obser & Pels Expires 14 November 2026 [Page 10]
Internet-Draft DNSSEC Key Restore May 2026
[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>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017,
<https://www.rfc-editor.org/rfc/rfc8078>.
[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>.
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
Additionally, we thank the following people for contributing ideas
and feedback:
* Libor Peltan
* Peter Thomassen
Obser & Pels Expires 14 November 2026 [Page 11]
Internet-Draft DNSSEC Key Restore May 2026
* Anand Buddhdev
* Wes Hardaker
Authors' Addresses
Florian Obser
RIPE NCC
Email: fobser@ripe.net
Martin Pels
RIPE NCC
Email: mpels@ripe.net
Obser & Pels Expires 14 November 2026 [Page 12]