You Don’t Need a Locksmith: Preparing for the Root Zone Key-Signing Key (KSK) Rollover in October 2026

Introduction

If your outbound recursive DNS infrastructure is performing DNS Security Extensions (DNSSEC) validation (and if it isn’t, it probably should be), then you need to be aware of the upcoming rollover of the DNSSEC key-signing key (KSK) for the root zone on October 11, 2026. If this is new information to you, then you may be inclined to ask, what is the root zone key, and why do I care about it rolling over? If that is you, fear not, because I’m here to provide those answers and, if you happen to be an Infoblox customer, walk through what you need to do to be fully prepared.

Root Zone Key Review

To start, we’ll assume you are already familiar with what DNSSEC provides (data authenticity and integrity, but NOT encryption), and what signing and validating are. If you aren’t acquainted with those concepts, there are many resources available on the internet to get you up to speed. With that out of the way, let’s briefly cover what the root zone KSK is, where it comes from, and why it’s important. We will skip over some of the technical minutiae and focus on what you need to know for this upcoming event.

What Is the Root Zone KSK?

For DNSSEC-signed zones, there are usually two keys, a zone-signing key (ZSK) and a key-signing key (KSK). These keys are published in the zone as DNSKEY records. The ZSK is used to sign the resource record sets present in the zone, and the KSK is used to sign just the DNSKEY resource record set for the zone. A core component of DNSSEC is the concept of a chain of trust when it comes to validating DNS responses. The chain starts with what is called the “trust anchor,” which is a public key that has been explicitly configured as trusted in the validating DNS server and matches a DNSKEY (or DS) resource record present in the DNS zone the anchor is configured for (usually the root zone). Of the two types of keys, it is important to know that KSKs are used as trust anchors.

Where Does the Root KSK Come From?

There are multiple organizations (such as ICANN) and several individuals involved in generating and using the root KSK. There is a very formal, open and independently audited process for conducting signings with the root key, known as a Key Signing Ceremony. The individuals are involved in the ceremony as experts representing different areas of the technical community, and they each provide some component required to access the KSK, such as keys or smart cards. ICANN has an article that provides further details on the keys and ceremonies.

Why Is the Root KSK Important?

All validation within a validating DNS server is dependent upon the configured trust anchor(s); therefore, if the KSK for the Internet root zone is changed and the validating resolver is not aware of the new key, then after the rollover, DNSSEC validation will fail for all signed zones. Therefore, keeping up to date with the latest root KSK is an important part of a DNS administrator’s job when DNSSEC validation is being performed by the system. Fortunately, ICANN does a terrific job planning and publicizing such an important key rollover. For example, the new root KSK was created in April of 2024, first published by ICANN in July 2024, and it was added to the root zone on January 11, 2025, 21 months before the rollover.

What Do I Need to Do?

To address the main question you likely have at this point, what you need to do depends greatly on what type of DNS server(s) you are responsible for. For the purpose of this article, I’m going to focus only on the actions required for Infoblox customers. If you are using other products, you should consult information from your DNS platform vendor. The specific actions will depend on which Infoblox products you happen to be using.

• Infoblox Threat Defense™: For Threat Defense, no actions are necessary; Infoblox manages the underlying keys for the recursive DNS service.
• Infoblox Universal DDI™: For Universal DDI customers, Infoblox generally manages the root trust anchors on your behalf (unless you manually configure root trust anchors in your configuration for some reason). Configuration bundles generated after July 2026 will have the new key automatically added to them, so administrators should validate that a new config bundle has been applied to their on-prem devices before October. For example, if an administrator updated their global configuration, the new keys would be added to the bundle for that configuration change. In addition, Infoblox expects to be able to force-push configuration updates to add the keys in September.
• NIOS: For NIOS customers, there are a few things that the administrator will need to do, so we will run through those in detail.

NIOS Preparation for Root KSK Rollover 2026

