On Jan. 11, 2025, Verisign supported the Internet Corporation for Assigned Names and Numbers (ICANN) in taking a major step to ensure the continued security, stability, and resiliency of the Domain Name System (DNS). While imperceptible to most users, this action – specifically, the introduction of a new Domain Name System Security Extensions (DNSSEC) Key Signing Key (KSK) in the root zone – is the next step of a multi-year-long process to change, or “roll,” the cryptographic key that secures the root of the DNS. In this blog post, we’ll go into more detail about what this means and what observations we can make about the new key, which we refer to as “KSK-2024.”1
Introduction to KSKs and ZSKs
As we’ve discussed on our blog, the root zone utilizes both a KSK and ZSK. ICANN serves as the KSK operator and Verisign serves as the Zone Signing Key (ZSK) operator. This means we work closely with and support ICANN when it comes to KSK rollovers and other important changes to the root zone.
One advantage of the split key design is that the KSK generates relatively few signatures and can be changed infrequently. The ZSK, on the other hand, generates more signatures and is changed more often. Whereas the ZSKs are changed every 90 days, the KSK has only been changed once before, in 2017 (read our older blog posts about the previous root KSK rollover).
KSKs and ZSKs are published in the DNS and become part of the chain-of-trust for validating DNSSEC signatures. One feature of this chain-of-trust is that a parent zone can vouch for the authenticity of the keys in child zones. This is the purpose of the Delegation Signer (DS) record type. As an example, the .com zone has a DS record that authenticates the DNSSEC keys for the example.com zone:
example.com. 86245 IN DS 370 13 2 (
BE74359954660069D5C63D200C39F5603827D7DD02B5
6F120EE9F3A86764247C )The Root Zone: A Special Case
For the root zone, however, this presents a unique challenge because there is no parent for the root zone. Instead, DNS resolvers need to configure a trust anchor which authenticates the root zone KSK.
Generally speaking, there are three methods by which trust anchors are configured in resolvers:
- manually by a system administrator
- via updates provided by an operating system vendor
- through the protocol described in RFC 5011 (“Automated Updates of DNS Security (DNSSEC) Trust Anchors”)
We expect most resolvers will be updated through the RFC 5011 process, due to the fact that it is widely implemented in recursive resolver software and is most likely to result in an updated trust anchor before any of the other methods. RFC 5011 states that when a new KSK first appears, the resolver remembers it and marks it as a candidate for acceptance. If the KSK remains present (and authentic) in the DNS for at least 30 days, the resolver considers it a valid trust anchor and adds it to its permanent trust anchor configuration.
Observing the KSK Adoption Process in Real Time
Thanks to another DNS feature, described in RFC 8145 (“Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)”) and implemented by many recursive resolver products, we have some visibility into the adoption of a new KSK.
Resolvers that support RFC 8145 will periodically indicate which KSKs are in their trust anchor configuration. They do this by sending a specially formatted DNS query to the name servers of the zone for the corresponding trust anchor. In this case, it’s the root zone, and those queries are sent to the root name servers. As one of the 12 root server operators, Verisign receives these trust anchor signals on an ongoing basis.
It has now been more than 30 days since KSK-2024 was published in the root zone. DNS resolvers that have observed the new key since Jan. 11 should now accept and include it in their trust anchor configuration. In the graph below we can see that, indeed, 91.3% of resolvers now signal that they trust KSK-2024, which is directly in line with the adoption rate we observed at this same time during the last KSK rollover.
A few items to note in this graph:
First, note that 100% of resolvers have KSK-2017 configured as their trust anchor (green line at the top). We expect it to remain like that until after KSK-2017 is revoked in early 2027.
Second, we can see that quite a few resolvers still trust KSK-2010 (purple line), even though it was revoked in 2019. This is most likely due to its lingering presence in operating system software updates.
Third, we can see that a small population of resolvers began including KSK-2024 in their trust anchor configuration in July 2024, right after the key was published in the Internet Assigned Numbers Authority (IANA) trust anchor file on their website. We believe the operators for a small number of resolvers configured it manually.
Continued Uptake and Future Monitoring of KSK-2024 Adoption
At the time of this writing, uptake sits at just shy of 100 percent. But is it a cause for concern that adoption is not yet at a full 100 percent?
In short, the current adoption rate is not concerning. It’s important to remember that the KSK rollover plan includes a long pre-publish period – nearly two years long when all is said and done – and the key won’t be used for generating signatures until October 2026. That means that while some resolvers may not trust the new key yet, there is still plenty of time for all DNS resolvers to accept it, either via the RFC 5011 process, software updates, or manual configuration.
Verisign will continue to monitor the uptake of KSK-2024 through trust anchor signals and other means, and we’ll work closely with ICANN and other research partners to track its progress. All in all, we are highly optimistic about a successful rollover process that helps continue to keep the DNS secure, stable, and resilient, beginning with the publication of this new KSK in the root zone.
Footnotes
- The root zone KSK rollover is a multi-year process. This one began in April 2024 when the key was generated, hence the name “KSK-2024.” The next milestone is scheduled for October 2026 when the new key will first be used for generating signatures. ↩︎
