Root KSK Rollover 2026: Prepare Your DNS Resolvers 

The 2026 Root Zone KSK rollover is a scheduled DNSSEC change that every operator of validating DNS resolvers should prepare for. Most properly updated resolvers should transition without any visible effect, but operators should verify their readiness rather than assume that an automatic update succeeded.

Key Takeaways

• On 11 October 2026, KSK-2024, key tag 38696, is scheduled to become the only key signing the root DNSKEY record set.
• Every DNSSEC-validating resolver must have KSK-2024 in its active trust-anchor configuration. Seeing the key in a DNS response is not enough.
• EfficientIP customers should install the applicable SOLIDserver maintenance release. If it cannot be installed before the rollover and KSK-2024 is absent, contact EfficientIP Support for the supported manual update procedure.

What Changes on 11 October 2026?

DNSSEC, the Domain Name System Security Extensions, provides authentication and integrity checks for DNS data through digital signatures. A validating resolver checks those signatures to determine whether DNS data is authentic.

The private component of the root Key Signing Key, or KSK, signs the root DNSKEY record set, which contains the root zone’s public keys. A trust anchor is a trusted public key, or its digest, configured as the starting point for DNSSEC validation. The resolver needs that trusted starting point to authenticate the keys and signatures it receives.

According to IANA’s rollover schedule, KSK-2024 was published in the root zone on 11 January 2025. On 11 October 2026, it is scheduled to replace KSK-2017, key tag 20326, as the key signing the root DNSKEY record set.

This is a planned key replacement, not an algorithm migration: both keys use 2048-bit RSA/SHA-256. ICANN’s rollover FAQ explains why proactive key changes are preferable to emergency replacements.

Why DNS Resolver Operators Need to Check

The relevant question is where DNSSEC validation occurs, not where a DNS server is hosted. A forwarder that does not perform validation on a particular query path does not need its own trust-anchor change for this event. However, its service may still depend on a validating upstream resolver that must be prepared.

Start with your DNS architecture inventory. Include production resolvers, branch deployments, cloud instances and recovery systems. For each one, record where validation occurs, how trust anchors are maintained and how readiness will be verified. Check individual service instances and representative query paths rather than assuming that one successful test covers the entire deployment.

An unprepared validator can start returning SERVFAIL when it can no longer authenticate the root DNSKEY record set. The effect may be delayed by caching. ICANN’s operational guide notes that the root DNSKEY record set has a 48-hour time to live, so failures need not begin at the moment of the rollover.

Increase DNS operational monitoring before the change and for at least 48 hours afterward. Watch for DNSSEC validation errors, changes in SERVFAIL rates and resolution failures, and test the service from representative client paths. A running DNS process is not proof that its answers remain usable.

Automatic Updates Still Need Verification

RFC 5011 defines automatic trust-anchor updates that use an already trusted key to authenticate its successor. Its Add Hold-Down Period is 30 days or the original DNSKEY record set TTL, whichever is greater. The resolver must then retrieve and validate the record set again before accepting the new key. Resolvers that observed KSK-2024 from its initial publication should have begun trusting it from 10 February 2025.

That opportunity for automatic learning is not evidence that it succeeded everywhere. ICANN explicitly asks resolver operators to verify that KSK-2024 is present in their trust-anchor configuration rather than assume automatic updates worked.

With the signing change approaching, a resolver that still lacks KSK-2024 should not rely on simply enabling automatic updates. Follow the resolver vendor’s supported software-update or recovery procedure immediately.

How EfficientIP Customers Should Prepare

Install the Applicable Maintenance Release

For EfficientIP customers, the standard preparation is to install the applicable SOLIDserver maintenance release: 9.1.1 or 8.4.11. A separate manual key import is not required when using this supported maintenance path.

Customers running earlier releases should first move to the latest supported 8.x release; if they then move to 9.x, they should continue to the latest supported 9.x release. Include every appliance providing validating DNS in the maintenance plan, then verify its trust-anchor configuration and DNSSEC resolution behavior after the update. If neither the upgrade nor the manual trust-anchor addition described below can be completed or verified, contact EfficientIP Customer Support.

Add and Assign the Trust Anchor Manually When Needed

If the applicable maintenance release cannot be installed before the rollover and KSK-2024 is absent, obtain the trust anchor from IANA’s official DNSSEC Trust Anchors and Rollovers page and follow the manual addition and assignment procedure in the next section.

In SOLIDserver, trust anchors are managed under DNS → Zones → All zones → All DNSSEC keys. After adding KSK-2024, assign it to every relevant validating DNS server and confirm that the intended servers appear in the trust anchor’s assignments (in the “DNS servers using this Trust Anchor” section”.

Adding the trust anchor to the database is not the same as assigning it to a resolver. In centrally managed or template-based deployments, verify that the change reaches every intended service instance.

Keep the existing KSK-2017 trust anchor during preparation. Adding its successor is not a reason to remove the key that currently supports validation. Follow EfficientIP Support guidance for its later retirement.

How to Verify Your Resolver Trusts KSK-2024

A successful DNSKEY lookup shows which keys were returned, not which keys the resolver has accepted as trust anchors. Readiness requires checking the active trust-anchor configuration, not just DNS data availability.

The community-review check_ksk script can provide an additional external test. It uses the root key sentinel mechanism defined in RFC 8509. The script first tests validly signed and deliberately bogus names in published Root Canary measurement zones, then applies sentinel tests only where that baseline behaves as expected.

The result applies to the tested query path and does not directly inspect resolver configuration. Mixed or indeterminate results can occur with resolver farms, service VIPs, forwarding paths or inconsistent resolver instances. Investigate such results through direct configuration checks.

The script is a community-review utility, not a replacement for checking each resolver’s configuration. Feedback from the DNS community is welcome, particularly on unexpected results and different resolver architectures. Join the conversation on Mastodon.

For further background, ICANN’s 26 August 2026 EMEA webinar provides a recording and slides covering the rollover.

Conclusion

Before 11 October 2026, confirm that KSK-2024 is trusted by every validating resolver and address any gaps. For EfficientIP customers, the preferred path is the applicable SOLIDserver maintenance release. Use the supported manual procedure only when the update cannot be installed in time and the new trust anchor is absent.

Treat readiness as a verified configuration, not an assumption about automatic updates, and continue monitoring throughout the 48 hours following the signing change.