DNSSEC Check: a beginner's guide

DNSSEC (Domain Name System Security Extensions) is a set of cryptographic signatures that prove a DNS answer came from the legitimate owner of the domain — and wasn't forged or modified along the path. The original DNS protocol from 1983 had no built-in way to verify authenticity: a resolver got back an IP, trusted it, and used it. An attacker who could intercept or poison DNS responses could redirect users to fake versions of any website without tripping alarms. DNSSEC fixes that. The full set of standards lives in RFC 4033, RFC 4034, and RFC 4035, with algorithm-specific extensions in RFC 5702 (RSA), RFC 6605 (ECDSA), and RFC 8080 (Ed25519).

You should care because **DNS forgery — spoofing, cache poisoning — is one of the most dangerous attacks against banks, exchanges, and SaaS that handle money**. A successful spoof routes every user to a perfect-looking phishing replica of the real site, complete with a valid TLS certificate if combined with a CA mis-issuance. DNSSEC is the only defense that operates at the DNS layer: a poisoned response fails signature verification at the resolver and never reaches the user's device.

How verification actually works. The chain of trust is a sequence of cryptographic signatures, not a vibe. Each signed RRset (records of the same type at the same name) has an RRSIG signature produced by the zone's signing key (a DNSKEY). The DNSKEY itself is authenticated by a DS (Delegation Signer) record published in the parent zone — the DS contains a hash of the child's KSK. Validators reconstruct the canonical form of the signed RRset per RFC 4034 §6.2 and call the appropriate verification primitive (RSA-SHA256, ECDSA P-256, Ed25519, etc.) using the DNSKEY's public key. Recursive resolvers signal validation success with the AD (Authenticated Data) flag in their reply.

The five things a real DNSSEC check looks at:

• Are DNSSEC records present? DNSKEY at the apex, DS at the parent, RRSIG covering each signed RRset.

• Does the DS digest match the published DNSKEY? Per RFC 4034 §5.1.4, the DS digest is computed over the canonical owner-name plus DNSKEY RDATA. A mismatch means the parent's DS doesn't correspond to any current child DNSKEY — the most common DNSSEC failure mode in the wild, usually "KSK rolled, registrar DS not updated."

• Do the RRSIG signatures actually verify? Reconstruct the canonical signed RRset, verify the signature against the matching DNSKEY using the algorithm in the RRSIG header. Trusting only the resolver's AD bit is not the same as doing the math yourself; a third-party validator answer is not a substitute for cryptographic verification.

• Are the signatures within their validity window? RRSIGs have inception and expiration timestamps. Expired signatures — and signatures with an inception in the future, usually a clock-skew bug — are treated as bogus and cause SERVFAIL.

• Are the algorithms current? RFC 8624 deprecates RSA/SHA-1 and DSA. The IANA DNSSEC algorithm registry is the canonical list; modern zones should use ECDSA P-256 (algorithm 13) or Ed25519 (algorithm 15).

Three questions a DNSSEC check answers:

• Is my domain protected against DNS forgery and cache poisoning?

• Does the DS my registrar published actually match my current KSK, or did a key rollover go wrong?

• Are any of my signatures about to expire and cause a self-inflicted outage?

The cost of a broken DNSSEC chain is total resolution failure for users on validating resolvers — every major resolver (Cloudflare, Google, Quad9) validates by default. The good news is that the failure is mechanical and the fix is publishable: republish the correct DS at the registrar, or re-sign the zone before the RRSIG expires.

In one sentence: Verify [DNSSEC (Domain Name System Security Extensions)](/guides/dns-dnssec) signing and validation

