Theme

Popular tools

DNSSEC Checker

This DNSSEC checker tests a domain's chain of trust from the root to its records, shows which resolvers refuse it, and how to fix it.

Verified from IANA's root key 20326 · 38696

DNSSEC Checker: dnssec-failed.org fails validation because the .org DS 42069 matches none of its keysDNSSEC Checker: dnssec-failed.org fails validation because the .org DS 42069 matches none of its keysOne verdictSecure, not signed, signed but not linked, changing keys or broken, from our own check of every signature, never from one resolver's error code.Why it brokeThe break named in plain words, with the fix at your DNS host and registrar in their own words, and the DS or key to copy.The chain of trustIANA's root key, the TLD, then the domain: each link's key tags, algorithms and whether it verifies.What resolvers answerGoogle, Cloudflare and Quad9 asked side by side: validated, refused, and their own error codes.
dnssec-failed.org, a zone kept broken on purpose: its DS at .org matches neither of its keys, so validating resolvers refuse it.

What is DNSSEC and how does the chain of trust work?

DNSSEC signs a domain's DNS records so a resolver can prove an answer is genuine. Trust runs down a chain: the root's key, which every validating resolver already holds, vouches for the TLD's key through a DS record, the TLD's key vouches for the domain's, and the domain's key signs its records.

Each link has two halves. The parent publishes a DS record: the digest of one of the child's keys (DNSKEY). The child signs its own key set with that key (RRSIG). A resolver checks that the digest matches and the signature verifies, then trusts the child's keys and moves down.

The first link has no parent: IANA publishes the root's key digests as the trust anchor, and resolvers ship with them. This checker starts from IANA's file and verifies every link itself, so Secure means the whole chain, not one resolver's say-so.

  1. IANA's trust anchor2032638696
  2. . (root)IANA's trust anchor 38696 → key 38696 signs the key set verified
  3. .orgDS 26974 → key 26974 signs the key set verified
  4. isc.orgDS 7250 → key 7250 signs the key set verified
  5. SOA + Akey 27566 verified
isc.org's chain as our check read it: IANA's anchor, the root, .org, then isc.org and its records.

Sources:rfc-editor.org

How do I check if DNSSEC is enabled?

Enter the domain in the checker above. It reads the DS at the parent and the domain's keys, verifies every link from the root, and gives one verdict: secure, not signed, signed but not linked, changing keys or broken, or says it couldn't check.

Two records decide it. A DS at the registry means the domain says it is signed; DNSKEY records in the zone mean it is. Both, with signatures that verify, is Secure. Neither is Not signed, which is not an error. Keys with no DS is an island: signed, but resolvers treat it as unsigned.

A resolver's AD flag shows the same from the outside: it is set only when the resolver validated the answer. The checker shows what Google, Cloudflare and Quad9 answered beside its own verdict.

VerdictNameDS at parentKeysGoogle answered
Secureisc.org72502validated (AD)
Securecloudflare.com23712validated (AD)
Not signedgithub.com––answered, not validated
Signed, not linkedno-ds.extended-dns-errors.com–2answered, not validated
Brokendnssec-failed.org420692SERVFAIL
Couldn't checked448.extended-dns-errors.com615962answered, not validated
Real runs of the checker on 2026-11-01, one per verdict, with what Google Public DNS answered.

Sources:rfc-editor.orgextended-dns-errors.com

Why does my domain fail DNSSEC validation?

Because a link of the chain doesn't verify, and a validating resolver then answers SERVFAIL instead of the address. The commonest cause is a DS left at the registry after the domain's DNS moved: the DS names a key the new host doesn't have.

The other breaks: a DS while the zone is no longer signed, signatures that expired because the signer stopped, a DS and keys of different algorithms after a half-done change, and a DS whose digest was copied wrong. Each fails on every validating resolver at once.

Resolvers say why in an Extended DNS Error, but they don't agree on the code for the same break: Google and Cloudflare send 9 for dnssec-failed.org, Quad9 sends 6. The checker diagnoses from the records and shows their codes only as evidence.

NameWhat's wrongGoogleCloudflareQuad9
dnssec-failed.orgThe DS matches no keySERVFAIL · EDE 9SERVFAIL · EDE 9SERVFAIL · EDE 6
ds-bad-tag.extended-dns-errors.comThe DS matches no keySERVFAIL · EDE 9SERVFAIL · EDE 9SERVFAIL · EDE 6
ds-bogus-digest-value.extended-dns-errors.comRight tag, wrong digestSERVFAIL · EDE 9SERVFAIL · EDE 6SERVFAIL · EDE 9
no-dnskey.extended-dns-errors.comA DS, but no keysSERVFAIL · EDE 10SERVFAIL · EDE 9SERVFAIL · EDE 10
no-rrsig-all.extended-dns-errors.comThe DS's key signs nothingSERVFAIL · EDE 10SERVFAIL · EDE 10SERVFAIL · EDE 10
rrsig-exp-all.extended-dns-errors.comSignatures expiredSERVFAIL · EDE 7SERVFAIL · EDE 7SERVFAIL · EDE 7
rrsig-not-yet-all.extended-dns-errors.comSignatures not valid yetSERVFAIL · EDE 8SERVFAIL · EDE 8SERVFAIL · EDE 8
Zones kept broken on purpose by their operators, as our check read them, with each resolver's error code.

