https://www.icann.org/en/system/files/files/ksk-rollover-expect-27jul26-en.pdf
Every three years, the cryptographic key used to secure the DNS root zone (Root Zone Key Signing Key (KSK)) changes in a rollover event to boost security on the internet. First successfully conducted in October 2018, the COVID-19 pandemic delayed the scheduled rollovers until now. The next one will take place this year in October.
But what is a cryptographic key? Why is it important? And what does this mean for internet users across the globe?
Let’s discuss all of these questions, along with steps on how to check if you will need to do anything to keep the rollover from disrupting your internet experience.
What is a Cryptographic Key and Why is it Important?
A cryptographic key is a parameter used with a cryptographic algorithm to determine its operation so that an entity without the key cannot reproduce or reverse the operation. In a sense, it’s a security measure to authenticate actions on the internet and keep you safe from predatory behavior. In Domain Name System Security Extensions (DNSSEC), the Zone Signing Key (ZSK) and the Key Signing Key (KSK) are cryptographic keys that work together to protect a DNS zone’s records to build a verifiable chain of trust back to the DNS root.
What’s the difference? It’s quite simple: the ZSK signs the actual DNS records in the zone – things such as A, MX, and CNAME records – to produce Resource Record Signature (RRSIG) records. This allows the resolver to confirm those records haven’t been tampered with. The KSK, meanwhile, doesn’t sign ordinary records directly. Instead, it signs the zone’s DNSKEY record set, which is what publishes the ZSK.
Basically, the KSK vouches for the ZSK’s authenticity, and the ZSK proves that a record hasn’t been tampered with.
While they work together, the separation between these two functions exists mainly for operational convenience. The ZSK handles high-volume, routine signing, meaning it needs to be rotated more frequently and can be swapped out with less disruption to users. Usually, the ZSK is rotated every few months, if not more often. The KSK is rotated less often – every one to two years – as it’s used far less often and is published in the parent zone to anchor the chain of trust. This process takes more care, since changing it requires coordination with the parent zone.
In October 2026, the Root KSK will rollover, which, as discussed above, is a much bigger deal than when the ZSK changes. Most users won’t notice an interruption in service because many resolver operators have manually upgraded their trust anchor from KSK-2017 to KSK-2024. If your resolver operator has not performed this upgrade, make sure it gets done before October to keep your service running.
Does a Secure64 Deployment Need to be Amended to Support the October 2026 KSK Rollover?
If you’ve configured your Secure64 deployment correctly, then you don’t need to do anything! Keep using your deployment as you always have. We’ve got you covered.
In some cases, you may notice log messages that reference failures. This might mean that your deployment was misconfigured in some way. Don’t worry! We’re here to help make sure this transition is as smooth as possible. There are a few simple steps to follow if you want to double-check your deployment:
- Check whether DNSSEC validation is operational using the following command:
dig @127.0.0.1 com. SOA +dnssec- Replace the @127.0.0.1 with the IP address of the DNSSEC resolver.
- The output should look like this:
; <<>> DiG 9.16.23-RH <<>> @127.0.0.1 com. SOA +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43362
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;com. IN SOA
;; ANSWER SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1786525119 1800 900 604800 900
com. 900 IN RRSIG SOA 13 1 900 20260819085839 20260812074839 41446 com. eJcLQAuW+9PcCXndk2h4VpSjnzvibfXUbqQFHAo6dWrCwMlwUvxLzjJi cuj2Hbvwo3i+GcYnBz7S+w0lqkwkKg==We have highlighted the AD bit as this is the important information.
- Run the following command to create a trust anchor file:
sudo s64unbound-anchor -a "/etc/unbound/root.key" Please make sure this file is readable by the process
- In our example, the file contains the following:
cat /etc/unbound/root.key
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1786525142 ;;Wed Aug 12 09:59:02 2026
;;last_success: 1786525142 ;;Wed Aug 12 09:59:02 2026
;;next_probe_time: 1786567136 ;;Wed Aug 12 21:38:56 2026
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
. 86400 IN DNSKEY 257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc= ;{id = 38696 (ksk), size = 2048b} ;;state=1 [ ADDPEND ] ;;count=2 ;;lastchange=1786524725 ;;Wed Aug 12 09:52:05 2026
. 86400 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1786524725 ;;Wed Aug 12 09:52:05 2026 Please check for the DNSKEY line with the ID = 38696
Assuming you have this ID, the rollover will work when the change happens.
