Back to Learning Center
DNS Security

DNSSEC Explained: How DNS Security Extensions Protect Your Domain

7 min read
Updated May 2026

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:

1
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.
2
TLD Zone (.com)
The TLD registry signs delegations to authoritative nameservers for each domain (example.com) using DS (Delegation Signer) records.
3
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).
4
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 TypePurpose
DNSKEYStores the public keys used to verify signatures
RRSIGCryptographic 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 / NSEC3Proves 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

Check Your Domain's DNSSEC Status

Our free DNSSEC checker validates your domain's DNSSEC configuration and chain of trust instantly.

Check DNSSEC Now