Defaults.Exposed › Fixes › DNSSEC

How to fix DNSSEC

Updated 17 October 2026, figures from the October 2026 census, snapshot 2026-10-12.

DNSSEC (Domain Name System Security Extensions) is a digital seal on your domain's address book. It lets the internet prove that the answer to 'where does this domain live?' came from you and wasn't tampered with on the way. Without it, the answer can be forged, and your visitors sent somewhere else.

308,837,141 of the 332,492,319 domains carrying a grade are unsigned: 92.9%.

Counted over the 332,492,319 graded and dead domains that carry every grade share in this edition.

Without DNSSEC, an attacker who can poison a DNS (Domain Name System) answer can point your customers at a perfect copy of your site while their browser still shows your real domain name. Logins, card numbers and personal data get harvested. A broken half-finished DNSSEC setup is worse still: it can make your site unreachable for a growing slice of visitors with no error you'd ever notice.

Why DNSSEC matters

DNS is the internet's address book, and by default its answers travel unsigned. Anyone who can slip in a forged reply can send your customers and your email anywhere they like, with your real domain still showing in the browser. DNSSEC puts a tamper-proof seal on those answers so they can be verified as yours. The fix is free at most providers; the only real cost is doing it wrong, which is why we walk through both halves carefully.

Fixing DNSSEC, in order

1. Check registrar and DNS host support. Confirm both your registrar and your DNS host support DNSSEC before starting.
2. Enable signing at your DNS host. Turn on DNSSEC; the host signs your zone and produces a DS (Delegation Signer) record.
3. Publish the DS record at your registrar. Copy the DS record into your registrar DNSSEC settings to complete the chain of trust.
4. Allow propagation. Allow 24-48 hours and do not switch DNS hosts mid-way, or you can break resolution.
5. Verify it worked. Recheck to confirm the chain of trust validates end to end.

DNSSEC, in plain words

Every time someone visits your website or sends you an email, their computer first asks the internet a simple question: “where does this domain live?” The answer (the set of addresses for your site and your mail servers) comes back from the DNS, the internet’s address book.

By default, those answers travel unsigned. There’s nothing attached to prove the answer is genuine. If someone can slip a forged reply into that conversation (and there are well-known, proven ways to do exactly that), your visitor’s computer will happily accept it. From that moment on, the visitor can be talking to an attacker’s server while their browser still shows your domain name in the address bar.

DNSSEC is the fix. It adds a tamper-proof digital seal to your DNS answers. When DNSSEC is switched on, the internet can mathematically verify that an answer came from you and wasn’t altered on the way. A forged reply fails the check and gets thrown away.

This page covers the two parts our check looks at together: whether the seal is published (the DS record) and whether the matching key behind it exists (the DNSKEY record). You’ll see why both matter shortly, because having one without the other is its own kind of trouble.

What this can cost you

These are realistic, aggregate patterns. None describes a single named business.

• An attacker poisons the DNS answer for your domain. Customers type your real web address, see your real domain in the bar, and land on a flawless copy of your login or checkout page hosted by the attacker. Every password and card number they enter goes straight to the criminal. You hear about it only when the chargebacks and “I was hacked through your site” calls start, and the trail leads back to your brand rather than the attacker’s.
• DNS points to your mail servers as well as your website. Forge that answer and inbound email can be rerouted through an attacker first. They read sensitive messages, harvest the one-time codes that services email to “verify it’s you,” and reset passwords on accounts tied to your domain, all without ever logging into your mailbox.
• A half-finished DNSSEC setup causes outages you can’t reproduce. The public seal (DS) is sitting at your registrar, but the matching key (DNSKEY, DNS Public Key) is missing or wrong. Visitors on ISPs (Internet Service Providers) and corporate networks that check DNSSEC (and there are more every year) simply can’t resolve your domain at all. Your site and email work fine for you and your tech, but a slice of real customers get “this site can’t be reached” with no error you can see. It’s one of the hardest problems to diagnose precisely because it’s invisible from the inside.
• A prospect’s pre-contract scan of your domain puts a red mark against “DNS security basics” when DNSSEC is missing. The control is free and well understood, so that mark can cost you the contract.
• Regulations and buyer checklists increasingly name DNSSEC as expected baseline hygiene (it’s referenced under NIS2’s DNS-security provisions). Larger B2B and public-sector buyers may filter you out before a sales conversation begins, simply because the box isn’t ticked.

The two moving parts that have to agree

DNSSEC works as a chain of trust, and it has two moving parts that have to agree with each other. This is the heart of why our check looks at two things.

The DNSKEY: your key. Your DNS provider holds a cryptographic key and uses it to sign your DNS records. The public half of that key is published as a DNSKEY record. That key is the seal-stamp held at your end.

The DS record: the fingerprint that vouches for the key. A short fingerprint of that key, called a DS (Delegation Signer) record, is published one level up, at your domain’s registry, via your registrar. This is what lets the rest of the internet trust your key: each level vouches for the one below it, all the way up to the internet’s root. The DS is the seal being officially registered so everyone else can recognise it.

For DNSSEC to protect you, both must be present and must match:

