nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Trending KB Articles

DNSSEC Root Zone KSK Rollover 2026: Required Actions for NIOS DNSSEC-Validating Resolvers

Executive Summary

ICANN is scheduled to roll over the DNS root zone Key Signing Key (KSK) on 11 October 2026. Customers using Infoblox NIOS as a DNSSEC-validating recursive resolver should verify that their resolvers trust the successor root KSK before that date. If a validating resolver does not trust the successor root KSK after the rollover, DNSSEC validation can fail. In practice, this may cause DNS lookups for signed domains to return SERVFAIL, which can then impact applications and services that depend on successful name resolution. Based on current product guidance, the primary area of customer action is NIOS deployments that perform DNSSEC validation and rely on manually managed trust anchors. NIOS-X and Universal DDI are not expected to require the same manual steps for updating the trust anchor.

For NIOS-X / Universal DDI, refer to KB NIOS-X - DNSSEC Root Zone KSK Rollover in October 2026.

Timeline in UTC

26 April 2024: ICANN generated the successor root KSK (KSK-2024).
11 January 2025: KSK-2024 was prepublished so validating resolvers could begin learning or receiving the new trust anchor.
11 October 2026: The root zone is scheduled to begin using only KSK-2024 for signing.
11 January 2027: KSK-2017 is scheduled to be revoked/retired.

Potentially affected

NIOS deployments that perform DNSSEC validation
NIOS deployments where root trust anchors are configured manually
NIOS resolvers that have not received the successor root KSK through software updates, hotfixes, or manual trust-anchor maintenance

Potentially not affected

NIOS-X
Universal DDI
NIOS deployments that do not perform DNSSEC validation

Why is this important?

DNSSEC-validating resolvers use the root trust anchor as the starting point of the DNSSEC chain of trust. After the October 2026 rollover, resolvers that do not trust the successor root KSK may be unable to validate DNSSEC signatures.

When this happens, DNS lookups can fail even when the destination service itself is healthy. Customers may observe SERVFAIL responses, intermittent or persistent application reachability issues, and other symptoms that appear to be DNS outages.

How to determine whether you are affected

You may be affected if your NIOS deployment performs DNSSEC validation and relies on manually configured root trust anchors.

DNSSEC-validating resolvers must trust the current root zone Key Signing Key (KSK) in order to validate signed DNS responses. If a validating resolver does not recognize the new root KSK after the rollover, DNSSEC validation may fail.

Check 1: Is DNSSEC Validation Enabled?

Determine whether the NIOS appliance is configured as a DNSSEC-validating recursive resolver.

If DNSSEC validation is not enabled, the rollover is not expected to impact DNS resolution through that resolver.

Check 2: Does the Resolver Use a Root Trust Anchor?

Determine whether the resolver has a trust anchor for the DNS root zone (.).

Resolvers that validate DNSSEC-signed responses depend on this trust anchor as the starting point of the chain of trust. If the resolver does not recognize the successor root KSK when the rollover occurs, validation can fail.

How to verify the current configuration in Grid Manager

Use this method to verify whether DNSSEC validation is enabled and whether a root trust anchor is configured:

Log in to Grid Manager.
Go to Data Management > DNS.
Open Grid DNS Properties.
If Advanced Mode is not enabled, enable/toggle Advanced Mode.
Select DNSSEC.
Verify that Enable DNSSEC is selected.
Verify whether Enable DNSSEC validation is selected.
Scroll to the Trust Anchors section.
Verify whether a trust anchor exists for the root zone, represented as a single dot: . .
Verify that the configured root trust anchor matches the current root trust-anchor information published by IANA.

If DNSSEC settings are overridden at the member level, verify the same DNSSEC validation and trust-anchor settings on each DNS member that performs recursive validation.

If DNSSEC settings are overridden at the DNS View level, go to Data Management > DNS > Zones (or DNS Views), select the applicable DNS View, and click Edit. Review the inherited DNSSEC settings and click Override when a view-specific configuration is present. Verify Enable DNSSEC validation and the root-zone trust anchor for each DNS View that serves recursive clients.

What happens if no action is taken?

If an affected validating resolver does not trust the successor root KSK by the rollover date:

DNSSEC validation failures may occur.
DNS queries for DNSSEC-signed domains may return SERVFAIL responses.
Applications that rely on successful DNS resolution may experience connectivity issues.

Required Actions

For NIOS DNSSEC-Validating Resolvers

Review the resolver's trust-anchor configuration and ensure that support for the new root KSK is available before the rollover date.

Customers should:

Identify all NIOS systems performing DNSSEC validation.
Review trust-anchor configuration on those systems.
Apply the applicable Infoblox hotfix for your NIOS version.
After applying the hotfix, verify that DNSSEC validation continues to function as expected.

Hotfix Guidance

For deployments requiring the generic hotfix to add the new root trust-anchor key, the hotfix file and associated release form are attached to this KB in the Support Portal. Review the release form and follow the documented installation procedure before applying the generic hotfix.