DNSSEC explained simply: what it is and why the 11 October key rollover affects you

On Sunday, 11 October 2026, at 14:00 UTC, something happened that 99% of Internet users didn't notice—but something that anyone managing domains and servers ought to have checked. The key that signs the DNS root zone changed. If you're not a sysadmin, you're probably still wondering what that means. Let's explain it without unnecessary acronyms.

What DNSSEC is, in practice

DNS translates a domain name into an IP address. Fundamentally, this response is unsigned: anyone who can insert themselves into the path between you and the DNS server can feed you a false address, and you'd have no way of knowing. DNSSEC (DNS Security Extensions) adds a digital signature to that response. It doesn't encrypt anything or hide traffic—it simply guarantees that the response you received is the one published by the domain owner and hasn't been tampered with along the way.

The signature works in a chain: your domain signs its own records with a key, that key is itself guaranteed by the domain one level up (e.g. .it, .com), which is guaranteed by the DNS root zone—the one that has nothing above it. The key that signs the root is called the KSK, or Key Signing Key. If that key changes, the entire chain must update accordingly.

Why 11 October matters even if you don't work with DNS

On 11 October 2026 at 14:00 UTC, KSK-2024 began signing the root DNS zone as planned, according to ICANN. The new key has key tag 38696 and replaces the previous root zone key, identified by key tag 20326 (KSK-2017). This wasn't a sudden surprise: this process replaces the existing trust anchor (KSK-2017) with a new one (KSK-2024), which was published in the root zone in February 2025 to give resolvers time to update before the actual changeover.

For the general public, if everything works correctly, nothing changes: you browse as before. The problem affects anyone running a DNSSEC-validating DNS resolver (a corporate recursive DNS server, an ISP, a hoster) who hasn't updated the trust key. In that case, if the DNSSEC-validating resolver doesn't have KSK-2024 configured, complete DNS resolution failures occur, cutting users off from the Internet. At the moment, no widespread operational outages have been reported, but ICANN has nonetheless urged verification.

The official advice, aimed squarely at those managing resolvers: verify that KSK-2024 (key tag 38696) is present in your trust anchor configuration, without taking it for granted that automatic updates succeeded. For those using common DNS software, the files to check are bind.keys for ISC BIND, root.key for Unbound and PowerDNS Recursor, and root.keys for Knot Resolver.

Anyone wanting the technical details of the rollover, including phases, will find them in our in-depth article already published on UptimeMag covering the KSK changeover.

How to verify whether your domain is signed with DNSSEC

You don't need to install anything special—just dig, which is already present on almost every Linux/Unix system and downloadable on Windows. The basic command is:

dig +dnssec yourdomain.it +short

If the domain is signed, the results include an RRSIG record, the actual signature. If the response lacks signatures, the domain doesn't have DNSSEC active.

To understand whether verification (not just the presence of a signature) is working properly, it's worth checking the flags in the full response:

dig yourdomain.it +dnssec

In the ;; flags: line, the letter ad (Authenticated Data) should appear: it's a signal that the resolver has validated the entire chain of trust, from the root down to your domain. If it's missing, or if the query returns a SERVFAIL error, you can isolate the problem by temporarily disabling validation with the +cd option:

dig yourdomain.it +dnssec +cd

If +cd returns a normal response while it fails without it, the problem lies in the DNSSEC chain: expired key, misaligned DS record at the registrar, or—as happened in recent days—a resolver that hasn't yet updated its root key.