• DS present + DNSKEY present and matching → good. The chain of trust is complete. Forged answers get rejected; legitimate ones verify. This is the “pass” state.
• No DS (and no DNSKEY) → DNSSEC simply isn’t on. You have no protection, but nothing is broken. This is the most common “not yet done” state. (In our scoring this is where the DS check counts against you; the combined-key check treats a clean, fully “off” state as informational rather than a hard failure, because nothing is actively breaking.)
• DS present, but DNSKEY missing or mismatched → broken, and worse than off. The internet sees a published seal that points to a key that isn’t there. Validating resolvers conclude your domain has been tampered with and refuse to resolve it, causing the intermittent outages described above. This is the most urgent state to fix, and our check flags it as high severity.
• DNSKEY present, but no DS at the registrar → switched on but not activated. Your records are signed, but because the fingerprint was never registered one level up, the rest of the internet has no way to trust them. The fix is to add the DS record at your registrar.

What “good” looks like, in one line: a DS record at your registrar whose fingerprint matches a live DNSKEY at your DNS provider, both confirmed with a quick lookup.

How to fix it (free, about 10 to 30 minutes)

Hand this section to whoever manages your domain or website. The fix itself is free at most providers. The only cost is doing it carefully so the two halves stay in sync. We charge only if you later want us to monitor that it stays correctly enabled.

Always enable signing first (which creates the DNSKEY), then publish the DS record at the registrar, never the other way around, and never one without the other. Publishing a DS before the key exists is exactly what causes outages.

The simple path (recommended: Cloudflare):

1. In Cloudflare, make sure Cloudflare is running your DNS (your nameservers point to Cloudflare).
2. Go to DNS → Settings → DNSSEC → Enable DNSSEC. Cloudflare generates and manages the keys for you (this creates the DNSKEY side automatically).
3. Cloudflare shows you the DS record details to publish at your registrar.
4. Log in to your domain registrar (e.g. Blacknight, GoDaddy, Namecheap, OVH) and find the DNSSEC section. Paste in the DS values Cloudflare gave you.
5. Wait 24 to 48 hours for full propagation. Your site and email keep working throughout.

Other DNS providers (AWS Route 53, your web host, etc.):

1. In your DNS provider’s control panel, enable DNSSEC / “sign this zone.” This generates the signing keys and publishes the DNSKEY records.
2. Copy the DS record the provider produces.
3. Add that DS record at your registrar under its DNSSEC settings.
4. Confirm the registrar accepted it and wait for propagation.

Platform notes:

• Cloudflare. One-click enable, then one DS paste at the registrar. The easiest route by far.
• AWS Route 53. Enable DNSSEC signing on the hosted zone, then add the DS record at your domain’s registrar (if the domain is registered with Route 53, AWS can link it for you).
• Microsoft 365 / Google Workspace. These run your email and don’t usually run your DNS zone. DNSSEC is enabled wherever your DNS records live (often your registrar, host, or Cloudflare) rather than in the 365/Workspace admin centre.
• Your DNS provider doesn’t support DNSSEC at all? That’s common with older or budget hosts. The clean fix is to move DNS management to a provider that does (Cloudflare is free), then follow the simple path above. Moving DNS does not require moving your website or email.

Verify it worked:

• Run dig DS yourdomain.com and dig DNSKEY yourdomain.com: both should return records.
• Or use any free online DNSSEC checker and confirm a green/valid chain of trust.
• Don’t consider it done until both return matching records. A DS with no DNSKEY is the broken state; fix or remove it immediately.

Common mistakes

• Publishing the DS before the key exists. The costliest mistake: adding the DS record at the registrar before signing is live at the DNS provider. This creates the “published seal, missing key” state that makes your domain unresolvable for DNSSEC-checking visitors. Always enable signing first, then publish DS.
• Leaving a stale DS behind after switching providers. If you migrate DNS providers (or disable signing) but forget to remove or update the old DS record at the registrar, you’re left pointing at a key that no longer exists, with the same broken outcome. When you turn DNSSEC off or move it, update the DS at the registrar in the same change.
• Stopping after step one. Enabling signing at the DNS provider (creating the DNSKEY) but never adding the DS at the registrar. Everything looks “on” in the DNS dashboard, but with no DS the protection never activates.
• Assuming HTTPS (Hypertext Transfer Protocol Secure) or email authentication already covers it. The padlock and email authentication (SPF / DKIM / DMARC) are valuable but solve different problems. None of them stop a forged DNS answer from sending visitors to the wrong place to begin with.
• Not monitoring after enabling. A setup that’s perfect today can silently break months later when keys are rolled, providers change or records are edited. If DNSSEC matters enough to enable, it’s worth a periodic check that it’s still valid.

Where this sits in your grade

Both of these checks count toward your DNS Security score. The DS record check is treated as the higher-priority of the two: a missing DS is scored as a failure. The DNSKEY check confirms the rest of the chain is intact. It passes only when a matching DS and DNSKEY are both present, and it flags the dangerous “DS-without-key” broken state as high severity. A clean “DNSSEC simply isn’t enabled yet” result is the common starting point for many businesses; moving from there to a complete, matching DS + DNSKEY pair is a free, well-understood upgrade that improves your DNS Security standing and closes one route to impersonation and interception.

Where the change goes, host by host

The click path for the providers people ask about most:

• Set up DNSSEC on REG.RU

Questions people ask

Figures as of 12 October 2026, from the October 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.