Why do most domains still not use DNSSEC?

**Three reasons.** First, **registrars** make it awkward: in many control panels you still have to manually copy a DS record between your DNS host and your registrar, with key rotations done by hand. Second, **operational risk**: if you misconfigure DNSSEC the domain breaks **only for users on validating resolvers** (about 30% globally), which is the worst kind of bug because it is invisible to whoever ran the change. Third, the **business case is fuzzy**: end users do not see DNSSEC, no browser shows a padlock for it, so it never makes the launch checklist. Adoption is around **5 to 10% of .com** depending on whose stats you read.

What is the chain of trust, exactly?

A chain of **signatures** going from your domain up to a key everyone trusts. Your zone signs its records with a **ZSK** (Zone Signing Key). The ZSK itself is signed by the **KSK** (Key Signing Key). The KSK's hash is published as a **DS record** at the parent zone (`.com`). `.com`'s ZSK signs that DS record, `.com`'s KSK is hashed into a DS record at the **root**, and the **root KSK** is the global trust anchor every resolver ships with. Break one link and the whole chain collapses for that domain.

KSK vs ZSK: what is the difference?

**ZSK (Zone Signing Key)** signs the actual records in your zone (A, MX, TXT, ...). It is rotated often (every few weeks or months) because it sees a lot of use. **KSK (Key Signing Key)** signs only the DNSKEY set. It is rotated rarely (yearly or less) because every rotation requires updating the **DS record at the parent**, which is a multi-day TTL dance. The split exists so you can rotate the noisy ZSK without touching the registrar. **Flags 256 = ZSK, 257 = KSK** in the DNSKEY record.

Why do DS records at the parent matter so much?

A DS record is the **only thing the parent zone publishes about your DNSSEC keys**. It is a hash of your KSK, signed by the parent. When a resolver validates your domain it walks **top down**: it trusts the root, the root's DS proves it can trust `.com`, `.com`'s DS proves it can trust `example.com`. **No DS at the parent = no chain = your DNSKEY is ignored** even if it is perfectly valid. This is the single most common cause of a "broken DNSSEC" verdict: somebody enabled DNSSEC at the DNS host but never pasted the DS into the registrar.

How do attackers exploit a domain without DNSSEC?

**Two classic attacks.** (1) **Cache poisoning**: an attacker races a forged response to a resolver before the legitimate one arrives, injecting a fake IP for, say, your bank. Without DNSSEC the resolver has no way to tell the responses apart. Dan Kaminsky's 2008 disclosure made this practical at internet scale. (2) **On-path DNS spoofing**: anyone who can intercept DNS traffic (rogue Wi-Fi, ISP, nation-state) can substitute their own answer. DNSSEC makes both attacks fail closed: the signature does not verify, the resolver returns SERVFAIL, no IP. The attacker can DoS the domain but cannot impersonate it.

The root and .com are signed, so why are so few domains protected?

Because **signing the parent is necessary but not sufficient**. The root and `.com` being signed only means they **can vouch for your DS record** if you publish one. If your domain itself does not publish a DNSKEY and a matching DS, the chain stops at `.com` and your records travel **unprotected** the last hop. About 95% of `.com` domains are in exactly this state today: the highway up to your exit is signed, but the off-ramp is not.

Does DNSSEC slow down DNS resolution?

**A little, not enough to matter for users.** A validating resolver makes extra queries (for DNSKEY and RRSIG records) and does some signature math. On a cold cache that adds **20 to 80 ms**. On a warm cache, basically zero. The response packets are larger (signatures are big), which historically caused issues with old middleboxes that dropped DNS over 512 bytes, but today's **EDNS0** and DNS over TCP / TLS / HTTPS handle that fine. Modern algorithms like **ECDSAP256SHA256** and **ED25519** produce signatures **5 to 10x smaller** than RSA2048, which fixed most of the size complaints.

RSASHA256 vs ECDSAP256SHA256 vs ED25519: which algorithm should I use?

**ECDSAP256SHA256 (algorithm 13)** is the current default for new deployments: small keys (256 bits), small signatures, universal resolver support. **ED25519 (algorithm 15)** is even smaller and faster, but a tiny minority of old resolvers still fall back to insecure for it (treat the zone as unsigned), so it is a good choice only if you do not need legacy compatibility. **RSASHA256 (algorithm 8)** still dominates real-world traffic (`.com` zone keys use it), it is rock-solid but signatures are 5 to 10x larger. Avoid **RSASHA1 (5, 7)** and **RSAMD5 (1)**: they are deprecated and resolvers are starting to reject them outright.

My validator says "Broken Chain". How do I troubleshoot?

**Five things to check, in order.** (1) **Does the DS keyTag at the parent match a KSK keyTag at the child?** A mismatch is 80% of breakages, usually caused by rotating the KSK without updating the registrar. (2) **Are the signatures (RRSIG) expired?** Signatures have a validity window, typically 7 to 30 days. If your signer stopped working, signatures expire and the chain breaks at midnight. (3) **Did you rotate algorithms recently?** Going from RSA to ECDSA requires double-signing for a TTL window. (4) **Check the parent algorithm field in the DS record** matches what your zone actually signs with. (5) Use **dnsviz.net** for a deeper trace once this tool tells you which level is broken.

