From the Beginning: Key Transitions in the First 15 Years of DNSSEC

When the global rollout of the DNS Security Extensions (DNSSEC) began in 2005, it started a first-of-its-kind trial: increasing complexity of a core Internet protocol in favor of better security for the overall Internet. The necessary cryptographic key management is made particularly challenging by DNS' loosely-federated delegation substrate and unprecedented cryptographic scale. Though fundamental for current and future operational success, our community lacks a clear notion of how to empirically evaluate the process of securely changing (or transitioning) keys. In this paper, we propose two building blocks to fundamentally understand and assess key transitions. First, the anatomy of key transitions: measurable and well-defined properties of key changes; and second a novel classification model based on this anatomy to describe key transitions practices in abstract terms. Our anatomy enables the evaluation of cryptographic keys' life cycles in general, and comparison of operational practices with prescribed key management processes, e.g., RFC key rollover guidelines. The fine-grained transition anatomy is then abstracted through our classification model to characterize transitions in abstract terms which rather describe a transition's behavior than its specific features. The applicability and utility of our proposed transition anatomy and transition classes are exemplified for the global DNSSEC deployment. Specifically, we use measurements from the first 15 years of the DNSSEC rollout to detect and measure which key rollover/transitions have been used, to what degree, and what their rates of errors and warnings have been. Our results show measurable gaps between prescribed key management processes and key transitions in the wild. We also find evidence that such noncompliant transitions are inevitable in the wild.



There are no comments yet.


page 11

page 12


Comparative Analysis of Cryptographic Key Management Systems

Managing cryptographic keys can be a complex task for an enterprise and ...

Wallet Attestations for Virtual Asset Service Providers and Crypto-Assets Insurance

The emerging virtual asset service providers (VASP) industry currently f...

Integrating Hardware Security into a Blockchain-Based Transactive Energy Platform

This applied research paper introduces a novel framework for integrating...

Cryptographic key distribution over a public network via variance-based watermarking in compressive measurements

The optical communication has an increasing need for security in public ...

Modeling, Analysis, and Hard Real-time Scheduling of Adaptive Streaming Applications

In real-time systems, the application's behavior has to be predictable a...

RansomClave: Ransomware Key Management using SGX

Modern ransomware often generate and manage cryptographic keys on the vi...

AniVis: Generating Animated Transitions Between Statistical Charts with a Tree Model

Animated transitions help viewers understand changes between related vis...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1. Introduction

Key transitions are a critical aspect of Internet-scale cryptographically enhanced infrastructures. The Internet, however, is composed of loosely-federated administrative domains, and managing cryptography under those conditions presents operational challenges. Mismanagement of cryptography can lead to security shortfalls in those systems and infrastructures that depend on them (e.g., (l-edcs-13, ; k-ddd-13, ; p-cpsci-16, ; t-llir-20, )). Paul Mockapetris and Kevin J. Dunlap (1988) wrote, “Distributing authority for a database does not distribute a corresponding amount of expertise” (mockapetris-sigcomm88, ). With DNSSEC, which begun its global deployment in 2005, these words ring true again, but perhaps as the question: can distributing responsibility to manage cryptographic material teach us the corresponding amount of expertise?

One task that is common in DNSSEC is to periodically change the cryptographic keys that are being used. In some cases this is done as a hygienic prescription, in others it can be an emergency response to a security event (such as from a key compromise, or a cryptosystem weakness). The changing of keys is a process called key rollover (or key transitioning, as we discuss below). This is a process in which a system gracefully transitions from using keys that are departing, i.e., removed, to using keys that are remaining, i.e., unchanged or newly added, while ensuring continuity of protections during the change. Following structured process models for key transitions is critical for maintaining the security assurances of the overall system, and different infrastructures dictate different processes, and prescribe them in different ways (rfc5011, ; rfc7583, ; rfc6480, ; barker2007nist, ). While guidance for DNSSEC key life cycle management and timing exists in RFCs, a more foundational evaluation framework is needed so the community can quantify and evaluate all operational complexities, and to not only compare them to prescribed guidance but to each other as well.

In this work, we propose to represent the complexity of key transitions by identifying which elements are necessary to measure (which we define as the anatomy of DNSSEC key transitions), and a measurement methodology to quantify key transitions seen in the wild. By using our anatomy and transition model as a platform, we are able to model key transition behaviors in the wild from both RFCs (rfc5011, ; rfc7583, ) and from related work in the literature (wang2014emergency, ). Our measurements cover 19 million key transitions during 2005-2020, the first 15 years of DNSSEC deployment. They reveal a significant amount of heterogeneity in key transitions, many of which deviate significantly from standards without necessarily reducing security.


DNSSEC Deployment + .se signed


Kaminsky Attack


Root + .net signed DURZ rollover


.com signed



Sea Turtle


Root KSK rollover




This work coverage

Osterweil et al. (Osterweil:2008:QOS:1452520.1452548, )

Deccio et al. (Deccio_2012, )


Lian et al. (182950, )


Chung et al. (chung2017longitudinal, )

Müller et al. (muller2019rolling, )

van Rijswijk-Deij et al. (10.1145/3123878.3131987, )

Müller et al. (Muller:2019:RRR:3355369.3355570, )

Data coverage

DNS(SEC) Events
Figure 1. Notable DNS(SEC) deployment events (blue) and security incidents (red) during the measurements of this work and related work.

Our contributions in this work are threefold:

  1. Anatomy: We first examine the timing features of keys being transitioned and propose an anatomy of DNSSEC key transitions, which defines a candidate set of measures that are necessary to characterize key transitions.

  2. Transition Classification: Based on this anatomy, we present a novel methodology, which we use to illustrate that key transitions seen in the wild can be concisely quantified and analyzed.

  3. Platform and Data set: Finally, to illustrate the generality of this work, we present measurements of operational key transitions that span 15 years of DNSSEC’s deployment, covering a number of notable events that are not fully analyzed by related works (see Figure 1).

The remainder of this paper is organized as follows: Section 2 describes background information about DNSSEC. In Section 3, we describe our proposed key transitions anatomy, and how we construct our model of transition. Next, we explain the details of the measurement corpus used for this work, in Section 4. Then, Section 5 details the methodology used to create a continuous model of the lifetimes of DNSSEC keys from discrete observations. Section 6

introduces our approach to classify life cycle management and transitions of keys. From that, we proceed and present our use case study in Section 

7. We cover related work in Section 8, before a discussion in Section 9. Finally, we conclude in Section 10.

2. Background

The DNS is a hierarchically administered global database of Resource Records (RRs), which are inserted and removed whenever operators choose. The design of the DNS allows the administrator of any sub-tree (called a DNS zone) to delegate the management authority of any branch under their zone to another authority. Delegations are implemented when a zone’s parent (predecessor) adds Name Server RRs (of type NS) that point to that sub-zone’s DNS name servers. This hierarchical delegation allows administrators to operate their zones independently, and (unless there are changes) only requires the one-time coordination of setting up NS RRs.

To compensate for a number of security threats (see (bellovin1995using, ; RFC3833, )), DNS evolved to have the DNS Security Extensions (DNSSEC), whose specifications underwent their final round of standardization (rfc4033, ; rfc4034, ; rfc4035, ) in 2005. DNSSEC overloads the hierarchical namespace of DNS with cryptographic key learning and verification. In its design, DNSSEC-enabled zones generate and manage their own public/private cryptographic key pairs, using any of a set of cryptographic algorithms (i.e., cryptosystems) that are standardized for DNSSEC by the IETF. Operators then encode the public portion of their key pair in a new RR type, DNSKEY. DNSSEC specifies that zones should manage two separate classes of DNSKEYs: Zone Signing Keys (ZSKs) to sign all of a zone’s contents (e.g., A and NS records), and Key Signing Keys (KSKs) that are only used to sign DNSKEYs. While the cryptographic material used for these keys is fundamentally identical, their key life cycle management and roles are distinct. ZSK pairs are used every time data in a zone is changed and must be re-signed. The KSKs are used whenever DNSKEYs are changed, and when KSKs change a new DS record must be configured at a zone’s hierarchical parent zone. DNSKEYs are used to verify cryptographic signatures that are generated by the DNSKEYs’ corresponding private keys over sets of RR data in each zone, called RRsets. Signatures are served in DNSSEC zones as RRSIG records and are returned with each DNSSEC response. An RRSIG definitively specifies its inception and expiration times to limit its period of validity, and to resist replay attacks. For any given zone the validity period of signatures over its RRs governs how often the records can change, while still being protected by DNSSEC, i.e., cryptographically validated. Any other change outside this time frame can pose a security violation: for example, replacing a key before its expiration date while its generated signatures are still verifiable and within their lifetimes exposes that zone to replay attacks. Similarly, using a key before it becomes valid makes the validation process infeasible.

