DNSSEC Setup Guide Protect Your Domain From DNS Spoofing

DNS spoofing and cache poisoning attacks are not theoretical threats. Attackers who successfully poison a resolver cache can redirect your users to fake sites, intercept email, and steal credentials without anyone noticing until the damage is done. DNSSEC — the DNS Security Extensions — closes that hole by adding cryptographic signatures to every DNS record your zone publishes. When a validating resolver fetches a record, it checks the signature chain all the way back to the root. If anything has been tampered with, the query fails instead of silently handing back a forged answer. This guide walks through the complete DNSSEC setup process: how signing works, how to generate and publish keys, how to submit your DS record to your registrar, and how to verify everything is working correctly.

How DNSSEC Signatures Actually Work

Before touching any configuration, it helps to understand the three key record types DNSSEC introduces, because you will see them referenced constantly in error messages and audit tools.

• DNSKEY — Contains the public key published in your zone. There are two flavours: the Zone Signing Key (ZSK) used to sign individual records, and the Key Signing Key (KSK) used to sign the ZSK itself.
• RRSIG — The actual cryptographic signature attached to each resource record set. Resolvers use the public DNSKEY to verify these.
• DS (Delegation Signer) — A hash of your KSK that lives at your parent zone (the TLD registry), submitted via your registrar. This is what connects your zone to the global chain of trust.

The chain goes: root zone signs the TLD (.com, .ca, .net), the TLD publishes your DS record, your DS record points to your KSK, your KSK signs your ZSK, and your ZSK signs all the records in your zone. Break any link and validation fails. The goal of this guide is to build that chain correctly the first time.

Step 1: Decide Where Your Zone Is Signed

There are two common scenarios, and the process differs between them.

1. Your DNS hosting provider signs the zone for you — Cloudflare, AWS Route 53, Google Cloud DNS, and most major managed DNS platforms have a one-click or API-driven DNSSEC feature. You enable it in the dashboard, they generate the keys and sign the zone automatically, and then give you the DS record values to take to your registrar.
2. You run your own authoritative name server (BIND, Knot, NSD, PowerDNS) — You generate the keys yourself, configure the signing policy, and extract the DS record from the resulting KSK.

Both paths end at the same destination: a DS record entered at your domain registrar. The difference is only in how you get there.

Step 2: Enable DNSSEC on Managed DNS Providers

Cloudflare

Log in to your Cloudflare dashboard, select the domain, and go to DNS > Settings. Scroll to the DNSSEC section and click Enable DNSSEC. Cloudflare will display a DS record with the Key Tag, Algorithm, Digest Type, and Digest fields populated. Copy all four values — you will paste them at your registrar in Step 4.

AWS Route 53

Open the Route 53 console, navigate to Hosted Zones, select your zone, and choose Enable DNSSEC signing. Route 53 will create a KSK in AWS Key Management Service (KMS). Once signing is active, click View information to create DS record and copy the DS record output. Note: Route 53 DNSSEC requires the hosted zone to be in us-east-1 regardless of where your resources live.

Google Cloud DNS

In the Cloud Console, go to Network Services > Cloud DNS, click your zone name, then DNSSEC in the left panel. Set the state to On and choose an algorithm (ECDSAP256SHA256 is the modern default). After a minute, the DS records will appear on the same panel. Export them before navigating away.

Step 3: Sign the Zone on a Self-Hosted Name Server

If you run BIND 9.16 or newer, the simplest approach is to use the built-in dnssec-policy directive, which handles key generation, rotation, and signing automatically.

Add this inside your zone block in named.conf:

Create the key directory and reload BIND:

BIND will generate both the KSK and ZSK, sign the zone inline, and write the key files to /etc/bind/keys. To extract your DS record, run:

The output will look something like this:

For Knot DNS, add dnssec-signing: on to the zone section in knot.conf and run knotc zone-sign example.com. The DS record is extracted with keymgr example.com ds.

For PowerDNS Authoritative Server with the pdnsutil tool:

The output of show-zone includes the DS record lines near the top.

Step 4: Submit the DS Record at Your Registrar

This is the step most people get wrong because registrar interfaces vary wildly. The DS record has four fields: Key Tag, Algorithm, Digest Type, and Digest. Do not confuse the DS record with the DNSKEY record — they look similar but are not the same thing.

Common Registrar Locations

• Namecheap — Domain List > Manage > Advanced DNS > DNSSEC section at the bottom of the page.
• GoDaddy — My Products > DNS > scroll to DNSSEC. GoDaddy uses a five-field form that includes an optional "Public Key" field — leave it blank unless your provider supplies it.
• Google Domains / Squarespace Domains — DNS > DNSSEC (toggle) > Add DS Record. Google's interface auto-detects Cloudflare DS records if Cloudflare is the nameserver, but for other providers you enter them manually.
• Tucows / OpenSRS / Hover — Domain Manager > DNSSEC tab. If you do not see a DNSSEC tab, the registrar may not support it and you will need to transfer to one that does.
• Porkbun — Details > DNSSEC > Add DS Record.

After saving, the registrar transmits your DS record to the TLD registry. Propagation of DS records typically takes 1–24 hours because TLD zones have conservative TTLs.

Step 5: Verify the DNSSEC Chain of Trust

Do not skip this step. A misconfigured DNSSEC deployment is worse than no DNSSEC at all — it will cause SERVFAIL responses for your entire domain on validating resolvers, making your site and email unreachable for a significant portion of internet users.

Check With dig

