How to Enable DNSSEC on Your Domain

DNSSEC (DNS Security Extensions) adds cryptographic signatures to your DNS records so resolvers can prove an answer really came from you and wasn't tampered with in transit. Without it, DNS answers can be spoofed — sending your visitors to an attacker's server. This guide explains what DNSSEC protects and walks through enabling it.

What DNSSEC actually does

Plain DNS has no authentication: a resolver simply trusts whatever answer it receives, which opens the door to cache poisoning and man-in-the-middle spoofing. DNSSEC signs each record set with a private key; resolvers validate the signature against a public key, and a chain of trust runs from your domain up to the root zone. If an answer is forged, the signature fails and the resolver rejects it. It builds on the fundamentals in how DNS works.

Two things to know:

• DNSSEC authenticates DNS answers; it does not encrypt them (that's DoH/DoT).
• It needs support at two places: your DNS host signs the zone, and your registrar publishes a DS record to the parent zone.

Step 1: Enable signing at your DNS host

Wherever your zone is hosted:

• Cloudflare: DNS → Settings → Enable DNSSEC. It generates the keys and shows you a DS record.
• Route 53 / other managed DNS: enable DNSSEC signing on the hosted zone, which produces a DS record.

The DS (Delegation Signer) record looks like:

example.com  DS  2371 13 2  1F987CC6583E92DF0890718C42...

It contains a key tag, an algorithm number (13 = ECDSA P-256), a digest type, and the digest itself.

Step 2: Publish the DS record at your registrar

This is the step people miss. The DS record must go into the parent zone, which only your registrar can do. In your registrar's panel find DNSSEC and add the DS record with the four fields:

• Key Tag: 2371
• Algorithm: 13
• Digest Type: 2
• Digest: the long hex string

Some registrars instead ask for the DNSKEY and generate the DS for you. If your DNS host and registrar are the same company, this often happens automatically with one click. Related: how to set up custom nameservers for your domain.

Step 3: Verify the chain

Check that the DS record is published and the chain validates:

dig example.com DS +short
dig example.com +dnssec +short

The second command should return RRSIG records alongside your data. For a full pass/fail with the whole chain, use the Verisign DNSSEC Debugger or DNSViz. If validation fails, the resolver returns SERVFAIL — see diagnosing DNS problems with dig and nslookup.

Important cautions

• Never move DNS providers with DNSSEC still on. If you switch DNS hosts without first removing the DS record, the old signatures won't match the new zone and your domain goes dark (SERVFAIL everywhere). Turn DNSSEC off, wait for the old TTL, migrate, then re-enable. This matters if you move your DNS to Cloudflare.
• Key rollovers are usually handled automatically by managed hosts. Don't hand-edit keys unless you know exactly what you're doing.

Choosing the algorithm

When your DNS host signs the zone it picks a signing algorithm, encoded as a number in the DS record. The two you'll see:

• 13 (ECDSA P-256 / SHA-256) — modern, short keys, fast validation. Prefer this.
• 8 (RSA / SHA-256) — older, widely supported, larger keys.

Cloudflare and most managed hosts default to algorithm 13, which is the right choice for new setups. You rarely touch this by hand — the host generates keys and the matching DS for you. If your registrar's DNSSEC form asks for the algorithm, it must match what your DNS host actually used, or validation fails.

What DNSSEC does and doesn't protect

It's worth being precise so you don't over-trust it:

• It protects: the integrity and authenticity of DNS *answers*. A forged A record, a poisoned cache, or a man-in-the-middle altering a lookup all get rejected.
• It does NOT protect: confidentiality (answers are still plaintext — use DoH/DoT for privacy), your website itself (that's TLS/HTTPS), or against a compromised DNS account (an attacker who logs into your DNS host can just re-sign). DNSSEC and a CAA record are complementary layers, not substitutes for TLS or account security.

Monitor it so it doesn't silently break

The failure mode of DNSSEC is total: a broken chain returns SERVFAIL and your domain vanishes for validating resolvers, which is most of them. Guard against it:

• Let your managed host handle key rollovers (Cloudflare and Route 53 do this automatically). Manual key handling is the usual cause of self-inflicted outages.
• Set up external monitoring that alerts on SERVFAIL, and periodically validate with DNSViz or the Verisign DNSSEC Debugger.
• Never change DNS providers with DNSSEC live — disable it, wait for the DS to clear, migrate, then re-enable. This is the exact trap flagged in how to move your domain's DNS to Cloudflare.

A quick health check any time:

dig example.com A +dnssec +multiline

An ad (authenticated data) flag in the response header means a validating resolver accepted the signatures.

FAQ

Does DNSSEC encrypt my DNS traffic?

No. It authenticates answers so they can't be forged, but the data itself is still visible. Encryption is a separate feature (DNS over HTTPS/TLS).

Do I need DNSSEC?

It's strongly recommended for anything security-sensitive and increasingly expected for email and government domains. For a hobby site it's optional but harmless when set up correctly.

Why did my domain break after enabling DNSSEC?

Almost always a mismatched DS record or changing DNS hosts without removing the DS first. Remove the DS record, let it clear, and the domain resolves again.

Can I use DNSSEC with Cloudflare?

Yes — Cloudflare signs the zone and gives you a DS record to paste at your registrar. It's a one-click enable on their side.

Does enabling DNSSEC affect my website's speed?

Negligibly for visitors. DNSSEC adds cryptographic signatures to DNS responses, making them slightly larger and adding a validation step at the resolver — but this happens during name resolution, is cached for the record's TTL, and typically adds only a few milliseconds most users never notice. It does not touch your website's actual page-load speed, which is governed by TLS and server performance, not DNS. The bigger operational consideration isn't speed but fragility: a broken signature chain returns SERVFAIL and takes the domain fully offline for validating resolvers. So the real trade-off is a tiny, invisible resolution cost for meaningful protection against DNS spoofing — well worth it, provided you let a managed host handle key rollovers and never migrate DNS with a stale DS record.

Security starts at the DNS layer and continues on the server. Harden the rest of your stack with tips from Nxeon's security page, and run it all on a fast NVMe VPS.