In order to be globally verifiable by Relying Party (RP) software (also called validating recursive resolvers, or just validators), DNSSEC zones must have their parent zone securely delegate resolution to their DNSKEY(s) through an RR type called a Delegation Signer (DS) record. In this way, validators use the DNS Root zone’s KSK as a Trust Anchor (TA) that unambiguously recursively delegates verifiable paths to any DNSSEC zone in the hierarchy. This follows the same way DNS zones are normally resolved recursively via NS records. However, unlike NS delegations, which need not be attended to regularly, DS delegations require cryptographic re-signing and updating whenever child-zones change their KSKs (which operational best practices direct to be a periodic event). The entire secure delegation chain from the DNS root to delegated zones, the chain of trust, is the element that creates operational dependence between the cryptographic management of zones and their predecessors.

3. Modeling Key Transitions

Figure 2. Frequencies of key transitions with different cardinalities between 2005–2020

A key transition refers to the procedure of modifying the set of valid DNS keys over time. The growing literature discusses DNSSEC key transitions in terms of key “rollovers” (muller2019rolling, ; Muller:2019:RRR:3355369.3355570, ), i.e., a single new key replacing the only existing key. Based on consistent monitoring data from DNSSEC’s first 15 years, evidence indicates that global DNSSEC deployment follows a different reality as depicted in Figure 2: we see that beside the majority of one-to-one transitions, a non-negligible portion of transitions involve more than two keys and requires a more expressive model. To reflect this reality, we introduce a generic model of key transitions. In our proposal, a transition succeeds only when the removal of one or more departing keys results in a different (possibly overlapping) set of remaining keys. It should be noted that the set of remaining keys includes both newly added keys (if any) and existing keys which were not modified during the transition. This model allows us to evaluate both key transitions in the majority of cases (i.e., key rollovers) as well as the more complex key changes seen in the wild.

In the following, we introduce a temporal model of DNS keys, which we use to define a transition anatomy; and provide a method to capture the semantics of key transitions in terms of transition classes.

3.1. Anatomy of a Key Transition

Key transitions are measurable through changes in DNSKEY resource records, and their respective RRSIG records; in case of KSKs additionally through changes in DS records in the parent zone. While such changes are present, we consider a transition as ongoing.

Before we describe the temporal features of DNSKEY transitions, we first need to define a temporal lifetime model for DNSKEYs, which adequately describes a key’s existence from its inception through its usage, including its retirement, and through its expiration; as depicted in Figure 3. Within DNSSEC, the only temporal information that is explicitly expressed about resource records are encoded in (i) TTL values, and (ii) the validity period as defined by respective RRSIGs. TTL values are indicators used by caching resolvers to locally determine a time window after which a record should be considered stale, and thereby be flushed from the cache. TTLs do not have any cryptographic security protections and are meant to establish and maintain eventual-consistency in caches (rfc4033, , §8.1). They do not provide any life cycle information on resource records. By contrast, the validity of DNSKEYs (through RRSIGs) provides verifiable cryptographic information which intentionally forms the core of DNSSEC’s protections and key transitions. Key transition process models are designed to preserve security assurances during key changes. Among their security goals is being sure that only valid keys are used/trusted during a transition and invalid keys are not. As an illustration, if a key has been compromised and a zone does not want that key to be verified anymore, it needs to be transitioned away from. If its signatures have expired, then validating resolvers will not verify it , and it cannot be replayed or otherwise used. By contrast, if a key’s signatures are still valid, they can be replayed into caches and then cached according to the TTLs (because TTLs have no verifiable security semantics). The security assurances of keys and the derived signatures those keys verify are orthogonal to the TTL values. This is the motivation for designing transition process models using signature lifetimes. Accordingly, we create a temporal model of keys using (i) signatures over, and (ii) signatures generated by those keys. Using RRSIGs over a key (recall that a single DNSKEY can be signed multiple times throughout its lifetime) the total lifetime of that key, i.e., the earliest and latest point in time when the key was singed (), are measurable properties. The RRSIGs generated by a DNSKEY, in turn, can be used to determine when the key was active (i.e., being used). In other words, the earliest and latest times that data was verifiable by this key (), the time when the key stopped generating new signatures (), and subsequently the duration in which the key was only used to verify existing signatures (). In addition, for KSKs only, the signatures over DS records of the parent zone are used to infer the period in which the parent zone’s key was in use, for securely delegating to this key ().

Figure 3. A temporal model for DNS keys showing total lifetime of the DNSKEY. RRSIGs generated by the key define active usage, i.e., the period when new signatures were created, and key run-out, i.e., as no new signatures were created while existing ones are still valid; and RRSIG(s) covering respective DS records define a key’s delegation period.

Next, we use this temporal model to define a simple 1:1 transition. To this end we define a transition anatomy based on the following ten features. These include measures of when keys were observed to actually be in use for a departing key and a remaining key , visually presented in Figure 4:

  1. PreDS (): When a corresponding DS record was introduced for in the parent zone.

  2. DoubleSig (): The period during the transition when both departing and remaining keys were actively signing.

  3. PreStage (): The amount of time that the remaining key was valid, but before being used to verify zone data.

  4. DepSigOnly (): The duration during the key transition when only the departing key was in use.

  5. Retire (): The duration during the key transition when signatures generated by departing key run out (run out described in Figure 3).

  6. DSOverlap (): The duration (if at all) that DS(es) for the departing and remaining keys overlapped.

  7. RemSigOnly (): The duration during the key transition when only the remaining key was in use.

  8. DsPreRem (): If the departing key was covered by a DS, the amount of time that the key was valid after DS(es) no longer delegated to it.

  9. RemPreDS (): When a corresponding DS record was introduced for the remaining key in the parent zone.

  10. TotalDuration (): Duration of the entire transition. Equals to for ZSK transitions; and to for KSK transitions.

Based on our anatomy, we are able to describe any arbitrary transition of departing keys to remaining keys, using pairwise 1 : 1 transitions. Our measurements of operational zones over 15 years indicate that this distinction important. For example, consider a zone where there are keys (with possibly different initial inception times) where to keys are being used to sign data. If that zone transitions to keys (where to are used to sign data), a couple of questions arise. Which key(s) rolled over to which other keys? Did all the departing keys roll over to all the remaining keys? If some keys persisted, did they get rolled over to as well? Figure 2 clearly shows that while the majority of key transitions observed change by one key (gaining or losing), there are many where . These measurements of real deployments are illustrations of why additional expressiveness is necessary, because many of the previous discussions and characterizations of “rollovers” in the literature apply only to cases in which a single active key is rolling over to another single active key. We further define a transition by saying that if more than one key is added or departs at same time, these are multiple transitions that occur at the same timestamp. The intuition here is that no single departing key is measurably more pivotal than another. Thus, we define each departing key as transitioning to each of the keys that remain. This definition of key transitions allows us to measure behaviors like how many active keys are in use, when transitions are aborted or rolled back, when secure delegations (from DS records) are correct, and more.

Figure 4. Anatomy of a key transition.

In addition, our transition model measures the relative ages (of the remaining to departing keys): newer, older, or the same age. These semantics, although not used by the RFCs, are useful in some process models (e.g.,  (wang2014emergency, ) described below).

Our proposed anatomy is a fine-grained description of the atomic timing components that are necessary and sufficient to fully characterize key transitions. Whether key transitions are being performed manually, using a process, being automated, or result from unsupervised ad hoc changes in a DNSSEC zone, the diversity of their actions is concisely represented by this anatomy.

3.2. Transition Classes

Our transition anatomy allows for the precise reconstruction and description of any pairwise key transition. Special care needs to be taken when characterizing transitions abstractly, as RFC 5011 or RFC 7583 do for example. To compare transitions, we measure each aspect of the anatomy and represent the pattern as an ordered set of the measurements. Then, we discretize each element of the set. Transition classes allow us to to compare them to each other, and to assess whether prescribed security guarantees are preserved while keys are changing (e.g., by adhering to specifications such as RFCs).

