What Is DNSSEC? DNS Security Extensions Explained

DNS was designed in 1983 with no built-in security. Every DNS response is sent in plain text, and nothing in the original protocol prevents an attacker from injecting false records. DNSSEC — DNS Security Extensions — addresses this by adding cryptographic signatures to DNS data, giving resolvers the ability to verify authenticity.

The Problem DNSSEC Solves

Without DNSSEC, DNS is vulnerable to cache poisoning (also called DNS spoofing). In a cache poisoning attack, an attacker injects forged DNS records into a resolver's cache. Victims who query that resolver receive the fake IP address and are silently redirected to a malicious server — often one that mimics a legitimate site to steal credentials or deliver malware.

The Kaminsky attack, discovered in 2008, demonstrated how easily DNS caches could be poisoned at scale. This accelerated adoption of DNSSEC across major TLDs and DNS providers.

DNSSEC does not encrypt DNSDNSSEC validates the authenticity of DNS responses — it proves records come from the authoritative source and have not been altered. It does not encrypt DNS queries or responses. For privacy, separate standards like DNS over HTTPS (DoH) or DNS over TLS (DoT) are needed.

How DNSSEC Works

DNSSEC introduces a chain of trust that extends from the DNS root down to individual domain zones. Each level of the DNS hierarchy signs its data and provides a way for the next level to verify that signature.

Key Record Types in DNSSEC

Record Type	Purpose
DNSKEY	Contains the public key used to verify signatures in a zone
RRSIG	A cryptographic signature for a set of DNS records
DS	A hash of a child zone's DNSKEY, published in the parent zone to create the chain of trust
NSEC / NSEC3	Proves that a domain or record type does not exist (authenticated denial of existence)

The Chain of Trust

The DNSSEC chain of trust works as follows:

The DNS root zone is signed with a well-known key called the Root Trust Anchor, maintained by ICANN. DNSSEC-validating resolvers are pre-configured with this key.
Each TLD (such as .com, .net) publishes a DS record in the root zone. This DS record is a hash of the TLD's DNSKEY, linking the root's trust to the TLD.
When you enable DNSSEC for your domain, your registrar publishes a DS record in the TLD's zone. This links the TLD's trust to your domain's zone.
Your authoritative nameserver signs all records in your zone with an RRSIG, using a private key whose corresponding public key is published as a DNSKEY record.

A DNSSEC-validating resolver follows this chain from the root to your domain, verifying each signature at every step. If any signature is invalid or missing, the resolver treats the response as SERVFAIL — it refuses to return potentially tampered data.

text

Root (.) → signs TLD DS record
└── .net (TLD) → signs domain DS record
    └── example.net → signs all zone records (A, MX, TXT, etc.)
        └── RRSIG covers each record set

DNSSEC Validation

Not all resolvers validate DNSSEC. Validation must be enabled on the resolver. Major public resolvers including Google (8.8.8.8), Cloudflare (1.1.1.1), and most ISP resolvers now perform DNSSEC validation by default.

When a resolver validates a DNSSEC-signed domain, it checks:

That the RRSIG signature over the record set is valid and has not expired.
That the DNSKEY used to create the signature is trusted (via the DS record in the parent zone).
That the DS record in the parent zone is itself signed and trusted (working up to the root).

bash

# Check if a domain has DNSSEC configured
dig example.com DNSKEY +short

# Check the DS record in the parent zone
dig example.com DS +short

# Verify DNSSEC validation — look for "ad" flag in flags section
dig example.com A +dnssec

# Use a DNSSEC-validating resolver explicitly
dig example.com A +dnssec @8.8.8.8

In the dig output, look for the ad (Authenticated Data) flag in the header. If present, the resolver successfully validated the DNSSEC signatures.

text

; <<>> DiG 9.18 <<>> example.com A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, ...
                        ^^
                        "ad" = Authenticated Data (DNSSEC validated)

Check DNSSEC on ShowDNSUse the ShowDNS DNSSEC Validator to instantly check whether a domain has DNSSEC configured and whether validation succeeds.

Key Signing Key vs Zone Signing Key

DNSSEC typically uses two pairs of keys:

KSK (Key Signing Key): A long-lived key that signs the DNSKEY record set. Its public key hash is published as the DS record in the parent zone. This is the "anchor" key.
ZSK (Zone Signing Key): A shorter-lived key used to sign all other record sets in the zone (A, MX, TXT, etc.). It is signed by the KSK.

This separation allows zone operators to rotate the ZSK frequently (improving security) without needing to update the DS record in the parent zone every time.

DNSSEC Limitations and Considerations

DNSSEC is valuable but comes with trade-offs:

Larger responses: DNSSEC adds RRSIG and DNSKEY records, significantly increasing response sizes. This can cause issues with UDP fragmentation and may require TCP fallback.
Key management: Signing keys must be rotated periodically. An expired signature causes SERVFAIL for all resolvers that validate DNSSEC.
Zone enumeration: NSEC records (used for authenticated denial) make it possible to walk the zone and enumerate all records. NSEC3 mitigates this with hashed names.
Amplification attacks: The larger response sizes make DNSSEC-signed zones more attractive for DNS amplification DDoS attacks.
No protection after resolver: DNSSEC only validates data between resolvers and authoritative servers. The "last mile" between your device and the resolver is not covered unless DoH or DoT is used.

How to Enable DNSSEC

Enabling DNSSEC typically involves two steps:

Enable signing on your DNS host: Your DNS hosting provider (Cloudflare, Route 53, Google Cloud DNS, etc.) generates the DNSKEY pair and begins signing zone records.
Publish the DS record at your registrar: Copy the DS record (provided by your DNS host) and enter it in your domain registrar's control panel. This links your zone to the parent zone's chain of trust.

Many modern DNS providers (like Cloudflare) automate both steps when you enable DNSSEC with a single click.

Frequently Asked Questions

Does DNSSEC protect against all DNS attacks?

No. DNSSEC prevents cache poisoning and record tampering by authenticating DNS responses. It does not protect against DDoS attacks on DNS infrastructure, DNS hijacking at the registrar level, or eavesdropping on DNS queries (DoH/DoT addresses that separately).

What happens if a DNSSEC signature expires?

Validating resolvers will return SERVFAIL for any query to the domain until the signature is renewed. The domain becomes effectively unreachable for users on DNSSEC-validating resolvers. This is why key rotation schedules and automated signing are important.

Can I use DNSSEC with any DNS provider?

Not all DNS providers support DNSSEC. Major providers like Cloudflare, AWS Route 53, Google Cloud DNS, and many others do. Check your DNS provider's documentation before enabling DNSSEC.

Is DNSSEC required?

DNSSEC is not required for most websites, but it is strongly recommended for domains where authenticity is critical — financial services, government sites, email-heavy domains, and any domain that could be an attractive target for spoofing attacks.

How do I know if a domain has DNSSEC?

Use the ShowDNS DNSSEC Validator or run dig example.com DNSKEY +short. If the domain has DNSSEC, you will see one or more public key values returned.