What is DNSSEC and how does it work

What is DNSSEC

DNSSEC (Domain Name System Security Extensions) is a set of extensions to the DNS protocol that adds cryptographic verification to DNS responses. It is defined by three RFCs: RFC 4033, RFC 4034, and RFC 4035.

Standard DNS operates on trust — a resolver accepts responses from authoritative servers without any verification. An attacker who can position themselves between the resolver and the authoritative server can forge responses. DNSSEC solves this: every DNS response carries a cryptographic signature that the resolver verifies before passing data to the application.

Why plain DNS is not enough

DNS was designed in the 1980s as a simple system for translating domain names to IP addresses. The protocol was never designed to verify responses — a resolver has no way to tell whether a response came from a legitimate server or an attacker.

The most well-known vulnerability is DNS cache poisoning. An attacker sends a forged response to a resolver before the legitimate response arrives. The resolver stores the forged response in its cache, and all its users then receive false data — for the duration of the record's TTL.

In 2008, security researcher Dan Kaminsky demonstrated that DNS cache poisoning was significantly easier than previously assumed. This finding dramatically accelerated DNSSEC adoption worldwide.

How DNSSEC works

DNSSEC adds four new record types to DNS that together form a chain of trust from the root zone down to individual domains.

Key record types

Chain of trust

DNSSEC works hierarchically, mirroring DNS itself:

1. The root zone has a public key known to every validating resolver. This key is the trust anchor.
2. The root zone signs the DS record for a TLD (e.g., .com).
3. The .com TLD has its own DNSKEY and signs the DS record for your domain (example.com).
4. Your domain example.com has its own DNSKEY and signs all its DNS records (A, MX, TXT, ...) using RRSIG.

The resolver validates the entire chain from the root: if every signature matches the key of the parent zone, the response is trustworthy. If any signature in the chain fails, the resolver rejects the response.

Verification example

When a resolver looks up the MX record for example.com:

1. It queries the root server for .com — receives the DS record for .com signed by the root key.
2. It queries the .com server for example.com — receives the DS record for example.com signed by the .com key.
3. It queries the authoritative server for example.com for MX — receives the MX record and its RRSIG.
4. It verifies the RRSIG using the DNSKEY for example.com, verifies the DNSKEY's link to the DS in the parent zone, and so on back to the root.

The entire process is automatic at the resolver level — users and applications are unaware of it.

Why DNSSEC matters for email authentication

SPF, DKIM, and DMARC records are published in DNS as TXT records. MX records determine where emails are delivered. Without DNSSEC, an attacker can forge these records and bypass email authentication entirely:

• MX record spoofing: an attacker redirects emails to their own server and reads someone else's mail.
• SPF record spoofing: an attacker modifies the list of authorized sending servers — legitimate emails fail, forged ones pass.
• DKIM record spoofing: an attacker replaces the public key with their own — they can sign emails on behalf of another domain.
• DMARC record spoofing: an attacker changes the policy from reject to none — forged emails pass unnoticed.

DNSSEC ensures that the resolver receives authentic DNS records. SPF, DKIM, and DMARC then operate on verified data.

How to check if your domain has DNSSEC

Online tool

The quickest way is to check your domain with our analyzer — the results include DNSSEC status.

Using dig command

Alternatively, you can inspect the records via DNS lookup or in the terminal. Query your domain's DNSKEY record:

dig example.com DNSKEY +short

If the command returns one or more keys, your domain has DNSSEC enabled. An empty response means DNSSEC is not deployed.

Check the DS record in the parent zone:

dig example.com DS +short

The DS record must exist at the TLD registrar — without it, the chain of trust does not work, even if your domain has a DNSKEY.

How to enable DNSSEC

Enabling DNSSEC requires cooperation between two parties: your DNS provider (hosting) and your domain registrar.

1. Sign your zone

Your DNS provider (authoritative server) must generate keys and sign all records in the zone. Most modern DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS) handle this automatically — you just need to enable DNSSEC in the admin panel.

2. Submit the DS record to your registrar

After signing the zone, you'll get a DS record. You need to submit it to your domain registrar, who passes it to the parent zone (TLD). Some registrars automate this step when you enable DNSSEC.

3. Verify it works

After activation, wait for DNS propagation (typically a few hours) and verify the chain of trust. Check your domain with our analyzer or use the delv command:

delv example.com A +rtrace

DNSSEC limitations

DNSSEC is not a silver bullet and has its limitations:

• Does not encrypt DNS traffic: DNSSEC verifies the authenticity of responses, but data travels unencrypted. For DNS query encryption, use DNS over HTTPS (DoH) or DNS over TLS (DoT) — they complement DNSSEC, not replace it.
• Increases DNS response size: signatures (RRSIG) increase DNS response sizes, which can cause issues with UDP packet fragmentation.
• Requires proper key management: expired signatures or botched key rollovers can make an entire domain unreachable.
• Depends on a validating resolver: if the user's resolver does not validate DNSSEC, the protection is ineffective. Most major public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) do validate DNSSEC.

DNSSEC in context of email security

DNSSEC works alongside other protocols to create layered protection:

DANE (DNS-Based Authentication of Named Entities) is the only protocol that directly requires DNSSEC. It allows publishing a TLS certificate fingerprint in a TLSA DNS record — the recipient then verifies the mail server's certificate directly via DNS instead of relying on certificate authorities.

Check your domain's security — the analyzer verifies SPF, DKIM, DMARC, and DNSSEC all at once.