Here, discretization is the process that allows us to compare key transitions whose measurable values are different (e.g., that have different durations or signing intervals) but whose behavior is similar or the same. We discretize features (1) through (9) based on whether their values are , , , or N/A.111N/A can result for elements such as measurements of DS records for ZSKs that have no DS record to measure Later, in Section 6, we will see that N/A cases do not have an impact on transition classes. The value of each feature is the width of the interval defining that feature, i.e.,  for an interval . For intervals defined as intersections of other intervals, e.g., DoubleSig, the respective values are always non-negative, while others can assume negative values, e.g., PreDS can be negative when a KSK is securely delegated before being signed and included in the DNSKEY RRset (). Discretization allows us to empirically compare completely independent key transitions. For example, if two keys in a transition are both observed to be signing data at the same time, their observed DoubleSig feature would be a finite value. This would then be discretized as . Two other keys, in another transition (possibly in another zone) would likely have a different finite time period value, but would be discretized to the same discrete classification value, and thus enable comparisons between the transitions. As a result, every pairwise key transition can be represented as an ordered set of discretized features.

4. Monitoring System and Data Corpus

In this section, we introduce the DNSSEC measurements taken from our monitoring system (secspider-web, ) that we used to evaluate key transitions in the wild. We give an overview of our monitoring system, describe its operational aspects, and discuss the characteristics of the resulting data corpus, which covers the first 15 years of the global DNSSEC rollout.

4.1. Monitoring System

Our monitoring system queries DNS zones searching for DNSSEC records (DNSKEYs, DSes, RRSIGs, etc.) by polling all of every zone’s name servers222Specified by all NS records, from both the parent zone and the zone itself from distributed vantage points across the Internet (secspider-acsac10, ; secspider-web, ). This comprehensive polling is a critical feature for key transitions like those specified in RFC-8901 (rfc8901, ). In order to capture the holistic status of the global DNSSEC deployment, we broadly define zones as being DNSSEC-enabled if they have deployed one or more DNSKEY records. The set of DNSSEC zones in this corpus was learned from proactive crawling of online sources, techniques such as NSEC-walking (kolkman2009dnssec, ; secspider-acsac10, ), user-submissions, selected top-lists333Alexa Top One Million (alexa, ), the Majestic Million (majestic, ), and the Cisco Umbrella Popularity (umbrella, ), which account for a corpus of 74,557 out of the total 9.5 million DNSSEC-enabled zones measured at the time of this writing., and other techniques. As there is no systematic mechanism to discover all zones in the global DNSSEC, measurements can be subject to sample bias; nonetheless we argue these measurements of over 9.5 million DNSSEC zones over 15 years represent a relevant set on which to measure general behaviors of key transitions in the wild.

Polling Frequency

Our monitoring system polls its corpus of DNSSEC zones concurrently in four ways:

  1. The monitoring system repeatedly queries all zones from each of its remote polling locations. These full measurements poll hundreds of zones concurrently, and when finished, the system starts again. As the number of DNSSEC zones has increased, the full-corpus polling period has grown from taking days to taking weeks, making the periodicity of polling a varying interval.

  2. In parallel, it polls the DNS Root zone and all Top-Level Domains (TLDs) once per day, which is the TTL period of those zones.

  3. Every two days it polls popular DNSSEC-enabled domains seen in the Alexa top one million, the Majestic Million, or the Cisco Umbrella Popularity list.

  4. In addition to these multiple concurrent corpus polls ((1) - (3) above) the monitoring system’s website allows users to poll any zone on-demand.

Noteworthy, though, is that zones that delegate to others are implicitly queried and measured multiple times beyond when they are specifically scheduled. For example, the .com zone is not only monitored once but its keys and their usages are also re-observed for every delegated domain below, in order to assess NS and DS records. So, for example, the root zone is measured over 1,300 times every day (once for every Top-Level Domain polled). This greatly increases the frequency of observation, albeit in an aperiodic way.

Necessary Timing Measurements

Due to the fact that there are only two types of temporal information in DNSSEC records (TTL and signature-based lifetimes), there is debate in the literature about which of these defines the necessary lower bound on measurement frequency. In this work, we address this debate by proposing a candidate answer, based both on first-principles analysis and on measurements. We present a more detailed treatise in Section 10. What we show there is that when conducting a key transition, changing zone contents (DNSKEYs or otherwise) before their definitive RRSIG-based lifetimes have elapsed (such as at the granularity of TTLs) exposes zones to replay vulnerabilities. What we illustrate is the security guarantees of DNSSEC are orthogonal to TTLs and caching. The TTL values cannot ensure the absence of replayed keys (which may be compromised) into validating resolvers’ caches. In other words, an adversary can replay compromised keys whose RRSIGs are still valid, regardless of their TTL. For example, if a zone’s private key were compromised, and that zone’s operator were to replace it with a new key (i.e., remove the old key immediately or when TTLs have expired) she/he would still be vulnerable to replay attacks. While this does not stop operators from performing key transitions in this way, one of the objectives of the analyses of this work is to demonstrate to relationships (and independence) between protections and practices.

4.2. Data Corpus

This work makes use of data from October 2005 to August 2020. The resulting data corpus encompasses over 30.8 billion DNSSEC measurements444This corpus includes various types of RRsets, network PMTU measurements, name server versions, and many other relevant measurements from each name server and from each polling vantage point. from 9,535,615 DNSSEC-enabled zones with 35,882,395 distinct DNSKEYs: we observed 58,193,197 points in time when keys were either added or removed from zones. Of those changes, 17,965,575 key transitions (none observed in 2005) were detected (see Section 3.1) and analyzed, which we will discuss in Section 7.

Our data corpus spans several events that are notable for the global deployment of DNSSEC. First, multiple Top-Level Domains (TLDs) such as .com, .edu

, and 145 country-code TLDs (ccTLDs) deployed DNSSEC for the first time. Second, the announcement of a crucial large-scale DNS cache poisoning attack vector called the Kaminsky Attack 

(kaminsky2008black, ; cert2008vulnerability, ), whose remediation was publicized to be the deployment of DNSSEC. Third, the DNS Root zone enabled and rolled out DNSSEC for the first time using a Deliberately Unvalidatable Root Zone (DURZ) key. Fourth, in 2010, the DNS Root zone performed its first ever Key Signing Key (KSK) transition, from the DURZ key to the 2010 KSK. Fifth, over 1,200 DNSSEC-enabled new generic Top-Level Domains were added since 2013. Finally, the Root KSK was transitioned for the second time ever in 2018, after being started and paused during 2017. Figure 1 depicts a number of these notable events and incidents and by overlaying the measurement periods of related work and this study, shows this work has a uniquely complete longitudinal dataset to draw conclusions from.

It should be noted that our monitoring system has occasionally undergone migration to new hosting infrastructures, database backups, and other operational maintenance events leaving irregular gaps in our data corpus, which we control for in our methodology in Section 5.

5. Methodology

The initial step in our methodology is to reconstruct the lifetime of DNSKEYs according to our proposed temporal model (see § 3.1) from our discrete measurements. This is a deceptively challenging step because when keys are provisioned into zones there are no semantics to express (or for zone administrators to even know) life cycle information. For example, what will a key’s lifetime be, what frequency will it be re-signed, what key will succeed it, how many keys are active, which keys are stand-by keys and which are actually being used, etc.? Further, changes such as re-signings or deployment of new keys may occur at varying times between polling cycles—there will be gaps in time between three events: when these events happen on the authoritative name servers, when we poll the zones, and when we observe them in use. This may lead to changes that a measurement system completely misses. A simple example is the replacement of a DNSKEY multiple times between two polls.

Figure 5. Visualization of an observable for a given ¡DNSKEY,RRSIG¿ tuple.

Our first step in reconstructing the complete and continuous lifetime of keys from our discrete measurements is to infer a so-called observable for any unique ¡DNSKEY, RRSIG¿ tuple and any respective secure delegation period (if applicable) while preserving points of time when this specific observable was seen during our measurements. If a key’s lifetime is extended by re-signing (i.e., generating a new RRSIG over the same DNSKEY), our methodology creates a new observable tuple. In this sense, an observable can be considered as a piece of evidence based on a given RRSIG denoting that a key has been valid from the inception to expiration dates of that RRSIG. Figure 5 depicts one observable for key . This single observable’s lifetime duration is calculated from the signature covering , the delegation period from the signature in the parent zone covering DS record(s), and and denote the times when this single observable was first and last seen during the measurements. Note that is recorded once per observable, and never changed again, while is updated if the same ¡DNSKEY, RRSIG¿ tuple is encountered again in a subsequent measurement. Individual observables expand the information about a key’s lifetime from a discrete snapshot to a continuous timeline within the validity period of its covering RRSIG.

Such extrapolation of observables, however, might still leave some gaps in our continuous lifetime model. Furthermore, other life cycle information, such as key usage (see Figure 3), cannot be inferred from RRSIGs over keys. It must be measured from signatures generated by those keys when they are in use. To extend sets of observables into full key lifecycles (i.e., the same key re-signed multiple times) and measure signing frequency, management errors, other aggregate behaviors, and to account for gaps we introduce a novel methodology that we call Bridging, Busting, and Binding in a three-step process:

  1. Bridging: extend observables by filling in measurement gaps with place-holder observables (which we call bridging “ghosts”).

  2. Busting: use collected evidence, e.g., RRSIGs over non-DNSKEY records, to remove (or “bust”) incorrect ghosts.

  3. Binding: for any given DNSKEY combine remaining contiguous observables into a continuous holistic life cycle model.

