DNSSEC Explained: How DNS Security Extensions Protect Your Domain
The Domain Name System (DNS) is the internet's phone book — it translates human-readable domain names into IP addresses. But DNS was designed in the 1980s without security in mind. DNSSEC (DNS Security Extensions) was created to address this fundamental vulnerability. Here is how it works and why it matters.
The Problem DNSSEC Solves: Cache Poisoning
In a DNS cache poisoning attack (also called DNS spoofing), an attacker injects forged DNS records into a resolver's cache. When users query that resolver for your domain, they receive the attacker's IP address instead of yours — and are redirected to a malicious server without any visible warning.
This type of attack can be used to intercept login credentials, serve phishing pages that look exactly like your website, redirect email, or distribute malware. Because the redirection happens at the DNS level — before the browser even makes a connection — even HTTPS does not fully protect against it.
Real-world example — in 2018, the DNSpionage campaign redirected DNS records for multiple government and corporate websites in the Middle East, successfully intercepting VPN and email credentials. DNSSEC would have prevented this attack.
How DNSSEC Works: Digital Signatures
DNSSEC adds cryptographic signatures to DNS records. When a resolver receives a DNS response, it can verify that the data has not been tampered with by checking the signature against a public key stored in the DNS hierarchy itself.
Here is the chain of trust:
- Root Zone: The root DNS servers sign the TLD zones (.com, .org, .io, etc.) with the Root Key Signing Key (KSK). The root zone's trust anchor is hardcoded into resolvers.
- TLD Zone (.com): The TLD registry signs delegations to authoritative nameservers for each domain (example.com) using DS (Delegation Signer) records.
- Domain Zone (example.com): Your authoritative nameserver signs its own records (A, MX, CNAME, etc.) using a Zone Signing Key (ZSK). The ZSK is in turn signed by the Key Signing Key (KSK).
- RRSIG Record: Each signed DNS record set has an associated RRSIG record containing the signature. Resolvers verify RRSIG against the public key in the DNSKEY record.
Key DNSSEC Record Types
| Record Type | Purpose |
|---|---|
| DNSKEY | Stores the public keys used to verify signatures |
| RRSIG | Cryptographic signature over a set of DNS records |
| DS (Delegation Signer) | Hash of the child zone's KSK, stored in the parent zone to create the chain of trust |
| NSEC / NSEC3 | Proves the authenticated denial of a DNS record's existence (prevents enumeration in NSEC3) |
How to Verify DNSSEC Is Working
You can check DNSSEC status using dig or delv:
# Check if DNSSEC is enabled (look for AD flag in response) dig +dnssec example.com A # Full DNSSEC validation delv @8.8.8.8 example.com A +rtrace # Online alternative — check AD (Authenticated Data) flag dig +short +dnssec +cd example.com DS
Look for the ad (Authenticated Data) flag in the dig response header. Its presence means the resolver has successfully validated the DNSSEC chain. You can also use online tools like dnsviz.net or Verisign's DNSSEC debugger.
DNSSEC Limitations
DNSSEC is powerful but not a complete security solution:
- DNSSEC prevents tampering with DNS records, but does not encrypt DNS queries — use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) for privacy
- Implementation errors in DNSSEC can cause DNS outages (broken signature chains make the domain unreachable)
- Key rotation must be handled carefully — mistakes can invalidate the chain of trust
- DNSSEC adoption among authoritative nameservers remains below 50% globally, though TLD coverage is high for major TLDs
Use our free DNSSEC Checker to verify your domain's DNSSEC configuration is correctly deployed and validation is working across resolvers.