DNSSEC: why it exists, who uses it and what it has broken
In plain words: DNSSEC puts a seal on the internet's address book so nobody can forge an entry, but if the seal is applied wrongly the whole address vanishes. Network and segmentation, explained simply
In short
- DNS was designed to answer quickly, not to prove anything. DNSSEC adds signatures, so a resolver can check that an answer came from whoever controls the name and was not changed on the way. It does not hide anything: queries and answers are still readable.
- It is used unevenly. Most top-level domains are signed, and in some countries nearly every user sits behind a resolver that checks signatures. Yet only a few per cent of the names people actually look up are signed, because most domain owners never turned it on.
- Its failures are dramatic because a validating resolver refuses an answer it cannot verify. A key change that goes wrong does not weaken a domain; it makes it disappear. That has happened to companies, to top-level domains and, in January 2024, to the whole of
.ru.
Why it exists
When your laptop asks for www.example.org, it usually asks a resolver run by your organisation, your broadband provider or a public service. The resolver goes and asks the servers responsible for that name, then caches the answer for everyone else who asks. Classic DNS has no way to tell a genuine answer from a well-timed fake: it accepts the first reply that matches the question.
People knew this in the 1990s, and work on signing DNS started then. What turned it from a standards project into an urgent one was Dan Kaminsky's discovery in 2008. He showed that an attacker could poison a resolver's cache in seconds rather than days, by racing it with forged replies for made-up names until one stuck, and then using that to take over the whole domain. Every major DNS vendor patched at once, in a coordinated release that was unusual for its time. The patches made forgery much harder by randomising the source port, but everyone involved said the lasting fix was cryptographic.
That fix is DNSSEC, in the form standardised in 2005 (RFCs 4033 to 4035). Each zone signs its records with its own key. The parent zone publishes a small record, the DS record, that vouches for the child's key. The root zone, signed since July 2010, vouches for the top-level domains. A resolver that trusts the root key can therefore check every link from the root down to the answer it was given.
The root key itself is looked after in public: it lives in hardware security modules in two US facilities and is only used in recorded key ceremonies, with community representatives from around the world holding the credentials needed to open it. It is one of the few pieces of internet infrastructure whose trust model you can watch on video.
Who uses it
There are two sides to DNSSEC, and they have moved at very different speeds.
Validation, on the resolver side, is fairly common. Google Public DNS, Cloudflare's 1.1.1.1 and Quad9 all check signatures, and so do many broadband providers. APNIC's measurements, which test millions of users through online adverts, show validation above 85 per cent in countries such as Sweden, Estonia and New Zealand, and about 95 per cent of Comcast's users in the US. Elsewhere it is far lower, and in a few places providers have switched it off again.
Signing, on the owner's side, is rare. The root and most top-level domains are signed. Some country domains, including .nl, .se and .cz, pushed their registrars with discounts and now have most of their names signed. Governments have often led: a US mandate from 2008 required .gov domains to be signed, and several European governments list DNSSEC among the standards their own sites must meet. But most commercial domains under .com and its peers are not signed. Geoff Huston at APNIC, looking at queries to Cloudflare's resolver in 2025, found that only about 3 per cent were for signed names.
So the common case today is a resolver ready to check signatures, asking about a name that has none.
The problems it has caused
Outages by key change. Keys have to be replaced from time to time, and the parent's DS record has to match the child's key at every moment, allowing for caches that may hold old records for hours or days. Get the timing wrong and every validating resolver refuses the domain. On 30 January 2024 a key rollover in .ru produced signatures that resolvers could not verify, and sites across .ru and .рф were unreachable for several hours for anyone behind a validating resolver. The registry blamed the software that generated the keys. New Zealand's .nz and Sweden's .se have had smaller incidents of the same kind.
Outages by switching it on. Slack enabled DNSSEC on slack.com on 30 September 2021. A bug in how its DNS provider signed answers for wildcard records led some resolvers to conclude that Slack's addresses did not exist. Slack rolled back, but resolvers had cached the DS record, so validation now failed outright. Some users could not reach Slack for about a day, and Slack's own write-up is one of the most honest accounts of how DNSSEC's edge cases compound.
The root key rollover that had to wait. The root key was due to be replaced for the first time in October 2017. ICANN postponed it by a year when data from resolvers suggested that many had not picked up the new key and would have stopped resolving anything at all. The change went ahead on 11 October 2018 with very little disruption, but the delay showed how hard it is to change a trust anchor that is configured in millions of places nobody manages.
A new way to attack resolvers. Checking signatures costs work, and that work can be abused. In February 2024 researchers at ATHENE in Germany disclosed KeyTrap: a crafted zone with many colliding keys and signatures that made validating resolvers try every combination. A single packet could stall some resolvers for anything from a minute to sixteen hours. The flaw was in the standard itself, so every major resolver needed a patch. Larger signed answers have also made DNS a more effective amplifier for denial of service attacks.
Leaks of a different kind. To prove that a name does not exist, the original design returned the neighbouring names in the zone, which let anyone walk the zone and list everything in it. A hashed variant (NSEC3) and newer techniques that sign answers on the fly have largely fixed this, at the cost of more complexity.
Brittleness as a design choice. When a website's certificate is wrong, the browser warns and the user can choose. When a signature is wrong, the resolver answers "server failure" and the user sees only that the site is gone. Some providers have added negative trust anchors (RFC 7646), which let them stop validating one broken domain while its owner fixes it. That is sensible, and also an admission that the strictness hurts.
What it does not do
DNSSEC proves an answer is authentic; it does not keep it private. Encrypted DNS (DNS over HTTPS or TLS) does that, and is a separate thing. Usually the check happens at the resolver, so the last hop to your device is still trusted on faith. And DNSSEC cannot help when the attacker controls the account that publishes the records. The DNS hijacking campaigns of 2018 and 2019 worked by stealing registrar and DNS provider credentials; with those, an attacker can change the records and the keys together. Protecting the registrar account, with strong sign-in and a registry lock, matters at least as much as signing.
Where it does help is against forgery on the path. In April 2018 attackers hijacked internet routes to Amazon's DNS service and gave out false answers for MyEtherWallet, sending its users to a copy of the site that emptied their wallets. The domain was not signed. Had it been, resolvers that validate would have refused the forged answers.
Is it worth turning on?
I think yes for most organisations, with care. Many DNS providers now sign automatically and handle key changes, and the registrar can publish the DS record for you, which removes most of the timing risk that caused the outages above. It also makes other things possible: DANE, which lets mail servers publish which certificates they use, depends on DNSSEC, and large mail providers have started to support it for mail between organisations.
There is a longer-term catch. Post-quantum signatures are much larger than today's, and DNS answers have to stay small. Moving DNSSEC to quantum-safe algorithms is an open problem, and one more reason to know where your cryptography lives, as I argued in Post-quantum migration starts with a cryptography inventory.
What to do on Monday
- Check whether your main domains are signed, and whether the resolvers your staff and servers use validate. Both are quick to test with public tools.
- If you sign, find out who rotates the keys and how. Prefer a provider that does it automatically and supports publishing the DS record through the registrar.
- Before switching DNSSEC on for a busy domain, test the awkward records first, especially wildcards, and plan the rollback: remove the DS record and wait for caches to expire before you stop signing, not the other way round.
- Put a registry lock and phishing-resistant sign-in on your registrar and DNS provider accounts, whether or not you sign.
Sources
- CERT Coordination Center, VU#800113: Multiple DNS implementations vulnerable to cache poisoning (July 2008).
- IETF, RFC 4033: DNS Security Introduction and Requirements (March 2005).
- ICANN, DNSSEC: what is it and why is it important? (2019).
- ICANN, The recent KSK rollover: summary and next steps (October 2018).
- Geoff Huston, APNIC, Measuring the use of DNSSEC (September 2023), and DNSSEC at ICANN 82 (March 2025).
- Slack Engineering, What happened during Slack's DNSSEC rollout (2021).
- Domain Incite, Russia blames DNSSEC, not Ukraine, for internet downtime (January 2024).
- ATHENE, KeyTrap: denial of service through DNSSEC (2024).
- The Register, MyEtherWallet DNS hijack (April 2018).
- IETF, RFC 7646: Definition and Use of DNSSEC Negative Trust Anchors (September 2015).
Personal work and my own view, not my employer's. Sources are public.