(a) Between observables of the same DNSKEY
(b) Between observables of different DNSKEY
Figure 6. Filling in observation gaps with bridging ghosts.


Bridging begins by time-ordering observables for each zone. If the maximum time of a single observable (i.e., )) is less than the minimum time of the next observable (i.e., ), then a ghost record is inserted, which exactly covers the missing time. Note that a ghost does not necessarily fill the whole gap between two polling cycles, but only the time for which no temporal information can be inferred (see (a)). If the ghost observable covers a gap between the observables of the same DNSKEY (but different RRSIGs), then the ghost observable proposes that the key existed continuously during the gap, as shown in Figure 5(a). If, on the other hand, the gap exists between observables of two different DNSKEYs, then the process cannot know precisely when the older DNSKEY stopped being present and the newer DNSKEY was deployed, if/when they may have overlapped, or if there was a period of no key(s) being present. Therefore, at this stage, the bridge is temporarily used, whereby a trailing ghost for DNSKEY is inserted until the next observable and a leading (overlapping) ghost for DNSKEY is inserted, starting just after the previous observable, as seen in Figure 5(b). Ghosts represent optimistic assumptions about consistency between observations, but in the next phase we bust ghosts if additional evidence proves they are incorrect or need to be adjusted.


Ghost observations model place-holders of what data existed between the data we observed and inferred at polling cycles for each key individually. After the initial optimistic Bridging phase, our process begins to look at each zone, and examines keys in relation to each other and incorporates additional evidence to detect if a ghost assumption can be refuted (and thereby busted). For this, additional measured data (such as NS, SOA, A, and associated RRSIGs) allows the process to determine if, or how, a ghost should be busted. For example, if a ghost bridges a key, but another key was seen during that time, we can determine the ghost-key was not present for the period when the other key was seen. Or, monitoring a child zone will necessarily prompt the system to poll the DS, and thereby record the RRSIG(s) in use at parent zone, which would reveal the DNSKEY(s) in use there. The ghost is, then, busted by truncating it to the time interval(s) that are not covered by the other key. Alternately, if ghosts for two keys overlap between a transition (as seen in Figure 5(b)), information about which of them was able to verify signatures over other measured data is used to determine when one key was removed and the other was present, and truncate ghost overlaps accordingly. Overall, ghosts may be truncated if a zone’s data was observed and the key was absent, and affirmed if a ghost’s key was seen to be signing other records. Ghosts which may have been causes by measurement outages are removed altogether. Gaps caused by outages are distinguished through their relatively long duration. For our purposes, we take the yearly statistics of our measurement system’s crawl times, i.e.,

 a complete round of polling all zones, to bust gaps caused by outages: for any given year all gaps that are larger than the mean crawl time plus four standard deviations are considered as an

outage gap, are busted and removed. While the removal of long-ghosts could result in missed key transitions and key management behaviors, not removing them could alternately enshrine inaccurate assumptions.

Figure 7. Observations are bound together to find minimum and maximum timestamps for inception, expiration, first seen, and last seen. In addition, bounds are measured by using evidence of when keys were used to generate signatures (green region) and how long their signatures were valid for (blue region).


For every key, all the contiguous observations (including unbusted ghosts) are used to Bind observables into one single continuous key, as seen in Figure 7. Bound keys describe the lifetime of a DNS key in terms of our temporal model depicted in Figure 3 with two additional features, the first timestamp that the key was measured () and the last time a key was observed (). Here, all the observed RRSIG records that could be verified by each key, regardless of which DNS record type they covered, are used to quantify whether keys were in active use. The inception timestamp of each RRSIG is used as evidence to indicate when a key pair was in use signing data (). Further, the expiration of that signature specifies the run-out (or, the duration that a key’s data was verifiable while no new signatures were detected) (). Every new signature over zone data RRsets that can be verified by the same key extends the actively signing period (if the observations were contiguous). Absence of these signatures in these measurements does not prove keys were unused, but their presence proves that they were in use. Examples of transitions are in Appendix B.

6. Classifying Keys and Transitions

Having modeled the continuous life cycle of DNSKEYs allows us now to classify single keys’ life cycle management states as well transitions that are more complex than pairwise key transitions.

6.1. Key Life Cycle Classification

We present a novel classification scheme of measurable errors in a key’s life cycle management, as described in Figure 8. Based on this model we observe previously undetected errors in live deployments (see Section 7). This classification scheme defines six types of key life cycle management errors. Avoiding these errors is a necessary precondition for “valid” cryptographic protections. That does not imply that these preconditions are necessarily sufficient to ensure correct life cycle management, and that there are no other errors or problems with a specific key or its DNSSEC zone. Only that a given key must, at least, pass these implicit criteria. Similarly, while Bridging, Busting, and Binding allows us to measure the life-spans of keys, there is no formal requirement on how long their lifetimes must (or must not) be. Instead, the most direct measures of correctness that exist are for how RRSIGs’ dates should be specified, and our measurements reveal that there is a class of errors that arise from how keys are signed and when they are actually used.

Figure 8. Classification of key life cycle management states. Each state results from an observable property (rectangle) that is either fulfilled (Y) or not fulfilled (N). Properties include expiration (Exp) and inception (Incep) dates, as well as first () and last seen () of operational usage.

6.2. RFC-Based Classification

The IETF has specified many aspects of how DNSSEC zones and data should be configured and maintained across numerous RFCs (rfc4641, ; rfc6781, ; rfc5011, ; rfc7583, ). Among those are several processes that model ways in which DNSKEYs should be rolled over (or transitioned). In RFC 5011 (rfc5011, ), Trust Anchor (TA) rollover is specified for zones whose predecessor zones do not securely delegate DS records. Additionally, in RFC 7583 (rfc7583, ), processes are described for how zone administrators should transition their ZSKs and KSKs.

First we characterize RFC guidelines in terms of our temporal model and then investigate how transitions in the wild conform to these guidelines (in Section 7). We classify deviations as either warnings, i.e., the behavior does not strictly follow the RFC guidelines, yet, does not disturb validation; or as errors, which render the validation as bogus or insecure. For example, if a transition was specified as needing to have Retire ,555While conventional IETF parlance (e.g., SHOULD in RFC 8174 (RFC8174, )) often makes this explicit, the measurable quantities in RFC-7583 (rfc7583, ) do not use MUST, MAY, SHOULD, etc. We, therefore, semantically assign these values based on the overall processes. but it was 0, this would only be a warning because the key transition would still allow keys to verify data for a zone. In contrast to this, if a KSK must be present before a DS record in order to let resolvers securely verify the KSK during a Double-DS transition, then PreDS is a critical error.

RFC 5011 (Update of Trust Anchors)

This transition is specified by a Finite State Machine with timers and a rigorous process model. The process-model, however, is specified from a resolver’s perspective (i.e., timers that a resolver should set internally), which do not always directly correlate to observable timing of DNSKEYs in authoritative zones. Additional guidance (draft-ietf-dnsop-rfc5011-security-considerations, ) was written for authoritative zone administrators, which lends itself more directly to being measured. These two publications(rfc5011, ; draft-ietf-dnsop-rfc5011-security-considerations, ) define the specification for RFC 5011 transitions as those whose TotalDuration , where 30 days are specified in (draft-ietf-dnsop-rfc5011-security-considerations, ) and the key’s Time-To-Live (TTL) is specified as an additional component of the period. Additionally, those keys that are being removed must be revoked and be used to sign their own revoked DNSKEY set. In order to be conservative and permissive, we model the upper-bound (i.e.,  instead of ) from each key’s own average signature period. We conservatively modeled those zones that did adhered to RFC 5011 timing, but did not revoke as still being RFC 5011 compliant, but flagged them with a warning.

RFC 7583 (DNSSEC Key Rollover Timings)

RFC 7583 specifies the process models for both ZSKs and KSKs, and they are more stringent. For ZSK, these transitions are defined as either being “Pre-Publication” or “Double-Signature”; and for KSK as one of “Double-DS,” “Double-KSK,” “Double-RRset,” or “Double-RRSIG”. Note that the final type is identified as unrealistic in the RFC, and not even fully described there; therefore, we also omit it here.

Figure 9. An example from our measurements showing how zone performs a perfect ZSK Pre-Pub transition and a Double-KSK transition with warnings (Double-Sig and Retire ).

