Every time someone types your domain name into a browser, a DNS resolver has to translate that name into an IP address. That lookup travels across multiple servers, and at every hop there is an opportunity for an attacker to inject a forged answer. This attack is called DNS cache poisoning, or DNS spoofing, and without DNSSEC in place there is nothing in the classic DNS protocol to tell a resolver whether the answer it received is legitimate or fabricated. DNSSEC — the Domain Name System Security Extensions — fixes that problem by adding cryptographic signatures to DNS records, letting resolvers verify authenticity before trusting any answer.
What DNS Spoofing Actually Looks Like
DNS was designed in the early 1980s for a cooperative, trusted network. There was no authentication built in. A resolver asks a question, and whatever answer arrives first is accepted. That design flaw becomes dangerous in a world of BGP hijacks, on-path attackers at public Wi-Fi hotspots, and compromised upstream resolvers.
In a classic cache poisoning attack, an attacker floods a recursive resolver with forged UDP responses that pretend to come from an authoritative name server. Because DNS transaction IDs are only 16 bits wide, brute-forcing the correct ID is feasible. When the forged packet arrives before the real answer, the resolver caches the fake record. Every user who queries that resolver then gets directed to the attacker's server — a perfect platform for credential phishing, malware delivery, or man-in-the-middle interception of HTTPS traffic before the TLS handshake even begins.
The Kaminsky attack of 2008 made this vivid for the security community. It demonstrated that a single attacker with a consumer-grade internet connection could poison the cache of a major ISP's resolver in under a minute. Patches improved randomisation of source ports and transaction IDs, but the fundamental problem — no authentication — remained unsolved at the protocol level. DNSSEC is the protocol-level solution.
How DNSSEC Works
DNSSEC extends DNS by adding four new record types that together create a chain of cryptographic trust from the DNS root all the way down to individual records on your domain.
The Four Key Record Types
- RRSIG (Resource Record Signature): A digital signature over a set of DNS records. When a resolver retrieves an A record, it also retrieves the RRSIG for that record set and verifies the signature using the zone's public key.
- DNSKEY: Stores the public key for a DNS zone. There are typically two keys: the Zone Signing Key (ZSK) used to sign individual record sets, and the Key Signing Key (KSK) used to sign the DNSKEY record set itself.
- DS (Delegation Signer): A hash of the child zone's KSK, stored in the parent zone. This is what creates the chain of trust — the parent vouches for the child's key.
- NSEC / NSEC3: Used to provide authenticated denial of existence. If you query for a record that does not exist, these records let the resolver prove cryptographically that no such record exists, preventing an attacker from fabricating NXDOMAIN responses.
The Chain of Trust
The trust chain starts at the DNS root zone, which is signed by ICANN. The root publishes DS records for each signed top-level domain (TLD) like .com, .net, or .org. The TLD zone publishes DS records for signed second-level domains. Your registrar is responsible for uploading your domain's DS record (or the raw DNSKEY) to the TLD registry when you enable DNSSEC. A validating resolver — one that supports DNSSEC — walks up this chain when resolving your domain, verifying each signature against the parent's DS record until it reaches the root, which it already trusts via a hard-coded trust anchor.
If any signature in that chain is missing, expired, or does not match, the resolver returns SERVFAIL rather than handing the user a potentially poisoned answer. That failure mode is intentional: a hard fail is safer than silently serving forged data.
How to Enable DNSSEC on Your Domain
The exact process depends on whether your DNS is hosted by your registrar or by a third-party DNS provider. The two-step pattern is always the same: sign the zone, then upload the DS record to the parent TLD registry via your registrar.
Option 1: Registrar-Hosted DNS (One-Click Setup)
Most major registrars — Cloudflare, Namecheap, GoDaddy, Google Domains / Squarespace Domains — handle signing automatically if you use their nameservers. The process is roughly:
- Log in to your registrar's dashboard and navigate to your domain's DNS settings.
- Find the DNSSEC section (sometimes under Advanced DNS or Security).
- Toggle DNSSEC on. The registrar generates the ZSK and KSK, signs the zone, and automatically pushes the DS record to the TLD registry.
- Wait for propagation — DS records typically appear within 30 to 60 minutes for .com and .net, longer for some country-code TLDs.
On Cloudflare, go to your domain dashboard, click DNS, then the DNSSEC tab, and click Enable DNSSEC. Cloudflare handles everything automatically including key rollovers.
On Namecheap, go to Domain List, click Manage next to your domain, then the Advanced DNS tab, and scroll to DNSSEC. Toggle it on if Namecheap hosts your DNS.
Option 2: Third-Party DNS Provider with Manual DS Upload
If you use a DNS provider like AWS Route 53, Cloudflare (with a third-party registrar), or self-hosted BIND, you need to get the DS record from the DNS provider and paste it into your registrar.
On AWS Route 53, navigate to your hosted zone, click Enable DNSSEC signing, and Route 53 will display a DS record. Copy the key tag, algorithm, digest type, and digest values. Then go to your registrar and add a DS record in their DNSSEC / DS record panel with those exact values.
For self-hosted BIND 9.16+, DNSSEC signing can be fully automated with a single policy directive in your zone configuration:
After reloading BIND, retrieve the DS record to upload to your registrar:
The output gives you the exact string to paste into your registrar's DS record form.
Verifying DNSSEC Is Working Correctly
Never assume DNSSEC is working just because you clicked enable. A misconfigured or partially deployed DNSSEC setup is worse than no DNSSEC at all — validating resolvers will refuse to answer queries for your domain entirely.
Command-Line Verification
Use dig with the +dnssec flag to check for RRSIG records and the ad (Authenticated Data) bit in the response flags:
In the response, look for the ad flag in the flags line and an RRSIG record below your A record. If you see both, the chain of trust is complete and Google's resolver successfully validated your zone.
To check that your DS record is present in the parent zone:
A non-empty response means the TLD registry has your DS record. An empty response means the DS was not uploaded, or has not yet propagated.
To test what a DNSSEC-validating resolver sees when things go wrong (for testing purposes on a lab domain), you can use:
The +cd (checking disabled) flag tells the resolver to return the answer even if validation fails, which lets you compare the result with and without validation to isolate the problem.
Online Tools
The DNS Lookup tool on this site lets you query DS, DNSKEY, and RRSIG records directly from your browser without needing a terminal. Enter your domain, select the record type, and check that keys and signatures are present. For a full chain-of-trust analysis, Verisign's DNSSEC Debugger and DNSViz are the industry-standard graphical validators.
Common DNSSEC Problems and How to Fix Them
SERVFAIL After Enabling DNSSEC
The most common cause is a missing or incorrect DS record at the registrar. The zone is signed, but the parent has no DS record, so resolvers cannot build the chain of trust. Log in to your registrar, check the DNSSEC / DS record section, and verify the key tag and digest match what your DNS provider shows. If you recently migrated DNS providers, the old DS record may still be in place pointing to a key that no longer exists.
Expired RRSIG Records
RRSIG records have a validity period, typically between one and four weeks. If your signing software stops re-signing the zone (a cron job dies, an API key expires, a server goes offline), signatures expire and the zone breaks for all validating resolvers. Monitor signature expiry. BIND's dnssec-policy and Cloudflare's automatic management handle re-signing transparently. For manual setups, set up alerting when the nearest RRSIG expiry is within 72 hours.
Key Mismatch After DNS Provider Migration
When you move from one DNS provider to another, you must remove the old DS record from your registrar before pointing nameservers to the new provider. If you flip nameservers without updating the DS record, resolvers will look for a key that the new provider does not have, and validation will fail. The safe migration sequence is: disable DNSSEC at the old provider, remove the DS record from your registrar, wait for the DS TTL to expire, update nameservers, enable DNSSEC at the new provider, upload the new DS record.
DNSSEC Limitations to Understand
DNSSEC authenticates DNS answers but does not encrypt them. Queries and responses are still visible to anyone on the network path. DNS over HTTPS (DoH) and DNS over TLS (DoT) address privacy; DNSSEC addresses integrity. They solve different problems and are complementary.
DNSSEC also does not protect against a compromised authoritative server. If an attacker gains control of your DNS provider account and changes your records, those forged records will be signed with your legitimate keys and will validate correctly. DNSSEC validates the chain of custody in the DNS infrastructure, not the legitimacy of whoever controls your account. Strong authentication on your DNS provider account — hardware MFA at minimum — is essential.
Zone enumeration is partially mitigated by NSEC3 with opt-out, but determined attackers can still enumerate zones offline given enough NSEC3 responses. If your zone contains sensitive subdomains, keep them out of public DNS entirely rather than relying on DNSSEC to hide them.
Why You Should Enable DNSSEC Today
Major TLDs have supported DNSSEC for over a decade. Public resolvers from Google (8.8.8.8), Cloudflare (1.1.1.1), and most ISPs validate DNSSEC by default. Browser vendors and operating systems increasingly use validating resolvers. The cost of enabling DNSSEC on a registrar-hosted domain is approximately two minutes of your time. The cost of a successful DNS spoofing attack against your domain — credential theft, malware distribution, regulatory exposure — is orders of magnitude higher.
For domains handling financial transactions, login pages, email (where DANE records depend on DNSSEC), or any sensitive user data, DNSSEC is not optional. It is foundational infrastructure hygiene that sits alongside HTTPS, DMARC, and MFA as a baseline security control that every domain owner should have in place.