DNSSEC is the one DNS setting that can take your entire domain offline for some visitors while it looks perfectly fine to you. It protects visitors from forged DNS answers, but a stale DS record left behind after a provider change makes validating resolvers refuse to answer at all. This guide explains how DNSSEC works in practical terms, helps you decide whether to turn it on, and gives you a safe procedure for the moment it most often breaks: moving DNS providers.
Key takeaways
- DNSSEC adds signatures to DNS answers so resolvers can detect forged responses, but it does not encrypt DNS.
- The DS record at your registrar must always match the DNSKEY at your DNS provider, or validating resolvers return SERVFAIL.
- When changing DNS providers, remove the DS record first, wait for its TTL to expire, then switch nameservers and re-enable DNSSEC.
- DNSSEC is worth enabling for most domains if your DNS provider signs automatically and your registrar accepts DS records.
What DNSSEC protects against
Plain DNS has no built-in way for a resolver to tell a genuine answer from a forged one. An attacker who can inject a fake response, for example through cache poisoning, can send a resolver's users to an address they control. The browser still shows your domain name.
DNSSEC adds digital signatures to DNS data. As ICANN describes it, it provides two things:
- Data origin authentication: the answer really came from the zone that owns the name.
- Data integrity: nobody changed the answer after the zone owner signed it.
What it doesn't do matters just as much:
- It doesn't encrypt DNS. Queries and answers are still readable on the wire. Privacy is the job of DNS over HTTPS (DoH) or DNS over TLS (DoT).
- It doesn't protect against a compromised registrar or DNS account. If someone logs in and changes your records, DNSSEC will happily sign their changes.
- It only helps when the resolver validates. Many large public resolvers do, including Google Public DNS and Cloudflare's 1.1.1.1, but not every network's resolver does.
How DNSSEC works
You don't need the cryptography to run DNSSEC, but you do need to know the four record types involved, because they're what you'll see in error messages.
| Record | Lives in | Purpose |
|---|---|---|
| DNSKEY | Your zone | Public keys used to verify your signatures |
| RRSIG | Your zone | A signature over each set of records (your A records, MX records, etc.) |
| DS | The parent zone (e.g. .com), set via your registrar |
A hash of your key, which links your zone to the parent. A WHOIS lookup shows whether the registry has a DS record for your domain |
| NSEC / NSEC3 | Your zone | Signed proof that a name or record type doesn't exist |
The chain of trust
A validating resolver checks signatures from the top down:
- It trusts the root zone's key, which it has built in. The root has been signed since 2010.
- The root zone holds a signed DS record for
.com, so the resolver can trust.com's keys. - The
.comzone holds a signed DS record forexample.com, which you supplied through your registrar. - That DS record must match a DNSKEY in your zone. If it does, the resolver trusts your keys and checks the RRSIG on whatever record it asked for.
The important consequence: the DS record at the registrar and the DNSKEY at your DNS provider must always match. They're managed in two different places, often by two different companies, and that's where nearly every DNSSEC outage comes from.
KSK and ZSK
Many setups use two keys. The key-signing key (KSK) signs only the DNSKEY set, and its hash is what goes in the DS record. The zone-signing key (ZSK) signs everything else. This lets the provider rotate the ZSK without touching the registrar. Some providers, including Cloudflare, use a single combined key. Either way, managed DNS providers handle rotation for you.
Algorithms
Your DS record includes an algorithm number. RFC 9904 (2025), which replaced RFC 8624 and moved the guidance into IANA's registries, lists algorithms 8 (RSASHA256), 13 (ECDSAP256SHA256) and 15 (ED25519) as recommended for signing. Algorithms 5 and 7 (based on SHA-1) are not recommended, and SHA-1 digests (digest type 1) must not be used for DS records. If your registrar's form doesn't list algorithm 13, it may label it "ECDSA Curve P-256 with SHA-256."
Should you enable DNSSEC?
For most domains, yes, as long as your DNS provider signs automatically and your registrar accepts DS records. With a managed provider, enabling it is a toggle plus one record at the registrar, and ongoing key management is automatic.
Weigh it more carefully if:
- You change DNS providers often, or several teams can touch nameserver settings. Each change becomes a coordinated procedure.
- Your DNS is spread across providers (primary/secondary or multi-provider setups). This works, but every provider must support the same signing arrangement.
- You run your own authoritative servers. Then you own signature expiry and key rollovers, and an expired signature is an outage.
Domains that benefit most: anything handling logins, payments or email for others. DNSSEC is also a prerequisite for DANE, which some mail servers use to authenticate TLS between mail servers. If you only want to enforce TLS on inbound mail without DNSSEC, look at MTA-STS instead.
How to enable DNSSEC
The process is the same everywhere, only the button labels differ:
- Turn on signing at your DNS provider. It generates keys and starts serving DNSKEY and RRSIG records.
- Copy the DS values it shows you: key tag, algorithm, digest type and digest.
- Add the DS record at your registrar. Some registrars ask for the DNSKEY instead and compute the DS themselves. If your registrar and DNS provider are the same company, this step is often automatic. Some registries also support automatic DS updates using CDS/CDNSKEY records.
- Verify. Wait for the DS to appear, then test.
A DS record looks like this:
example.com. 3600 IN DS 2371 13 2 1F987CC6583E92DF0890718C42A3E9...
; tag alg digest-type digest
Check from the command line:
# The DS record published in the parent zone
dig example.com DS +short
# The keys published by your provider
dig example.com DNSKEY +short
# Ask a validating resolver; look for the "ad" (authenticated data) flag
dig example.com A @1.1.1.1 +dnssec
Common breakages when changing DNS providers
When you move nameservers, the old provider stops serving your zone, so the old DNSKEY disappears. If the old DS is still at the registry, validating resolvers find a DS with no matching key, mark your zone as bogus, and return SERVFAIL. Your website, email and everything else on the domain stop resolving for anyone behind a validating resolver. Meanwhile people on non-validating networks see no problem, which makes this confusing to diagnose.
The typical failure patterns
- Stale DS after a migration. You moved to a provider that doesn't sign, or hasn't been set up to sign, and nobody removed the DS. Google's Public DNS troubleshooting docs call this out specifically and say the fix is to have the registrar remove the stale DS records.
- Nameservers changed before the DS expired. You removed the DS, but switched nameservers right away. Resolvers that cached the old DS keep expecting the old key until that cache expires.
- New provider enabled, DS never updated. The new provider signs with new keys, but the registrar still has the old provider's DS.
- Domain transfer to a new registrar that dropped or failed to import the DS record, or a registrar that can't accept your provider's algorithm.
Safe migration option 1: go unsigned briefly
This is the simplest procedure and works with any providers. Cloudflare's docs describe the same sequence.
- Remove the DS record at the registrar. Keep signing enabled at the old provider.
- Wait for the DS TTL to expire. Check the TTL with
dig example.com DSagainst a public resolver, and wait at least that long. A day is a comfortable margin for most TLDs. - Switch nameservers to the new provider and confirm the zone resolves.
- Enable DNSSEC at the new provider and add its new DS record at the registrar.
The domain runs without DNSSEC for a day or two, but it never goes dark.
Safe migration option 2: multi-signer (no unsigned gap)
If both providers support importing each other's keys, you can stay signed throughout:
- Set up the zone at the new provider and enable DNSSEC with multi-signer support.
- Cross-import keys: add the old provider's ZSK as a DNSKEY at the new provider, and the new provider's key at the old one.
- At the registrar, add the new provider's DS and nameservers alongside the old ones.
- Remove the old DS and nameservers, wait at least 1.5 times the old DS TTL (Cloudflare's guidance), then remove the old provider's key.
This needs the old provider to allow DNSKEY records at the zone apex. Many don't, in which case use option 1.
Diagnosing a DNSSEC outage
If a domain returns SERVFAIL from 8.8.8.8 or 1.1.1.1, retry with validation disabled:
dig example.com A @8.8.8.8 # SERVFAIL?
dig example.com A @8.8.8.8 +cd # +cd = checking disabled; works?
If the +cd query works, DNSSEC is the problem. Newer resolvers also return Extended DNS Errors (EDE) explaining why. Google lists EDE 9 (DNSKEY Missing, no key matches the parent's DS) as the classic migration error, plus EDE 6 (DNSSEC Bogus) and EDE 10 (RRSIGs Missing). For a visual view of the whole chain, run the domain through DNSViz.
Check your domain
Run a free audit to see whether DNSSEC is enabled for your domain, alongside your NS, SOA and other DNS records. If you're planning a migration, run it before and after the change so you have a record of what the zone looked like. Our DNS propagation guide covers the TTL side of planning a cutover.
Frequently asked questions
Does DNSSEC slow down my website?
The effect is small. Signed responses are larger, and validating resolvers do extra lookups, but results are cached like any other DNS data. Choosing an ECDSA algorithm (13) keeps responses smaller than large RSA keys.
Does DNSSEC encrypt DNS queries?
No. DNSSEC proves answers are authentic and unaltered, but anyone on the network path can still read them. DNS over HTTPS and DNS over TLS handle privacy, and they work alongside DNSSEC.
What happens if I forget to remove the DS record when switching DNS hosts?
If the new host doesn't serve matching keys, validating resolvers will treat your domain as bogus and return SERVFAIL, so your site and email stop resolving for many users. Remove the DS at your registrar, or add the new provider's DS, to fix it.
Is DNSSEC required for email deliverability?
Gmail, Yahoo and Microsoft sender requirements focus on SPF, DKIM, DMARC and related practices, not DNSSEC. DNSSEC is needed for DANE, which some receiving mail servers use, but it isn't a requirement for reaching the inbox. See our sender requirements guide.
What to do next
Check whether your domain has a DS record (dig yourdomain.com DS +short). If it does, write down which provider issued it and add "remove or replace DS" to any future migration checklist. If it doesn't, and your DNS provider supports automatic signing, enabling it is a ten-minute job.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 30 October 2026 . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
