How to Enable DNSSEC on Your Domain

To enable DNSSEC, turn on signing at the company that hosts your DNS, copy the DS record it gives you, add that DS record at your domain registrar, then check the result with a free lookup tool.

This guide is for owners of small sites (WordPress, Shopify, indie SaaS, local business) who keep hearing "turn on DNSSEC" and don't know where to start. You'll learn what DNS Security Extensions (DNSSEC) actually do, whether you need them, and get a checklist you can follow at the most common registrars. You'll also learn the one mistake that can take your domain offline, so you can avoid it.

What DNSSEC is, in plain English

DNS is the internet's phone book. When someone types your domain, DNS tells their device which server to connect to. Ordinary DNS answers are not signed, so a device has no strong way to tell a real answer from a forged one.

DNS Security Extensions (DNSSEC) add a digital signature to your DNS answers. A resolver (the service that looks up DNS for a visitor, such as their ISP or a public resolver like 1.1.1.1) can check that signature. If an answer was forged or tampered with, a validating resolver rejects it instead of sending the visitor to the wrong place.

The design is a chain of trust. The root of DNS vouches for the top-level domain (like .com), and the top-level domain vouches for your domain. The link between your domain and its parent is a DS record (Delegation Signer). It is a fingerprint of your public signing key, stored at the registry (the organization that runs a top-level domain like .com). The formal design is in RFC 4033, and ICANN has a readable overview in What is DNSSEC and why is it important.

What DNSSEC does and does not protect

DNSSEC fixes one specific problem: forged DNS answers (often called DNS spoofing or cache poisoning). It is not a full shield for your domain.

Two points matter here. First, a common way domains get hijacked is a stolen registrar login, not forged DNS answers. Turn on two-factor authentication and the registrar lock before you worry about DNSSEC. Second, DNSSEC signs records but does not encrypt anything. You still need HTTPS.

If you want to see where DNS fits among other risks, read is my website hackable.

Do you need DNSSEC?

It is a sensible hardening step, and often free. It is worth doing if:

• Your DNS host makes it one click (Cloudflare, for example).
• A client questionnaire or security policy asks about it.
• You handle logins, payments or customer data.

It is lower priority if your DNS host doesn't support it. Don't move everything just to tick this box. Registrar security and a patched website come first.

Before you start: the safety checklist

DNSSEC is easy to turn on and easy to break. A wrong or stale DS record makes validating resolvers refuse to answer for your domain. For visitors on those resolvers, your website and your email can stop working.

Work through this first:

