DNSSEC Checker
Enter a domain to see whether DNSSEC is enabled and working: whether answers are authenticated, the zone is signed, and the DS record at the registrar matches its keys.
Overview
DNSSEC adds cryptographic signatures to DNS so resolvers can confirm that an answer really came from the domain’s nameservers and wasn’t forged along the way. It needs two parts to work: the zone must be signed with DNSKEY records, and the parent zone, through your registrar, must publish a DS record that matches one of those keys.
This checker asks a validating resolver about the domain and reports whether its answers are authenticated. It compares the DS record’s key tag with the key tags computed from the zone’s DNSKEY records, which catches the most common breakage: a DS record left over after changing DNS provider or rolling a key.
A domain whose DNSSEC is broken is worse off than one without it, because validating resolvers refuse to answer for it at all. The checker spots this by comparing validated and unvalidated lookups, and also flags deprecated algorithms such as RSA/SHA-1.
Examples & Sample Data
Signed and validating
cloudflare.com
Pass: Answers are authenticated. DS key tag 2371 matches the ECDSA P-256 key-signing key.
Broken DNSSEC
dnssec-failed.org
Problem: DNSSEC validation fails. The DS record doesn’t match any DNSKEY.
How It Works
- Enter a domain or subdomain. For a subdomain, keys are checked at the zone it belongs to.
- The checker queries a validating DNS resolver over HTTPS and reads the authenticated-data flag on the answer.
- It fetches the DS records from the parent zone and the DNSKEY records from the domain, and computes each key’s tag to match them.
- If validated lookups fail but unvalidated ones succeed, it reports the domain as bogus.
Common Use Cases
Enabling DNSSEC
Confirm the DS record at your registrar matches the keys your DNS provider signs with before and after switching it on.
Changing DNS providers
Catch a stale DS record that would make the domain unreachable for users of validating resolvers.
Troubleshooting resolution failures
Find out whether SERVFAIL errors from resolvers like 1.1.1.1 or 8.8.8.8 are caused by broken DNSSEC.
Tips & Best Practices
- When moving a DNSSEC-signed domain to a new DNS provider, remove the DS record at the registrar first, wait for its TTL to pass, then move and re-enable DNSSEC.
- ECDSA P-256 (algorithm 13) and Ed25519 (15) are the recommended algorithms today, with smaller signatures than RSA.
- Use SHA-256 (digest type 2) for DS records. SHA-1 digests are being phased out.
Frequently Asked Questions
Your zone may be signed, but the registry for your domain doesn’t know about its keys, so there is no chain of trust and DNSSEC gives no protection. Add the DS record your DNS provider shows you at your domain registrar.
A domain whose DNSSEC signatures can’t be validated, usually because the DS record doesn’t match the zone’s keys or signatures have expired. Validating resolvers return SERVFAIL for it, so many users can’t reach the site or deliver email to it.
It protects against forged DNS answers, such as cache poisoning, and is required for technologies like DANE. Many large sites still don’t use it, but most DNS providers now make enabling it a one-click change.
It queries Cloudflare’s validating public resolver over DNS-over-HTTPS, which reports whether answers passed DNSSEC validation.
Related Tools
Explore more high-performance utilities.