Sources:rfc-editor.orgdevelopers.google.comrdap.publicinterestregistry.orgextended-dns-errors.com

How do I turn on DNSSEC at my DNS host and registrar?

Turn DNSSEC on at your DNS host first: it signs the zone and shows a DS record. Then add that DS at your registrar, which sends it to the registry. Some registrars ask for the public key (DNSKEY) instead and make the DS themselves.

Route 53 Domains, OVHcloud and Gandi take the key, not the digest; GoDaddy, Namecheap, Hover and Name.com take the DS. When the DNS host is also the registrar, the DS is often added for you: Cloudflare Registrar reads the zone's CDS record, and IONOS adds it when it signs.

Some nameservers don't sign at all: DigitalOcean's and Hostinger's say so in their own help pages. With them, the only safe state is no DS at the registry.

DS record (for most registrars)

isc.org. IN DS7250132A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697CDA01CB2

  • key tag
  • algorithm
  • digest type
  • SHA-256 digest of the key

DNSKEY (for registrars that take the key)

isc.org. IN DNSKEY257313zEoOfseNFDM+E8spu7RR2Ar/GzFqAehe4yapWLiv6McIUF6xmI5GcIQ3+uLAizS2cNWHt6EArVj8ogjtrRXwfw==

  • flags: 257 = key-signing key
  • protocol (always 3)
  • algorithm
  • public key
  • ProviderIts nameservers sign
  • Cloudflareyes, when you turn it on
  • Amazon Route 53yes, when you turn it on
  • Google Cloud DNSyes, when you turn it on
  • Azure DNSyes, when you turn it on
  • DigitalOceanno
  • Hostingerno
  • OVHcloudyes, on by default
  • IONOSwith a paid plan
  • Gandiyes, when you turn it on
  • GoDaddyyes, when you turn it on
  • Namecheapyes, when you turn it on
  • Porkbunyes, when you turn it on
  • Squarespaceyes, on by default
  • ProviderIts registrar form takes
  • Cloudflare Registrarnothing: it reads your CDS
  • GoDaddythe DS
  • Namecheapthe DS
  • Porkbunthe DS or the DNSKEY
  • Gandithe DNSKEY
  • Squarespace Domainsthe DS
  • Name.comthe DS
  • Hoverthe DS
  • Hostingerthe DS
  • IONOSthe DS, by email
  • OVHcloudthe DNSKEY
  • Amazon Route 53 Domainsthe DNSKEY
isc.org's own DS and DNSKEY, the two forms a registrar may ask for, and what each DNS host and registrar documents.

Sources:developers.cloudflare.comdocs.aws.amazon.comcloud.google.comgodaddy.comdocs.gandi.nethelp.ovhcloud.comdocs.digitalocean.comhostinger.com

How do I turn DNSSEC off safely before moving DNS hosts?

Remove the DS at the registrar first, wait until its TTL has passed so resolvers forget it, and only then stop signing or change nameservers. Done the other way round, resolvers that still hold the DS refuse the domain until it expires.

Cloudflare, Route 53, Google Cloud DNS and Azure all document this order; Cloudflare puts the wait at commonly 24 to 48 hours and keeps the keys 1.5 times the DS TTL after. One registrar's help page gives the reverse order: don't follow it.

Moving between two DNS hosts without a gap needs both to sign with each other's keys (multi-signer DNSSEC). Cloudflare and Google Cloud DNS document a way; Route 53 says it isn't supported. For most moves, going unsigned until the old DS has expired is the safe path.

Safe

  1. Remove the DS at the registrar
  2. Wait for the DS TTL (1 h at .org)
  3. Change nameservers or stop signing

Unsafe

  1. Stop signing first
  2. Resolvers holding the DS answer SERVFAIL until it expires
  3. Remove the DS at the registrar
The safe order and the unsafe one, against the DS's TTL at .org as our check read it.

Sources:rfc-editor.orgdevelopers.cloudflare.comdocs.aws.amazon.comcloud.google.comlearn.microsoft.com

Which DNSSEC algorithms should I use?

Algorithm 13 (ECDSA P-256 with SHA-256) or 15 (Ed25519) for new keys, and SHA-256 (digest type 2) for the DS. RSASHA1 (5 and 7) and SHA-1 DS digests must not be used for signing any more: RFC 9905 deprecated them in 2025.

The rules now live in IANA's registries (RFC 9904). Algorithm 8 (RSA with SHA-256) is still recommended; .org's own keys use it. Resolvers still validate RSASHA1 zones today, but RFC 9905 tells them to treat those zones as unsigned, so moving off it is overdue.

NSEC3, the signed way to say a name doesn't exist, should use 0 extra iterations and no salt (RFC 9276). Some hosts' fixed defaults still add both.