Figure 9 shows how the translation of RFC guidelines into our transition anatomy is used to classify transitions from our measurements. Here, we see an excerpt of transitions for the zone operational zone was chosen as a representative example. and can verify where it performs a correct ZSK pre-publication transition while (at other times) performing double-KSK transitions with warnings (see Table 1).

6.3. Non-IETF Prescriptions: Emergency Key Transitions

In addition to the above guidance from RFCs, other prior work by Wang et al. (wang2014emergency, ) proposed an approach for conducting emergency key transitions. There, the authors present 10 candidate process prescriptions for emergency key transitions, which are distinct from conventional RFC guidance. Without judgment of the efficacy of those presented processes, Table 1 illustrates the versatility of using our proposed key transition anatomy and classification methodology. Due to space limitations, we only include Emergency Transitions 2 and 3.

Features of the Transition Anatomy
Transition Class PreDS DoubleSig PreStage DepSigOnly Retire DSOverlap RemSigOnly DSPreRem RemPreDS TotalDuration
ZSK Pre-Pub
2-12[.4pt/3pt] ZSK Double-Sig
2-12[.4pt/3pt] KSK Double-DS
2-12[.4pt/3pt] KSK Double-KSK

Based on RFCs

KSK Double-RRset
2-12[.4pt/3pt] KSK Update-TA
KSK Emergency 2
2-12[.4pt/3pt] KSK Emergency 3 extended
2-12[.4pt/3pt] ZSK Emergency 2

Based on (wang2014emergency, )

ZSK Emergency 3 extended
Table 1. Mapping of key transition processes specified in DNSSEC RFCs and other literature to Transition Anatomies. In each row, gray cells show the mandatory features that must be fulfilled to map a transition to a predefined class, whereas the other cells describe soft constraints, which only cause warnings if not followed exactly. Cells showing “–” indicate wildcards.

It is noteworthy that this prior work considers keys transitions to stand-by keys (which are envisioned to be perpetually present before the emergencies). This, therefore, does not precisely specify the TotalDuration threshold, but suffices to make the “extended” duration feature a necessary detectable discriminator in these emergency transitions’ classification. Table 1 shows how the timing constraints detailed in that work can be used to classify and detect these events specified by our anatomy and transition methodology, just as with RFC guidance. In addition, aspects of that work use features of our anatomy and our model of key life cycles that the RFC processes did not (specifically, the TotalDuration and relative ages). For example, the specification requires remaining keys to be newer (a feature of our behavior-based classification, below in Section 6.4). Additionally, ZSK Emergency 2 mandates the feature-set of the behavior-based classification Multi-Signatures (described below, in Section 6.4), and ZSK Emergency 4 requires Cutovers.

In summary, using the prior work’s prescription, we detected 49,894 emergency ZSK transitions (20,919 that were transitioning back or aborting transitions to older or same age keys), and 1,780,984 emergency KSK transitions (149,406 transitioning back or aborting to older or same age keys).

6.4. Behavior-Based Classification

In our behavior-based classification, we classify key transitions as being “Multi-Signatures,” “Co-Present,” “Cutovers” (with degrees of certainty, described below), or “Unknown.” This classification approach uses more holistic considerations of all keys in a transition (not just pair-wise). Here, key transitions were classified based on the type of overlaps they had with all other active keys, with how many keys they overlapped, and whether they were used to verify zone data during their transitions. ZSKs and KSKs are, again, separated because their functions (data signing vs. key signing) are managed independently of each other, but the way that they classified here are not differentiated, and the relationships to DS records are not considered. This classification approach focuses on just the dynamics of key management during transitions.

When more than one key was seen to be actively in-use (verifying signatures) at any given time, we classify the transition as a “Multi-Signature” transition. This indicates that redundant verification existed for data in a zone during the transition.

If, on the other hand, keys were observed to have overlapped, but we did not observe any of them in use, we classify the transition keys as being “Co-Present.” This classification does not represent evidence that keys went unused, but indicates that our observations did not detect usage.

Conversely, transitions are classified as “Cutovers” when a single key was observed to transition (or cut-over) to another single key, and they were seen to have been used to verify signatures. This type of transition depends heavily on measurement frequency (whereby the longer the gaps in observations, the more information is estimated from ghost records). Because of this, we further sub-classify Cutovers as “Cutover,” “Likely-Cutover,” or “Candidate-Cutover.” The differences between these are based solely on how much usage (

i.e., active signing) was directly observed. If active signing (the inception of RRSIGs) was observed for the departing key right up until the remaining key began to be used to verify RRSIGs (and not after), then we classify this as a “Cutover.” If, on the other hand, we did not observe new signatures, but the signature run-out (as shown in Figure 7) of the departing key overlapped with the signatures of the remaining key, we classify the transition as a “Likely-Cutover” (because, perhaps, the zone was just not polled frequently enough). Finally, (because we cannot discern whether signatures over data records existed and we did not observe them, or if a key stopped being used) if the departing key was used at any point, and later the remaining key began being used with no other signatures seen in the time-gap, we classify this as a “Candidate-Cutover.” The goal of these distinctions is to make our sub-classification results useful, but to also preserve their transparency.

Figure 10. Classified key management errors.

7. Classifying 15 Years of DNSSEC Key Transitions

In this section, we present results from three perspectives: (i) whether keys involved in transitions follow proper life cycle management policies, (ii) using transition anatomy, we compare key transitions in practice with RFC guidelines specifying rollovers, and (iii) which characteristics are popular in key transitions beyond key rollovers in terms of our behavior-based classification.

7.1. Key Life cycle Management

The atomic management of the keys themselves can result in errors, independent of transitions of other keys. Using the key life cycle management classification technique described in Section 5, we broadly examine the rates at which individual DNSKEYs followed proper key management life cycles, or had errors (i.e., whether they existed in the valid state, or any other), see Figure 10. Key life cycle management errors were clearly highest during the early years of DNSSEC’s global rollout. At that time, the tools that supported DNSSEC were in their nascent stages of maturity, which is very likely the core reason for larger rates of key life cycle management errors. This figure also illustrates that the error rates for keys were highest in 2008, just as the discovery rate of new DNSSEC zones surged and more than doubled the size of the global deployment in just a few months. This all correlated in time with publicity to remediate the newly announced Kaminsky vulnerability by deploying DNSSEC, which could have also correlated with inexperienced operators making operational errors in a rush to secure their deployments.

7.2. Conformance to RFC Guidelines

(a) Key Signing Keys (KSK)
(b) Zone Signing Keys (ZSK)
Figure 11. RFC-based classification of key transitions for in-use KSK and ZSK.

KSK and ZSK Transitions in the Wild

Figure 11 summarizes RFC-based classifications of both measured KSKs and ZSKs per year. Any transition that could not be classified as RFC-compliant is marked as noncompliant. This Figure confirms a common expectation but also reveals new insights. Unsurprisingly, early in DNSSEC’s deployment, KSKs were transitioned according to RFC 5011 (denoted here as “TA-Update”). This was necessarily the case because at that time there were very few registrars and also few parent zones that were able to offer secure delegations (i.e., DNSSEC-covered DS records), most Top-Level Domains did not deploy DNSSEC and were, therefore, unable to securely delegate.

In 2008, operational advice was given to deploy DNSSEC to counter the Kaminsky vulnerability (cert2008vulnerability, ). Our data (see Table A.2) indicate that the number of DNSSEC-enabled zones more than doubled during the next three months. Based on our classification, it is clearly visible that subsequently more variety in key transition techniques appeared (see (a)). In 2009, the Double-DS transition technique was the most popular. This technique, however, requires additional coordination between an authoritative zone and the operator of its predecessor zone. Our results illustrate, despite an increasing deployment over time, that the popularity of managing transitions based on Double-DS and Double-KSK fluctuates. The majority always conformed to either RFC 5011 or was “noncompliant.” This observation indicates that the RFC-specified key transition processes may not properly represent operational behaviors.

Our results also exhibit an interesting discrepancy compared to other related work. In the longitudinal study of Chung 

et al. (chung2017longitudinal, ), no Double-DS transitions were said to be observed. However, under .com alone, we observed 17,126 unique zones performing Double-DS transitions during the time period of their daily scans (from 2015-03-01 to 2016-12-31), and 7,256 transitions during the same period as their hourly scans (from 2016-09-29 to 2016-12-31). A concrete example of Double-DS transitions is (details see (e)). Further understanding the discrepancies of these findings will be part of our future work.

Figure 12. An example of RFC noncompliant transition performed among others by Root and com. zones

