DNSSEC Check: a beginner's guide
Verify DNSSEC signing and validation
DNSSEC: the wax seal that proves a DNS answer is real
DNSSEC (Domain Name System Security Extensions) is a set of cryptographic signatures that prove a DNS answer actually came from the legitimate owner of the domain — and was not forged or modified somewhere along the path. This is a meaningful protection because, unlike most internet protocols, the original DNS protocol from 1983 had no built-in way to verify that an answer was authentic. A resolver got back the IP address it was told, trusted it, and used it. An attacker who could intercept or poison the DNS responses on a network could redirect users to fake versions of any website without setting off any alarms. DNSSEC was designed to fix that, and the protocol has been gradually rolling out across the internet since 2010.
You should care because **DNS forgery (also called DNS spoofing or cache poisoning) is one of the most dangerous attacks against websites that handle money or sensitive data**. A successful DNS spoofing attack can route every user of a bank, a crypto exchange, or a critical SaaS to a perfect-looking phishing replica of the real site, complete with a valid SSL certificate (if combined with a CA mis-issuance). DNSSEC is the only defense that operates at the DNS layer itself. With DNSSEC, a poisoned response will fail signature verification at the resolver and never reach the user's device.
The four things every DNSSEC check looks at:
Is DNSSEC enabled on the domain? This requires both publishing signed records at the authoritative nameserver and submitting a `DS` record at the registrar (the parent zone) so the chain of trust links all the way back to the root.
Does the chain of trust validate? The signatures on each level (root → TLD → domain) all have to verify cleanly. A break anywhere in the chain marks the entire response as `BOGUS` and resolvers should refuse it.
Are the signing keys current? DNSSEC keys are rotated periodically. An expired or stale key produces validation failures that look identical to a real attack.
Are the signature timestamps valid? Signatures expire and have to be re-signed regularly (every few weeks). A lapsed signature is a self-inflicted outage.
Three questions a DNSSEC check answers:
Is my domain protected against DNS forgery and cache poisoning?
Is the chain of trust from the root all the way to my domain intact?
Are my signing keys and signatures current, or am I about to have a self-inflicted DNSSEC outage?
The cost of skipping DNSSEC is leaving the door open to a rare-but-devastating class of attack. The cost of enabling DNSSEC is mostly the operational complexity of key management — which is why most DNS providers now offer one-click DNSSEC and handle the rotation for you. Compliance frameworks like NIST SP 800-81 and several government directives now require DNSSEC for certain classes of domains. The original DNSSEC specification is in RFC 4033 and the full set of related standards.
The DNSSEC Check endpoint, in plain language
In one sentence: Verify [DNSSEC (Domain Name System Security Extensions)](/guides/dns-dnssec) signing and validation
Validates DNSSEC (Domain Name System Security Extensions) configuration including DS records, DNSKEY (DNS public key record) records, and the chain of trust. Validates against the official internet standard algorithm recommendations, flagging deprecated algorithms (RSA/SHA-1, DSA) and recommending ECDSA P-256 or Ed25519.
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.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Performs comprehensive DNSSEC (Domain Name System Security Extensions) validation by checking DS records at the parent zone, retrieving DNSKEY (DNS public key record) records, validating key algorithms and sizes, and verifying the chain of trust. Reports validation status as secure, insecure, bogus, or indeterminate per the official internet standard semantics. Identifies common outage causes including expired RRSIG (DNSSEC signature record) signatures, broken DS-to-DNSKEY chains, and key rollover failures.
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.
Why this specific tool matters
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.
DNSSEC (Domain Name System Security Extensions) protects against DNS (Domain Name System) spoofing and cache poisoning attacks but adoption is still only ~5% for .com domains. Proper DNSSEC configuration is required by many government and financial regulations. This endpoint helps identify whether DNSSEC is properly implemented or actively causing resolution failures.
Picture this in real life. Imagine a security auditor. Here's the situation they're walking into: Verify DNSSEC (Domain Name System Security Extensions) is properly configured for domains as required by security policies or regulations. 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.
Available on the free plan. The technical details: `GET /v1/dns/dnssec`.
When would I actually use this?
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 security auditor, a DNS administrator, and a devops engineer — 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: Security Compliance Check
Imagine you're a security auditor. Verify DNSSEC (Domain Name System Security Extensions) is properly configured for domains as required by security policies or regulations.
Why it matters: Ensure DNS-level protection against spoofing attacks for compliant infrastructure.
Story 2: DNSSEC Troubleshooting
Imagine you're a DNS administrator. Diagnose DNSSEC (Domain Name System Security Extensions) validation failures reported by users or monitoring systems.
Why it matters: Quickly identify the root cause of DNSSEC (Domain Name System Security Extensions) failures — expired signatures, algorithm mismatches, missing DS records, or broken chain of trust — reducing mean-time-to-resolution.
Story 3: Pre-Migration Validation
Imagine you're a devops engineer. Before DNS (Domain Name System) migration, document DNSSEC (Domain Name System Security Extensions) configuration to ensure it's correctly replicated.
Why it matters: Prevent DNSSEC-related outages during DNS (Domain Name System) provider migrations.
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.
The easiest way: just ask your AI assistant
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.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
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.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/dns/dnssec?domain=cloudflare.com"What you need to provide
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.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to validate DNSSEC (Domain Name System Security Extensions) for | cloudflare.com |
What you get back
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.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The queried domain |
status | string | Validation status: secure (valid chain, includes weak algorithm warnings), insecure (no DNSSEC (Domain Name System Security Extensions)), bogus (broken chain/orphaned RRSIGs), or indeterminate (inconclusive) |
has_dnssec | boolean | Whether DNSSEC (Domain Name System Security Extensions) is enabled |
has_valid_chain | boolean | Whether the DS-to-DNSKEY chain of trust is valid |
keys | array | DNSKEY (DNS public key record) records with key_tag, algorithm, KSK/ZSK flags, and security status |
ds_records | array | DS records at parent zone with key_tag, algorithm, and digest type |
rrsig_records | array | RRSIG (DNSSEC signature record) signatures with type covered, expiration, inception, is_expired, is_not_yet_valid, and expiry warnings |
issues | array | List of configuration issues found |
recommendations | array | Actionable recommendations for improving DNSSEC (Domain Name System Security Extensions) configuration |
Words you might be wondering about
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.
RRSIG (DNSSEC signature record) — The actual digital signature attached to a DNS record under DNSSEC — like a wax seal proving the record is genuine.
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.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.