DNSSEC (Domain Name System Security Extensions) is a set of additions to the DNS that lets a resolver check, cryptographically, that the answer it received for a domain name is the answer the domain’s operator actually published. It does one job well: it stops forged DNS answers from being accepted. It does not protect your registrar account, your DNS provider login, or the content of your website, and a signed domain that nobody watches can go offline through an expired signature. This guide explains what DNSSEC protects, what it leaves exposed, how widely it is used, and when we advise clients to turn it on. It is one of the controls covered in our domain security hub.
The problem DNSSEC solves
The DNS was designed to be fast and distributed, not to be trusted. When a resolver (the DNS server, usually run by an ISP or a public provider such as Google or Cloudflare, that looks up names on a user’s behalf) asks for the address of your domain, it accepts whatever answer comes back. Nothing in the original protocol lets it confirm that the reply came from the right server or was not altered on the way.
That gap is what cache poisoning exploits. An attacker races the legitimate nameserver and feeds the resolver a forged answer. If the forgery wins, the resolver caches the false address and hands it to every user who asks for that name until the record expires. Users who typed your domain correctly land on a server the attacker controls. A forged mail exchanger (MX) record redirects email the same way.
DNSSEC closes the gap by attaching a digital signature to each set of DNS records. A validating resolver checks the signature before it trusts the answer; a forged answer carries no valid signature, so the resolver rejects it. The key concept is simple: DNSSEC proves that a DNS answer is authentic. It does not decide who is allowed to change the records.
How DNSSEC works in plain English
Each signed zone (the set of DNS records for a domain) holds a private key that signs the records and a matching public key, published as a DNSKEY record, that anyone can use to verify the signatures. Most zones use two keys. The zone signing key (ZSK) signs the everyday records such as A, AAAA and MX. The key signing key (KSK) signs the DNSKEY set itself and is the key the outside world is told to trust.
The outside world learns which KSK to trust through the DS (delegation signer) record, a fingerprint of your KSK that lives in the parent zone. For example.com, the DS record sits in the .com zone, and it gets there through your registrar, which submits it to the registry. The .com zone is itself signed, and its own DS record sits in the root zone, whose key is built into validating resolvers as the trust anchor.
Those links form the chain of trust. A validating resolver starts at the root, verifies the .com DS record, uses it to verify your KSK, uses the KSK to verify your ZSK, and uses the ZSK to verify the signature (an RRSIG record) on the answer. If any link fails, the resolver marks the answer bogus and refuses to return it. That refusal is the entire security benefit, and it is also the operational risk discussed below, because the resolver cannot tell an attacker’s forgery from your own expired signature.
What DNSSEC does not protect
Because DNSSEC only authenticates published DNS data, it is silent about who published it. If an attacker takes over your registrar account, they can change the nameservers or remove the DS record through the ordinary control panel, and the registry will sign the new delegation as faithfully as it signed yours. If an attacker compromises your DNS provider account, the provider’s signing system will sign the edited records automatically. In both cases every validating resolver will confirm that the attacker’s answer is authentic. DNSSEC protects the path between your nameservers and the resolver, not the accounts that control what your nameservers say. Those accounts are the subject of our guide to how to secure a domain name.
DNSSEC also says nothing about the content of your website, and it is not transport encryption; it does not encrypt the connection between browser and site. That job belongs to TLS, whose certificates are issued by authorities that validate domain control by looking up DNS records, which is exactly why DNS hijackers obtain certificates for the domains they seize, a pattern described in our guide to DNS hijacking attacks.
How widely DNSSEC is used
Adoption is lopsided. The European Commission’s Joint Research Centre reported that 1,377 of 1,494 top-level domains in the root zone, about 92.2 percent, were DNSSEC-signed as of October 2021, but that only about 5 percent of second-level domains were signed, according to its analysis of DNSSEC uptake in the EU. The same report put the global validation rate by resolvers at around 27 percent.
Validation is the half domain owners cannot control, and a signature no one checks protects no one. Geoff Huston of APNIC measured that some 30 percent of the internet’s user population sits behind resolvers that perform DNSSEC validation, roughly half of it through the Google and Cloudflare public resolvers, in his September 2023 ISP Column on DNSSEC queries.
CSC’s 2024 Domain Security Report found DNSSEC adoption of 9 percent among Forbes Global 2000 companies, up from 3 percent in 2020. Part of the explanation is the registrar. A 2017 study by Chung and colleagues, Understanding the Role of Registrars in DNSSEC Deployment, found that as of December 31, 2016, only 0.7 percent of .com, 1.0 percent of .net and 1.1 percent of .org domains had DNSKEY records, that only 3 of the top 20 registrars supported DNSSEC when acting as the DNS operator, and that close to 30 percent of signed .com, .net and .org domains never uploaded a DS record, so they could not be validated. The data is dated, but the structural point stands: the DS record has to pass through the registrar, so the registrar is the bottleneck.
The operational risks of signing a zone
The risk DNSSEC introduces is self-inflicted outage. Signatures expire. If the signing system stops re-signing, or a key is rotated without the matching DS record being updated at the parent, every validating resolver marks the domain bogus and stops resolving it. Users behind non-validating resolvers still reach the site, so it is up for some people and gone for others.
This happens at scale. A 2025 study by Ashiq and colleagues, Decoding DNSSEC Errors at Scale, observed 319,277 signed second-level and lower domains between March 2020 and September 2024 and found that 25.6 percent, 81,805 domains, had at least one DNSSEC error. Of the domains that ever went bogus, 18 percent were still unresolvable at their latest snapshot, and NSEC3 misconfigurations, delegation failures and missing or expired signatures accounted for more than 70 percent of all bogus states.
Key rollover is the second risk. Rolling the KSK means publishing a new key, submitting a new DS record through the registrar, waiting for caches to expire, and only then retiring the old key. Out of order, those steps break the chain of trust; manual rollover is where errors creep in.
Provider migration is the third risk and the one we see most often. If a signed domain is moved to a new DNS provider by changing nameservers, the DS record at the registry still points to the old provider’s key, so validating resolvers reject the new provider’s answers. Remove the DS record first, wait for the parent zone’s TTL (time to live, the period caches hold a record) to expire, move the nameservers, and only then sign again and publish the new DS record.
Should you enable DNSSEC? A decision guide
We advise enabling DNSSEC when three conditions hold. The DNS provider manages signing and key rollover automatically. The registrar supports DS records for the top-level domain in question. And someone is monitoring the domain for resolution failures, so a bogus state is noticed in minutes rather than when a customer calls. Under those conditions the risk is low.
We advise deferring it in a few situations. If you are about to change DNS providers, finish the migration first. If no monitoring is in place, signing adds a failure mode without anyone to catch it. If the registrar does not support DS records for the TLD, the effort is wasted.
DNSSEC is also not a substitute for the controls that stop the attacks businesses actually suffer, which are overwhelmingly registrar account takeovers rather than cache poisoning. Multi-factor authentication on the registrar account, a registry lock on high-value domains, and change monitoring come first. DNSSEC is the next layer.
Enabling DNSSEC on a typical managed deployment
Where a DNS provider such as Cloudflare, Route 53, or the registrar’s own DNS hosts the zone, the process is short. First, confirm that the registrar accepts DS records for the domain’s TLD. Then enable DNSSEC for the zone in the provider’s control panel; the provider generates the keys, signs the records, and displays the DS record values (key tag, algorithm, digest type and digest). Next, copy those values into the DNSSEC section of the registrar’s control panel. The registrar submits the DS record to the registry, and once it appears in the parent zone the chain of trust is complete. Where the registrar is also the DNS provider, the two steps are often a single switch, which makes domain name security best practices at the registrar more important, not less.
How to verify that DNSSEC is working
Do not assume it worked because the control panel says so. Query the domain through a validating resolver and check for the AD (authenticated data) flag; the dig command with the +dnssec option shows it. Confirm the DS record in the parent zone matches the DNSKEY your provider published. Use a public analyzer such as DNSViz to render the full chain from the root to your zone and flag any broken link. Then repeat the check on a schedule, because what matters is whether DNSSEC still works after the next key rollover.
DNSSEC, registry lock and monitoring together
The three controls answer three different questions. DNSSEC answers whether a DNS answer is authentic. A registry lock answers whether anyone can change the nameservers or DS record at the registry without out-of-band verification, which stops a hijacker who has already stolen the registrar password. Monitoring answers whether anything has changed at all, including the signature state DNSSEC introduces. A domain with only DNSSEC is protected against the rarest of the three threats and exposed to the other two.
How DNAccess helps with DNSSEC
We review whether a client’s registrar and DNS provider can support DNSSEC properly, sequence the enablement around any migration, and verify the chain of trust afterward. For clients who want us to handle registrar, key management and DS records end to end, our domain name management service covers it. Our DNShield domain name monitoring watches nameserver, DS and resolution changes so that an expired signature or a removed DS record is caught early. To discuss a specific domain or portfolio, contact us.