DNSSEC Explained: Cryptographically Signing Your DNS

The Problem DNSSEC Solves

Standard DNS has no built-in way to verify that a response is genuine. A resolver asks a question and trusts whatever answer comes back – which means DNS is vulnerable to cache poisoning and man-in-the-middle attacks that redirect a hostname to an attacker-controlled IP, without either the resolver or the user having any way to tell the answer was forged.

DNSSEC (Domain Name System Security Extensions) fixes this by having each zone cryptographically sign its own records. A validating resolver can then verify the signature and know the answer wasn’t altered in transit, and genuinely came from the zone’s owner.

The New Record Types

DNSSEC introduces several record types alongside your existing A, MX, and CNAME records:

• RRSIG – the actual digital signature covering a set of records.
• DNSKEY – the public key used to verify RRSIGs for the zone.
• DS (Delegation Signer) – a hash of the child zone’s DNSKEY, published in the parent zone (e.g. the .com registry holds the DS record for example.com), forming the link in the chain of trust.
• NSEC / NSEC3 – used to prove a record doesn’t exist, since you can’t sign something that isn’t there.

Example Records

example.com. DNSKEY 256 3 8 AwEAAdSy7... (zone signing key)
example.com. DNSKEY 257 3 8 AwEAAagT9... (key signing key)
example.com. RRSIG A 8 2 3600 20261001000000 20260901000000 12345 example.com. abcd1234...
example.com. DS 12345 8 2 49FD46E6C4B45C55D4AC...

The RRSIG here covers the A record set, is valid from 1 September to 1 October 2026, and was generated with key tag 12345 – which corresponds to a DNSKEY the resolver can fetch and verify against.

The Chain of Trust

Verification works from the root down:

1. The root zone signs the DS record for .com.
2. .com signs the DS record for example.com.
3. example.com signs its own records (A, MX, etc.) using its DNSKEY.
4. A validating resolver checks each link: does the DS in the parent match a hash of the child’s DNSKEY? Does the RRSIG verify against that DNSKEY?

If every link checks out, the answer is authenticated. If any link is broken or a signature doesn’t match, the resolver returns a SERVFAIL rather than risk serving a forged answer.

Enabling It in Practice

You generally don’t hand-craft these records. Most registrars and DNS providers (Cloudflare, Route 53, most others) will generate and rotate the keys for you – your job is usually just to:

1. Enable DNSSEC signing in your DNS provider’s dashboard.
2. Copy the resulting DS record it gives you.
3. Paste that DS record into your domain registrar’s DNSSEC settings, so it gets published in the parent zone.

Miss that second step and you’ve signed your zone but nobody upstream can verify it – the chain of trust has a missing link.

What DNSSEC Doesn’t Do

It’s worth being clear about the scope: DNSSEC guarantees integrity and authenticity of DNS answers, not confidentiality. Queries and responses are still sent in plaintext and can be observed in transit – that’s a separate problem, addressed by things like DNS over HTTPS or DNS over TLS.

Next: MTA-STS, which uses DNS and a hosted policy file to make sure mail is actually delivered over an encrypted, verified connection.