Performs cryptographic DNSSEC (Domain Name System Security Extensions) validation per the official internet standard — not just a check that records exist. Computes the DS digest (Delegation Signer digest) from the published DNSKEY (DNS public key record) (the official internet standard §5.1.4) and compares it to the parent's DS record (Delegation Signer record). Reconstructs the canonical DNSKEY RRset (the official internet standard §6.2) and verifies the RRSIG (DNSSEC signature record) signature against the signing DNSKEY using the actual public-key algorithm — RSA-SHA256/512 (the official internet standard), ECDSA P-256/P-384 (the official internet standard), or Ed25519 (the official internet standard). Returns validation status as `secure`, `insecure`, `bogus (DNSSEC bogus state)`, or `indeterminate` per the official internet standard, with structured per-check detail so callers see exactly which DS digest didn't match or which signature failed.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Fetches DNSKEY (DNS public key record), DS, and RRSIG (DNSSEC signature record) records (with cd=1 to bypass resolver-side validation), parses each per the official internet standard, then performs three layers of validation: (1) structural — algorithm/key-tag/digest-type matching between DS and DNSKEY; (2) cryptographic DS digest (Delegation Signer digest) — compute SHA-1/256/384 over canonical owner-name + DNSKEY RDATA and compare to the published DS digest; (3) cryptographic RRSIG — reconstruct the canonical signed RRset and verify the signature with Web Crypto using the matching DNSKEY public key. Surfaces RRSIG expiry/inception, weak-algorithm warnings (the official internet standard), revoked-key flags (the official internet standard), and orphaned RRSIGs. Mismatched DS digests or failed signatures correctly downgrade status to `bogus (DNSSEC bogus state)` — validating resolvers will SERVFAIL the zone.

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the DNSSEC Check tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

Most DNSSEC-checking tools verify only that records exist — they trust the upstream resolver's AD bit (Authenticated Data bit) and never do the math themselves. That gives you a yes/no answer with no detail when something's wrong. EdgeDNS reconstructs the signed RRset and runs the cryptographic verification locally, so when a check fails the response tells you exactly which DS didn't match a DNSKEY (DNS public key record) (the most common DNSSEC (Domain Name System Security Extensions) misconfiguration: KSK (Key Signing Key) rolled, parent DS not updated at the registrar) or which RRSIG (DNSSEC signature record) signature failed. That's the difference between "your zone might be broken" and "your DS digest (Delegation Signer digest) doesn't match your KSK; here's the correct one to publish at your registrar".

Picture this in real life. Imagine a DNS administrator. Here's the situation they're walking into: A scheduled KSK (Key Signing Key) rotation has produced SERVFAILs from validating resolvers. The cryptographic verification surfaces the exact mismatch: the published DS digest (Delegation Signer digest) doesn't correspond to any current DNSKEY (DNS public key record), with the correct digest computed and returned in the response so it can be republished at the registrar. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the DNSSEC Check tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the DNSSEC Check tool is built for you:

• Is my domain pointing to the right place right now?

• Did the DNS change I just made actually take effect everywhere in the world?

• Is anything in my DNS misconfigured in a way that could break email or break the website?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Founders running their own infrastructure, marketers coordinating launches, IT admins inheriting domains from a former employee, and ops engineers troubleshooting live outages. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and you're flying blind on the one piece of config that decides whether your website and email work at all. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the DNSSEC Check tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a DNS administrator, a security auditor, a devops engineer, and an SRE — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Diagnose KSK rollover failures

Imagine you're a DNS administrator. A scheduled KSK (Key Signing Key) rotation has produced SERVFAILs from validating resolvers. The cryptographic verification surfaces the exact mismatch: the published DS digest (Delegation Signer digest) doesn't correspond to any current DNSKEY (DNS public key record), with the correct digest computed and returned in the response so it can be republished at the registrar.

Why it matters: Reduces MTTR on the most common DNSSEC (Domain Name System Security Extensions) outage from "your zone is bogus (DNSSEC bogus state), debug it" to "publish this exact DS at the registrar."

Story 2: Compliance evidence with cryptographic proof

