Root KSK Rollover 2026: Why DNSSEC Validation Dipped in Egypt and a DNS Resolver Checklist for Companies Before 11 January 2027

Quick answer: On 11 October 2026 a new key called KSK-2024 (key tag 38696) began signing the DNS root zone, replacing KSK-2017. The root KSK rollover went through worldwide without a major outage, but APNIC measurements placed Egypt among the economies with the largest drop in DNSSEC-validating users, about 301,000 users. If your company or clinic runs an internal DNS server or a firewall that validates DNSSEC, confirm that key 38696 is trusted before the old key is revoked on 11 January 2027.

This guide looks at the root KSK rollover from the point of view of companies and clinics in Egypt: what actually changed, what the numbers say about the Egyptian market, how an IT team can check its servers in under an hour, and which upcoming dates belong on the maintenance calendar.

What is the root KSK rollover?

The root Key Signing Key (KSK) is the cryptographic key that serves as the trust anchor for the Domain Name System Security Extensions (DNSSEC). Every DNS resolver that validates signatures starts its chain of trust from this key, then moves down to top-level domains such as .com and .eg, and finally to your own domain.

A rollover is the replacement of that key with a new one on a pre-announced schedule. According to ICANN's guide published on 27 July 2026, the root zone has been signed since 2010 and uses two kinds of keys: zone-signing keys (ZSKs), replaced every three months, and a longer-lived KSK that signs the key set itself. The first root KSK rollover took place in October 2018. This is the second one, and the first to follow the idealized three-year cycle described by IANA.

The official rollover timeline

Source: IANA's DNSSEC Trust Anchors and Rollovers page, which lists KSK-2024 as the active key with tag 38696 and KSK-2017, tag 20326, as a post-publication key that "remains a valid trust anchor".

What happened in Egypt? Reading APNIC's numbers after the rollover

On 21 October 2026, researcher Geoff Huston published "Rolling the root key: What happened?" on the APNIC Blog, based on APNIC's advertisement-based measurement network. The key findings:

• The global average DNSSEC validation rate rose from 39.7% before the roll to 40.6% after it, and the analysis concluded that the roll was a success with no major DNS outage.
• Of 13,538 measured networks, 58 saw their validation rate fall by 50% or more, and 660 saw it fall by 10% or more.
• Egypt appears in Table 2, the economies with the largest drop in DNSSEC-validating users: an estimated 63,180,212 users in total, with estimated validating users falling from 47,591,181 before the roll to 47,290,182 after it, a difference of 300,999 users.

A simple calculation from APNIC's own figures shows that about 75% of Internet users in Egypt sit behind DNSSEC-validating resolvers, well above the global average. In other words, most Egyptian users came through the rollover safely; the drop equals only about 0.6% of validating users in Egypt, but it also shows that specific networks were not ready.

Important caveat: these are statistical estimates. They do not name Egyptian networks or providers, and they do not prove that the whole drop was caused by the rollover alone. On 15 October 2026 ICANN also said it was aware of reports of issues affecting "a limited number of systems" and was still assessing their relationship to the rollover.

Why the root KSK rollover concerns your company, not only your ISP

Most home users rely on their ISP's resolvers, but companies and clinics often run their own resolvers without realizing it. Common places where a DNSSEC-validating resolver hides:

• Windows Server machines running the DNS role inside Active Directory environments.
• Firewalls and UTM appliances that provide DNS to devices on the internal network.
• Linux servers or VPS instances running BIND, Unbound, Knot Resolver or PowerDNS Recursor.
• Containers and applications that use a resolver set at build or deployment time, or rely on DNS-over-HTTPS, a case ICANN's guide explicitly warns about.
• Servers and virtual machine images restored from old backups whose trust anchor contains only key 20326.

ICANN's guide "What to Expect During the Root KSK Rollover" explains that an unprepared resolver starts failing within 48 hours of the rollover, because the root key set has a 48-hour TTL. Symptoms include web pages that do not load or load only partially, email that stops arriving, and automated systems that can no longer reach cloud services. If the network mixes prepared and unprepared resolvers, failures can be intermittent, which makes them harder to diagnose.

