The Domain Name System was built in the 1980s with no authentication at all. Anyone positioned between a client and an authoritative nameserver can tamper with responses and redirect traffic, which is exactly what DNSSEC was designed to fix. It adds cryptographic signatures to DNS records so resolvers can verify that the answers are legitimate and unmodified.
The concept is sound, but deployment has been slow and uneven.
Nearly 28 years after the first DNSSEC RFC, the global DNSSEC validation rate sits at about 35%, while HTTPS, which is roughly the same age, covers more than 95% of web traffic.
That gap raises an obvious question, and the answer comes down to how each protocol was designed, deployed, and incentivised.
DNSSEC requires coordination across four independent parties: the domain registry, the registrar, the authoritative DNS server operator, and the recursive resolver operator. A break at any point in this chain of trust invalidates the whole thing. For many organisations, deploying DNSSEC means consolidating DNS providers to a compatible vendor, which is a tangible cost weighed against a threat most teams consider hypothetical.
The protocol also adds ongoing operational burden: key rotation, signature renewal, TTL management. Each is a potential failure point, and unlike most DNS misconfigurations, a DNSSEC error doesn't degrade gracefully. A validating resolver that encounters an invalid signature returns SERVFAIL, which means the website doesn't load slowly, it doesn't load at all.
The failure record speaks for itself. Research published at ACM's Internet Measurement Conference in 2025 found that key validation failures and expired signatures account for over 70% of all bogus DNSSEC states, with 18% of affected domains remaining broken long after the initial error.
The Slack incident is worth examining in detail. Their infrastructure team had successfully enabled DNSSEC on every other public domain before attempting to enable it on slack.com. However, enabling DNSSEC on slack.com turned out to be unexpectedly difficult. On the third attempt, a bug in AWS Route 53's DNSSEC signing implementation caused validation failures. When the team tried to roll back by removing the DS record, they discovered that the cached record had a 24-hour TTL at the .com zone level.
Validating resolvers would continue failing regardless of what Slack did. The only way to accelerate recovery was to contact Google, Cloudflare, and individual ISPs that run the resolvers to manually flush their caches. DNSSEC turned what should have been a quick rollback into a day-long incident the team couldn't fully control.
A similar pattern played out in New Zealand, where a .nz outage broke resolution across the entire country-code TLD. 84% of NZ users sit behind validating resolvers, well above the global average of 31%, which meant a DNSSEC misconfiguration didn't just affect a subset of users. It broke resolution across the entire country-code TLD.
The community-maintained outage list documents DNSSEC failures affecting country-code TLDs, large platforms, and government domains with depressing regularity. Several notable incidents illustrate the range of failures that can occur, along with their technical causes and real-world impact:
1. Czechia (.cz) and USA (.us), February 2012
Both zones used RSA keys with large exponents that Go's crypto library could not parse, causing DNSSEC validation failures for any resolver built on Go. Users behind affected software could not resolve domains under either TLD until a fix was merged.
2. Madagascar (.mg), 2017 to 2019
A total of 29 DNSSEC-related incidents were reported during this period. The causes of outages ranged from missing signatures and invalid DNSKEY records to signature timing errors such as “signature before inception.”
3. Fiji (.fj), March 2022
A scheduled key rollover proceeded without updating the DS record in the root zone, causing all .fj domains to return SERVFAIL on validating resolvers. Time zone differences with IANA's US desk delayed recovery. Resolution came approximately 14 hours later.
4. Russia (.ru), January 2024
Flawed key-signing software generated incorrect DNSSEC records for the .ru zone. Hundreds of major websites went down, including Yandex, Tinkoff Bank, Sberbank, and VKontakte, affecting users inside and outside Russia for approximately four hours.
Coinciding with failures, one of the factors slowing adoption is an asymmetry between costs and benefits. When DNSSEC works correctly, the benefits are invisible: there's no padlock icon for DNS, so users have no way of knowing that their domain name resolution was authenticated.
The costs are more tangible. Larger signed responses increase bandwidth usage, trigger UDP fragmentation, and push traffic to TCP. Key management requires ongoing operational attention, and the failure mode is unforgiving: a signed domain with an invalid signature is less available than an unsigned one because validating resolvers will refuse to resolve it entirely.
This creates what researchers call a bootstrap problem. Individual deployments carry immediate operational overhead but deliver limited protection until adoption reaches widespread levels. After 28 years, that threshold hasn't arrived, though adoption continues to grow in certain regions and TLDs.
DNSSEC (Domain Name System Security Extensions) is a set of protocol extensions that adds cryptographic signatures to DNS records. These signatures allow resolvers to verify that DNS responses are authentic and have not been modified during transmission. DNSSEC helps prevent attacks such as DNS spoofing and cache poisoning, which could otherwise redirect users to malicious websites.
DNSSEC adoption remains limited because deployment requires coordination between multiple parties, including registries, registrars, DNS providers, and resolver operators. The protocol also introduces operational complexity, such as key management, signature renewal, and configuration management. Perhaps most troubling is that misconfigurations can cause domains to become completely unreachable for users.
When DNSSEC is misconfigured, validating resolvers may treat DNS responses as invalid and return a SERVFAIL error. Unlike many DNS issues that only degrade performance, DNSSEC errors can make a website entirely inaccessible. Common problems include expired signatures, incorrect DNSKEY records, and errors during key rotation.
Numerous major incidents have demonstrated the risks of DNSSEC misconfiguration. For example, DNSSEC validation failures have caused outages affecting platforms such as Slack, country-code top-level domains, and large national networks. In some cases, incorrect key rollovers or signing errors have caused entire domains to become unreachable for users.
Organizations deploying DNSSEC should carefully plan key management, monitor signature expiration, and test configuration changes before deploying them to production. Automated monitoring of DNSSEC validation status and DNS records can help detect problems early and reduce the risk of outages caused by misconfiguration.
Share your experience and expectations regarding DDoS protection. Your answers will help us tailor solutions to meet your cybersecurity needs.
Tell us about your company’s infrastructure and critical systems. This will help us understand the scope of protection you require.
Help us learn about how decisions are made in your company. This information will guide us in offering the most relevant solutions.
Let us know what drives your choices when it comes to DDoS protection. Your input will help us focus on what matters most to you.