If you are using NIOS as your DNSSEC validating resolver, then you have two options to add the new trust anchor alongside the existing one before October 11. The first is to apply the NIOS hotfix designed to update the trust anchor that is available from the Infoblox knowledge base article. The second is to manually add the new trust anchor. One quick note, because this requires a DNS service restart, please follow the appropriate change control procedures, if any, applicable to your environment. For those that wish to take care of it themselves, let’s walk through the pre-rollover actions step by step:

• Get the root trust anchors from IANA. While I could give them to you, it is a best practice to get it from the source.

  • Note that the key tag (sometimes referred to as “key id”) for the new key is 38696, versus the old 20326 (for KSK-2017).
  • You can see the key tag (labeled as “key id”) if you query for the root DNSKEY records via the command: dig . dnskey +multiline

• Log in to your Grid Manager interface and navigate to Data Management -> DNS, and from the toolbar on the right side select the button for Grid DNS Properties.

• 
  

  If you do not see DNSSEC in the list on the left side of the pop-up window, select the button near the top on the left side to Toggle Advanced Mode on, and when you can see DNSSEC, select that.

• 
  

  In the DNSSEC section, scroll down to where you see TRUST ANCHORS, and if both Enable DNSSEC at the top and Enable DNSSEC validation just above the trust-anchor heading are checked then you should see an entry for the zone “.”, which represents the root zone.

  • NOTE: If you don’t see any trust anchors listed, then you aren’t currently performing validation, because you can’t validate without at least one trust anchor. In that case, you will need to add both trust anchors to the configuration if you want to start performing validation.

• Press the + button for the trust anchors panel, which will add a new line for a trust anchor.

• 

  For the Zone, put in “.”, make sure that Secure Entry Point is checked, make sure that Responses Must Be Secure is NOT checked, select the correct algorithm, RSA/SHA-256 (8), and then add the new trust anchor information in the Public Key field.

  • NOTE: It is critical that the Responses Must Be Secure box is not checked, because if it is, then all queries for non-signed zones will fail, and, unfortunately, the internet isn’t quite ready for that yet.

    

• Click Save & Close.

• When the restart banner appears, restart services.

• After the restart, try looking up a domain name in a zone that you know is signed and ensure that it is validated properly, by ensuring the “ad” flag is present in the dig output.

  • One example query you could use: dig @<DNS server IP> www.ietf.org. +dnssec
  • Thus, if your DNS server is 192.0.2.100, it would look as follows: dig @192.0.2.100 www.ietf.org. +dnssec
  • If there is a problem with the configuration, it would manifest as a SERVFAIL response to that query along with any other queries for domain names in signed zones.

NIOS Post-Rollover Cleanup

As a part of the rollover, the old root KSK, KSK-2017, will stop signing the root zone in October. KSK-2017 is scheduled to be marked as revoked in January 2027 and removed from the root zone thereafter. Any changes to this would be announced on ICANN’s KSK Rollover page, so that is worth watching.

Assuming everything is rolled over successfully, at some point between November and January you should remove the KSK-2017 trust anchor from your NIOS configuration to avoid wasting DNS server resources on an expired key. This can be done by simply navigating to the Grid DNSSEC Trust Anchor configuration (see above) and instead of adding a trust anchor, deleting the old one (please double-check it is the old one you are removing, the first 10 characters of KSK-2017 are AwEAAaz/tA), clicking Save & Close and restarting services (as noted above, please follow any applicable change procedures).

Will There Be Future Root KSK Rollovers?

While this upcoming rollover is important, it is also important to take into account that there will be other rollover events in the future, with ICANN roughly targeting a three-year rollover cadence. Given that target, the next rollover would likely be in 2029. It is also worth noting that there is a proposal working through the community process to shift from the current RSA-SHA256 algorithm (algorithm 8) to ECDSA P-256 with SHA-256 (algorithm 13) instead, which would also require a rollover. If ICANN moves forward with the algorithm change, the algorithm rollover could be aligned with one of the target KSK rollover windows. The details of future rollover events are outside the scope of this article, but it is good to be aware that there will be future events you will also need to recognize and prepare for.

Conclusion

Hopefully now you have a better understanding of what the upcoming root KSK rollover is, why it is important and what you may (or may not) need to do to be prepared for it. If you have any questions, please reach out to your Infoblox account team for further information.