DNSSEC root key rollover is set for October 2026

The DNSSEC root key rollover scheduled for October 11, 2026 is a date every organisation running a validating DNS resolver should have on its change calendar. DNSSEC, short for Domain Name System Security Extensions, is the system that lets a DNS resolver check that a DNS answer is authentic and has not been tampered with. It does not encrypt DNS traffic, but it does help stop forged DNS data from being accepted as real.

The change concerns the key-signing key, or KSK, for the internet root zone. In DNS, the root zone sits at the top of the naming system and helps direct queries toward domains such as .org, .com and country-code domains. For zones signed with DNSSEC, two keys are usually involved. A zone-signing key, or ZSK, signs the sets of DNS records inside the zone. A key-signing key signs the DNSKEY record set, which is the published set of DNSSEC keys for that zone.

The reason the root KSK matters is the DNSSEC chain of trust. A validating DNS server starts from a trust anchor, meaning a public key that has been deliberately configured as trusted. That trust anchor normally matches a DNSKEY or DS record for the zone it applies to, usually the root zone. KSKs are the keys used as trust anchors. If the root KSK changes and a validating resolver does not know about the new key, validation can fail for signed zones after the rollover.

ICANN is one of the organisations involved in generating and using the root KSK, and the process includes several individuals from different parts of the technical community. The root key is handled through a formal, open and independently audited process known as a Key Signing Ceremony. Participants provide different components needed to access the KSK, such as keys or smart cards. ICANN has published more background on DNSSEC key signing ceremonies.

The 2026 rollover has been prepared well in advance. According to Infoblox, the new root KSK was created in April 2024, first published by ICANN in July 2024, and added to the root zone on January 11, 2025. That placed it in the root zone 21 months before the October 11, 2026 rollover. The practical aim is simple: validating resolvers should have both the old and new trust anchors in place before the old key stops signing.

What administrators need to do depends on the DNS platform they run. Infoblox states that no action is needed for Infoblox Threat Defense, because the underlying keys for its recursive DNS service are managed by Infoblox. For Infoblox Universal DDI, Infoblox says it generally manages root trust anchors for customers unless administrators have manually configured root trust anchors. Configuration bundles generated after July 2026 will automatically include the new key, so administrators should confirm that a new configuration bundle has been applied to on-premises devices before October. Infoblox also says it expects to be able to force-push configuration updates to add the keys in September.

For NIOS deployments that perform DNSSEC validation, Infoblox describes two ways to add the new trust anchor before October 11. Administrators can apply the NIOS hotfix intended to update the trust anchor, available through the Infoblox knowledge base, or they can add the new trust anchor manually. Infoblox notes that the change requires a DNS service restart, so normal change-control procedures should be followed.

For a manual NIOS update, Infoblox advises getting the root trust anchors from IANA rather than copying them from another source. The new key tag, sometimes called the key id, is 38696. The old KSK-2017 key tag is 20326. Administrators can see the key tag by querying the root DNSKEY records with the command dig . dnskey +multiline. The IANA trust anchor information is the authoritative place to retrieve the root trust anchors.

In NIOS, the work is done in Grid Manager under Data Management, DNS, then Grid DNS Properties. If DNSSEC is not visible in the left-hand list, administrators should switch on Advanced Mode and then select DNSSEC. In the DNSSEC section, if Enable DNSSEC and Enable DNSSEC validation are both checked, there should be a trust-anchor entry for the zone “.”, which represents the root zone. If no trust anchors are listed, the resolver is not currently validating, because validation needs at least one trust anchor. An administrator who wants to start validating would need to add both trust anchors.

When adding the new trust anchor, Infoblox says the zone should be “.”, Secure Entry Point should be checked, Responses Must Be Secure should not be checked, the algorithm should be RSA/SHA-256 (8), and the new public key should be entered in the Public Key field. The warning about Responses Must Be Secure is important: if it is checked, queries for zones that are not signed will fail, and the internet is not fully ready for that setting. After saving the change and restarting services, administrators can test a signed domain and check that the “ad” flag appears in dig output, for example by querying www.ietf.org with +dnssec. Infoblox says a bad configuration would show up as a SERVFAIL response for that query and other queries for signed zones.

There is also cleanup work after the rollover. Infoblox says KSK-2017 will stop signing the root zone in October, is scheduled to be marked as revoked in January 2027, and will be removed from the root zone after that. Any change to that plan would be announced on ICANN’s KSK rollover page. If the rollover succeeds, Infoblox says NIOS administrators should remove the KSK-2017 trust anchor between November and January to avoid wasting DNS server resources on an expired key. It identifies the first 10 characters of KSK-2017 as AwEAAaz/tA, which can help administrators avoid deleting the wrong key.

This will not be the last such event. Infoblox says ICANN is roughly targeting a three-year rollover cadence, which would make the next rollover likely in 2029. It also notes that a community proposal is working through a process to move from RSA-SHA256, algorithm 8, to ECDSA P-256 with SHA-256, algorithm 13. If ICANN proceeds with that algorithm change, it could be aligned with a future KSK rollover window.

For website owners and everyday users, the main lesson is to know who runs the DNS resolver you rely on and whether they maintain DNSSEC validation correctly. For readers choosing a resolver rather than running one, AEU DNS is a private, secure DNS for everyone, which is relevant because the resolver is the point where DNS answers are looked up and checked. Administrators running their own validating resolvers should treat the October 2026 rollover as planned maintenance, not an emergency, and put the new trust anchor in place before the deadline.