DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records, protecting against DNS spoofing, cache poisoning, and man-in-the-middle attacks. Our DNSSEC Validator checks a domain's DNSSEC configuration by verifying DNSKEY records, DS records at the parent zone, RRSIG signatures, and the overall chain of trust to confirm that the domain is properly secured against DNS tampering.
How to Use
Enter the domain name you want to check for DNSSEC configuration.
Click Validate to query DNSSEC records and verify the chain of trust.
Review whether DNSSEC is enabled and which record types are present.
Check individual record status to identify missing or misconfigured DNSSEC records.
Use Cases
DNS Security: Verify that your domains are protected against DNS spoofing and cache poisoning.
Compliance: Meet regulatory requirements that mandate DNSSEC for government and financial domains.
Email Security: Ensure DNSSEC is properly configured for DMARC and email authentication to function correctly.
Troubleshooting: Diagnose DNSSEC validation failures that prevent clients from resolving your domain.
Frequently Asked Questions
The chain of trust in DNSSEC starts at the root zone, where root DNSKEYs are trusted. Each zone signs its DNSKEY with its parent's private key via a DS record. This chain continues from root, through TLDs, down to your domain. The validator checks that this chain is complete and valid.
The validator checks for DNSKEY records (public keys used for verification), DS records (delegation signer linking to parent zone), and RRSIG records (digital signatures over DNS data). Optionally, it also checks for NSEC/NSEC3 records used for authenticated denial of existence.
No, DNSSEC does not encrypt DNS traffic. It only adds digital signatures to authenticate DNS data. For DNS privacy and encryption, use DNS over HTTPS (DoH) or DNS over TLS (DoT) in combination with DNSSEC for both authenticity and confidentiality.
Deployment cost and complexity. Signing a zone requires maintaining key material through rotation, and delegating to the parent zone needs a signed DS record — both straightforward for a domain you control and a genuine chore. Adoption has grown steadily but most of the domain space remains unsigned, so an insecure result is the normal answer and not a sign of misconfiguration.
Insecure means the zone has no signatures at all — nothing to validate, and not an attack. Bogus means signatures are present but the chain does not verify, which usually indicates a broken key, an expired signature, or a delegation problem. Only bogus indicates something wrong, and it usually affects validation for that whole subtree. Reading the two as equivalent would misreport a normal state as a fault.
No, and the distinction matters. DNSSEC guarantees that an answer for a signed domain came from that domain's authoritative nameservers and was not altered in transit. It cannot tell you whether a site at that address is legitimate, whether it is asking for credentials it should not, or whether it is a convincing copy. Those require the protections that operate after the connection is established, including TLS and user judgement.
Delegation errors break resolution for the whole zone, and they are the reason adoption is cautious. A DS record that does not match the zone's key signing key makes the domain resolve as bogus for validating resolvers, which looks like an outage to every visitor using one. Signing itself is safe; the parent delegation is the delicate part, and testing with a validating resolver before relying on it is the sensible sequence.
It can, but the CDN has to participate — an unsigned CDN zone with a signed origin breaks the chain. Providers that support DNSSEC validation at the edge configure this for you, which is one reason delegating to a major CDN is easier than signing in house. If you self-host any part of the chain, every name in the delegation path has to be signed consistently or the result is bogus for the entire subtree.
What Is Validated
DNSSEC adds cryptographic signatures to DNS answers so they cannot be forged. This page asks a validating resolver what it found, which is the only way to see the verdict — the signatures themselves are not visible to ordinary queries.
1Query a resolver that performs validation and request the DNSSEC-relevant record types. A standard resolver returns answers without checking signatures, so the AD flag in the response is the signal that validation actually happened.
2Distinguish secure, insecure and bogus. Secure means the chain of trust validated to a root key. Insecure means the zone is unsigned, which is not an attack. Bogus means signatures exist but do not verify — that is a genuine failure and the one that matters.
3Report the chain of trust from the domain's key signing key up to the trust anchor, so a broken delegation is visible as a specific missing link rather than a bare failure.
Most domains are unsigned, and that is the overwhelmingly common answer rather than a problem to fix. DNSSEC protects the integrity of DNS answers; it says nothing about the content they point to.
Tips & Best Practices
•Enable DNSSEC to protect against DNS spoofing and cache poisoning
•Verify DNSSEC configuration with this validator after setup
•Monitor DNSSEC signature expiry to prevent DNS failures
•Use DNSSEC alongside TLS for defense-in-depth security
Technical Details
Protocol: DNS Security Extensions (DNSSEC) validation Records: DNSKEY, RRSIG, DS, and NSEC record analysis Chain: DNSSEC trust chain validation Output: DNSSEC status with validation chain details