In comparison to KSK transitions, an even larger portion of ZSK transitions have constantly been nonconforming to RFC specifications, see (b). While the “Double-Signature” alternative never accounted for more than 10% of transitions, it is most noteworthy that between 2007 and 2020 (except for 2009) most of the observed ZSK transitions did not conform to either prescribed mode of key transition. Ignoring RFC guidelines, however, does not necessarily mean that the zone verification would fail during the transition. Figure 12 depicts an example of such transition performed by prominent zones such as the Root and com. zones: this transition is neither Pre-Pub (PreStage ), nor Double-Sig (DoubleSig ), yet at any time during the transition the RRs can be verified by either or both keys. Here, we also see discrepancies with prior work (chung2017longitudinal, ), which might be traced back to different process models in classifying transitions.

(a) Key Signing Keys (KSK)
(b) Zone Signing Keys (ZSK, excluding type noncompliant)
Figure 13. Share of valid, warning, and error rates of in-use KSK and ZSK.

Implications on Robustness

The warning and error rates for RFC-compliant transitions are notably different for KSKs and ZSKs, as depicted in Figure 13. KSK transitions show more valid cases than ZSK transitions overall. This is corresponds also with the fact that a higher share of transitions followed RFC guidelines (cf., (a)). Later, in 2011–2020, critical error rates became even more visible. This could be the result of inherent management complexity in terms of timing and data for chain-of-trust-based transitions between authoritative zones (DNSKEYs) and parent zones (DS records).

For ZSK, Figure 12(b) shows that the rate of warnings exceeded successes (i.e., no error) in every year, except in 2006, when the DNSSEC deployment was just beginning, and zones were deploying DNSSEC for the first time. In 2007 and 2008, warning rates greatly exceeded success, but the trend was increasing for success rates. In 2011, the success rates dropped precipitously. This, however, again correlated with a large increase in the discovery rate of new DNSSEC-enabled zones. During this time, the DNS Root was deploying DNSSEC and transitioning its KSK for the first time. This correlation between a large increase in newly deployed DNSSEC zones and increase in error rates suggest that these rates may also be due to operators who may have been learning how to manage the security postures of DNSSEC in their DNS zones.

7.3. Holistic Characteristics of Transitions

(a) Key Signing Keys (KSK)
(b) Zone Signing Keys (ZSK)
Figure 14. Behavior-based classification of key transitions for in-use KSK and ZSK.

Using the RFCs to classify key rollovers gives us a helpful start in understanding how to analyze key transitions, but to overcome the amount of “noncompliant” transitions (those that do not follow the RFCs) and high error rates, we use the alternate behavior-based classification scheme (see Section 5). This classification focuses on the relationships keys have to each other in a transition and when keys were actually used.

When applying our behavior-based classification to ZSKs that were seen to be in use, Figure 13(b) shows that almost every key transition observed for 15 years was able to be classified. Only in 2007, 4.32% transitions were classified as unknown; in all other years, ¿99% of transitions were classified successfully. The trend over the first 15 years was a shift from initially using multiple concurrent keys (“Multi-Sign”), to cleanly cutting over from a departing key to a remaining key.

