Hi,
the work on this draft is really beneficial, thank you for the ongoing
effort. However, it still needs many improvements to become perfect.
Some hints:
1) ZSK inoperable: simply promote KSK to CSK and the zone is immediately
fully operational. Later can be transitioned back to KSK+ZSK. Exception:
can be painful/impossible in Offline KSK setup.
2) KSK inoperable: simply perform "double-DS KSK roll-over" as known
since RFC 7583. The zone remains operational during the process,
including ZONEMD, CDNSKEY and stuff.
3) Either CSK inoperable or both KSK+ZSK: first, perform the double-DS
KSK roll-over to resurrect DNSKEY RRset (period A), second, publish new
DNSKEY(s), third, wait for (period B) until new ZSK can sign the zone.
The zone contents must be frozen for the whole time, and in the second
step, it must be somehow achieved that only DNSKEY RRset is changed and
re-signed, plus difficulties with propagation to secondaries as SOA
serial and ZONEMD is unchanged.
------
a) The chapters about SOA/CDS/CDNSKEY/ZONEMD considerations apply only
to case 3).
b) Each case deserves a special note about how the signing software
should help the operator. For example, in case 2) it should enable to
perform the zone signing process even when some private key is missing,
although the DNSKEY RR is still there (not used for signing). In case 3)
it should somehow enable to only sign the DNSKEY RRset alone, and on
secondaries, enable to forcefully refresh the zone with SOA serial
unchanged and ZONEMD invalid.
c) The chapter about Key roll-over considerations is completely
insufficient. There is a wide variety of non-obvious situations when
losing a private key in the middle of a roll-over can be a headache. Not
really impossible, not even requiring to perform more steps and wait for
longer periods, but much more difficult for the operator to do exactly
the right thing and not make mistakes.
d) The document also might encourage to use lower TTLs in all signed
zones in general. This recommendation is slightly off-topic to the
document, but when reading all those procedures, the operators might
understand better why a few-minute TTL is favorable against hourly,
daily or even weekly TTLs, as can be often seen in the wild.
Libor
On 10. 08. 26 9:13, [email protected] wrote:
Internet-Draft draft-ietf-dnsop-dnssec-keyrestore-02.txt is now available. It
is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: DNSSEC Key Restore
Authors: Florian Obser
Martin Pels
Name: draft-ietf-dnsop-dnssec-keyrestore-02.txt
Pages: 12
Dates: 2026-08-10
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 ([email protected]), 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/ietf-wg-dnsop/draft-ietf-dnsop-dnssec-keyrestore.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-keyrestore/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-keyrestore-02.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dnssec-keyrestore-02
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
