Defaults.Exposed › Fixes › DNSSEC

How to fix DNSSEC

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

Bottom line for your business: Without DNSSEC, an attacker who can poison a DNS 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, and you only find out from the chargebacks and complaints. 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.

What this can cost you

• Visitors typing your real domain get silently redirected to a look-alike that captures their password and card details — and because the address bar shows your domain the whole time, nobody suspects a thing until the fraud reports arrive.
• Your email gets quietly rerouted: an attacker forges the answer for your mail servers, reads or intercepts messages, and resets passwords on accounts that email you a code — all without touching your inbox.
• A half-configured DNSSEC setup (the public seal exists but the matching key is missing) makes your website and email randomly fail for customers on big ISPs and corporate networks — intermittent 'your site is down for me' reports you can't reproduce.
• A prospect's security team runs a pre-contract check, sees no DNSSEC, and marks you down as weak on fundamentals — putting a deal at risk over a free setting.
• Public-sector and larger B2B buyers increasingly expect DNSSEC as a baseline (it's named in regulations like NIS2); its absence quietly disqualifies you from tenders before a conversation even starts.

Why it 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 genuinely 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.

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 actually live?” The answer — the set of addresses for your site and your mail servers — comes back from the DNS, the internet’s address book.

Here’s the uncomfortable part: 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 really came from you and wasn’t altered on the way. A forged reply fails the check and gets thrown away. It’s the difference between an address book anyone can scribble in and one where every entry is signed and witnessed.

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 actually 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 — not any one named business.

• The invisible redirect. 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, not the attacker’s.
• Quiet email interception. DNS doesn’t just point to your website; it points to your mail servers. 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.
• The outage you can’t reproduce. This one comes from a half-finished DNSSEC setup. The public seal (DS) is sitting at your registrar, but the matching key (DNSKEY) is missing or wrong. Visitors on ISPs 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.
• The lost deal. A prospect’s security or procurement team runs a routine pre-contract scan of your domain. No DNSSEC shows up as a red mark on “DNS security basics.” For a free, well-understood control, its absence reads as carelessness — and it can quietly cost you a contract you never knew was in jeopardy.
• The tender you don’t even qualify for. 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.

What it actually is

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. Think of it as 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 actually 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. You get the work without the protection. 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, ~10–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.

The golden rule: 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 actually 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–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, not usually your DNS zone. DNSSEC is enabled wherever your DNS records actually live (often your registrar, host, or Cloudflare), not 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 single most damaging mistake: adding the DS record at the registrar before signing is actually 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 — 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. You did the work and got none of the benefit.
• Assuming HTTPS 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. Keys get rolled, providers change, records get edited. A setup that’s perfect today can silently break months later. 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 a real gap and 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 removes a genuine avenue for impersonation and interception.

Set it up on your host

Step-by-step for popular providers:

• Set up DNSSEC on GoDaddy
• Set up DNSSEC on Namecheap
• Set up DNSSEC on Cloudflare
• Set up DNSSEC on AWS Route 53

FAQ