Figure 13(a) illustrates that all of these trends were similar in the KSK transitions. A greater portion of the KSK transitions were Multi-Sign than in ZSKs, but the trend towards moving to Cutover (and the small incidence of noncompliant transitions) mimics the ZSK transitions. This could be due to the same operational approach being used for both ZSKs and KSKs by any given zone operator, but the DNSSEC tools available have traditionally offered more comprehensive automation for ZSK transitions (because they are managed in a single authoritative zone) than KSK transitions (which involve coordination with the zone’s hierarchical parent.

8. Related Work

The topic of DNSSEC key rollovers has recently begun to be covered by the literature. In 2017, the DNS Root zone began publicity around its, then, intentions to transition its KSK for second time (since DURZ, as discussed in Section 4). At that time, van Rijswijk-Deij et al. (10.1145/3123878.3131987, ) began the Root Canary project to track this specific transition. Later, Müller et al. (muller2019rolling, ) created a related monitoring tool to aid operators in successfully planning and conducting DNSKEY rollovers. More recently and maybe most closely related to our work, Müller et al. (Muller:2019:RRR:3355369.3355570, ) conducted an in-depth study of key life cycle management in the DNS Root zone. Both of these results synergize with the observations of our work: key life cycle management of DNSSEC zones is critical to their operational health. Most importantly, and in contrast to prior work, we do not only consider key rollovers but provide a framework to analyze key transitions in general.

As DNSSEC deployment has grown, numerous studies have incrementally tracked its deployment. Among the first measurement studies, Osterweil et al. (Osterweil:2008:QOS:1452520.1452548, ) observed that longitudinal measurement of DNSSEC deployment were critical to understand its health, and proposed a set of three metrics to summarize the status of the global deployment. Subsequent large-scale measurements (182950, ) reported to confirm earlier findings, but also began to raise concerns about validating resolvers and the limited number of users being protected by DNSSEC.

More recent work (chung2017longitudinal, ) has conducted large-scale longitudinal analysis of the global DNSSEC deployment. There, the authors examined two years of DNSSEC deployment data. Among the concerns addressed was the identification of key management errors as an area for concern. The authors also discussed the subject of recycled keys as key “sharing” and flagged the behavior as an error. Recycled keys are those that were shared in separate zones or used, removed, and then re-used. DNSSEC zones are often presumed to create distinct keys for themselves without sharing usage with other zones, and that once a key expires and completes its operational lifetime, it will not be used again. In our paper, we treated each appearance of a recycled key as being a new key, because when being re-used its operational life cycle is different. From our, corpus we identify 35,882,395 distinct DNSKEYs, 42,908,290 distinct DNSKEY/zone pairs, and 54,337,697 total operational lifetimes of keys. Our measurements confirm the earlier result, and further illustrate that a non-trivial number of DNSKEY records were shared between zones, and others may have been returned to service after completing an initial operational lifetime.

While recent related work signals a renewed interest in key transitions, previous literature exists that suggests augmenting the DNSSEC protocol to add explicit semantics that indicate ongoing key transitions. Guette et al. (guette2005algorithm, ) suggested an extension to the DNSKEY format, itself, to indicate when key transitions are underway. Then, in subsequent work (guette2009automating, ), this approach was evolved by proposing a new Resource Record (the KRI). Interestingly, the semantics that those works suggest as being necessary are observable in the current DNSSEC, when using our methodology.

Finally, DNSSEC algorithm rollovers, an aspect that is outside the scope of this work, has been subject of study by related work (chung2017longitudinal, ; muller2019rolling, ). In a recent publication Müller et al. (10.1145/3419394.3423638, ) study the lifetime of cryptographic algorithms for DNSSEC to conclude that algorithm agility has already been reached for DNSSEC.

9. Discussion

The global rollout of DNSSEC is flourishing, and is giving operators experience at scale in managing cryptography in a core Internet protocol. We believe that now is the right time to investigate what has been (and can be) learned from these experiences.

Capturing the right security model

Caching plays an important role in DNS(SEC), and (from a security perspective) is a data availability (fenrich2008securing, ) service that is controlled by records’ Time-To-Live (TTL) values. When changing DNSKEYs, if care is not taken, cached DNSKEYs and/or RRSIGs over valid data can become unverifiable. As one example, if a validating resolver caches DNSKEY for a zone , and then abruptly transitions to , i.e., replaces with in DNSKEY RRset before expires, may subsequently resolve new data but try to use the old key () to verify it. The resulting verification failure of new (valid) data, would not prompt to proactively check for new data. In order to ensure that caches will only have validatable RRsets in them, timing is managed by name servers (in part) at the granularity of TTLs.

DNSSEC’s availability protections are important, but separable from DNSSEC’s data integrity assurances. This availability model is entirely governed by TTL, whereas the integrity protections are entirely governed by DNSKEYs, RRSIGs, and DSes and their timings and life-times. TTL-based availability protections (designed for caching) are not involved in integrity assurances. Conversely, integrity protections actually mollify cache poisoning attacks (a central design goal of DNSSEC (kaminsky2008black, )). In such attacks, availability is not a factor because adversaries influence the presence of data in caches. Though DNSSEC operations involve the confluence of these two aspects of DNS(SEC), in this work we focused on DNSSEC’s integrity protections, because of the importance of evaluating their exclusive role.

We proposed that the necessary conditions to preserve integrity protections during a DNSSEC key transition are:

  1. Valid DNSKEYs must be verifiable by RRSIGs (i.e., cryptographically, temporally, etc.).

  2. Zones’ KSKs must be covered by valid and verifiable DS records.

  3. At all times, RRSIGs covering current data must be verifiable by at least one verifiable DNSKEY.

All of these conditions must be met to be sufficient to provide DNSSEC’s data integrity assurance during key transitions. We used our proposed anatomy to describe how to evaluate these in operational deployments.

Sufficient measurement frequency to obviate TTL-level frequency of polling

As mentioned in Section 4, there is debate in the literature on the general topic of needing to monitor DNSKEY transitions at the granularity of DNS TTLs or signature lifetimes. Specifically, related work by Chung et al. (chung2017longitudinal, ) considers TTL to be the primary discriminator of change frequency. While the analyses we present here illustrate weaknesses in this perspective, the measurement corpus we use actually includes observations taken at the TTL values of the DNS Root zone and all TLDs (whose TTLs are all two days, 172,800 seconds). We posit that one-day polling of these zones is sufficient based on the Nyquist-Shannon sampling theorem (nyquist1928certain, ; shannon1949communication, ): measuring continuous phenomena with discrete sampling can approximate those phenomena, and accurately characterize them, if polling occurs at a frequency that is at least twice that of the rate of change. This forms the basis for our conclusions that measuring key transitions needs to be done at frequencies relative to RRSIG lifetimes, that properly operated infrastructure (e.g., the Root and TLDs) perform their operations in accordance with these analyses, and that this work is able to compare these different timing hypotheses (RRSIG vs. TTL) with longitudinal measurements from the wild.

Key transitions are complex

Key transitions are deceptively complex, and our results suggest that they represent an area that needs further study. The anatomy of key transitions in the wild shows a great deal of diversity in the different ways that zone administrators are effectuating them. This diversity has often not conformed to those prescriptions set down in RFCs, but is that a problem of the zone owners (and their software), or with the standards? Based on the 18 million transitions that we observed in this work, a more foundational question arises: are operators’ practices exposing correctable security problems or are their implementations displaying insights that should be ingested—similar to Continuous Improvement paradigm (deming1982out, ), which has been applied recently in other areas (bhuiyan2005overview, )? This question serves as an additional motivation for the behavior-based classification approach (described in Section 5). We believe that defining an anatomy and measuring related features may serve as a rigorous framework that can be used to establish a sound feedback loop between standardization and measurable operational practice.

10. Conclusion and Outlook

In this work, we first proposed a novel definition of the anatomy of key transitions as ten separate measurable timing features. In addition, we identified related measurable aspects of key life cycle management (e.g., relative age and key management errors), and defined a holistic behavior-based classification method for transitions. We then introduced a novel methodology for converting discrete observations into continuous DNSKEY lifetimes, called Bridging, Busting, and Binding. Using this substrate, we created anatomies of key transitions observed in the wild and empirically evaluated this complex phenomenon for the first 15 years of DNSSEC operation. Our work allows us to measure how well operators have followed guidance and, as an example of the general utility of our methodology, where related work has applied (wang2014emergency, ). This, more generally, has let us evaluate what kinds of key transitions operators have been using. We found that the majority of KSK key transitions and the vast majority of ZSK key transitions do not conform to RFC guidance. Additionally, using our behavior-based classification, we also observed that in some years significant rates of key transitions were rolling backward. Our conclusions are that this work’s anatomy methodology serve as a useful platform for investigating DNSSEC key transitions in the wild, and derived analyses are well suited to inform evolving key transition practices.

Going forward, we intend to examine the specific implications of popular key transitions, to understand where deployed innovations can advise security standards. Further, we intend to investigate the applicability of using our anatomy for other large-scale security systems, such as the Resource Public Key Infrastructure (RPKI) (rfc6480, ) and the Web PKI (wpkops, ). Finally, we intend to make our feature set and the longitudinal dataset from (secspider-web, ) public, to encourage additional investigations from the community.


  • [1] Amazon. Alexa top sites.
  • [2] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS Security Introduction and Requirements. RFC 4033, IETF, March 2005.
  • [3] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Protocol Modifications for the DNS Security Extensions. RFC 4035, IETF, March 2005.
  • [4] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Resource Records for the DNS Security Extensions. RFC 4034, IETF, March 2005.
  • [5] D. Atkins and R. Austein. Threat Analysis of the Domain Name System (DNS). RFC 3833, IETF, August 2004.
  • [6] Elaine Barker, William Barker, William Burr, William Polk, and Miles Smid. PNIST special publication 800-57. NIST Special publication, 800(57):1–142, 2007.
  • [7] Steven M Bellovin. Using the domain name system for system break-ins. In USENIX Security Symposium, 1995.
  • [8] Nadia Bhuiyan and Amit Baghel. An overview of continuous improvement: from the past to the present. Management decision, 43(5):761–771, 2005.
  • [9] US CERT. Vulnerability Note VU# 800113: Multiple DNS implementations vulnerable to cache poisoning. Technical report, US CERT Vulnerability Notes Database, 2008.
  • [10] Taejoong Chung, Roland van Rijswijk-Deij, Balakrishnan Chandrasekaran, David Choffnes, Dave Levin, Bruce M Maggs, Alan Mislove, and Christo Wilson. A Longitudinal, End-to-End View of the DNSSEC Ecosystem. In Proceedings of USENIX Security Symposium (Security ’17), pages 1307–1322, Washington, D.C., 2017. USENIX Assoc.
  • [11] Cisco. Cisco umbrella 1 million., July 2020.
  • [12] Casey Deccio, Jeff Sedayao, Krishna Kant, and Prasant Mohapatra. Quantifying DNS namespace influence. Computer Networks, 56(2):780–794, feb 2012.
  • [13] W Edwards Deming. Out of the Crisis. MIT Press, 1982.
  • [14] Kim Fenrich. Securing your control system: the” cia triad” is a widely used benchmark for evaluating information system security effectiveness. Power Engineering, 112(2):44–49, 2008.
  • [15] Gilles Guette. Automating trusted key rollover in dnssec. Journal of Computer Security, 17(6):839–854, 2009.
  • [16] Gilles Guette, Bernard Cousin, and David Fort. Algorithm for dnssec trusted key rollover. In International Conference on Information Networking, pages 679–688. Springer, 2005.
  • [17] Wes Hardaker and Warren Kumari. Security Considerations for RFC5011 Publishers. Internet-Draft – work in progress 13, IETF, July 2018.
  • [18] S. Huque, P. Aras, J. Dickinson, J. Vcelak, and D. Blacka. Multi-Signer DNSSEC Models. RFC 8901, IETF, September 2020.
  • [19] IETF. Web PKI Ops (WPKOPS).
  • [20] Dan Kaminsky. Black ops 2008: It’s the end of the cache as we know it. Black Hat USA, 2, 2008.
  • [21] O. Kolkman and R. Gieben. DNSSEC Operational Practices. RFC 4641, IETF, September 2006.
  • [22] O. Kolkman, W. Mekking, and R. Gieben. DNSSEC Operational Practices, Version 2. RFC 6781, IETF, December 2012.
  • [23] Olaf Kolkman. DNSSEC HOWTO, a tutorial in disguise. URL: http://www. nlnetlabs. nl/dnssec_howto/dnssec_howto. pdf, 2009.
  • [24] Olaf Kolkman. DNSSEC, DANE, and Diginotar. Conference presentation, APNIC 35 Conference, 2013.
  • [25] Adam Langley. Enhancing digital certificate security. Technical report, Google Security, 2013.
  • [26] B. Leiba. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. RFC 8174, IETF, May 2017.
  • [27] M. Lepinski and S. Kent. An Infrastructure to Support Secure Internet Routing. RFC 6480, IETF, February 2012.
  • [28] Wilson Lian, Eric Rescorla, Hovav Shacham, and Stefan Savage. Measuring the Practical Impact of DNSSEC Deployment. In Proceedings of the 22nd USENIX Security Symposium (Security ’13), pages 573–588, Washington, D.C., 2013. USENIX Assoc.
  • [29] Majestic. The majestic million., January 2021.
  • [30] P. Mockapetris and K. J. Dunlap. Development of the domain name system. In Proceedings of ACM SIGCOMM, pages 123–133, New York, NY, USA, 1988. ACM.
  • [31] S. Morris, J. Ihren, J. Dickinson, and W. Mekking. DNSSEC Key Rollover Timing Considerations. RFC 7583, IETF, October 2015.
  • [32] Moritz Müller, Taejoong Chung, Alan Mislove, and Roland van Rijswijk-Deij. Rolling with Confidence: Managing the Complexity of DNSSEC Operations. IEEE Transactions on Network and Service Management, 16(3):1199–1211, 2019.
  • [33] Moritz Müller, Matthew Thomas, Duane Wessels, Wes Hardaker, Taejoong Chung, Willem Toorop, and Roland van Rijswijk-Deij. Roll, Roll, Roll Your Root: A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover. In Proceedings of the Internet Measurement Conference, IMC ’19, pages 1–14, New York, NY, USA, 2019. ACM.
  • [34] Moritz Müller, Willem Toorop, Taejoong Chung, Jelte Jansen, and Roland van Rijswijk-Deij. The reality of algorithm agility: Studying the dnssec algorithm life-cycle. In Proceedings of the ACM Internet Measurement Conference, IMC ’20, page 295–308, New York, NY, USA, 2020. Association for Computing Machinery.
  • [35] Harry Nyquist. Certain topics in telegraph transmission theory. Transactions of the American Institute of Electrical Engineers, 47(2):617–644, 1928.
  • [36] Eric Osterweil. Secspider.
  • [37] Eric Osterweil, Dan Massey, and Lixia Zhang. Deploying and monitoring dns security (dnssec). In 2009 Annual Computer Security Applications Conference, pages 429–438. IEEE, 2009.
  • [38] Eric Osterweil, Michael Ryan, Dan Massey, and Lixia Zhang. Quantifying the Operational Status of the DNSSEC Deployment. In Proceedings of the Internet Measurement Conference, IMC ’08, pages 231–242, New York, NY, USA, 2008. ACM.
  • [39] Matthew Prince. How the Consumer Product Safety Commission is (Inadvertently) Behind the Internet’s Largest DDoS Attacks. Technical report, Cloudflare, 2016.
  • [40] Claude Elwood Shannon. Communication in the presence of noise. Proceedings of the IRE, 37(1):10–21, 1949.
  • [41] M. StJohns. Automated Updates of DNS Security (DNSSEC) Trust Anchors. RFC 5011, IETF, September 2007.
  • [42] Nathalie Trenaman. Lessons Learned on Improving RPKI. Technical report, RIPE Labs, 2020.
  • [43] R. van Rijswijk-Deij, T. Chung, D. Choffnes, A. Mislove, and W. Toorop. The root canary: Monitoring and measuring the dnssec root key rollover. In Proceedings of the SIGCOMM Posters and Demos, SIGCOMM Posters and Demos ’17, page 63–64, New York, NY, USA, 2017. Association for Computing Machinery.
  • [44] Zheng Wang and Liyuan Xiao. Emergency key rollover in dnssec. In 2014 IEEE 13th International Conference on Trust, Security and Privacy in Computing and Communications, pages 598–604. IEEE, 2014.

Appendix A Raw Data of Key Transition Classifications

Throughout the paper we normalize our data to better distinguish and highlight trends. Tables A.1A.4 tabulate the raw numbers used to generate Figures 1014.

’06 ’07 ’08 ’09 ’10 ’11 ’12 ’13 ’14 ’15 ’16 ’17 ’18 ’19 ’20
ancient 175 4765 36176 1998 NA 41217 25409 167665 186119 158774 203820 69694 196446 59613 287679
[.4pt/3pt]exp 7 282 40 1399 NA 16929 12 1898 548 82 222 5355 6930 4937 20361
[.4pt/3pt]future NA 52 9426 NA NA 53 NA 495 232 103 124 52 628 143 325
[.4pt/3pt]inverted NA NA NA NA NA NA NA NA 28 22 10 4 NA 3 6
[.4pt/3pt]no-sigs NA NA 1703 679 NA 8018 5039 24889 35518 27482 27931 14958 25906 33372 55879
[.4pt/3pt]pre-incep NA NA NA NA NA 122 NA 254 NA NA NA NA 8 25 105
[.4pt/3pt]valid 280 2064 10098 13211 NA 170944 235059 1061506 1145816 1346260 5537326 5875182 8889718 7368282 23240768
Table A.1. Classified key management errors.
’06 ’07 ’08 ’09 ’10 ’11 ’12 ’13 ’14 ’15 ’16 ’17 ’18 ’19 ’20
5011 11 15 4 179 2202 14 759 5395 5101 7084 18061 5445 3905 16100 33845
[.4pt/3pt]DoubleDS 0 1 0 8 78 0 455 1862 4087 2847 24411 47035 46284 183326 243542
[.4pt/3pt]DoubleKSK 0 0 0 11 410 13 293 8565 20180 13424 25206 39552 42935 53756 80228
[.4pt/3pt]DoubleRRset 0 0 0 0 240 0 102 691 613 825 793 718 388 162 396
[.4pt/3pt]Noncompliant 0 21 0 286 10036 6 2554 11397 34103 36636 137853 178225 174423 357362 290231
DoubSig 7 15 0 250 1913 2 1274 17330 16555 20042 39605 79402 95631 232452 116298
[.4pt/3pt]PrePub 26 10 0 1202 8326 16 4068 67146 62260 67601 181305 451082 583795 474944 980721
[.4pt/3pt]Noncompliant 4 72 43 1229 17555 24 17110 241960 260294 352031 1462711 1693579 1568447 2781118 3012187
Table A.2. RFC-based classification of key transitions for in-use KSK (top) and ZSK (bottom).
’06 ’07 ’08 ’09 ’10 ’11 ’12 ’13 ’14 ’15 ’16 ’17 ’18 ’19 ’20
Critical 0 1 0 0 30 0 225 245 620 820 9892 3781 11700 18749 108796
[.4pt/3pt]Valid 0 21 0 287 10103 6 2555 11442 34160 36777 137956 178466 176729 357478 290280
[.4pt/3pt]Warning 11 15 4 197 2833 27 1383 16223 29304 23219 58476 88728 79506 234479 249166
Valid 19 1 0 517 4170 1 1255 24428 21048 26721 33833 88625 75826 79421 69998
[.4pt/3pt]Warning 14 24 0 935 6069 17 4087 60048 57767 60922 187077 441859 603600 627975 1027021
Table A.3. Share of valid, warning, and error rates of in-use KSK (top) and ZSK (bottom; excluding type noncompliant).
’06 ’07 ’08 ’09 ’10 ’11 ’12 ’13 ’14 ’15 ’16 ’17 ’18 ’19 ’20
Cand-Cutover 0 5 0 7 296 0 81 486 195 683 14957 38777 64779 68512 144642
[.4pt/3pt]Cutover 0 1 0 5 267 2 124 8162 22182 9288 64264 55846 25438 57983 93264
[.4pt/3pt]Likely-Cutover 0 1 0 91 1551 10 1729 6712 27041 12475 87465 119004 148585 220946 306866
[.4pt/3pt]Multi-Sign 11 28 4 380 10804 21 2133 12123 14230 37662 37929 56173 28458 260701 101843
[.4pt/3pt]unknown 0 2 0 1 48 0 96 427 436 708 1709 1175 675 2564 1627
Cand-Cutover 0 10 0 12 612 3 1127 14709 5063 10416 91476 337814 492256 375772 1012625
[.4pt/3pt]Cutover 0 1 0 222 2131 0 1209 35893 53307 61372 268118 211801 95878 274009 149507
[.4pt/3pt]Likely-Cutover 10 28 38 566 6256 15 15341 193788 179113 250088 1168321 1474685 1478350 2396792 2643776
[.4pt/3pt]Multi-Sign 27 53 5 1872 18677 24 4679 81445 100092 116860 154093 194519 179959 431296 299926
[.4pt/3pt]unknown 0 5 0 9 118 0 96 601 1534 938 1613 5244 1430 10645 3372
Table A.4. Behavior-based classification of key transitions for in-use KSK (top) and ZSK (bottom).

Appendix B Transitions in the Wild

To illustrate the complete key life cycles of zones, Figures B.1 and B.2 include both ZSKs (in blue), KSKs (in yellow), and red sections indicate periods in which keys have the revoke bit set [41]. Notable in these (and other) zones is how visibly different the life cycles of ZSKs and KSKs are (as similarly evident in our measurements).

(a) The key management of the .com zone shows exemplary regularity and structure in its key transitions.
(b) Shown here is the Root zone’s KSK transition away from the DURZ key (followed by revocation), and regular periodicity in its ZSK transitions.
Figure B.1. The key transition behaviors of some prominent DNSSEC zones.
(a) shows distinctive key transition behavior, with up to 55 valid keys (though not all in use at the same time).
(b) The zone shows high-frequency transitions of its ZSKs, with regular periodicity and extended Retire times.
(c) The key management of ARIN (a Regional Internet Registry, RIR), uses extended PreStage periods for its keys (ZSKs and KSKs).
(d) The key management of visibly changes from having protracted PreStage periods to a different model at the end of 2014.
(e) The key management of exhibits regular DoubleDS transitions without having any ZSKs in the zone.
Figure B.2. Key transition patterns from other operational zones in the wild.