| # | Type | Answer(s) | TTL | Query ms | Copy |
|---|---|---|---|---|---|
| {{ i + 1 }} | {{ row.type }} | {{ row.answer }} | {{ row.ttl }} | {{ row.time }} |
| DNSSEC Checks | Status | Copy |
|---|---|---|
| {{ c.label }} | Pass Fail |
| Resolver | DNSKEY Status | DNSKEY AD | DNSKEY # | DNSKEY ms | DS Status | DS AD | DS # | DS ms | Notes | Copy |
|---|---|---|---|---|---|---|---|---|---|---|
| {{ row.resolverLabel }} | {{ row.dnskey_status }} ({{ row.dnskey_status_text }}) | {{ row.dnskey_ad ? 'Yes' : 'No' }} | {{ row.dnskey_answers }} | {{ row.dnskey_time }} | {{ row.ds_status }} ({{ row.ds_status_text }}) | {{ row.ds_ad ? 'Yes' : 'No' }} | {{ row.ds_answers }} | {{ row.ds_time }} | {{ row.note || '—' }} |
DNSSEC adds signed records to the Domain Name System so resolvers can detect answers that do not match the published chain of trust. That matters most when a domain has just enabled signing, rolled keys, changed delegation, or started failing validation in one place but not another.
This validator checks the visible DNSSEC pieces for a domain by querying DNSKEY, DS, RRSIG, NSEC, and NSEC3PARAM records through a selected DNS-over-HTTPS resolver. It then turns those answers into a record table, a package-specific checklist, an optional resolver comparison, a pass-versus-fail chart, and a JSON snapshot you can copy into a ticket or handoff.
The page is most useful when you need fast evidence rather than a textbook explanation. It shows whether the domain has published keys, whether a DS record is visible, whether the DNSKEY set carries signatures that are currently inside their validity window, whether the code sees the expected key roles, and whether the chosen resolver is returning the AD bit on the most important lookups.
That makes it a practical troubleshooting tool after DNS changes. If one resolver still shows no AD, if a DS record has not appeared where you expect it, or if a key rollover left signatures or key tags mismatched, the line-by-line checks usually point to the missing piece faster than a single red-or-green badge would.
The boundary is important, though. The package is not a full cryptographic validator that rebuilds the entire chain to the root and proves every signed RRset. It reads resolver responses, checks specific DNSSEC signals in those responses, and summarizes them for human review. That is excellent for triage and comparison, but it should still be paired with deeper validation when the domain is about to enter production or when an outage is severe.
The normal workflow starts with the domain name only. The input sanitizer removes a scheme, path, and trailing dot if you paste a fuller URL by habit, so an entry such as https://example.com/ is reduced to the bare name before validation. The current validator accepts ordinary fully qualified names, punycode-style names that begin with xn--, and localhost.
After the lookup runs, read the top summary first. It condenses the result into one of four states: Configured, Partial, Incomplete, or Missing. The badges underneath it give a second quick scan by showing whether the page found DNSKEY, DS, KSK, and ZSK evidence, plus which resolver produced the main result.
The optional resolver comparison has a narrow purpose. It compares DNSKEY and DS answers across the three supported resolvers, then records response code, AD presence, answer count, and latency for both record types. That keeps the comparison focused on the parts most likely to expose a trust-path disagreement.
The main lookup path is browser-side DNS-over-HTTPS. The code queries one resolver selected in the advanced panel, builds URLs for that resolver's JSON endpoint, and requests DNSKEY, DS, RRSIG, NSEC, and NSEC3PARAM in parallel. Each request is timed, and each fetch is bounded by a six-second timeout so the page can fail visibly instead of hanging without explanation.
Once the answers arrive, the package parses only the record fields it needs for its own checks. DNSKEY rows are read for flags, protocol, and algorithm. DS rows are read for key tag, algorithm, and digest type. RRSIG rows are filtered to the signatures that cover DNSKEY, then inspected for algorithm, key tag, inception, and expiration. The page does not attempt to validate every RRset in the zone. It focuses on the pieces the author chose as practical DNSSEC health signals for a quick report.
The checklist is therefore opinionated and easy to audit. It asks whether DNSKEY and DS records are present, whether at least one flag-257 key and one flag-256 key appear, whether all DNSKEY records declare protocol 3, whether an RRSIG over DNSKEY exists and is valid at the current time, whether the DS and DNSKEY algorithms overlap, whether the DS digest type is in the package's accepted set, whether the code sees an acceptable DNSKEY algorithm, whether a DS key tag matches an RRSIG(DNSKEY) key tag, whether NSEC or NSEC3PARAM is present, and whether the resolver set AD on DNSKEY and DS responses.
The summary status is simpler than the checklist. Configured requires DNSKEY, DS, KSK, and ZSK evidence. Partial covers cases where DNSKEY and DS are present but a role is missing, or where DNSKEY exists with at least one key role already visible. Incomplete means only one side of the core pair is present. Missing is reserved for cases where neither DNSKEY nor DS appears.
| Check family | What the package tests | Why it helps |
|---|---|---|
| Record presence | DNSKEY, DS, and denial-related records are checked for visible answers. | Missing core records usually point to incomplete signing or delegation. |
| Key roles | Flag 257 and flag 256 DNSKEY rows are counted as KSK and ZSK evidence. | Separate role visibility helps catch partial rollovers or incomplete publication. |
| Protocol and algorithms | All DNSKEY rows must use protocol 3; the package also applies its own accepted algorithm lists. | This catches malformed key material and highlights algorithm mismatches the code considers suspicious. |
| Signature timing | RRSIG(DNSKEY) must exist and the current time must sit between inception and expiration. | Expired or not-yet-valid signatures can break otherwise plausible DNSSEC deployments. |
| Delegation consistency | DS algorithm and DS key tag are compared with DNSKEY and RRSIG(DNSKEY) data. | These checks help surface mismatched parent-to-child delegation details. |
| Resolver-side trust signal | The page records whether the chosen resolver returned AD on DNSKEY and DS. | This is a useful troubleshooting clue when different resolvers disagree, even though it is not independent proof. |
The chart tab is intentionally narrow. Despite the tab label Trust Chain Chart, the graph itself is a pass-versus-fail donut built from the checklist count rather than a topology diagram of the delegation chain. That makes it easy to export and easy to compare between runs, but it should be read as a checklist summary rather than as a visualization of the entire DNS tree.
The resolver-comparison mode asks Cloudflare, Google Public DNS, and Quad9 for DNSKEY and DS, then reports status, answer count, latency, and AD presence. That is useful troubleshooting evidence, but it is still resolver-side evidence rather than full validation under your own control. The browser sends these DNS-over-HTTPS queries directly, and the selected providers receive the queried domain names.
A Configured result means the package saw the core pieces it considers most reassuring: DNSKEY, DS, at least one KSK, and at least one ZSK. That is the strongest summary state in the current code, but it still does not mean every DNSSEC edge case is clean. It means the visible structure and timing signals passed this package's chosen checks.
Partial and Incomplete are often the most useful states during active changes because they distinguish "something important exists" from "the trust path is still visibly broken." A domain that has published DNSKEY but not yet exposed DS where the resolver can see it should not be read the same way as a domain with no signing evidence at all, and the page keeps those cases separate.
The AD rows deserve careful reading. RFC 4035 treats the AD bit as a limited resolver-side signal rather than something a stub should trust blindly, so this tool uses it best as a troubleshooting clue, not a final verdict.
The NSEC or NSEC3PARAM pass row should also be read modestly. The package only checks for visible presence of one of those denial-related record families. It does not try to prove complete negative-response behavior for every case. A passing row is therefore a useful hint, not exhaustive proof of correct authenticated denial handling.
Suppose the resolver returns DNSKEY and DS answers, the DNSKEY set includes both flag 257 and flag 256 entries, an RRSIG covering DNSKEY is present and valid at the current time, and the resolver sets AD on both DNSKEY and DS. In this package that usually produces a Configured summary, a mostly green checklist, and a chart dominated by passing rows.
If DNSKEY answers are present but the DS record is missing or the resolver still returns no DS answer, the page can still show some healthy evidence while keeping the overall result below Configured. That is exactly the sort of state where the tool is useful: it shows that signing work has started, but that the parent-side delegation signal is not yet visible where the resolver is looking.
Enable the resolver comparison after a key rollover or delegation update. If one provider returns AD on DNSKEY and DS while another does not, the comparison table will expose that split even if the main lookup looks acceptable on its own. That does not tell you which resolver is "right," but it gives you concrete evidence that the trust signal is not uniform yet.
No. It means the page found the records, roles, timing, algorithms, and AD signals it knows how to inspect. It does not rebuild or prove the complete chain of trust to the root for every signed record set.
Because resolvers can differ in cache state, validation behavior, or timing around changes. The comparison view gives you a quick way to see whether DNSKEY and DS trust signals are consistent across three common public resolvers.
It tells you whether the selected resolver marked the response as authenticated data. That is useful evidence, but it is still the resolver's signal rather than an independent validation performed by this page.
Yes. The package performs live DNS-over-HTTPS requests from the browser to the selected resolver, and optional comparison mode sends additional DNSKEY and DS lookups to the other supported resolvers.