DNSSEC Key Restore

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 a new key MUST be added to the zone per algorithm for which there is an inoperable key.

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.

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

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 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 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 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: 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 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. 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. At this point the zone can be changed again.