For clinics in particular, this means a cloud booking system, a payment gateway or a lab integration might stop working from inside the clinic while working normally on a staff member's phone over mobile data, so time is lost hunting for an application bug when the real problem is DNS.

Smart One Group's KSK-2024 checklist: the four-layer framework

This framework was prepared by the Smart One Group team. Its goal is to help an IT team cover every risk point in under an hour of work, based on ICANN and IANA recommendations.

Layer 1: Does the resolver validate DNSSEC at all?

ICANN recommends a simple test using dnssec-failed.org, a test domain deliberately built to fail validation. Run dig @ADDRESS dnssec-failed.org a +dnssec, replacing ADDRESS with your resolver's address:

• If the status is SERVFAIL, the resolver validates DNSSEC; move on to Layer 2.
• If the status is NOERROR, the resolver does not validate and was not affected by the rollover, but you should decide whether to enable validation in the future.

Layer 2: Is key 38696 in the trust anchor?

ICANN's rollover page asks resolver operators not to assume that automatic updates succeeded and to verify for themselves that KSK-2024 is present. Here is where to check in the most common software:

Layer 3: Applications, containers and backups

1. Review container and application configuration to find the resolver actually in use, which may differ from the operating system's resolver.
2. Check any system image or backup created before February 2025 before restoring it, because its trust anchor may contain only the old key.
3. Add a key 38696 check to the build procedure for every new server.

Layer 4: Monitoring and an emergency plan

• Watch resolver logs for sudden spikes in SERVFAIL responses, the first warning sign of failed validation.
• If a failure happens, ICANN's guide says the operator may temporarily disable validation or configure a negative trust anchor for the root zone (RFC 7646), then install KSK-2024 as soon as possible and turn validation back on.
• Document these steps in your runbook so a temporary workaround does not become a permanent state.

What comes next: 11 January and 22 March 2027

The rollover cycle is not over. On 11 January 2027 the old key will be published with the REVOKE bit, and on 22 March 2027 it will be removed from the root. Prepared resolvers need no action, but we recommend treating the January date as a second checkpoint. There is no need to delete KSK-2017 manually ahead of schedule; IANA currently describes it as a valid trust anchor. And since IANA plans an idealized three-year cycle, it makes sense to put a trust anchor review on your recurring maintenance calendar.

It is important to separate two things: the root key rollover concerns resolvers that validate signatures, while signing your own domain concerns your domain's authoritative servers. We covered the second side in our article on DNSSEC status for .eg domains and a company DNS checklist. If your DNS servers run on an old Windows release, also see our Windows Server 2016 end-of-support plan.

How Smart One Group can help

Our team can run the four-layer check on your servers, firewall and applications, and document the results and an emergency plan, as part of our hosting and server services and technical support contracts. We also help manage domains and DNS settings, and review DNS configuration inside the custom systems we build for clinics and companies. For a quick check of your environment, get in touch.

Frequently asked questions

Do I need to do anything if everything has worked since 11 October 2026?

Probably not, because the 48-hour failure window ended on 13 October 2026. The risk remains, however, when you restore a server from an old backup or install a new device with outdated settings, so run the Layer 2 check once and document the result.

What is the key tag of the new root KSK?

The new key is KSK-2024 with key tag 38696, and it began signing on 11 October 2026. The previous key, KSK-2017, has key tag 20326 and signed the root from 11 October 2018 to 11 October 2026.

Does the root key rollover mean I must change DNSSEC settings for my .eg or .com domain?

No. The root key concerns resolvers that validate signatures; it does not change your domain's keys or its DS records at the registrar.

What are the symptoms of a DNS resolver that is not ready for the new key?

According to ICANN: web pages that do not load or load partially, email that does not arrive, automated systems that stop working, and possibly intermittent failures if the network uses more than one resolver. The clearest technical sign is SERVFAIL responses for healthy domains.

Is disabling DNSSEC validation a permanent fix?

No. ICANN treats it as a temporary step to stop the outage immediately, followed by installing KSK-2024 and re-enabling validation, because validation protects your users from forged DNS responses.

When is the next root KSK rollover?

IANA plans an idealized three-year cycle, with each new key published about two years before it is used. We found no official date for the next rollover at the time of writing, so follow ICANN's root KSK rollover page.