DNSSEC Chain Validator - free

What this tool does

This tool walks the DNSSEC chain of trust for any domain and shows you, level by level, whether it is properly signed. You get the root (.), the TLD (like `.com`) and your domain, each with its DNSKEY records, the DS record at the parent zone, the algorithm in use (RSASHA256, ECDSAP256, ED25519, ...) and the key tag.

The actual cryptographic check is done by Cloudflare's validating resolver 1.1.1.1: we set the resolver up to check signatures and read back its AD (Authenticated Data) flag. Green means signed and validated, yellow means the level simply does not use DNSSEC, red means signatures or DS records do not match and the chain is broken.

How to use it

Type a domain like `cloudflare.com` (no `https://`, no path).
Click Validate DNSSEC. We query DoH for DNSKEY at each level and DS at the parent.
Read the chain card top to bottom: root, then TLD, then your domain. Each card is colour coded.
Green = signed and authenticated. Yellow = no DNSSEC at this level (not an error, just unprotected). Red = broken chain, clients may refuse the domain.
Inspect the DS / DNSKEY tables: the key tags must match between a child DNSKEY and the parent DS. Algorithm and digest type tell you which crypto is in use.
Try the sample chips: cloudflare.com, paypal.com, ietf.org are fully signed. example.com is signed but its subzone is not, so it lands in "partial".

When this is useful

Six places where a DNSSEC chain validator beats reading raw `dig +trace +dnssec` output:

Audit a domain you just enabled DNSSEC for. You toggled the switch in your registrar, you pasted the DS record at the parent, now you need to confirm both sides match. The chain visualisation makes a key-tag mismatch obvious in seconds.
Debug "DNSSEC validation failure" errors. End users see a sudden `SERVFAIL` only on validating resolvers (Cloudflare, Google, Quad9). The red card pinpoints the level that broke and the message explains why.
Pre-launch checklist for banking, government and any high-trust domain. Fully signed DNSSEC blocks an entire class of attacks (cache poisoning, on-path DNS spoofing). Confirm before going live.
Compare two domains side by side. Run `yourbank.com` against a competitor and see who actually deploys DNSSEC.
Verify a parent zone rotation. You rolled the KSK at the registry, you submitted a new DS, you want to confirm propagation finished and the AD flag is back to true.
Teach DNSSEC. The three-level chain (root, TLD, SLD) plus per-level records is the cleanest way to explain delegation and trust to someone who has never seen it.

Questions and answers

DNSSEC is a set of extensions that adds cryptographic signatures to DNS answers. A regular DNS query returns "example.com is at 1.2.3.4" with no way to prove it actually came from example.com's real DNS server. DNSSEC attaches a signature to that answer, plus a chain of trust going all the way up to the root zone, so a validating resolver can confirm the IP was published by the legitimate owner and nobody tampered with it in flight. It is a defence against cache poisoning and on-path DNS spoofing, not against site takeover or stolen credentials.

What this tool does

How to use it

Type a domain like `cloudflare.com` (no `https://`, no path).

Click Validate DNSSEC. We query DoH for DNSKEY at each level and DS at the parent.

Read the chain card top to bottom: root, then TLD, then your domain. Each card is colour coded.

Green = signed and authenticated. Yellow = no DNSSEC at this level (not an error, just unprotected). Red = broken chain, clients may refuse the domain.

Inspect the DS / DNSKEY tables: the key tags must match between a child DNSKEY and the parent DS. Algorithm and digest type tell you which crypto is in use.

Try the sample chips: cloudflare.com, paypal.com, ietf.org are fully signed. example.com is signed but its subzone is not, so it lands in "partial".

When this is useful

Six places where a DNSSEC chain validator beats reading raw `dig +trace +dnssec` output:

Audit a domain you just enabled DNSSEC for. You toggled the switch in your registrar, you pasted the DS record at the parent, now you need to confirm both sides match. The chain visualisation makes a key-tag mismatch obvious in seconds.
Debug "DNSSEC validation failure" errors. End users see a sudden `SERVFAIL` only on validating resolvers (Cloudflare, Google, Quad9). The red card pinpoints the level that broke and the message explains why.
Pre-launch checklist for banking, government and any high-trust domain. Fully signed DNSSEC blocks an entire class of attacks (cache poisoning, on-path DNS spoofing). Confirm before going live.
Compare two domains side by side. Run `yourbank.com` against a competitor and see who actually deploys DNSSEC.
Verify a parent zone rotation. You rolled the KSK at the registry, you submitted a new DS, you want to confirm propagation finished and the AD flag is back to true.
Teach DNSSEC. The three-level chain (root, TLD, SLD) plus per-level records is the cleanest way to explain delegation and trust to someone who has never seen it.

Questions and answers

DNSSEC Chain Validator

What this tool does

How to use it

When this is useful

Questions and answers

Related tools

DNS Lookup

Reverse DNS (PTR) Lookup

Email DNS Checker (SPF/DKIM/DMARC)

WHOIS Lookup

DKIM Keypair Generator

DNSSEC Chain Validator

What this tool does

How to use it

When this is useful

Questions and answers

Related tools

DNS Lookup

Reverse DNS (PTR) Lookup

Email DNS Checker (SPF/DKIM/DMARC)

WHOIS Lookup

DKIM Keypair Generator