DNSSEC Check
free/v1/dns/dnssecPerforms cryptographic DNSSEC validation per RFC 4034 — not just a check that records exist. Computes the DS digest from the published DNSKEY (RFC 4034 §5.1.4) and compares it to the parent's DS record. Reconstructs the canonical DNSKEY RRset (RFC 4034 §6.2) and verifies the RRSIG signature against the signing DNSKEY using the actual public-key algorithm — RSA-SHA256/512 (RFC 5702), ECDSA P-256/P-384 (RFC 6605), or Ed25519 (RFC 8080). Returns validation status as `secure`, `insecure`, `bogus`, or `indeterminate` per RFC 4035, with structured per-check detail so callers see exactly which DS digest didn't match or which signature failed.
What It Does
Fetches DNSKEY, DS, and RRSIG records (with cd=1 to bypass resolver-side validation), parses each per RFC 4034, then performs three layers of validation: (1) structural — algorithm/key-tag/digest-type matching between DS and DNSKEY; (2) cryptographic DS 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 (RFC 8624), revoked-key flags (RFC 5011), and orphaned RRSIGs. Mismatched DS digests or failed signatures correctly downgrade status to `bogus` — validating resolvers will SERVFAIL the zone.
Why It's Useful
Most DNSSEC-checking tools verify only that records *exist* — they trust the upstream resolver's AD 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 (the most common DNSSEC misconfiguration: KSK rolled, parent DS not updated at the registrar) or which RRSIG signature failed. That's the difference between "your zone might be broken" and "your DS digest doesn't match your KSK; here's the correct one to publish at your registrar".
Use Cases
Diagnose KSK rollover failures
A scheduled KSK rotation has produced SERVFAILs from validating resolvers. The cryptographic verification surfaces the exact mismatch: the published DS digest doesn't correspond to any current DNSKEY, with the *correct* digest computed and returned in the response so it can be republished at the registrar.
Reduces MTTR on the most common DNSSEC outage from "your zone is bogus, debug it" to "publish this exact DS at the registrar."
Compliance evidence with cryptographic proof
SOC 2 / ISO 27001 evidence requires verifiable DNSSEC posture. The endpoint returns per-DS digest checks (RFC 4034 §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."
Audit reports can show the cryptographic verification was performed locally rather than trusting an upstream resolver's AD bit.
Pre-migration DNSSEC validation
Before migrating DNS 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.
Catches DNSSEC breakage immediately at migration time rather than 24 hours later when validators start rejecting the zone.
RRSIG expiry monitoring
Schedule the endpoint daily. Alert when any RRSIG's `is_expiring_soon` flag turns true (signature within 7 days of expiration). Re-sign before validators start treating the zone as bogus.
Prevents the self-inflicted DNSSEC outage that happens when zone-signing automation silently fails.
Parameters
| Name | Type | Required | Description |
|---|---|---|---|
domain | string | Required | The domain to validate DNSSEC forExample: cloudflare.com |
Response Fields
| Field | Type | Description |
|---|---|---|
domain | string | The queried domain |
status | string | Validation status (RFC 4035): secure, insecure, bogus (cryptographic check failed or chain broken), or indeterminate |
has_dnssec | boolean | Whether DNSSEC records are present |
has_valid_chain | boolean | Whether the DS-to-DNSKEY chain of trust is structurally valid AND cryptographically verified |
resolver_validated | boolean | AD bit returned by Cloudflare's recursive resolver (third-party validation indicator; distinct from our own cryptographic verification) |
keys | array | DNSKEY records with key_tag, algorithm, KSK/ZSK flags, and security status |
ds_records | array | DS records at parent zone with key_tag, algorithm, digest_type, and is_secure |
rrsig_records | array | RRSIG signatures with type covered, expiration, inception, is_expired, is_not_yet_valid, is_expiring_soon, and days_until_expiry |
ds_digest_verified | boolean | True iff at least one DS record's digest matches the SHA-256/384 we computed over canonical owner-name + DNSKEY RDATA (RFC 4034 §5.1.4). Null when no DS or no DNSKEY is present. |
ds_digest_checks | array | Per-DS detail: ds_key_tag, ds_digest_type, ds_digest_published, matched_dnskey_key_tag, digest_computed, matches, error. When matches=false, the published DS does not correspond to any current DNSKEY — the most common DNSSEC misconfiguration. |
rrsig_signatures_verified | boolean | True iff every attempted DNSKEY-RRset signature verified cryptographically via Web Crypto. Null when not run (no signing DNSKEY or unsupported algorithm). |
rrsig_signature_checks | array | Per-RRSIG detail: type_covered, algorithm, key_tag, signer_name, verified, reason. Algorithms supported: RSA-SHA256/512 (RFC 5702), ECDSA P-256/P-384 (RFC 6605), Ed25519 (RFC 8080). |
issues | array | Configuration findings (weak algorithm, expired RRSIG, DS-DNSKEY mismatch, orphaned RRSIG, revoked key) |
recommendations | array | Actionable remediation guidance, including the specific DS digest to publish at the registrar when DS verification fails |
Code Examples
curl "https://api.edgedns.dev/v1/dns/dnssec" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d "domain=cloudflare.com"const response = await fetch(
'https://api.edgedns.dev/v1/dns/dnssec?domain=cloudflare.com',
{
headers: {
'Authorization': 'Bearer YOUR_API_KEY'
}
}
);
const data = await response.json();
console.log(data);import requests
response = requests.get(
'https://api.edgedns.dev/v1/dns/dnssec',
headers={'Authorization': 'Bearer YOUR_API_KEY'},
params={
'domain': 'cloudflare.com'
}
)
data = response.json()
print(data)Read the full DNSSEC Check guide
Why it matters, real-world use cases, parameters, response fields, and how to call it from Claude, ChatGPT, or Gemini via MCP.
Read the guide →Related Endpoints
External References
Learn more about the standards and protocols behind this endpoint.
Try This Endpoint
Test the DNSSEC Check endpoint live in the playground.