A signed record is not the whole trust chain
DNSSEC adds signatures to DNS data so that a validating resolver can detect certain forms of forged answers. It does not encrypt the query and does not make the website behind the domain trustworthy. Validation connects signed data through delegations to a trusted starting point. Publishing a DNSKEY without a usable chain of trust does not provide the same assurance as a successfully validated answer.
This inspector asks a validating public resolver for an A answer, DS records and DNSKEY records. It reports the resolver’s authenticated-data flag and exposes the returned records. The important boundary is explicit: this application relies on the resolver’s validation assertion. It does not independently fetch and cryptographically verify every signature, delegation and denial-of-existence proof.
Understand the AD flag and resolver perspective
The AD flag means authenticated data when set by a validating resolver according to its policy and trust configuration. In this tool, an A query with AD=true is reported as an authenticated answer from Google Public DNS. The response status and timestamp remain part of the evidence. The application does not turn that assertion into a universal statement about every possible query for the domain.
AD=false is not a single diagnosis. The domain may be unsigned, an answer may not carry authenticated data, or resolution may have failed. An unsigned domain can resolve successfully with status NOERROR. A DNSSEC problem can lead a validating resolver to return SERVFAIL. Read the status together with the authentication flag instead of equating every false flag with an attack.
The resolver request asks for DNSSEC-related data and leaves validation enabled. These options help obtain relevant evidence, but the transport between the browser and this page is also part of your trust path. Public deployment should use HTTPS so the displayed response cannot be altered in transit to your browser.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Read DS and DNSKEY at the right boundary
A DNSKEY record publishes a key for a signed zone. A DS record in the parent zone identifies key material for the delegated child. That parent-to-child link is one part of the chain a validating resolver follows. If the DNS operator rotates a key without updating the parent’s DS appropriately, the zone can become bogus to validating resolvers even while an authoritative server continues returning records.
Delegation boundaries matter. A host such as www.example.com may be inside the example.com zone rather than operating as a separately delegated zone. Querying DS and DNSKEY at the full host name can therefore return no such records while its A answer still validates through the containing zone. Absence of a separate key at every host name is normal.
This tool displays the direct queries you requested. It does not discover the effective zone apex, walk through every ancestor or interpret all key algorithms. If you administer the domain, consult the DNS provider and registrar configuration together. One controls the zone’s keys and signatures; the other often controls the parent-side delegation data.
Investigate validation failures without weakening protection
When a recently signed domain starts returning SERVFAIL, compare the behaviour of validating and authoritative resolvers with suitable DNS tools. Check the parent DS, active DNSKEY set, signature validity periods and whether all authoritative servers serve consistent data. Clock-related signature problems and incomplete rollovers can be operational issues rather than malicious interference.
Do not solve a validation failure by telling users to disable validation permanently. That removes the protection rather than repairing the chain. Coordinate changes using the provider’s supported signing and rollover procedure. Deleting or replacing a DS without understanding the transition can prolong an outage because caches retain earlier delegation data.
Keep a time-stamped record of the returned status and flags. If only one resolver fails, compare its cache state and documented policy. If multiple validating resolvers agree, investigate the authoritative chain. This inspector is useful for establishing the symptom and collecting a report; deeper diagnosis may require a full DNSSEC validation tool that shows each link and cryptographic check.
Interpreting the evidence together
| Observation | Likely next question |
|---|---|
| AD=true and NOERROR | The resolver authenticates this response. Which exact name and type were queried? |
| AD=false and NOERROR | Is the name unsigned, or does the response lack authenticated data? |
| SERVFAIL | Is there a delegation, authoritative availability or validation problem? |
| No DS at a hostname | Is this name a zone apex or merely a host inside a signed zone? |
Strengths and limitations
What this is useful for
The inspector makes resolver authentication visible and places it beside direct key and delegation queries. It helps distinguish an unsigned response from a reported resolution failure. Exporting the raw evidence gives an administrator a concrete starting point for a DNSSEC investigation.
What to keep in mind
This is not an independent validator or a complete chain visualiser. It does not enumerate zone boundaries, verify every signature locally, perform a registrar update or establish the security of an HTTPS service. The public resolver’s policy and cache are part of the observation.
Common questions
Does DNSSEC hide the domain I look up?
No. DNSSEC authenticates DNS data; it does not encrypt DNS transport. This application uses an HTTPS connection to the public resolver, but the resolver still sees the queried name. Confidentiality and authenticity are separate properties that require different mechanisms.
Can a subdomain validate without its own DNSKEY?
Yes. A non-delegated host can be covered by signatures from the zone containing it. It does not need a separately published DNSKEY at the host name. The relevant question is which zone is authoritative and how that zone’s signatures connect to a trusted delegation.
Where are the checks performed?
The entered name is sent to the site server, which queries Google Public DNS. The resolver performs validation according to its configuration. The browser displays the returned flags and records; it does not independently repeat the cryptographic validation of the chain.
Is AD=true enough to trust a website?
It is evidence about the authenticity of a DNS response as asserted by the resolver. It says nothing about the honesty of the domain owner, the safety of downloaded files, the website’s application code or whether a valid TLS certificate is presented. Use the relevant checks for those separate questions.