RFC 6781
DNSSEC Operational Practices, Version 2
4. Signature Generation, Key Rollover, and Related Policies
4.1. Key Rollovers
Regardless of whether a zone uses periodic key rollovers or only rolls keys in case of an irregular event, key rollovers are a fact of life when using DNSSEC. Zone administrators who are in the process of rolling their keys have to take into account the fact that data published in previous versions of their zone still lives in caches. When deploying DNSSEC, this becomes an important consideration; ignoring data that may be in caches may lead to loss of service for clients. The most pressing example of this occurs when zone material signed with an old key is being validated by a resolver that does not have the old zone key cached. If the old key is no longer present in the current zone, this validation fails, marking the data Bogus. Alternatively, an attempt could be made to validate data that is signed with a new key against an old key that lives in a local cache, also resulting in data being marked Bogus. The typographic conventions used in the diagrams below are explained in Appendix B.4.1.1. Zone Signing Key Rollovers
If the choice for splitting ZSKs and KSKs has been made, then those two types of keys can be rolled separately, and ZSKs can be rolled without taking into account DS records from the parent or the configuration of such a key as the trust anchor. For "Zone Signing Key rollovers", there are two ways to make sure that during the rollover data still cached can be verified with the new key sets or newly generated signatures can be verified with the keys still in caches. One scheme, described in Section 4.1.1.1, uses
key pre-publication; the other uses double signatures, as described in Section 4.1.1.2. The pros and cons are described in Section 4.1.1.3.4.1.1.1. Pre-Publish Zone Signing Key Rollover
This section shows how to perform a ZSK rollover without the need to sign all the data in a zone twice -- the "Pre-Publish key rollover". This method has advantages in the case of a key compromise. If the old key is compromised, the new key has already been distributed in the DNS. The zone administrator is then able to quickly switch to the new key and remove the compromised key from the zone. Another major advantage is that the zone size does not double, as is the case with the Double-Signature ZSK rollover. Pre-Publish key rollover from DNSKEY_Z_10 to DNSKEY_Z_11 involves four stages as follows: ------------------------------------------------------------ initial new DNSKEY new RRSIGs ------------------------------------------------------------ SOA_0 SOA_1 SOA_2 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) ------------------------------------------------------------ ------------------------------------------------------------ DNSKEY removal ------------------------------------------------------------ SOA_3 RRSIG_Z_11(SOA) DNSKEY_K_1 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) ------------------------------------------------------------ Figure 1: Pre-Publish Key Rollover
initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing
Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e.,
it is the Zone Signing Key.
new DNSKEY: DNSKEY_Z_11 is introduced into the key set (note that no
signatures are generated with this key yet, but this does not
secure against brute force attacks on its public key). The
minimum duration of this pre-roll phase is the time it takes for
the data to propagate to the authoritative servers, plus the TTL
value of the key set.
new RRSIGs: At the "new RRSIGs" stage, DNSKEY_Z_11 is used to sign
the data in the zone exclusively (i.e., all the signatures from
DNSKEY_Z_10 are removed from the zone). DNSKEY_Z_10 remains
published in the key set. This way, data that was loaded into
caches from the zone in the "new DNSKEY" step can still be
verified with key sets fetched from this version of the zone. The
minimum time that the key set including DNSKEY_Z_10 is to be
published is the time that it takes for zone data from the
previous version of the zone to expire from old caches, i.e., the
time it takes for this zone to propagate to all authoritative
servers, plus the Maximum Zone TTL value of any of the data in the
previous version of the zone.
DNSKEY removal: DNSKEY_Z_10 is removed from the zone. The key set,
now only containing DNSKEY_K_1 and DNSKEY_Z_11, is re-signed with
DNSKEY_K_1.
The above scheme can be simplified by always publishing the "future" key immediately after the rollover. The scheme would look as follows (we show two rollovers); the future key is introduced in "new DNSKEY" as DNSKEY_Z_12 and again a newer one, numbered 13, in "new DNSKEY (II)": initial new RRSIGs new DNSKEY ----------------------------------------------------------------- SOA_0 SOA_1 SOA_2 RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_11 DNSKEY_Z_12 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) ---------------------------------------------------------------- ---------------------------------------------------------------- new RRSIGs (II) new DNSKEY (II) ---------------------------------------------------------------- SOA_3 SOA_4 RRSIG_Z_12(SOA) RRSIG_Z_12(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_Z_11 DNSKEY_Z_12 DNSKEY_Z_12 DNSKEY_Z_13 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) ---------------------------------------------------------------- Figure 2: Pre-Publish Zone Signing Key Rollover, Showing Two Rollovers Note that the key introduced in the "new DNSKEY" phase is not used for production yet; the private key can thus be stored in a physically secure manner and does not need to be 'fetched' every time a zone needs to be signed.4.1.1.2. Double-Signature Zone Signing Key Rollover
This section shows how to perform a ZSK rollover using the double zone data signature scheme, aptly named "Double-Signature rollover". During the "new DNSKEY" stage, the new version of the zone file will need to propagate to all authoritative servers and the data that exists in (distant) caches will need to expire, requiring at least the propagation delay plus the Maximum Zone TTL of previous versions of the zone.
Double-Signature ZSK rollover involves three stages as follows: ---------------------------------------------------------------- initial new DNSKEY DNSKEY removal ---------------------------------------------------------------- SOA_0 SOA_1 SOA_2 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) ---------------------------------------------------------------- Figure 3: Double-Signature Zone Signing Key Rollover initial: Initial version of the zone: DNSKEY_K_1 is the Key Signing Key. DNSKEY_Z_10 is used to sign all the data of the zone, i.e., it is the Zone Signing Key. new DNSKEY: At the "new DNSKEY" stage, DNSKEY_Z_11 is introduced into the key set and all the data in the zone is signed with DNSKEY_Z_10 and DNSKEY_Z_11. The rollover period will need to continue until all data from version 0 (i.e., the version of the zone data containing SOA_0) of the zone has been replaced in all secondary servers and then has expired from remote caches. This will take at least the propagation delay plus the Maximum Zone TTL of version 0 of the zone. DNSKEY removal: DNSKEY_Z_10 is removed from the zone, as are all signatures created with it. The key set, now only containing DNSKEY_Z_11, is re-signed with DNSKEY_K_1 and DNSKEY_Z_11. At every instance, RRSIGs from the previous version of the zone can be verified with the DNSKEY RRset from the current version and vice versa. The duration of the "new DNSKEY" phase and the period between rollovers should be at least the propagation delay to secondary servers plus the Maximum Zone TTL of the previous version of the zone. Note that in this example we assumed for simplicity that the zone was not modified during the rollover. In fact, new data can be introduced at any time during this period, as long as it is signed with both keys.
4.1.1.3. Pros and Cons of the Schemes
Pre-Publish key rollover: This rollover does not involve signing the zone data twice. Instead, before the actual rollover, the new key is published in the key set and thus is available for cryptanalysis attacks. A small disadvantage is that this process requires four stages. Also, the Pre-Publish scheme involves more parental work when used for KSK rollovers, as explained in Section 4.1.2. Double-Signature ZSK rollover: The drawback of this approach is that during the rollover the number of signatures in your zone doubles; this may be prohibitive if you have very big zones. An advantage is that it only requires three stages.4.1.2. Key Signing Key Rollovers
For the rollover of a Key Signing Key, the same considerations as for the rollover of a Zone Signing Key apply. However, we can use a Double-Signature scheme to guarantee that old data (only the apex key set) in caches can be verified with a new key set and vice versa. Since only the key set is signed with a KSK, zone size considerations do not apply. Note that KSK rollovers and ZSK rollovers are different in the sense that a KSK rollover requires interaction with the parent (and possibly replacing trust anchors) and the ensuing delay while waiting for it.
--------------------------------------------------------------------- initial new DNSKEY DS change DNSKEY removal --------------------------------------------------------------------- Parent: SOA_0 -----------------------------> SOA_1 ------------------------> RRSIG_par(SOA) --------------------> RRSIG_par(SOA) ---------------> DS_K_1 ----------------------------> DS_K_2 -----------------------> RRSIG_par(DS) ---------------------> RRSIG_par(DS) ----------------> Child: SOA_0 SOA_1 -----------------------> SOA_2 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) DNSKEY_K_1 DNSKEY_K_1 ------------------> DNSKEY_K_2 ------------------> DNSKEY_K_2 DNSKEY_Z_10 DNSKEY_Z_10 -----------------> DNSKEY_Z_10 RRSIG_K_1(DNSKEY) RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) ----------> RRSIG_K_2(DNSKEY) --------------------------------------------------------------------- Figure 4: Stages of Deployment for a Double-Signature Key Signing Key Rollover initial: Initial version of the zone. The parental DS points to DNSKEY_K_1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY_K_1 -- it is needed during the rollover, and we refer to the value as TTL_DS. new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY_K_2. The key is provided to the parent, and the child will have to wait until a new DS RR has been generated that points to DNSKEY_K_2. After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches. DS change: The parent replaces DS_K_1 with DS_K_2. DNSKEY removal: DNSKEY_K_1 has been removed. The scenario above puts the responsibility for maintaining a valid chain of trust with the child. It also is based on the premise that the parent only has one DS RR (per algorithm) per zone. An alternative mechanism has been considered. Using an established trust relationship, the interaction can be performed in-band, and the removal of the keys by the child can possibly be signaled by the parent. In this mechanism, there are periods where there are two DS
RRs at the parent. This is known as a KSK Double-DS rollover and is shown in Figure 5. This method has some drawbacks for KSKs. We first describe the rollover scheme and then indicate these drawbacks. -------------------------------------------------------------------- initial new DS new DNSKEY DS removal -------------------------------------------------------------------- Parent: SOA_0 SOA_1 ------------------------> SOA_2 RRSIG_par(SOA) RRSIG_par(SOA) ---------------> RRSIG_par(SOA) DS_K_1 DS_K_1 -----------------------> DS_K_2 -----------------------> DS_K_2 RRSIG_par(DS) RRSIG_par(DS) ----------------> RRSIG_par(DS) Child: SOA_0 -----------------------> SOA_1 ----------------------------> RRSIG_Z_10(SOA) -------------> RRSIG_Z_10(SOA) ------------------> DNSKEY_K_1 ------------------> DNSKEY_K_2 -----------------------> DNSKEY_Z_10 -----------------> DNSKEY_Z_10 ----------------------> RRSIG_K_1 (DNSKEY) ----------> RRSIG_K_2 (DNSKEY) ---------------> -------------------------------------------------------------------- Figure 5: Stages of Deployment for a Double-DS Key Signing Key Rollover When the child zone wants to roll, it notifies the parent during the "new DS" phase and submits the new key (or the corresponding DS) to the parent. The parent publishes DS_K_1 and DS_K_2, pointing to DNSKEY_K_1 and DNSKEY_K_2, respectively. During the rollover ("new DNSKEY" phase), which can take place as soon as the new DS set propagated through the DNS, the child replaces DNSKEY_K_1 with DNSKEY_K_2. If the old key has expired from caches, at the "DS removal" phase the parent can be notified that the old DS record can be deleted. The drawbacks of this scheme are that during the "new DS" phase, the parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2 using the DNS, as DNSKEY_K_2 is not yet published. Besides, we introduce a "security lame" key (see Section 4.3.3). Finally, the child-parent interaction consists of two steps. The "Double Signature" method only needs one interaction.
4.1.2.1. Special Considerations for RFC 5011 KSK Rollover
The scenario sketched above assumes that the KSK is not in use as a trust anchor but that validating name servers exclusively depend on the parental DS record to establish the zone's security. If it is known that validating name servers have configured trust anchors, then that needs to be taken into account. Here, we assume that zone administrators will deploy RFC 5011 [RFC5011] style rollovers. RFC 5011 style rollovers increase the duration of key rollovers: The key to be removed must first be revoked. Thus, before the DNSKEY_K_1 removal phase, DNSKEY_K_1 must be published for one more Maximum Zone TTL with the REVOKE bit set. The revoked key must be self-signed, so in this phase the DNSKEY RRset must also be signed with DNSKEY_K_1.4.1.3. Single-Type Signing Scheme Key Rollover
The rollover of a key when a Single-Type Signing Scheme is used is subject to the same requirement as the rollover of a KSK or ZSK: During any stage of the rollover, the chain of trust needs to continue to validate for any combination of data in the zone as well as data that may still live in distant caches. There are two variants for this rollover. Since the choice for a Single-Type Signing Scheme is motivated by operational simplicity, we describe the most straightforward rollover scheme first. ------------------------------------------------------------------- initial new DNSKEY DS change DNSKEY removal ------------------------------------------------------------------- Parent: SOA_0 --------------------------> SOA_1 ----------------------> RRSIG_par(SOA) -----------------> RRSIG_par(SOA) -------------> DS_S_1 -------------------------> DS_S_2 ---------------------> RRSIG_par(DS_S_1) --------------> RRSIG_par(DS_S_2) ----------> Child: SOA_0 SOA_1 ----------------------> SOA_2 RRSIG_S_1(SOA) RRSIG_S_1(SOA) -------------> RRSIG_S_2(SOA) -------------> RRSIG_S_2(SOA) DNSKEY_S_1 DNSKEY_S_1 -----------------> DNSKEY_S_2 -----------------> DNSKEY_S_2 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) ----------> RRSIG_S_2(DNSKEY) ----------> RRSIG_S_2(DNSKEY) ------------------------------------------------------------------- Figure 6: Stages of the Straightforward Rollover in a Single-Type Signing Scheme
initial: Parental DS points to DNSKEY_S_1. All RRsets in the zone
are signed with DNSKEY_S_1.
new DNSKEY: A new key (DNSKEY_S_2) is introduced, and all the RRsets
are signed with both DNSKEY_S_1 and DNSKEY_S_2.
DS change: After the DNSKEY RRset with the two keys had time to
propagate into distant caches (that is, the key set exclusively
containing DNSKEY_S_1 has been expired), the parental DS record
can be changed.
DNSKEY removal: After the DS RRset containing DS_S_1 has expired
from distant caches, DNSKEY_S_1 can be removed from the DNSKEY
RRset.
In this first variant, the new signatures and new public key are
added to the zone. Once they are propagated, the DS at the parent is
switched. If the old DS has expired from the caches, the old
signatures and old public key can be removed from the zone.
This rollover has the drawback that it introduces double signatures
over all data of the zone. Taking these zone size considerations
into account, it is possible to not introduce the signatures made
with DNSKEY_S_2 at the "new DNSKEY" step. Instead, signatures of
DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an
additional stage between the "DS change" and "DNSKEY removal" step:
After the DS RRset containing DS_S_1 has expired from distant caches,
the signatures can be swapped. Only after the new signatures made
with DNSKEY_S_2 have been propagated can the old public key
DNSKEY_S_1 be removed from the DNSKEY RRset.
The second variant of the Single-Type Signing Scheme Key rollover is
the Double-DS rollover. In this variant, one introduces a new DNSKEY
into the key set and submits the new DS to the parent. The new key
is not yet used to sign RRsets. The signatures made with DNSKEY_S_1
are replaced with signatures made with DNSKEY_S_2 at the moment that
DNSKEY_S_2 and DS_S_2 have been propagated.
----------------------------------------------------------------------- initial new DS new RRSIG DS removal ----------------------------------------------------------------------- Parent: SOA_0 SOA_1 -------------------------> SOA_2 RRSIG_par(SOA) RRSIG_par(SOA) ----------------> RRSIG_par(SOA) DS_S_1 DS_S_1 ------------------------> DS_S_2 ------------------------> DS_S_2 RRSIG_par(DS) RRSIG_par(DS) -----------------> RRSIG_par(DS) Child: SOA_0 SOA_1 SOA_2 SOA_3 RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA) DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_2 DNSKEY_S_2 DNSKEY_S_2 RRSIG_S_1 (DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) ----------------------------------------------------------------------- Figure 7: Stages of Deployment for a Double-DS Rollover in a Single-Type Signing Scheme4.1.4. Algorithm Rollovers
A special class of key rollovers is the one needed for a change of signature algorithms (either adding a new algorithm, removing an old algorithm, or both). Additional steps are needed to retain integrity during this rollover. We first describe the generic case; special considerations for rollovers that involve trust anchors and single- type keys are discussed later. There exist both a conservative and a liberal approach for algorithm rollover. This has to do with Section 2.2 of RFC 4035 [RFC4035]: There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). The conservative approach interprets this section very strictly, meaning that it expects that every RRset has a valid signature for every algorithm signaled by the zone apex DNSKEY RRset, including RRsets in caches. The liberal approach uses a more loose interpretation of the section and limits the rule to RRsets in the zone at the authoritative name servers. There is a reasonable argument for saying that this is valid, because the specific section is a subsection of Section 2 ("Zone Signing") of RFC 4035.
When following the more liberal approach, algorithm rollover is just as easy as a regular Double-Signature KSK rollover (Section 4.1.2). Note that the Double-DS KSK rollover method cannot be used, since that would introduce a parental DS of which the apex DNSKEY RRset has not been signed with the introduced algorithm. However, there are implementations of validators known to follow the more conservative approach. Performing a Double-Signature KSK algorithm rollover will temporarily make your zone appear as Bogus by such validators during the rollover. Therefore, the rollover described in this section will explain the stages of deployment and will assume that the conservative approach is used. When adding a new algorithm, the signatures should be added first. After the TTL of RRSIGs has expired and caches have dropped the old data covered by those signatures, the DNSKEY with the new algorithm can be added. After the new algorithm has been added, the DS record can be exchanged using Double-Signature KSK rollover. When removing an old algorithm, the DS for the algorithm should be removed from the parent zone first, followed by the DNSKEY and the signatures (in the child zone). Figure 8 describes the steps.
---------------------------------------------------------------- initial new RRSIGs new DNSKEY ---------------------------------------------------------------- Parent: SOA_0 --------------------------------------------------------> RRSIG_par(SOA) -----------------------------------------------> DS_K_1 -------------------------------------------------------> RRSIG_par(DS_K_1) --------------------------------------------> Child: SOA_0 SOA_1 SOA_2 RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_2 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_2(DNSKEY) ---------------------------------------------------------------- new DS DNSKEY removal RRSIGs removal ---------------------------------------------------------------- Parent: SOA_1 -------------------------------------------------------> RRSIG_par(SOA) ----------------------------------------------> DS_K_2 ------------------------------------------------------> RRSIG_par(DS_K_2) -------------------------------------------> Child: -------------------> SOA_3 SOA_4 -------------------> RRSIG_Z_10(SOA) -------------------> RRSIG_Z_11(SOA) RRSIG_Z_11(SOA) -------------------> -------------------> DNSKEY_K_2 DNSKEY_K_2 -------------------> -------------------> DNSKEY_Z_11 DNSKEY_Z_11 -------------------> -------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY) ---------------------------------------------------------------- Figure 8: Stages of Deployment during an Algorithm Rollover
initial: Describes the state of the zone before any transition is
done. The number of the keys may vary, but all keys (in DNSKEY
records) for the zone use the same algorithm.
new RRSIGs: The signatures made with the new key over all records in
the zone are added, but the key itself is not. This step is
needed to propagate the signatures created with the new algorithm
to the caches. If this is not done, it is possible for a resolver
to retrieve the new DNSKEY RRset (containing the new algorithm)
but to have RRsets in its cache with signatures created by the old
DNSKEY RRset (i.e., without the new algorithm).
The RRSIG for the DNSKEY RRset does not need to be pre-published
(since these records will travel together) and does not need
special processing in order to keep them synchronized.
new DNSKEY: After the old data has expired from caches, the new key
can be added to the zone.
new DS: After the cache data for the old DNSKEY RRset has expired,
the DS record for the new key can be added to the parent zone and
the DS record for the old key can be removed in the same step.
DNSKEY removal: After the cache data for the old DS RRset has
expired, the old algorithm can be removed. This time, the old key
needs to be removed first, before removing the old signatures.
RRSIGs removal: After the cache data for the old DNSKEY RRset has
expired, the old signatures can also be removed during this step.
Below, we deal with a few special cases of algorithm rollovers:
1: Single-Type Signing Scheme Algorithm rollover: when there is no
differentiation between ZSKs and KSKs (Section 4.1.4.1).
2: RFC 5011 Algorithm rollover: when trust anchors can track the
roll via RFC 5011 style rollover (Section 4.1.4.2).
3: 1 and 2 combined: when a Single-Type Signing Scheme Algorithm
rollover is performed RFC 5011 style (Section 4.1.4.3).
In addition to the narrative below, these special cases are
represented in Figures 12, 13, and 14 in Appendix C.
4.1.4.1. Single-Type Signing Scheme Algorithm Rollover
If one key is used that acts as both ZSK and KSK, the same scheme and figure as above (Figure 8 in Section 4.1.4) applies, whereby all DNSKEY_Z_* records from the table are removed and all RRSIG_Z_* are replaced with RRSIG_S_*. All DNSKEY_K_* records are replaced with DNSKEY_S_*, and all RRSIG_K_* records are replaced with RRSIG_S_*. The requirement to sign with both algorithms and make sure that old RRSIGs have the opportunity to expire from distant caches before introducing the new algorithm in the DNSKEY RRset is still valid. This is shown in Figure 12 in Appendix C.4.1.4.2. Algorithm Rollover, RFC 5011 Style
Trust anchor algorithm rollover is almost as simple as a regular RFC 5011-based rollover. However, the old trust anchor must be revoked before it is removed from the zone. The timeline (see Figure 13 in Appendix C) is similar to that of Figure 8 above, but after the "new DS" step, an additional step is required where the DNSKEY is revoked. The details of this step ("revoke DNSKEY") are shown in Figure 9 below. --------------------------------- revoke DNSKEY --------------------------------- Parent: -----------------------------> -----------------------------> -----------------------------> -----------------------------> Child: SOA_3 RRSIG_Z_10(SOA) RRSIG_Z_11(SOA) DNSKEY_K_1_REVOKED DNSKEY_K_2 DNSKEY_Z_11 RRSIG_K_1(DNSKEY) RRSIG_K_2(DNSKEY) --------------------------------- Figure 9: The Revoke DNSKEY State That Is Added to an Algorithm Rollover when RFC 5011 Is in Use
There is one exception to the requirement from RFC 4035 quoted in Section 4.1.4 above: While all zone data must be signed with an unrevoked key, it is permissible to sign the key set with a revoked key. The somewhat esoteric argument is as follows: Resolvers that do not understand the RFC 5011 REVOKE flag will handle DNSKEY_K_1_REVOKED the same as if it were DNSKEY_K_1. In other words, they will handle the revoked key as a normal key, and thus RRsets signed with this key will validate. As a result, the signature matches the algorithm listed in the DNSKEY RRset. Resolvers that do implement RFC 5011 will remove DNSKEY_K_1 from the set of trust anchors. That is okay, since they have already added DNSKEY_K_2 as the new trust anchor. Thus, algorithm 2 is the only signaled algorithm by now. That is, we only need RRSIG_K_2(DNSKEY) to authenticate the DNSKEY RRset, and we are still compliant with Section 2.2 of RFC 4035: There must be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.4.1.4.3. Single Signing Type Algorithm Rollover, RFC 5011 Style
If a decision is made to perform an RFC 5011 style rollover with a Single Signing Scheme key, it should be noted that Section 2.1 of RFC 5011 states: Once the resolver sees the REVOKE bit, it MUST NOT use this key as a trust anchor or for any other purpose except to validate the RRSIG it signed over the DNSKEY RRset specifically for the purpose of validating the revocation. This means that once DNSKEY_S_1 is revoked, it cannot be used to validate its signatures over non-DNSKEY RRsets. Thus, those RRsets should be signed with a shadow key, DNSKEY_Z_10, during the algorithm rollover. The shadow key can be removed at the same time the revoked DNSKEY_S_1 is removed from the zone. In other words, the zone must temporarily fall back to a KSK/ZSK split model during the rollover. In other words, the rule that at every RRset there must be at least one signature for each algorithm used in the DNSKEY RRset still applies. This means that a different key with the same algorithm, other than the revoked key, must sign the entire zone. Thus, more operations are needed if the Single-Type Signing Scheme is used. Before rolling the algorithm, a new key must be introduced with the same algorithm as the key that is a candidate for revocation. That key can than temporarily act as a ZSK during the algorithm rollover.
As with algorithm rollover RFC 5011 style, while all zone data must be signed with an unrevoked key, it is permissible to sign the key set with a revoked key using the same esoteric argument given in Section 4.1.4.2. The lesson of all of this is that a Single-Type Signing Scheme algorithm rollover using RFC 5011 is as complicated as the name of the rollover implies: Reverting to a split-key scheme for the duration of the rollover may be preferable.4.1.4.4. NSEC-to-NSEC3 Algorithm Rollover
A special case is the rollover from an NSEC signed zone to an NSEC3 signed zone. In this case, algorithm numbers are used to signal support for NSEC3 but they do not mandate the use of NSEC3. Therefore, NSEC records should remain in the zone until the rollover to a new algorithm has completed and the new DNSKEY RRset has populated distant caches, at the end of the "new DNSKEY" stage. At that point, the validators that have not implemented NSEC3 will treat the zone as unsecured as soon as they follow the chain of trust to the DS that points to a DNSKEY of the new algorithm, while validators that support NSEC3 will happily validate using NSEC. Turning on NSEC3 can then be done during the "new DS" step: increasing the serial number, introducing the NSEC3PARAM record to signal that NSEC3-authenticated data related to denial of existence should be served, and re-signing the zone. In summary, an NSEC-to-NSEC3 rollover is an ordinary algorithm rollover whereby NSEC is used all the time and only after that rollover finished NSEC3 needs to be deployed. The procedures are also listed in Sections 10.4 and 10.5 of RFC 5155 [RFC5155].4.1.5. Considerations for Automated Key Rollovers
As keys must be renewed periodically, there is some motivation to automate the rollover process. Consider the following: o ZSK rollovers are easy to automate, as only the child zone is involved. o A KSK rollover needs interaction between the parent and child. Data exchange is needed to provide the new keys to the parent; consequently, this data must be authenticated, and integrity must be guaranteed in order to avoid attacks on the rollover.
4.2. Planning for Emergency Key Rollover
This section deals with preparation for a possible key compromise. It is advisable to have a documented procedure ready for those times when a key compromise is suspected or confirmed. When the private material of one of a zone's keys is compromised, it can be used by an attacker for as long as a valid trust chain exists. A trust chain remains intact for o as long as a signature over the compromised key in the trust chain is valid, and o as long as the DS RR in the parent zone points to the (compromised) key signing the DNSKEY RRset, and o as long as the (compromised) key is anchored in a resolver and is used as a starting point for validation (this is generally the hardest to update). While a trust chain to a zone's compromised key exists, your namespace is vulnerable to abuse by anyone who has obtained illegitimate possession of the key. Zone administrators have to make a decision as to whether the abuse of the compromised key is worse than having data in caches that cannot be validated. If the zone administrator chooses to break the trust chain to the compromised key, data in caches signed with this key cannot be validated. However, if the zone administrator chooses to take the path of a regular rollover, during the rollover the malicious key holder can continue to spoof data so that it appears to be valid.4.2.1. KSK Compromise
A compromised KSK can be used to sign the key set of an attacker's version of the zone. That zone could be used to poison the DNS. A zone containing a DNSKEY RRset with a compromised KSK is vulnerable as long as the compromised KSK is configured as the trust anchor or a DS record in the parent zone points to it. Therefore, when the KSK has been compromised, the trust anchor or the parent DS record should be replaced as soon as possible. It is local policy whether to break the trust chain during the emergency rollover. The trust chain would be broken when the compromised KSK is removed from the child's zone while the parent still has a DS record pointing to the compromised KSK. The assumption is that there
is only one DS record at the parent. If there are multiple DS records, this does not apply, although the chain of trust of this particular key is broken. Note that an attacker's version of the zone still uses the compromised KSK, and the presence of the corresponding DS record in the parent would cause the data in this zone to appear as valid. Removing the compromised key would cause the attacker's version of the zone to appear as valid and the original zone as Bogus. Therefore, we advise administrators not to remove the KSK before the parent has a DS record for the new KSK in place.4.2.1.1. Emergency Key Rollover Keeping the Chain of Trust Intact
If it is desired to perform an emergency key rollover in a manner that keeps the chain of trust intact, the timing of the replacement of the KSK is somewhat critical. The goal is to remove the compromised KSK as soon as the new DS RR is available at the parent. This means ensuring that the signature made with a new KSK over the key set that contains the compromised KSK expires just after the new DS appears at the parent. Expiration of that signature will cause expiration of that key set from the caches. The procedure is as follows: 1. Introduce a new KSK into the key set; keep the compromised KSK in the key set. Lower the TTL for DNSKEYs so that the DNSKEY RRset will expire from caches sooner. 2. Sign the key set, with a short validity period. The validity period should expire shortly after the DS is expected to appear in the parent and the old DSs have expired from caches. This provides an upper limit on how long the compromised KSK can be used in a replay attack. 3. Upload the DS for this new key to the parent. 4. Follow the procedure of the regular KSK rollover: Wait for the DS to appear at the authoritative servers, and then wait as long as the TTL of the old DS RRs. If necessary, re-sign the DNSKEY RRset and modify/extend the expiration time. 5. Remove the compromised DNSKEY RR from the zone, and re-sign the key set using your "normal" TTL and signature validity period.
An additional danger of a key compromise is that the compromised key could be used to facilitate a legitimate-looking DNSKEY/DS rollover and/or name server changes at the parent. When that happens, the domain may be in dispute. An authenticated out-of-band and secure notify mechanism to contact a parent is needed in this case. Note that this is only a problem when the DNSKEY and/or DS records are used to authenticate communication with the parent.4.2.1.2. Emergency Key Rollover Breaking the Chain of Trust
There are two methods to perform an emergency key rollover in a manner that breaks the chain of trust. The first method causes the child zone to appear Bogus to validating resolvers. The other causes the child zone to appear Insecure. These are described below. In the method that causes the child zone to appear Bogus to validating resolvers, the child zone replaces the current KSK with a new one and re-signs the key set. Next, it sends the DS of the new key to the parent. Only after the parent has placed the new DS in the zone is the child's chain of trust repaired. Note that until that time, the child zone is still vulnerable to spoofing: The attacker is still in possession of the compromised key that the DS points to. An alternative method of breaking the chain of trust is by removing the DS RRs from the parent zone altogether. As a result, the child zone would become Insecure. After the DS has expired from distant caches, the keys and signatures are removed from the child zone, new keys and signatures are introduced, and finally, a new DS is submitted to the parent.4.2.2. ZSK Compromise
Primarily because there is no interaction with the parent required when a ZSK is compromised, the situation is less severe than with a KSK compromise. The zone must still be re-signed with a new ZSK as soon as possible. As this is a local operation and requires no communication between the parent and child, this can be achieved fairly quickly. However, one has to take into account that -- just as with a normal rollover -- the immediate disappearance of the old compromised key may lead to verification problems. Also note that until the RRSIG over the compromised ZSK has expired, the zone may still be at risk.
4.2.3. Compromises of Keys Anchored in Resolvers
A key can also be pre-configured in resolvers as a trust anchor. If trust anchor keys are compromised, the administrators of resolvers using these keys should be notified of this fact. Zone administrators may consider setting up a mailing list to communicate the fact that a SEP key is about to be rolled over. This communication will of course need to be authenticated by some means, e.g., by using digital signatures. End-users faced with the task of updating an anchored key should always verify the new key. New keys should be authenticated out-of- band, for example, through the use of an announcement website that is secured using Transport Layer Security (TLS) [RFC5246].4.2.4. Stand-By Keys
Stand-by keys are keys that are published in your zone but are not used to sign RRsets. There are two reasons why someone would want to use stand-by keys. One is to speed up the emergency key rollover. The other is to recover from a disaster that leaves your production private keys inaccessible. The way to deal with stand-by keys differs for ZSKs and KSKs. To make a stand-by ZSK, you need to publish its DNSKEY RR. To make a stand-by KSK, you need to get its DS RR published at the parent. Assuming you have your normal DNS operation, to prepare stand-by keys you need to: o Generate a stand-by ZSK and KSK. Store them safely in a location different than the place where the currently used ZSK and KSK are held. o Pre-publish the DNSKEY RR of the stand-by ZSK in the zone. o Pre-publish the DS of the stand-by KSK in the parent zone. Now suppose a disaster occurs and disables access to the currently used keys. To recover from that situation, follow these procedures: o Set up your DNS operations and introduce the stand-by KSK into the zone. o Post-publish the disabled ZSK and sign the zone with the stand-by keys.
o After some time, when the new signatures have been propagated, the
old keys, old signatures, and the old DS can be removed.
o Generate a new stand-by key set at a different location and
continue "normal" operation.
(page 39 continued on part 3)
