TL;DR: DNSSEC adds a digital signature to your DNS records so resolvers can verify they haven't been tampered with. To enable it: generate or activate DNSSEC at your DNS provider, then publish the DS record at your domain registrar. Most modern registrars and DNS providers do both steps for you automatically. Run a free Kalenfy scan to check whether DNSSEC is active on your domain.
What DNSSEC does (and doesn't do)
DNSSEC signs your DNS records with public-key cryptography. When a resolver queries your domain, it checks the signature against the published key. If the response has been altered in transit — a cache poisoning attack — the signature fails and the resolver refuses to use the forged data.
What DNSSEC does not protect:
- The content of DNS queries themselves (use DNS-over-HTTPS/TLS for privacy)
- Denial-of-service attacks against your DNS servers
- Correctly signed but malicious records (e.g. a legitimate redirect to a bad site)
Before you start: check your current DNSSEC status
First, confirm whether DNSSEC is already active:
dig +dnssec yourdomain.com AIf you see an AD (Authenticated Data) flag in the response header,
DNSSEC is already enabled and validating. If not, follow the steps below.
You can also check with a browser: visit Verisign's DNSSEC Analyzer and enter your domain.
Step 1 — Enable DNSSEC at your DNS provider
Your DNS provider (where your zone file lives — often your registrar, or a dedicated DNS host like Cloudflare, Route 53, or Google Cloud DNS) must sign the zone. How you do this depends on the provider:
| Provider | Where to find DNSSEC | Auto or manual? |
|---|---|---|
| Cloudflare | DNS → Settings → DNSSEC → Enable | Automatic (one click) |
| GoDaddy | Domain Settings → Additional Settings → DNSSEC | Auto for GoDaddy DNS; manual DS otherwise |
| Namecheap | Domain List → Manage → Advanced DNS → DNSSEC | Auto for BasicDNS |
| AWS Route 53 | Hosted Zone → Enable DNSSEC signing | Manual — generates Key Signing Key |
| Google Cloud DNS | Cloud DNS → Zone → DNSSEC → On | Automatic once enabled |
| Porkbun | Domain Management → DNSSEC | Automatic for Porkbun DNS |
After enabling, the provider generates a Key Signing Key (KSK) and a Zone Signing Key (ZSK), signs every record in the zone, and gives you a DS (Delegation Signer) record to publish at your registrar.
Step 2 — Publish the DS record at your registrar
If your DNS provider and domain registrar are the same company (e.g. you use Cloudflare for both), this step is usually automatic — they handle the DS record publication for you.
If they are different (e.g. you registered at Namecheap but use Cloudflare for DNS), you must manually copy the DS record from Cloudflare and paste it into Namecheap's DNSSEC panel:
- In Cloudflare: DNS → Settings → DNSSEC. Copy the DS record values (Key Tag, Algorithm, Digest Type, Digest).
- In Namecheap: Domain List → Manage → Advanced DNS → DNSSEC → Add DS Record. Paste the values.
- Wait for propagation — typically 5–30 minutes, but can take up to 48 hours depending on TTL settings.
The DS record lives in the parent zone (the TLD registry, e.g. Verisign for
.com) and creates the chain of trust from the root down to your zone.
Step 3 — Verify the chain of trust
Once propagation is complete, verify that the full chain is intact:
# Check for the DS record at the TLD level
dig DS yourdomain.com @8.8.8.8 +short
# Check for RRSIG records on your zone
dig RRSIG yourdomain.com @8.8.8.8 +short
# Full DNSSEC validation
dig +dnssec +cd yourdomain.com A @1.1.1.1If you see DS and RRSIG records, and the AD flag appears without the
CD (Checking Disabled) flag, DNSSEC is validating correctly.
Use the Verisign DNSSEC Analyzer for a visual chain-of-trust diagram that shows exactly where a problem is if one exists.
Common DNSSEC problems
| Problem | Cause | Fix |
|---|---|---|
| SERVFAIL on all queries after enabling DNSSEC | DS record not published at registrar, or wrong values | Verify DS record values match what the DNS provider shows |
| DNSSEC was working but broke after changing DNS provider | Old DS records still at registrar pointing to old keys | Delete old DS records at registrar before migrating DNS |
| Signature expiry (RRSIG expired) | Auto-rotation failed or zone wasn't re-signed | Re-sign the zone; check your provider's auto-rotation settings |
| Algorithm mismatch | DS record uses different algorithm than DNSKEY | Re-generate DS record from current DNSKEY |
Critical warning: If you change DNS providers without removing the old DS records first, your domain will go dark for all DNSSEC-validating resolvers (which is most resolvers today). Always remove old DS records before migrating.
DNSSEC key rotation
DNSSEC keys need periodic rotation. Most managed DNS providers (Cloudflare, Route 53, Google Cloud DNS) handle key rotation automatically. If you manage your own nameservers (BIND, NSD), you need to rotate keys manually — the process involves a pre-publication period where both old and new keys are published simultaneously before switching over.
Check your provider's documentation for their rotation schedule and whether you need to update the DS record at your registrar each time.
FAQ
Is DNSSEC required for DMARC or SPF to work?
No. SPF, DKIM and DMARC work independently of DNSSEC. However, DNSSEC makes your SPF/DKIM/DMARC records more trustworthy — an attacker who can poison DNS could otherwise replace your SPF record with one that allows them to send email as your domain, even if SPF is configured correctly.
Does DNSSEC slow down DNS queries?
Slightly — DNSSEC responses are larger because they include signature records, and validation adds a small computational step at the resolver. In practice the difference is imperceptible (milliseconds) for end users, and most modern resolvers cache validated results aggressively.
My registrar doesn't support DNSSEC — what can I do?
You have two options: switch to a registrar that supports DNSSEC (Cloudflare Registrar, Porkbun, Namecheap, GoDaddy, Google Domains all do), or use a DNS provider that is also your registrar so they can handle both steps. DNSSEC requires cooperation between your DNS provider and registrar — you can't enable it with an unsupportive registrar.
Should I use algorithm 8 (RSA/SHA-256) or 13 (ECDSA P-256)?
Algorithm 13 (ECDSA P-256/SHA-256) is recommended for new deployments — smaller key sizes, faster validation, and equivalent security. Algorithm 8 is widely supported and still fine. Avoid algorithms 1, 3, 5 and 6, which are deprecated.