| # | Metric | Value | Notes | |
|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.metric }} | {{ row.value || '-' }} | {{ row.note || '-' }} |
| # | Priority | Recommendation | Why now | |
|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.priority }} | {{ row.recommendation }} | {{ row.rationale }} |
| # | Section | Type | Name | Data | TTL | |
|---|---|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.section }} | {{ row.type }} | {{ row.name }} | {{ row.data }} | {{ row.ttl }} |
| # | Query | Status | Resolver | Answers | AD | Latency (ms) | |
|---|---|---|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.query }} | {{ row.status }} | {{ row.resolver }} | {{ row.answers }} | {{ row.ad ? 'Yes' : 'No' }} | {{ row.ms === null ? '-' : row.ms }} |
DNS records are the public instructions that tell resolvers where a name points, which mail hosts should accept traffic, and whether extra controls such as DNSSEC or mail-authentication policies are visible from the outside. When those records drift, a service can look healthy from one network and broken from another, even though nothing about the application itself changed.
This enumerator builds a broad snapshot of what public recursive resolvers return for one target. For hostnames, it can query core zone records, optional service-binding records, optional DNSSEC records, optional mail-policy names, and optional A and AAAA probes for related hosts. For IP addresses, it switches to a reverse-DNS path and asks only for the PTR name derived from the address.
The result is wider than a single lookup table. You get an overview panel, a prioritized hardening queue, a normalized record ledger, per-query resolver evidence, a chart that shows record-type mix, and a second chart that summarizes a local posture heuristic. That makes the page useful during migrations, outage review, and security hygiene work.
The boundary matters. This page does not perform zone transfers, interrogate your authoritative servers directly, or prove that a website, mail host, or certificate endpoint is reachable. Its queries go from your browser to public DNS-over-HTTPS endpoints, and the active target and settings are written into the page URL, so treat both the queried name and any shared link as data you are deliberately disclosing.
Start with the preset that matches the question. Balanced is the normal first pass because it includes core DNS, DNSSEC, mail-policy names, and a modest host-probe list. Fast triage strips the run down to the essentials. Mail hardening focuses on SMTP-related TXT names and common mail hosts. Deep audit widens the run with more probes and the Additional section.
Read the Probe Snapshot and Hardening Queue first. The snapshot compresses the run into target, resolver mode, success rate, record count, latency, TTL range, and headline mail signals. The hardening queue turns discovered gaps into ranked actions, each with a short explanation. If nothing urgent surfaced, the queue still emits a single Good row.
Use the other tabs to answer narrower questions. Record Ledger is the evidence table for what the resolvers actually returned after the page normalized each answer. Resolver Evidence is the per-query audit trail, including status, answer count, AD visibility, latency, and failure messages. Record Constellation is a count view, not a severity view. Policy Signal Radar is a heuristic summary meant for comparison and triage, not a standard or compliance score.
A few operating patterns are worth keeping in mind. Use the same preset and resolver mode before and after a DNS change if you want a fair comparison. Turn on host probes when you care about typical service names such as www, mail, or autodiscover. Turn on the Additional section only when you want glue-like helper data in the ledger.
The query plan is assembled entirely in the browser. For hostnames, the fixed core set is A, AAAA, NS, SOA, MX, TXT, and CAA. Optional service records add SVCB, HTTPS, SRV, and NAPTR. Optional DNSSEC records add DNSKEY, DS, RRSIG, NSEC, and NSEC3. Optional mail checks query _dmarc, _mta-sts, _smtp._tls, and whatever DKIM selectors you supply. Host probes add A and AAAA lookups for each selected label.
Input handling is conservative by design. Only the first nonblank line is used. A pasted URL contributes its hostname, a pasted email contributes the domain portion after the last @, brackets and trailing dots are stripped, and text is lowercased before validation. IP addresses are accepted directly and converted into in-addr.arpa or ip6.arpa PTR names. Hostnames, however, must already be ASCII and contain at least one dot, so raw Unicode internationalized names will be rejected rather than converted automatically.
Resolver behavior is also explicit. The page sends DNS-over-HTTPS requests to Cloudflare or Google, using the selected timeout, retry count, and optional DO and CD bits. In auto mode it tries Cloudflare first and falls back to Google only after a hard failure. By default only the Answer section becomes record rows. Turning on the Authority or Additional switches expands the ledger to include those sections as well.
Returned data is normalized before display. TXT strings are unquoted, trailing dots are removed where sensible, MX rows are shown as preference plus exchange, SOA rows are reduced to the primary server plus serial, and CAA, SVCB, or HTTPS rows keep the most useful fields visible. The ledger still preserves section, type, name, normalized data, TTL, resolver label, and the source query that produced each row.
The posture radar is an internal scoring model built from the collected evidence. Core DNS checks for apex NS, SOA, address, and CAA visibility. Mail Auth checks for SPF, DMARC, enforcement, MTA-STS, and TLS reporting. DNSSEC checks for DNSKEY, DS, RRSIG, and whether AD was observed. Reliability reflects successful probes as a share of total probes. Action Debt starts at 100 and drops according to the severity of the current hardening rows.
| Output | Built from | Best use |
|---|---|---|
| Probe Snapshot | Run-wide stats, mail findings, and top queued action | Fast triage and before-versus-after comparison |
| Hardening Queue | Rule checks around NS, SOA, apex address, CAA, SPF, DMARC, MTA-STS, TLS-RPT, DNSSEC signals, and probe failures | Prioritizing what to fix next |
| Record Ledger | Normalized Answer, Authority, and optional Additional rows | Inspecting exact record content and TTLs |
| Resolver Evidence | Per-query resolver, status, answer count, AD flag, latency, and error state | Troubleshooting drift, refusal, or timeout patterns |
| Record Constellation | Counts per record type | Seeing record-family mix at a glance |
| Policy Signal Radar | The local 0 to 100 posture heuristic across five dimensions | Comparing runs without treating the result as a standard |
| JSON export | Normalized inputs, warnings, stats, overview, hardening rows, records, resolver evidence, email findings, and posture scores | Archiving an exact run snapshot |
AD visibility is useful evidence, but it is still evidence reported by the recursive resolver. It is a clue that the resolver claims the relevant data is authentic, not a guarantee that your browser performed end-to-end DNSSEC validation itself.
If the target is an IP address, the page is answering a reverse-DNS question only. Rerun the hostname separately if you also need forward records, mail TXT names, or DNSSEC visibility for the zone.
The summary box is meant to answer three immediate questions: how many records were collected, how many probes succeeded, and what the highest-priority action is right now. The badges beneath it then add resolver mode, record-type count, probe count, average latency, AD visibility, and selected mail-policy cues such as DMARC policy and SPF lookup count.
| Signal | What it usually means here | What to check next |
|---|---|---|
| High-priority hardening row | A missing or risky signal such as absent NS, SOA, SPF, DMARC, or an SPF lookup count above the RFC ceiling | Read the rationale column, then confirm the relevant rows in Record Ledger |
DMARC p=none |
The record is present, but the page treats it as monitoring-only rather than enforcement | Decide whether policy data is stable enough for quarantine or reject |
| SPF count near 10 | The page counted many DNS-query terms inside the first SPF record it found at the apex | Trim includes or other lookup-causing terms before the policy breaks for some evaluators |
Probe failures or SERVFAIL/REFUSED |
Some selected lookups did not return a successful DNS answer | Use Resolver Evidence to separate timeout, HTTP failure, resolver refusal, and DNS status issues |
| Low Action Debt score | The local posture model saw several High, Medium, or Low hardening rows | Treat it as a triage prompt, not an external grade |
The charts need the same caution as the tables. Record Constellation is simply a count of observed record types. Policy Signal Radar is more interpretive because it compresses multiple yes-or-no checks into one 0 to 100 view. It is best used to compare repeat runs of the same target with the same options.
TTL and latency also need context. A wide TTL range can be normal, and higher average latency can reflect resolver reachability or network conditions rather than a bad zone.
A team is moving inbound mail to a new platform and wants one pass that covers routing and policy hygiene together. Running the Mail hardening preset keeps MX-adjacent TXT checks and common mail host probes in scope. The useful sequence is Probe Snapshot first, Hardening Queue second, then Record Ledger for exact MX, SPF, DMARC, and DKIM evidence. If the queue flags missing DMARC, an SPF count near the lookup ceiling, or absent MTA-STS, that is a deployment issue worth fixing before the DNS change is treated as complete.
An administrator has only an address and wants to know whether public reverse DNS exists. Entering the IP tells the page to build the PTR name and query only that path. A successful result answers the reverse-DNS question quickly, while an empty result tells you nothing yet about the forward zone. To inspect MX, TXT, or DNSSEC state, you still need the hostname and a second run.
After publishing DNSKEY material, parent DS records, and CAA policy, a deeper pass helps verify that those signals are externally visible. Deep audit widens the run, and the most informative places to look are the ledger rows for CAA, DNSKEY, DS, and RRSIG, plus the resolver evidence rows that show whether AD was observed. A stronger radar result is useful as a comparison point, but the real proof is still in the underlying rows and hardening notes.
The current validator accepts only ASCII host labels. Enter the ASCII form rather than the raw Unicode spelling.
The package intentionally processes only the first nonblank line and warns about the discarded lines.
No. AD is still a signal reported by the recursive resolver. It is helpful when read alongside DNSKEY, DS, and RRSIG visibility, but it is not the same thing as your own client performing independent validation.
The selected query plan may not include the record family you expected, the resolver may have returned an error, or the target may have been an IP address that triggered PTR-only behavior. Resolver Evidence is the fastest place to separate those cases.
No private server helper is involved. The browser sends the lookups to public DNS-over-HTTPS resolvers, and the current target and settings are mirrored into the URL.
._domainkey when looking up a DKIM public key record._dmarc.