Free DNSSEC Checker

What is DNSSEC?

DNSSEC (Domain Name System Security Extensions) adds a layer of cryptographic authentication to DNS responses. It allows resolvers to verify that DNS answers (IP addresses, MX records, etc.) have not been tampered with in transit. Without DNSSEC, attackers can forge DNS responses (cache poisoning) to redirect traffic to malicious servers.

DNS was designed in the 1980s with no way to prove an answer is genuine: a resolver trusts the answer it receives. Dan Kaminsky showed in 2008 that planting a forged answer in a resolver's cache was far easier than previously believed, and everyone who uses that resolver is then sent to the attacker's server.

DNSSEC protects people whose resolver validates, as Cloudflare's 1.1.1.1, Google's 8.8.8.8 and Quad9 do: when a signature does not match, the resolver returns an error (SERVFAIL) instead of the forged answer.

Why Should You Enable DNSSEC?

• Prevent DNS Spoofing: DNSSEC makes it cryptographically impossible for attackers to forge DNS responses, protecting your users from being redirected to phishing or malware sites.
• Foundation for Other Protocols: DANE (DNS-based Authentication of Named Entities) requires DNSSEC. DANE allows you to publish TLS certificate constraints in DNS.
• Email Security: DNSSEC protects MX, SPF, DKIM, and DMARC records from being spoofed, strengthening your entire email authentication chain.
• Trust Signal: DNSSEC is increasingly expected by security-conscious organisations and is a requirement in many government procurement frameworks.

How DNSSEC works: the chain of trust

Each level of DNS vouches for the one below it, from the root zone down to your domain.

1. The root zone is signed with its own key. Validating resolvers come with the root's key installed as their trust anchor.
2. The top-level domain (such as .uk or .com) is vouched for by a DS (Delegation Signer) record that the root publishes.
3. Your domain is vouched for by a DS record in its parent zone, run by the registry (such as .com or .co.uk), and your DNS host signs the records in your zone.
4. A validating resolver follows the chain from the root to your domain and checks each signature. When every link matches, it sets the AD (Authenticated Data) flag on its answer. When one does not, it rejects the answer.

Without a DS record at the parent, the chain stops there: resolvers treat your zone as unsigned, however well it is signed.

How to enable DNSSEC

Enabling DNSSEC takes two steps in two places: your DNS host signs the zone, and your registrar publishes the DS record in the parent zone.

1. Turn on signing at your DNS host. Cloudflare, AWS Route 53 and Google Cloud DNS all support it. The host creates the keys, signs your records and gives you the DS record details: key tag, algorithm, digest type and digest.
2. Add the DS record at your registrar, using exactly the values your DNS host gave you. This is the step that links your zone into the chain of trust.
3. Wait for the change to spread. It usually takes minutes, but can take up to 48 hours depending on TTLs.
4. Check the chain with the checker at the top of this page. A working set-up reads “DNSSEC is active and validating”.

Where your DNS host is also your registrar, as with Cloudflare Registrar, turning DNSSEC on can publish the DS record for you.

Common DNSSEC mistakes

A broken chain is worse than no DNSSEC: validating resolvers return SERVFAIL, so the domain stops resolving, websites and email included, for everyone who uses them. These are the usual causes.

• Expired signatures: if the zone is not re-signed before its RRSIG records expire, validating resolvers reject its answers. Managed DNS hosts normally re-sign for you; a zone you sign yourself needs monitoring.
• A DS record that no longer matches: moving DNS host, or replacing the KSK, without updating the DS record at your registrar leaves the parent pointing at a key you no longer publish, and validation fails for every lookup. The checker shows whether each DS record matches a published key.
• A key rollover done out of order: removing the old key, or its DS record, before the new one has spread breaks validation. Automated key management, which Cloudflare and other managed hosts offer, reduces this risk.
• Turning DNSSEC off in the wrong order: if you stop signing but leave the DS record at your registrar, resolvers still expect signatures and the domain stops resolving. Remove the DS record first, wait for the change to spread, then turn signing off. Do the same before moving to a DNS host that will not sign your zone.
• Large responses: signatures make DNS answers bigger, and some firewalls block large UDP packets. Make sure your network allows EDNS0 and DNS over TCP.

What this tool checks

• DNSKEY records: whether the zone publishes signing keys, with each key's tag, role (KSK or ZSK) and algorithm.
• DS records: whether the parent zone holds a DS record, and whether its digest matches a key the zone publishes.
• Validation: whether Cloudflare's resolver (1.1.1.1) confirms the chain and sets the AD flag. When a zone has keys and a DS record but Cloudflare does not confirm it, we ask Google (8.8.8.8) too.
• What broke: when the chain fails, the reason the resolvers give, such as an expired signature, and what to do about it.
• Retired algorithms: a warning when the zone is signed with algorithm 5 or 7, or its DS record uses a SHA-1 digest, which RFC 9905 and RFC 9904 (the successor to RFC 8624) retire.

Need Automated Monitoring?

This free tool is great for one-off checks. If you need continuous monitoring of DNSSEC, CAA, SSL, DMARC, and more across all your domains, start a free trial for 30 days free.