DNSSEC checker
Validate DNSSEC signing for any domain. Check DNSKEY, DS, and RRSIG records and verify the chain of trust.
How to read your DNSSEC results
DNSSEC signs DNS answers so a resolver can prove they were not tampered with in transit. It does not encrypt anything and it does not hide your records. It only proves the answer you received is the answer the zone published.
- DNSKEY is the public key set published in your own zone. Present but unvalidated means the zone is signed while the parent does not know about it yet.
- DS is the fingerprint of that key held by the parent zone, usually via your registrar. This is the link that makes the chain work, and it is the piece people forget.
- RRSIG is the signature over a record set. Each one has an expiry, and an expired signature makes the whole zone fail validation even though every record in it is still correct.
- Resolver validated (AD) means a validating resolver checked the signatures and accepted them. This is the summary result and the one to look at first.
- Chain of trust walks from the root down to your zone. A break at any level invalidates everything below it, so the level that fails tells you where to look.
What usually goes wrong
DNSSEC failures are unusually harsh. A domain that fails validation does not degrade or show a warning, it stops resolving entirely for anyone using a validating resolver.
- Zone signed but no DS at the registrar. The common half finished state. Nothing breaks, but nothing is protected either, because resolvers have no way to know the zone is signed.
- DS record left behind after moving hosts. The most damaging failure. The parent still points at a key the new provider does not have, so every validating resolver refuses the domain. The site is unreachable and the DNS records themselves all look perfectly fine.
- Expired RRSIG. Signatures need periodic resigning. If that automation stops, the zone fails once the last signature lapses, with no warning beforehand.
- Key rotation done in the wrong order. The new DS has to be published and given time to propagate before the old key is withdrawn. Doing it the other way round breaks the chain for the length of the TTL.
Before any nameserver migration on a signed domain, remove the DS record first, wait for it to expire from caches, then move. Re-add it once the new provider is signing.
Common questions
Do I need DNSSEC?
It is worth having, but it is not free of risk. It protects against DNS spoofing and cache poisoning, which are real but not common attacks on a typical site. The cost is that a misconfiguration takes your domain offline completely rather than degrading. Enable it where the registrar and DNS host manage the key lifecycle for you.
Why is my domain signed but not validating?
Almost always a missing DS record at the registrar. Signing the zone publishes keys, but until the parent zone holds the matching fingerprint, resolvers have no reason to trust them. The zone is signed and unprotected at the same time, which looks like success from inside the DNS panel.
My site went down after changing DNS hosts. Is DNSSEC the cause?
Very likely, if the domain was signed. A DS record left at the registrar points at a key the new provider does not hold, so validating resolvers reject every answer for the domain. The fix is to remove the DS record at the registrar and wait for it to clear from caches.
Does DNSSEC encrypt my DNS queries?
No. DNSSEC authenticates answers, it does not conceal them. Anyone on the path can still see which names are being looked up. Encrypting the query itself is a different mechanism, DNS over HTTPS or DNS over TLS, and the two solve separate problems.