Domain Name System Security Extensions

What is DNSSEC?

The internet's phone book has no signature on its entries. Anyone who can slip a forged reply in front of you can send you to the wrong address — silently. DNSSEC is the wax seal that makes forgery detectable. Here's how it works, shown not just told.

READ · 12 min LEVEL · Beginner → Practitioner INTERACTIVE · 5 live diagrams UPDATED · 2026-06-01
The 30-second version

DNSSEC in five sentences

  • The problem: plain DNS answers are unauthenticated — a network attacker or poisoned cache can forge them.
  • The fix: DNSSEC adds a digital signature to every DNS record set, so resolvers can verify authenticity and integrity.
  • The trust: signatures chain upward — the root vouches for the TLD, the TLD vouches for your domain — anchored in one well-known root key.
  • The limit: it authenticates, it does not encrypt. Privacy is DoH/DoT's job, not DNSSEC's.
  • The proof: scroll to the bottom and check any domain live, from your browser.
Contents
01 — The Problem

How DNS gets hijacked

When your computer asks "what's the IP for bank.example?", that question travels through a recursive resolver out to the authoritative servers. Classic DNS attaches no proof to the answer. If an attacker can inject a reply that arrives first — on a coffee-shop network, through a poisoned resolver cache, via a hijacked route — your machine believes it. You type the right name and land on the wrong server.

Flip the switch below to enable DNSSEC, then launch the attack and watch what changes.

DNSSEC: OFF
You resolver Resolver recursive Authoritative the real server Attacker forged reply A?
Idle — flip DNSSEC and launch an attack.
Fig 1 · A spoofing attack against a resolver, with DNSSEC validation toggled off / on.

Without DNSSEC the resolver has no way to tell the attacker's reply from the real one — first answer wins. With DNSSEC, the forged record carries no valid signature, validation fails, and the resolver returns SERVFAIL instead of a lie. A clear error beats a confident wrong answer.

02 — The Fix

What DNSSEC actually adds

DNSSEC doesn't replace DNS — it layers cryptographic signatures on top of it. Every set of records of the same type (an "RRset") is signed with a private key held by the zone's operator. The matching public key is published in DNS itself, so any resolver can fetch it and verify the signature.

Two guarantees come out of this:

① Authenticity — the answer genuinely came from the domain's owner, not an impostor.
② Integrity — not a single byte was altered between the authoritative server and you.

Key idea: DNSSEC moves trust from "whoever answered fastest" to "whoever holds the private key." Speed no longer wins arguments — math does.
03 — The Building Blocks

The four record types

DNSSEC introduces a small family of new record types. Tap each one to see what it carries and why it exists.

Fig 2 · The DNSSEC record family. Each plays one role in the verification path.
04 — The Trust Model

The chain of trust

A signature is only as good as the key behind it — and how do you trust that key? DNSSEC answers with a chain: each zone's key is vouched for by its parent, all the way up to the root. Click a link in the chain to inspect it.

Root zone  . TLD  .in dnssec.in A / MX / TXT… DS → ↓ DS → ↓ RRSIG ↓
Fig 3 · Trust flows downward. Break any link and validation below it fails.

The resolver already trusts one thing out of the box: the root zone's public key, shipped as a built-in trust anchor. From there it walks the chain — root signs .in, .in signs dnssec.in — verifying each DS-to-DNSKEY handoff until it reaches the record you asked for.

05 — Keys

KSK, ZSK & key rollover

Most zones split signing into two keys for operational sanity:

KSK — Key Signing Key. Signs only the DNSKEY record set. This is the key your parent vouches for via the DS record. Long-lived, rotated rarely, because each rotation means updating the DS at your registrar.

ZSK — Zone Signing Key. Signs all the actual data (A, MX, TXT…). Shorter, rotated often, entirely under your control — no registrar involvement needed.

Why split them? It lets you change the workhorse key (ZSK) on a frequent schedule without ever touching the parent delegation. The KSK stays put as the stable anchor; the ZSK churns freely underneath it. Rolling keys carefully — publishing the new one before retiring the old — is what keeps a zone from going dark during rotation.
06 — Boundaries

What DNSSEC does not do

It does not encrypt. Anyone watching the wire still sees which domains you look up. Confidentiality is the job of DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) — they hide the questions; DNSSEC proves the answers. They stack nicely together.

It does not secure the last mile by itself. Validation usually happens at your recursive resolver. The hop from that resolver to your device still relies on a trusted network or DoH/DoT to carry the verified verdict safely.

It does not vouch for the website. DNSSEC proves you reached the right IP, not that the server is honest or the TLS certificate is valid. It secures the lookup, not the destination.

07 — The Real World

Adoption is wildly uneven

Whether a domain is signed depends enormously on its TLD and registrar. Some country-code registries pushed hard (and even gave discounts for signed domains); others barely moved. The chart below shows the rough shape of that gap.

0%
.se
0%
.nl
0%
.cz
0%
.com
0%
.net
0%
.org
Fig 4 · Approximate share of signed domains by TLD — illustrative figures to show the spread, not exact live statistics. Nordic/EU ccTLDs lead; the big gTLDs lag in the single digits.

The takeaway isn't the precise numbers — it's the shape: registries that made signing easy and cheap got adoption in the majority; the global generics, where it's optional and invisible to most owners, sit in the low single digits.

08 — Practice

How to turn it on

The mechanics differ per DNS platform, but the shape is always the same three steps:

① Sign the zone on your authoritative server — generate keys and let it produce RRSIG/DNSKEY/NSEC records. On PowerDNS that's a single command:

pdnsutil secure-zone dnssec.in

② Read the DS record that represents your KSK, which your registrar needs:

pdnsutil show-zone dnssec.in  → copy the DS line.

③ Publish the DS at your registrar, which inserts it into the parent TLD zone and completes the chain of trust. Until that DS exists, your zone is signed but validators treat it as "insecure" — the parent isn't vouching for it yet.

Test before you trust. After the DS propagates, verify the whole chain end-to-end with the live checker below — or independent tools like Verisign's DNSSEC debugger and dig +dnssec.
09 — Try It

Check a domain, live

This runs entirely in your browser: it asks a validating DNS-over-HTTPS resolver for the domain's DNSKEY and DS records and reads the Authenticated Data (AD) flag. Try cloudflare.com (signed) versus a typical unsigned domain.

Queries are sent to Cloudflare's public resolver (1.1.1.1) over HTTPS. Nothing is stored; the lookup happens from your device. Each result has a shareable permalink at dnssec.in/check/<domain> (dots become hyphens) — or browse the DNSSEC status of the top 100 domains →

10 — FAQ

Frequently asked

Does DNSSEC encrypt my DNS traffic?

No. It authenticates answers — it doesn't hide them. Pair it with DoH or DoT if you also want privacy.

Will DNSSEC slow down my site?

Marginally. Responses are larger and validation costs a little CPU at the resolver, but for users it's imperceptible. The bigger operational risk is misconfiguration — an expired signature or a botched key roll can take a zone offline, which is why careful automation matters.

Do I need DNSSEC if I already use HTTPS?

They protect different layers. HTTPS secures the connection after you've resolved a name; DNSSEC secures the resolution itself. Together they close gaps neither covers alone.

How do I check if a domain uses DNSSEC?

Use the live checker above, or run dig +dnssec example.com and look for RRSIG records and the ad flag in the response header.