Imagine you're a security auditor. SOC 2 (Service Organization Control 2) / ISO 27001 (ISO/IEC 27001 information security management standard) evidence requires verifiable DNSSEC (Domain Name System Security Extensions) posture. The endpoint returns per-DS digest checks (the official internet standard §5.1.4) and per-RRSIG signature verification for RSA-SHA256/512, ECDSA P-256/P-384, and Ed25519 — the actual math, not just "the resolver said it was OK."

Why it matters: Audit reports can show the cryptographic verification was performed locally rather than trusting an upstream resolver's AD bit (Authenticated Data bit).

Story 3: Pre-migration DNSSEC validation

Imagine you're a devops engineer. Before migrating DNS (Domain Name System) to a new provider, capture a baseline of DS-digest-verified, RRSIG-verified state. After the cut-over, re-run; any change in `ds_digest_verified` or `rrsig_signatures_verified` indicates a replication or signing issue at the new provider.

Why it matters: Catches DNSSEC (Domain Name System Security Extensions) breakage immediately at migration time rather than 24 hours later when validators start rejecting the zone.

Story 4: RRSIG expiry monitoring

Imagine you're an SRE. Schedule the endpoint daily. Alert when any RRSIG (DNSSEC signature record)'s `is_expiring_soon` flag turns true (signature within 7 days of expiration). Re-sign before validators start treating the zone as bogus (DNSSEC bogus state).

Why it matters: Prevents the self-inflicted DNSSEC (Domain Name System Security Extensions) outage that happens when zone-signing automation silently fails.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the DNSSEC Check tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• Right before launching a new website or migrating to a new host.

• After making any DNS change, to confirm the new settings are live everywhere.

• When customers report that your site or email "just stopped working" out of nowhere.

• As a recurring monthly health check to catch silent misconfigurations early.

If you can see yourself in even one of those bullets, the DNSSEC Check tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the DNSSEC Check tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the DNSSEC Check tool to check cloudflare.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with DNSSEC Check. If you're already running this check, the related ones often answer the next question that comes up:

• DNS Lookup — Query any of 22 DNS record types or ALL at once with DNSSEC validation

• CAA Records — Check which CAs can issue certificates

• NSEC Walkability — Grade zone-enumeration risk from NSEC3PARAM configuration

• Security Score — Composite security score from 10 weighted factors

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check DNSSEC Check and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

DNSKEY (DNS public key record) — A DNS entry that holds the public key used to verify DNSSEC signatures — part of the chain that proves your DNS records haven't been tampered with.

DS record (Delegation Signer record) — A DNS entry stored at your domain registrar that vouches for your DNSSEC keys — it's the link in the chain that proves your DNS keys are real.

RRSIG (Resource Record Signature) — The digital signature attached to a DNS record set. Validators verify the signature against the zone's public key (the DNSKEY) using the algorithm in the RRSIG header.

DNSSEC (Domain Name System Security Extensions) — A way to digitally sign DNS records so attackers can't trick your computer into looking up the wrong server.

RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.

SOC 2 (Service Organization Control 2) — A widely used security audit. Proves to customers that you handle their data responsibly.

ISO 27001 (ISO/IEC 27001 information security management standard) — An international certification that shows your company has a documented, working security program.

DS digest (Delegation Signer digest) — A cryptographic fingerprint of a domain's signing key, published in the parent zone (usually at the registrar). Validators recompute the digest from the published key and compare — if they don't match, the chain of trust is broken and the zone fails validation.

KSK (Key Signing Key) — The DNSSEC key whose hash is published in the parent zone's DS record. Used to sign the DNSKEY records, which in turn authorize the ZSK that signs everything else.

bogus (DNSSEC bogus state) — A DNSSEC validation result meaning "the cryptography failed" — usually expired RRSIG, mismatched DS digest, or broken chain. Validating resolvers return SERVFAIL on bogus zones, so users can't reach the domain.

AD bit (Authenticated Data bit) — A flag that recursive resolvers set in their reply when they successfully validated DNSSEC. Useful as a signal but not the same as verifying the cryptography yourself — it tells you what the resolver said, not what the math shows.