NumberAlgorithmFor signingThis checker
1RSAMD5MUST NOTcan't verify it here
3DSAMUST NOTcan't verify it here
5RSASHA1MUST NOTverifies it, says must migrate
6DSA-NSEC3-SHA1MUST NOTcan't verify it here
7RSASHA1-NSEC3-SHA1MUST NOTverifies it, says must migrate
8RSASHA256RECOMMENDEDverifies it
10RSASHA512NOT RECOMMENDEDverifies it
12ECC-GOSTMUST NOTcan't verify it here
13ECDSAP256SHA256RECOMMENDEDverifies it
14ECDSAP384SHA384MAYverifies it
15ED25519RECOMMENDEDverifies it
16ED448MAYcan't verify it here
17SM2SM3MAYcan't verify it here
18ML-DSA-44MAYcan't verify it here
23ECC-GOST12MAYcan't verify it here

DS digest types

  • 1 SHA-1 MUST NOT
  • 2 SHA-256 RECOMMENDED
  • 3 GOST R 34.11-94 MUST NOT
  • 4 SHA-384 MAY
  • 5 GOST R 34.11-2012 MAY
  • 6 SM3 MAY
IANA's DNSSEC algorithm registry for signing, and the DS digest types, as the checker reads them.

Sources:iana.orgrfc-editor.orgextended-dns-errors.com

Does my resolver validate DNSSEC?

Ask your resolver for a signed domain with dig and look at the flags: a validating resolver sets ad (authentic data) on the answer. No ad flag means your resolver passes answers on without checking them.

Google Public DNS, Cloudflare 1.1.1.1 and Quad9 all validate, as their own documentation says. Your device may not use the resolver you think: a browser with DNS over HTTPS, a VPN or iCloud Private Relay sends lookups elsewhere, so test from the place you care about.

delv checks the signatures on your own machine from the root key, whatever your resolver does. A page in your browser can only test the resolver that browser uses, and only by loading a deliberately broken name beside a working one.

What a validating resolver answers for a signed domain: the ad flag, recorded from Google Public DNS on 2026-11-01.

Sources:rfc-editor.orgdevelopers.google.comdevelopers.cloudflare.comquad9.netfirefox-source-docs.mozilla.orgchromium.orgsupport.apple.com

DNSSEC questions

How do I check if DNSSEC is enabled for a domain?

Enter the domain in the DNSSEC checker above. It looks for a DS record at the registry and DNSKEY records in the zone, then verifies every signature from the root's key down. Secure means both exist and the whole chain checks out. With a terminal, dig example.com DS +short shows the registry's side and dig example.com DNSKEY +short the zone's.

What does it mean when DNSSEC validation fails?

A validating resolver found a signature or DS that doesn't check out, so it refuses to answer: it returns SERVFAIL instead of the address, and the domain stops working for everyone using that resolver, including Google Public DNS, Cloudflare 1.1.1.1 and Quad9. The data is still there: asked with checking disabled, the same resolver answers.

What is a DS record?

A Delegation Signer record, published by the registry in the parent zone, holds the digest of one of the domain's keys: key tag, algorithm, digest type and the digest itself. It is the link that carries trust from the TLD to the domain. You add it at your registrar, copied from your DNS host's DNSSEC settings.

What happens if I turn off DNSSEC without removing the DS record?

The domain breaks. The DS at the registry still tells resolvers the zone is signed, the zone no longer has keys or signatures, and validating resolvers answer SERVFAIL. Remove the DS at the registrar first, wait for its TTL to pass, and only then turn signing off at your DNS host.

How long does a DS record change take?

Two waits add up. The registrar and registry publish it, from minutes to a day: GoDaddy says within an hour, Namecheap 60 minutes, Cloudflare Registrar one to two days. Then resolvers keep the old DS until its TTL runs out, often a day: Cloudflare says commonly 24 to 48 hours.

Is it bad if my domain isn't signed with DNSSEC?

It isn't broken: resolvers answer an unsigned domain normally, and most domains are unsigned. It just isn't protected against forged DNS answers. The IETF calls DNSSEC best current practice (RFC 9364). Sign it when your DNS host supports it; a broken DNSSEC setup is worse than none, so check it after.

Why does my DS record have key tag 2371?

Cloudflare's DS record always has key tag 2371 with algorithm 13, so that DS came from Cloudflare DNS. If your domain's DNS is now somewhere else, it is a leftover that breaks DNSSEC validation: remove it at your registrar, and add the new DNS host's DS if it signs. The checker names it when it finds one.

Which DNSSEC algorithm should I use?

Algorithm 13 (ECDSA P-256 with SHA-256) is the common choice and what Cloudflare, Route 53 and Azure use; 15 (Ed25519) is also recommended, and 8 (RSA with SHA-256) still is. Don't use 5 or 7: RFC 9905 says they must not be used to sign. Use SHA-256 for the DS digest.

Missing something?Suggest a feature or a new tool

Related tools