• [ ] Log in to your registrar and DNS host with two-factor authentication on.
• [ ] Write down who hosts your DNS. It is whoever runs your nameservers, the servers that answer DNS questions for your domain. NS records list them (look at the NS records in your registrar's DNS settings).
• [ ] Confirm that your DNS host supports DNSSEC. Check their docs.
• [ ] Confirm that your registrar lets you add a DS record (or can do it for you).
• [ ] Take a screenshot or export of your current DNS records.
• [ ] Pick a quiet time and keep both dashboards open.

One rule saves most people from trouble: the DNS host signs, the registrar publishes the DS record. If both are the same company, it may be one switch. If they differ, you do both steps yourself.

How to enable DNSSEC in 4 steps

This is the general flow for DNSSEC setup, whichever company you use.

1. Enable signing at your DNS host. Find the DNSSEC option and turn it on. The host generates signing keys and shows you DS record details.
2. Copy the DS record values. You need four items: key tag, algorithm, digest type and digest. A typical result looks like this:

   example.com. IN DS 2371 13 2 <long-hex-digest>

Here 2371 is the key tag, 13 is the algorithm (ECDSA P-256 with SHA-256), 2 is the digest type (SHA-256), and the last part is the digest. Copy it exactly, with no spaces added.

1. Add the DS record at your registrar. Paste each value into the matching field. Some registrars also ask for the public key itself (a DNSKEY record). Use whichever your DNS host provides.
2. Wait, then verify. It can take from minutes to a few hours for the parent zone to update. Then run the checks in the next section.

Registrar-by-registrar checklist

Menus change often, so treat these paths as a guide and confirm in each vendor's docs.

Shopify, Wix and Squarespace sites: the website platform usually doesn't control DNSSEC. Your domain's DNS host does. Check where your nameservers point, then follow that provider's steps. If you bought the domain through the platform and it uses the platform's own DNS (for example a Shopify-managed or Wix-managed domain), DNSSEC support may not be offered at all. Confirm with the platform's docs or support. If it isn't available, you can move DNS to a host that supports DNSSEC. If a DS record already exists, follow the DS removal order described in "Mistakes that break DNSSEC" below before you move.

WordPress hosts: if your host manages DNS (many managed hosts do), ask support whether they offer DNSSEC. If you use Cloudflare in front of WordPress, enable it in Cloudflare.

How to check that DNSSEC is working

Use all three checks.

1. Look for the DS record. Run this in a terminal (Mac, Linux, or Windows with WSL):

dig DS example.com +short @1.1.1.1

You should see output matching the values from your DNS host. Empty output can mean the registry has no DS record yet. It can also be caching of an earlier empty answer, so recheck after a while.

2. Ask a validating resolver.

dig +dnssec example.com A @1.1.1.1

In the header line, look for flags: qr rd ra ad. The ad flag means "authenticated data": the resolver verified the signatures. A SERVFAIL status can mean DNSSEC validation failed, but other DNS problems also cause it. To confirm, repeat the query with +cd (checking disabled, which skips validation):

dig +dnssec +cd example.com A @1.1.1.1

If that returns an answer but the normal query gives SERVFAIL, the DNSSEC chain is the likely problem. If both fail, look for another DNS issue.

3. Use a visual checker. Free web tools such as DNSViz and the Verisign DNSSEC Debugger draw the whole chain of trust and flag the exact broken link. Paste your domain and read the red or yellow items.

Mistakes that break DNSSEC

Most failures come from a short list.

• Switching DNS hosts with the old DS still in place. The new host has different keys, so the old DS no longer matches. Remove the DS record at the registrar first (and wait for it to expire), move DNS, then re-enable DNSSEC at the new host.
• Typos in the DS values. One wrong character breaks the chain. Copy and paste.
• Adding a DS record without signing enabled. The registrar publishes a fingerprint for keys that don't exist yet.
• Turning off DNSSEC at the host but leaving the DS at the registrar. Same outcome: validating resolvers reject your domain.
• Forgetting that email uses DNS too. A broken chain can hurt mail delivery. After any change, send a test email.

If your site suddenly stops loading for some people right after a DNS change, undo the DS record at your registrar first (or fix the mismatch). Validating resolvers may keep the old DS cached for up to its TTL (time to live, the cache lifetime), often several hours to a day, so recovery is not instant. Do not also change other DNS settings while you wait. Do not turn off signing at the DNS host until the DS record is gone from the registrar. If you suspect something worse than a mistake, see our website hacked page.

DNSSEC is one layer, not the whole job

DNS protection works best next to other basics:

• Two-factor authentication and registrar lock on your domain account.
• Correct email authentication records (SPF, DKIM, DMARC). Our email spoofing tool checks yours.
• HTTPS with sensible security headers.
• Updated plugins, themes and platform software.

You can run a free website security check for a quick outside look at some of these. It is a passive check, so it won't find everything a person would.

Where a human audit fits

DNSSEC covers one narrow risk. Your site can have it switched on and still have an exposed admin page or an outdated plugin. If you want a real person to look at the whole picture, the Circuit audit is $49, one time. A security engineer manually reviews your site and writes up every issue with severity, evidence and exact fixes. It is a focused small-site review, not a compliance certification or an enterprise pentest. If it isn't right for you yet, the free check above is a fine place to start.

Key takeaways

• DNSSEC adds signatures to DNS answers so forged answers get rejected. It does not encrypt traffic or stop account takeovers.
• Enabling it takes two steps in two places: sign at your DNS host, publish the DS record at your registrar.
• Never change DNS hosts or turn DNSSEC off without removing the DS record first.
• Verify with dig +dnssec (look for the ad flag) and a chain checker like DNSViz.
• Lock down your registrar account with two-factor authentication before anything else.