Look for the ad flag (Authenticated Data) in the response flags line. If you see flags: qr rd ra ad, validation passed. If the ad flag is absent but you get an answer, DNSSEC is not yet validated. If you get SERVFAIL with no answer, validation is failing — start debugging immediately.

Check the DS Record Specifically

This should return one or more DS record lines. If it returns nothing, your registrar has not yet published the record or it has not propagated yet.

Verify the Full Chain With Drill

The drill tool from ldns traces the entire delegation chain and explicitly marks each step as secure or insecure. It is the fastest way to pinpoint exactly where a chain break is occurring.

Use the Online Validators

The DNS Lookup tool lets you query for DNSKEY and DS record types directly from the browser without installing anything. DNSVIZ (dnsviz.net) generates a visual graph of the entire chain of trust and highlights any broken links in red — highly recommended for a final sanity check before declaring the deployment done.

Troubleshooting Common DNSSEC Failures

SERVFAIL After Enabling DNSSEC

The most common cause is submitting the DS record to your registrar before the signed zone is fully propagated from your authoritative servers. Resolvers fetch the DS record, try to validate, contact your nameservers, and find unsigned records or the wrong DNSKEY. Fix: ensure the signed zone is live on all authoritative nameservers before submitting the DS record. Run dig DNSKEY example.com @ns1.yourprovider.com against each nameserver and confirm all return matching DNSKEY records.

Algorithm Mismatch

If your registrar shows algorithm number 5 (RSA/SHA-1) but your DNS provider generated keys with algorithm 13 (ECDSA P-256/SHA-256), some validators will reject the chain. Always use algorithm 13 (ECDSAP256SHA256) or algorithm 8 (RSASHA256) for new deployments. Algorithm 5 and 7 are deprecated.

Expired Signatures

RRSIG records have an expiry date. If your signing server goes offline or key rotation fails, signatures expire and resolvers start returning SERVFAIL. On managed platforms this is handled automatically. On self-hosted BIND with dnssec-policy, ensure the BIND process is running and the named service is not stuck. Check with:

The output shows the signature expiry timestamp. If it is in the past, resign the zone immediately with rndc sign example.com.

DS Record Points to Wrong Key

If you recently rolled your KSK and submitted a new DS record but deleted the old one too quickly, there will be a window where resolvers holding the old DS record cannot validate the new KSK. Always keep both old and new DS records active at the registrar during a KSK rollover for at least the TTL of the DS record (usually 24–48 hours).

Preventing DNSSEC Outages

DNSSEC requires ongoing maintenance. A set-and-forget approach will eventually cause an outage. These practices will keep your deployment healthy:

• Monitor signature expiry — Set up a monitoring check that queries an RRSIG record and alerts you when the expiry is within 7 days. Nagios, Zabbix, and Prometheus all have DNSSEC check plugins.
• Automate key rollover — Use your DNS platform's built-in rollover scheduling. BIND's dnssec-policy handles this automatically. Do not manage key rollover manually unless you have documented procedures and at least two people who understand the process.
• Do not remove DS records impulsively — If you are migrating DNS providers, the safe order is: (1) enable DNSSEC on the new provider, (2) add the new provider's DS record at your registrar alongside the old one, (3) migrate nameservers, (4) wait 48 hours, (5) remove the old DS record. Skipping any step causes outages.
• Test after any zone change — After adding new record types or making bulk changes, run dig +dnssec against the modified records to confirm signatures are present and the ad flag appears.
• Keep registrar contact details current — Some registrars will send DS expiry warnings by email. Make sure those emails reach someone who acts on them.

Algorithm Recommendations for New Deployments

If you have a choice of signing algorithm, use ECDSAP256SHA256 (algorithm 13). It produces smaller keys and signatures than RSA equivalents, meaning less DNS response bloat and lower risk of hitting the 512-byte UDP limit that causes fallback to TCP. Algorithm 13 is supported by all major resolvers including BIND 9.10+, Unbound 1.6+, and all cloud DNS platforms. For extremely high-security environments, Ed25519 (algorithm 15) is also available on BIND 9.12+ and Knot DNS 2.7+ but has slightly less universal support among older enterprise resolvers.

What DNSSEC Does Not Do

DNSSEC prevents forged DNS responses but it does not encrypt DNS traffic. A passive observer on the network can still see which domains you are querying. For query privacy, that requires DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) in addition to DNSSEC — they solve different problems and both are worth deploying. DNSSEC also does not protect against a compromised authoritative server or registrar account. If an attacker gains access to your registrar account and changes your DS record or nameservers, DNSSEC provides no defence. Enable multi-factor authentication on your registrar account and use registrar lock on your domain to prevent unauthorised transfers or nameserver changes.

Confirming the Deployment Is Complete

Run through this final checklist before closing the ticket:

1. DNSKEY records are present on all authoritative nameservers for your zone.
2. All A, AAAA, MX, CNAME, and TXT records have corresponding RRSIG records.
3. DS record is visible in the parent TLD zone via dig DS example.com @a.gtld-servers.net.
4. dig +dnssec example.com @8.8.8.8 returns the ad flag.
5. DNSVIZ shows a clean green chain with no broken links.
6. Email deliverability is unaffected — test by sending a message and checking headers for DMARC pass.
7. An alert is configured to notify you of signature expiry or validation failure.

DNSSEC is one of the most impactful security controls you can apply to a domain. It is also one of the most punishing to misconfigure. Follow the steps in order, verify at each stage, and you will have a fully validated zone that protects your users from DNS-based attacks without any visible disruption to your services.