DNSSEC Checker
Verify whether a domain has DNSSEC enabled, check DS and DNSKEY records, confirm the chain of trust, and detect misconfigured or BOGUS DNSSEC — the DNSSEC lookup tool built for DNS admins, MSPs, and security engineers.
What is DNSSEC?
DNSSEC (Domain Name System Security Extensions) adds cryptographic authentication to DNS. Without it, DNS responses can be forged — an attacker positioned between a user and their resolver can return fabricated DNS answers that redirect the user to a malicious server while the browser shows the legitimate domain name in the address bar. This class of attack is called DNS cache poisoning or DNS spoofing, and it is undetectable by the user.
DNSSEC prevents this by having the authoritative DNS server sign every record it publishes. Resolvers that support DNSSEC validation verify these signatures before returning results. If the signature is missing, expired, or does not match the record, the resolver refuses the response. The end result is that DNS data is tamper-evident — any modification in transit is detectable.
For MSPs and DNS admins: DNSSEC is increasingly required by security frameworks. CISA's BOD 18-01 requires DNSSEC for all .gov domains. Many enterprise security checklists now include DNSSEC status alongside SPF, DKIM, and DMARC checks. This tool lets you verify DNSSEC in seconds before a client audit or onboarding call.
How the DNSSEC chain of trust works
DNSSEC validation follows a hierarchical chain starting from the DNS root. Each level of the hierarchy signs the public key of the zone below it, creating a continuous chain from the root down to the target zone. A validating resolver can verify a response by checking signatures all the way up the chain.
Chain of trust layers
- DNS Root (.) — The root zone is self-signed. Resolvers ship with the root public key (trust anchor) hard-coded. IANA publishes the root DNSKEY as KSK-2017.
- TLD Zone (.com, .org, .uk) — The root zone signs the DS record for each TLD. This links root trust to the TLD's DNSKEY.
- Second-level domain (example.com) — The TLD registry (.com) publishes a DS record pointing to your zone's Key Signing Key. Your registrar submits this DS record on your behalf.
- Your zone (example.com) — Your authoritative DNS server signs all records (A, MX, TXT, etc.) with the Zone Signing Key (ZSK), and signs the ZSK with the Key Signing Key (KSK).
What this tool checks
- DS record — Queries the parent zone for a Delegation Signer record. Present means the TLD has published a hash of your KSK — the chain of trust is established.
- DNSKEY record — Queries your zone for public signing keys. If DNSKEY is present but DS is absent, the chain is broken at the TLD boundary.
- RRSIG — Checks whether Resource Record Signature records are returned alongside the SOA record. This confirms the zone is actively signing records, not just publishing keys.
- AD bit — Queries Cloudflare's validating resolver and checks whether it sets the Authenticated Data bit. AD=1 means the full chain from root to zone was verified.
- NSEC/NSEC3 — Checks which authenticated denial-of-existence mechanism the zone uses.
DS records vs DNSKEY records
These two record types work together but live in different zones. Understanding the difference helps explain why a domain can have DNSKEY records but still show "Partial" DNSSEC status.
DNSKEY record
Published in your zone by your DNS provider.
- KSK (Key Signing Key, flags 257) — Signs the DNSKEY record set itself. The DS record in the parent zone is derived from the KSK. Long-lived; rolled infrequently (months to years).
- ZSK (Zone Signing Key, flags 256) — Signs all other record types in the zone (A, MX, TXT, etc.). Rolled more frequently (weeks to months) to limit exposure if the key is compromised.
example.com. 3600 IN DNSKEY 257 3 13 <base64-key>
257 = KSK | 13 = ECDSAP256SHA256
DS record
Published in the parent zone (TLD registry) by your registrar.
- Contains a hash (digest) of your KSK — not the full public key.
- The registrar submits the DS record on your behalf when you enable DNSSEC. Many registrars call this "DNSSEC activation."
- The TLD registry adds the DS record to the parent zone (e.g., .com), linking their trust to your zone's KSK.
example.com. 3600 IN DS 12345 13 2 <sha256-digest>
12345 = key tag | 13 = algorithm | 2 = SHA-256
Partial DNSSEC means DNSKEY is present but DS is not. This is the most common misconfiguration. The zone is generating signatures, but validating resolvers cannot trust those signatures because the parent zone never published the DS record. Fix: log in to your registrar and publish the DS record.
DNSSEC signing algorithms
The algorithm used to sign DNSSEC records affects security strength and DNS response sizes. Modern elliptic-curve algorithms (ECDSA, EdDSA) produce much smaller signatures than RSA, which is important because DNS traditionally uses small UDP packets.
| Number | Name | Status | Notes |
|---|---|---|---|
| 13 | ECDSAP256SHA256 | Recommended | Elliptic curve. Small keys, fast validation. Default on Cloudflare and most modern providers. |
| 14 | ECDSAP384SHA384 | Strong | Larger ECDSA curve. Suitable for high-security use cases. |
| 15 | ED25519 | Strong | Modern EdDSA. Very small signatures. Excellent for performance-sensitive zones. |
| 16 | ED448 | Strong | Larger EdDSA curve. Limited resolver support compared to ED25519. |
| 8 | RSASHA256 | Acceptable | RSA with SHA-256. Widely supported but larger signatures than ECDSA. |
| 10 | RSASHA512 | Acceptable | RSA with SHA-512. Very large signatures — may cause UDP fragmentation. |
| 5 | RSASHA1 | Deprecated | SHA-1 is cryptographically weak. RFC 8624 recommends against use. |
| 7 | RSASHA1-NSEC3-SHA1 | Deprecated | SHA-1 based. Replace with algorithm 13 or 15. |
| 3 | DSA | Avoid | DSA is weak. Do not use. |
| 1 | RSAMD5 | Avoid | MD5 is broken. Do not use. |
BOGUS DNSSEC and key rollovers
BOGUS DNSSEC is the most dangerous DNSSEC state. A zone is BOGUS when it has DNSKEY and DS
records configured but the signatures fail validation. Validating resolvers — including
Cloudflare 1.1.1.1, Google 8.8.8.8, and most enterprise DNS resolvers — return
SERVFAIL for BOGUS zones.
This makes the domain completely unreachable for affected users, with no visible browser error
that identifies DNS as the cause.
Common causes of BOGUS DNSSEC
- Failed key rollover — The old DNSKEY was removed from the zone before the new DS record propagated to the parent TLD zone. There is a window of several hours during rollover where both must coexist.
- Expired RRSIG signatures — If the zone signing automation stops, RRSIG records expire and signatures become invalid. Most DNS providers auto-renew; check your provider's DNSSEC status dashboard.
- DS record mismatch — The DS record at the registrar references a KSK that no longer exists in the zone, or the hash does not match the current KSK value.
- Migrating DNS providers — Moving a zone to a new DNS provider without updating the DS record at the registrar, or the new provider uses a different KSK.
Safe key rollover process
- Pre-publish KSK — Add the new KSK to the zone while the old KSK is still active. Allow time for both to be seen by resolvers (at least 2× the DNSKEY TTL).
- Update DS at registrar — Submit the new DS record at the registrar. Wait for TLD propagation (typically 24–48 hours).
- Verify validation — Confirm that resolvers see the new DS and that the AD bit is still set. Use this tool to verify.
- Remove old KSK — Only after the new DS is confirmed published and validated, remove the old DNSKEY from the zone.
NSEC vs NSEC3: authenticated denial of existence
DNSSEC needs a way to prove that a DNS name does not exist — otherwise an attacker could simply strip NXDOMAIN responses. NSEC and NSEC3 solve this by including a signed pointer to the next existing name in the zone.
NSEC works by chaining all names in sorted alphabetical order. The chain reveals plaintext names — an attacker can "walk" the zone by querying NSEC records sequentially, enumerating every hostname in the zone. For internal domains this is a significant information leak.
NSEC3 hashes each name with a salt before including it in the chain.
The chain reveals only hashed values, preventing enumeration of plaintext names.
NSEC3 requires support from both the zone's DNS provider and the resolvers (all major
resolvers support NSEC3). The NSEC3 opt-out
flag can further reduce zone size by not requiring NSEC3 records for unsigned delegations.
How to enable DNSSEC for your domain
Enabling DNSSEC requires two separate steps at two separate places: your DNS hosting provider and your domain registrar. Both steps are required for a valid chain of trust.
Step 1 — Enable signing at your DNS provider
- Cloudflare — DNS → Settings → DNSSEC → Enable DNSSEC. Cloudflare signs the zone automatically and shows you the DS record to submit.
- AWS Route 53 — Hosted Zone → DNSSEC signing → Enable. Route 53 creates a KSK in AWS KMS and begins signing.
- Google Cloud DNS — Cloud DNS → Zone → DNSSEC tab → Enable. Choose algorithm (ECDSAP256SHA256 recommended).
- Azure DNS — Currently does not support DNSSEC signing (as of 2025). Use a third-party provider for DNSSEC.
Step 2 — Publish DS record at your registrar
- Cloudflare Registrar — If Cloudflare manages both your DNS and your registration, DNSSEC is enabled automatically — no manual DS submission required.
- GoDaddy — My Products → DNS → DS records → Add. Enter the Key Tag, Algorithm, Digest Type, and Digest from your DNS provider.
- Namecheap — Domain List → Manage → Advanced DNS → DNSSEC → Add new record.
- Google Domains / Squarespace Domains — DNS → DNSSEC → Add a Key. Paste the DS record values from your DNS provider.
After publishing the DS record, allow 24–48 hours for TLD propagation. Run this tool again to confirm the Signed status.
Frequently asked questions
What is DNSSEC and why does it matter?
DNSSEC adds cryptographic signatures to DNS records so that resolvers can verify the data came from the authoritative server and was not modified in transit. Without DNSSEC, DNS responses can be forged — an attacker can redirect users to malicious servers while the browser shows the legitimate domain. DNSSEC is the DNS equivalent of HTTPS for web pages: HTTPS encrypts and authenticates HTTP, DNSSEC authenticates DNS responses.
What is the difference between DS records and DNSKEY records?
DNSKEY records live in your zone and contain your zone's public signing keys. DS (Delegation Signer) records live in the parent zone (e.g., .com registry) and contain a cryptographic hash of your Key Signing Key. The DS record links the parent's trust to your zone. Both must be present for a complete chain of trust. If only DNSKEY is present, this tool reports "Partial" status — the zone is signing records but the parent zone has not published the trust link.
What does "Partial" DNSSEC status mean?
Partial means your zone has DNSKEY records but no DS record in the parent zone. The zone is signing records, but validating resolvers cannot verify those signatures because the chain of trust is broken at the TLD boundary. Resolvers treat the zone as unsigned — they do not validate or reject signatures, they simply ignore them. Fix this by logging in to your domain registrar and publishing the DS record your DNS provider generated.
What is BOGUS DNSSEC and how dangerous is it?
BOGUS DNSSEC means DNSKEY and DS records are configured but signatures fail validation. Validating resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, and many ISPs) return SERVFAIL for BOGUS zones — the domain is completely unreachable for affected users. Unlike other DNSSEC states, BOGUS can cause an outage. The most common causes are expired RRSIG records, a DS record mismatch after a key rollover, or removing a DNSKEY before the new DS propagates. Fix urgently: verify that the DS at your registrar matches the current DNSKEY, and re-sign the zone if signatures have expired.
Which DNSSEC algorithm should I use?
Use ECDSAP256SHA256 (algorithm 13) or ED25519 (algorithm 15). Both are modern elliptic-curve algorithms with small key sizes and fast validation. ECDSAP256SHA256 has broader compatibility with older resolvers, while ED25519 has the smallest possible signature size. Avoid RSASHA1 (algorithm 5) and RSASHA1-NSEC3-SHA1 (algorithm 7) — these use SHA-1 which is cryptographically weak. Avoid RSAMD5 (algorithm 1) and DSA (algorithm 3) entirely — these are broken algorithms.
What is the Authenticated Data (AD) bit?
The AD bit in a DNS response signals that the resolver successfully validated the DNSSEC signatures for the response. If a DNSSEC-validating resolver (like Cloudflare 1.1.1.1) returns AD=1, the full chain of trust from the DNS root through the TLD to the zone has been verified. This tool queries Cloudflare's resolver and checks whether the AD bit is set — it is the strongest indicator that DNSSEC is correctly configured end-to-end.
Can enabling DNSSEC break my domain?
Yes — misconfigured DNSSEC can make a domain unreachable for users on validating resolvers. The risk is highest during key rollovers (when you rotate signing keys) and during DNS provider migrations. The safe rollover sequence is: add the new KSK to the zone alongside the old KSK, wait for the new DS record to propagate from the registrar to the TLD, verify validation still works, then remove the old KSK. Never remove a DNSKEY before confirming the new DS record is live in the parent zone.
Why use NSEC3 instead of NSEC?
NSEC allows zone walking — an attacker can enumerate all DNS names in your zone by querying NSEC records sequentially. This reveals your internal naming structure: hostnames, servers, services, and subdomains. NSEC3 hashes each name before including it in the chain, preventing enumeration. If your zone contains sensitive hostnames (internal servers, staging environments, customer subdomains), use NSEC3. Most modern DNS providers offer NSEC3 as the default or as an option in the DNSSEC settings.
How does this tool validate DNSSEC — does it verify signatures directly?
No. This tool delegates DNSSEC validation to two major public DNSSEC-validating resolvers — Cloudflare 1.1.1.1 and Google Public DNS — rather than independently verifying RRSIG cryptography. Each resolver is queried without the CD (Checking Disabled) flag, so they perform full internal DNSSEC validation. The tool then checks the Authenticated Data (AD) bit in their responses: AD=1 means the resolver successfully verified the full chain of trust from the DNS root to the zone. SERVFAIL from a resolver indicates BOGUS DNSSEC. This approach covers all practical failure modes — unsigned zones, broken chains, expired signatures, and DS mismatches — and reflects what real-world users on those resolvers actually experience. For authoritative cryptographic verification, use tools like dnssec-verify, ldns-verify-zone, or your DNS provider's signing dashboard.
What does "Resolver Disagreement" mean?
Resolver Disagreement means one public DNSSEC-validating resolver accepted the chain of trust (returned AD=1) while the other returned SERVFAIL. This is an unusual state that indicates something is wrong with the DNSSEC configuration, but the picture is not fully clear. Common causes: a key rollover where the new DS record has propagated to one resolver's cache but not the other; a timing issue where signatures are expiring but one resolver is still serving a cached valid response; or resolver-specific behavior differences. Re-run the check in a few minutes — persistent disagreement warrants checking your DS records at the registrar and RRSIG expiry dates.