DNSSEC has a reputation for being complicated. That reputation is mostly deserved, but the actual setup on modern DNS providers takes about ten minutes. The hard part is understanding what it does and why, so you don't misconfigure it and silently break your domain for a subset of users.
This is that guide.
What DNSSEC actually does
DNS responses have no built-in authentication. When a resolver asks your nameserver "what's the IP for yourapp.com," there's nothing in the original protocol that proves the answer came from you and wasn't modified in transit. Cache poisoning attacks (Kaminsky, 2008) exploited exactly this.
DNSSEC adds cryptographic signatures to your DNS records. Each record set gets signed with a private key. Resolvers that support DNSSEC validation can verify those signatures against a public key published in your zone. If the answer was tampered with, validation fails and the resolver returns an error instead of a forged response.
It does not encrypt DNS traffic. Someone watching the network can still see what domains you're querying. That's what DNS over HTTPS (DoH) and DNS over TLS (DoT) are for, which is a separate topic. DNSSEC is about integrity, not confidentiality.
The key concepts you need before touching anything
Zone Signing Key (ZSK) signs your actual DNS records (A, MX, CNAME, etc.). It rotates frequently, typically every 30-90 days depending on your provider.
Key Signing Key (KSK) signs the ZSK. It rotates less often and is the one that gets published up the chain to your parent zone (your TLD's nameservers).
DS record is a hash of your KSK that lives in the parent zone. This is the link in the chain of trust. When you enable DNSSEC, your registrar takes your DS record and publishes it in the TLD zone. Resolvers walk up this chain to verify your signatures.
NSEC/NSEC3 records prove that a name doesn't exist. Without them, an attacker could return NXDOMAIN for a name that actually exists and you'd have no way to verify they're lying. NSEC3 hashes the names so you're not exposing your full zone contents in the process.
If this sounds like a lot, managed DNSSEC on most providers handles all of it for you. You enable it, copy a DS record to your registrar, and the provider rotates keys automatically.
Setup by provider
Cloudflare
Cloudflare's DNSSEC is one click. Go to DNS > Settings > DNSSEC and enable it. Cloudflare gives you a DS record to add at your registrar. That's it. Key rotation is automatic and you never have to think about it again.
The one thing to check: if you're using Cloudflare as a proxy (orange cloud), DNSSEC only covers the DNS layer. The traffic between Cloudflare and your origin is a separate concern.
AWS Route 53
Route 53 added managed DNSSEC in 2020. In the console, go to your hosted zone, select DNSSEC signing, and enable it. AWS creates a KSK backed by a KMS key in your account, which you can see and control.
After enabling, Route 53 shows you the DS record. You add that record at your domain registrar. If your registrar is Route 53 as well, there's a button to do it automatically.
One Route 53 gotcha: the KMS key has to be in us-east-1. If your infrastructure is in another region, the key still needs to live there. This surprises people.
Google Cloud DNS
Go to your Cloud DNS zone, click DNSSEC, enable it. Google manages key rotation automatically. You get a DS record to copy to your registrar. Same pattern as the others.
Self-hosted BIND or NSD
This is where it gets manual. You need to generate your ZSK and KSK with dnssec-keygen, sign your zone with dnssec-signzone, and set up automated re-signing before signatures expire. If you're running your own nameservers and haven't done this before, the official BIND documentation is the right starting point. The managed provider path is meaningfully easier.
The DS record and your registrar
This step is where most DNSSEC setups fail. Enabling signing on your DNS provider is only half the job. The DS record has to be published in the parent zone (the TLD), and that happens through your registrar.
Every registrar has a different UI for this. You're looking for something called "DNSSEC," "DS records," or "domain security." You'll paste in four fields: key tag, algorithm, digest type, and digest. These come directly from your DNS provider after you enable signing.
If you change DNS providers later, you have to update the DS record at your registrar before you disable DNSSEC on the old provider. The failure mode is ugly: resolvers that validate DNSSEC will return SERVFAIL for your domain, which looks like your site is down to roughly 30% of users (the ones whose resolvers validate). The other 70% will see nothing wrong. This makes it hard to diagnose.
Checking your setup
After enabling DNSSEC and adding the DS record, give it 15-30 minutes to propagate, then verify:
# Check if your zone is signed
dig DNSKEY yourapp.com +short
# Check if the DS record is in the parent zone
dig DS yourapp.com @8.8.8.8 +short
# Full validation check
dig yourapp.com +dnssec +short
For a more readable output, dnsviz.net generates a visual graph of your DNSSEC chain of trust. It's the clearest way to see if something is broken.
DANE Validator is useful if you're also doing TLSA records for email.
What breaks when you get it wrong
Signature expiry. DNSSEC signatures have an expiration date. If your provider doesn't auto-rotate and you forget to re-sign, signatures expire and validating resolvers start returning SERVFAIL. This has taken down larger domains than you'd expect. With a managed provider, this is their problem. On self-hosted DNS, put re-signing on a cron job with monitoring.
DS/DNSKEY mismatch. If you publish a DS record at your registrar that doesn't match the KSK on your nameserver, validation fails for everyone. This usually happens during a provider migration where someone enabled DNSSEC on the new provider before updating the DS record.
Removing DNSSEC incorrectly. If you want to disable DNSSEC: remove the DS record at your registrar first, wait for TTL to expire, then disable signing on your provider. Doing it in the wrong order is the same failure mode as the migration problem above.
Monitoring after setup
DNSSEC is one of those things that works silently when it's right and breaks loudly when it's wrong. The breakage is often partial, which makes it worse to debug. Automated monitoring that continuously checks your DNSSEC chain and alerts you if signatures are about to expire or if the DS record stops matching is worth having.
ZeroHook monitors DNS record changes and flags anomalies, including DNSSEC issues, without you having to remember to check manually: zerohook.org.
TL;DR
DNSSEC signs your DNS records so resolvers can verify the answers haven't been tampered with. On managed providers (Cloudflare, Route 53, Google Cloud DNS), setup is: enable signing, copy DS record to registrar, done. The common failure modes are forgetting the DS record step, and misconfiguring during provider migrations.
If you're on a managed provider and haven't enabled it yet, you can do it right now. It takes ten minutes and you're protected against a whole class of attacks that otherwise have no defense at the DNS layer.
Part of an ongoing series on DNS security. Previous posts: DNS hijacking · Certificate Transparency logs · Subdomain takeover and dangling DNS
Top comments (0)