DNSSEC checker
DNSSEC signs the answers your domain gives, so that a client can tell they were not forged on the way. A half-finished setup is worse than none: a broken signature does not make the domain less secure, it makes it disappear. Check a domain you control and see whether DNSSEC is on and whether it validates.
Watched, not just checked
This is one scan of one layer, run once. In AYAsec the same check runs on a schedule across every asset you own, and you are told the day a grade drops.
What DNSSEC is, in one paragraph
Ordinary DNS answers are not signed: a resolver believes whatever reaches it first. DNSSEC adds signatures to the answers and a chain of trust that leads from the root, through the top-level domain, down to your zone. Your zone publishes its public keys; the parent publishes a fingerprint of them (the DS record). A validating resolver walks that chain and refuses an answer that does not match.
Five reasons to check your own DNSSEC
01
See whether DNSSEC is on at all
It is off by default at most providers and it has to be switched on at two places - the DNS provider, which signs the zone, and the registrar, which publishes the DS record at the parent. Doing only one of them leaves the domain signed on paper and unprotected in practice. A check from the outside is the only way to see the result of both.
02
A broken chain takes the domain offline
This is the part that makes DNSSEC different from every other record on this list. If the signatures do not match the DS record - after a provider migration, a key rollover or a registrar change - validating resolvers answer with an error, not with the wrong address. The domain stops resolving for everyone behind such a resolver, which includes a large share of the internet, and nothing on the server is wrong.
03
Enabled is not the same as validating
Keys can be published and signatures can exist and the chain can still be broken somewhere. What counts is whether a validating resolver accepts the result, and that is what this page asks one.
04
Zone walking, or how NSEC lists your names
To prove that a name does not exist, DNSSEC has to sign the gaps between the names that do. With plain NSEC that proof names the next record in the zone, so anyone can ask a few questions and read the whole list of names. NSEC3 hashes them to make that harder. A zone that lists its names for anyone who asks is giving away its internal structure for free.
05
Evidence that the domain is protected
Insurers and enterprise customers ask about DNSSEC by name. A dated report showing that the chain validated, and when it changed, is a better answer than a screenshot of a DNS panel, and it is evidence you can keep.
Know the day your DNSSEC changes
DNSSEC is the one record set where a routine change can break everything: a provider migration, a registrar transfer, a key rollover nobody scheduled.
Scheduled scans turn that into a difference you are told about: this zone was signed last week and is not now, this chain stopped validating, this grade dropped. Alerts arrive in-app, by e-mail, or through Slack, Teams, Jira or a webhook.
Step 01
Name the domain
A domain you control, added to your AYAsec account. Ownership is checked before anything is dispatched - AYAsec will not schedule scans against infrastructure you have not demonstrated control of, and proving it takes one DNS record. The quick check above skips this: no account, no verification, just IP rate-limiting and a rule that the target has to be a public address.
Step 02
Let the check run
DNSSEC data is public, so this reads rather than probes. It asks a validating resolver for the keys and the answer and looks at what it says.
Step 03
Read the result
Findings arrive ordered by severity and scored A+ to F. A zone that does not validate and a zone that is merely unsigned are not sitting in the same undifferentiated list.
What this is part of
DNSSEC is one of several things AYAsec checks as part of its DNS scan, alongside SPF, DKIM, DMARC, MTA-STS and TLS-RPT, and nameserver configuration and record health. It is one scan, and this page is about one part of what it looks at.
DNS carries 20% of the composite grade. The others are HTTP at 30%, TLS and ports at 20% each, and domain credibility at 10%. All of them together are what attack surface management means in practice.
Questions before you check
What may I check?
Infrastructure you own or are contracted to test. The quick check above doesn't verify that for you - it only rate-limits by IP and refuses to target anything but a public address. Add the domain to an AYAsec account instead, and control is verified before anything scheduled runs: a legal boundary as much as a practical one, since an unverified scan is of no use to you as evidence either.
DNSSEC data is public. Why does this need verification?
The data is public and the check is read-only, so the check itself is harmless. Verification is about what happens next: a domain in your AYAsec account is monitored, graded and kept in your history, and none of that should be possible for a domain that is not yours.
Does DNSSEC encrypt anything?
No. It proves that an answer is genuine; it does not hide it. Encrypting the traffic between a client and a resolver is a different thing.
Is DNSSEC worth the risk of breaking the domain?
For most domains, yes, as long as it is switched on and then watched. The risk is real but narrow: it sits in the moments when keys or providers change. A scheduled check is what turns "we hope the chain is fine" into a notice the day it is not.
My provider signs the zone for me. Am I done?
Not until the registrar publishes the matching DS record. A signed zone without a DS at the parent is not validated by anyone.
Do you keep the results?
Not the quick check above - it lives in memory for about fifteen minutes so you can read it once, then it's gone. That's a deliberate privacy choice, not a limitation: nobody but you ever sees that scan, and you can download the full result before it expires. Add the domain to an AYAsec account instead, and every scan is kept - a series that tells you which edit broke it. Retention depends on your plan.
Keep the history, not just the result
Run the full DNS check against your own domains, on a schedule, with every change flagged to whoever needs to see it.