DNSSEC Explained: How Signed Domains Prevent DNS Spoofing

DNS answers are unsigned by default, which means any resolver between you and a site can be tricked into returning the wrong IP. DNSSEC fixes that by signing every record, and a DNSSEC checker tells you in seconds whether a domain actually uses it. This post explains what DNSSEC is, how validation works, and why signed domains matter for anyone running services.

The DNS Spoofing Problem

DNS is a plaintext, connectionless protocol. A query goes out over UDP, an answer comes back, and nothing in the protocol verifies that the answer came from the real server. That gap enables cache poisoning: an attacker injects a forged record into a recursive resolver’s cache, and every user served by that resolver now resolves the victim domain to the attacker’s IP. The classic 2008 Kaminsky attack automated this at scale, and on-path attackers can forge answers for any domain while DNS traffic is in flight.

The result is silent traffic hijacking. Users type the right domain, the browser dials the wrong server, and the TLS certificate they eventually see is the only remaining check — which is why unsigned DNS remains a weak link even for sites that do everything else right.

How DNSSEC Validation Works

DNSSEC adds public-key cryptography to the DNS tree. Each signed zone publishes a zone-signing key (DNSKEY) and signs its records into RRSIG records. A validating resolver walks a chain of trust up to the root, verifying each layer:

1. The parent zone publishes a DS record containing a digest of the child’s DNSKEY.
2. The resolver verifies the child’s DNSKEY against the parent’s DS record.
3. The resolver verifies the zone’s RRSIG signatures against the DNSKEY.
4. If everything checks out, the answer is marked authentic.

Any break in the chain — a bad signature, a DS mismatch, a stripped record — makes the answer bogus, and a validating resolver discards it with SERVFAIL rather than serving it. You can see the result from the command line:

dig +dnssec checksec.dev A

# ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1
# ;; ANSWER SECTION:
# checksec.dev.  300  IN  A  185.199.108.153
# checksec.dev.  300  IN  RRSIG  A 13 2 300 ...

The ad flag is the tell. It stands for “authentic data” and is set only when the resolver verified the signatures. Its absence does not prove the zone is unsigned — the client resolver may simply not be validating — which is exactly why you need a proper check rather than eyeballing one dig.

DS Records: How the Chain Connects

The DS record is the linchpin. DNSSEC is not enabled by publishing keys in your own zone alone; the parent zone must also publish your DS record, because that is what lets resolvers trust your key. In practice you enable signing at your DNS provider and the provider submits the DS record to your registrar. Break that link and the domain becomes unresolvable for validating resolvers — a common cause of “the site stopped resolving after enabling DNSSEC.” A good dnssec checker reports on both sides of the link: the domain’s DNSKEY chain and the DS record published by the parent.

Why Signed Domains Matter

Signing is the difference between trusting a web of unverifiable claims and having cryptographic proof. It stops cache poisoning dead, which protects email delivery, API calls, and any client that resolves hostnames before connecting. It also hardens adjacent systems: CAA records, which constrain which CAs may issue certificates for your domain, are only trustworthy when DNSSEC-protected. Governments now require DNSSEC on their own domains, and infrastructure operators increasingly expect it upstream. An unsigned domain remains spoofable no matter how strong its TLS and application security are, because the lookup itself is the attack surface.

How to Check a Domain’s DNSSEC Status

Run the DNSSEC checker on any domain you control to see whether it is signed, whether the DS record is present and correct, and whether validating resolvers would accept it. For your own domains, the fix when unsigned is to enable DNSSEC at your DNS provider, confirm the DS record publishes at your registrar, and re-check until validation passes.

Next step: run a free DNSSEC check on every domain you operate, and enable signing at your DNS provider for any that come back unsigned.

More posts →