{{ summaryStateLabel }}
{{ summaryHeadline }}
Last run: {{ lastRunLocal }}
{{ badge.label }}
{{ recommendationLead }}
{{ dnsStageQueryLabel }} {{ dnsStageResolverShort }} {{ dnsStageTypeLabel }} {{ dnsStageProbeLabel }}
Use a domain, host, URL, email domain, IPv4, or IPv6; only the first nonblank line runs.
Balanced covers core records; Fast limits scope; Mail and Deep add targeted evidence.
{{ progress.stage }}: {{ progress.note }}
{{ progress.done }}/{{ progress.total }}
Auto falls back from Cloudflare to Google; pinned modes keep all queries on one provider.
Enter milliseconds per query before a retry or fallback resolver is attempted.
ms
Use 0 for fastest triage; 1-2 helps noisy networks without flooding.
attempts
Turn on when you need DNSKEY, DS, RRSIG, NSEC, or NSEC3 visibility.
{{ do_flagBool ? 'On' : 'Off' }}
Use for broken-chain troubleshooting; leave off for normal validation posture.
{{ cd_flagBool ? 'On' : 'Off' }}
Queries SVCB, HTTPS, SRV, and NAPTR alongside the core record set.
{{ include_servicesBool ? 'On' : 'Off' }}
Queries DNSKEY, DS, RRSIG, NSEC, and NSEC3 for signed-zone evidence.
{{ include_dnssecBool ? 'On' : 'Off' }}
Checks SPF, DMARC, selected DKIM TXT, MTA-STS, and TLS-RPT records.
{{ include_emailBool ? 'On' : 'Off' }}
Enter selectors separated by commas or spaces, such as default google selector1.
Include NS, SOA, and related authority data returned with each DNS answer.
{{ include_authorityBool ? 'On' : 'Off' }}
Include glue-like or companion records returned in the Additional section.
{{ include_additionalBool ? 'On' : 'Off' }}
Turn on to check labels such as www, mail, api, autodiscover, and ftp.
{{ probe_hostsBool ? 'On' : 'Off' }}
Use labels or fully qualified names separated by commas or spaces.
Enter 0 to skip expansion, or a positive count to limit A/AAAA probe pairs.
hosts
# Metric Value Notes Copy
{{ idx + 1 }} {{ row.metric }} {{ row.value || '-' }} {{ row.note || '-' }}
# Priority Recommendation Why now Copy
{{ idx + 1 }} {{ row.priority }} {{ row.recommendation }} {{ row.rationale }}
# Section Type Name Data TTL Copy
{{ idx + 1 }} {{ row.section }} {{ row.type }} {{ row.name }} {{ row.data }} {{ row.ttl }}
# Query Status Resolver Answers AD Latency (ms) Copy
{{ idx + 1 }} {{ row.query }} {{ row.status }} {{ row.resolver }} {{ row.answers }} {{ row.ad ? 'Yes' : 'No' }} {{ row.ms === null ? '-' : row.ms }}

          
Customize
Advanced
:

Introduction

DNS failures often look like something else. A web server appears down, mail is rejected, a certificate order stalls, or a new service works from one network but not another. Before changing application code or firewall rules, the useful first question is narrower: which public DNS records can a normal recursive resolver see for this name or IP address?

Enumeration collects those public answers by asking for several record families in one run. Address records point names to IPv4 and IPv6 addresses. Delegation records expose authoritative name servers and zone administration. Mail records describe routing and sender policy. DNSSEC records show whether signing material is visible. Service records and host-label probes can reveal public endpoints without claiming to discover every subdomain.

A recursive resolver is an evidence source, not the zone itself. It may answer from cache, apply DNSSEC validation, hide an authority-section detail, time out on one record type, or show a value that another resolver has not seen yet. That is why target spelling, resolver choice, DNSSEC flags, record families, timeout, retries, and host probes should stay consistent when comparing two runs.

DNS enumeration query flow
Target name or IP Recursive resolver cache and policy view Record families A / AAAA / PTR MX / TXT / CAA DNSSEC / services authority evidence Same target plus same resolver settings makes repeat evidence comparable.

Public DNS records answer DNS questions only. An A record can exist while the web server is offline. An MX record can route mail while SPF, DKIM, or DMARC is weak. A visible CAA record can limit certificate authorities without proving that a certificate is installed. A PTR answer can name a host without proving that the hostname maps back to the same address.

DNS record families and common interpretation limits
Record family Useful evidence Common mistake
Address and reverse DNS A, AAAA, and PTR answers. Reading resolution as proof of HTTP, TLS, SSH, or application health.
Mail and sender policy MX, SPF TXT, DMARC TXT, DKIM selector TXT, MTA-STS, and TLS-RPT records. Assuming successful delivery means sender authentication is enforced.
Delegation and security policy NS, SOA, CAA, DNSKEY, DS, and RRSIG. Treating optional policy records as universal requirements for every domain role.

Enumeration is strongest as a triage and audit aid for zone migrations, mail-provider cutovers, certificate policy reviews, DNSSEC checks, reverse-DNS checks, and public-host inventory. It narrows where to investigate next, but the final confirmation often comes from a second DNS resolver or a protocol-specific test such as HTTP, TLS, SMTP, or a mail-authentication report.

How to Use This Tool:

Begin with the smallest record set that answers the current change or incident, then widen the run when the first evidence points to a DNS, mail, DNSSEC, or host-discovery gap.

  1. Enter one DNS target. A domain, hostname, URL, email address, IPv4 address, or IPv6 address is accepted. If several lines are pasted, only the first nonblank target runs and Run Notes reports the ignored lines.
  2. Choose Preset. Balanced includes core records, service records, DNSSEC, mail-auth checks, authority data, and up to 6 host probes. Fast triage limits optional checks and uses no retries. Mail hardening focuses on mail policy and mail host labels. Deep audit includes authority, additional, service, DNSSEC, mail, and up to 12 host probes.
  3. Set Resolver. Auto tries Cloudflare and can fall back to Google. Pin Cloudflare or Google when you need one provider view for repeat comparisons.
  4. Open Advanced for repeatable troubleshooting. Timeout is clamped from 400 to 20,000 ms, and Retries is clamped from 0 to 4. The DNSSEC DO bit asks for DNSSEC material, while the CD bit is for broken-chain troubleshooting.
  5. Toggle record families to match the question. Service binding adds SVCB, HTTPS, SRV, and NAPTR. DNSSEC adds DNSKEY, DS, RRSIG, NSEC, and NSEC3. Mail-auth checks add SPF, DMARC, selected DKIM, MTA-STS, and TLS-RPT names.
  6. Use Probe common host labels when public hostnames matter. Host probe list accepts labels or full names, and Max host probes limits the expanded A and AAAA questions.
  7. Run Enumerate. If the target is rejected, check for spaces, unsupported characters, labels longer than 63 characters, a hostname without a dot, or an internationalized domain that needs its ASCII A-label form.

Interpreting Results:

Probe Snapshot is the first read. Check the normalized target, resolver mode, successful probes, record count, latency profile, TTL range, SPF coverage, DMARC policy, and top queued action. Counts are useful for comparing runs with the same settings, but they are not a health score.

Record Ledger is the row-by-row evidence. Confirm owner names, record types, values, TTLs, and resolver labels there before editing a zone. Resolver Evidence explains how each DNS question behaved, including DNS status, answer count, authenticated-data flag, resolver, and latency.

Hardening Queue turns current evidence into follow-up items. High items commonly include missing apex NS or SOA, missing SPF, missing DMARC, or SPF policies above the 10 DNS-mechanism lookup ceiling. Medium and low items need context, especially for CAA, MTA-STS, TLS-RPT, DNSSEC signing material, and failed query classes.

Record Constellation and Policy Signal Radar are comparison aids. They can show whether repeated runs are moving in the expected direction, but a full-looking chart does not prove website reachability, mailbox delivery, TLS validity, DNSSEC correctness, or certificate issuance policy by itself.

Technical Details:

DNS enumeration is a typed lookup plan. For domain-like targets, the core plan asks the apex for A, AAAA, NS, SOA, MX, TXT, and CAA. Optional families add service binding, DNSSEC, mail-authentication names, authority records, additional records, and A/AAAA probes for selected host labels. IP targets switch to a single reverse-DNS PTR path.

Input normalization keeps the run bounded. A URL is reduced to its host, an email address is reduced to its domain, a trailing dot is removed, hostnames are lowercased, and internationalized names need their ASCII A-label form. Pasted extra lines are ignored after the first nonblank target so one run cannot mix unrelated domains.

Rule Core:

DNS enumeration query families and evidence meaning
Query family Names and record types What the evidence can support
Core zone view Apex A, AAAA, NS, SOA, MX, TXT, and CAA. Address visibility, delegation clues, zone administration, mail routing, text policy, and certificate-authority policy.
Mail-authentication view Apex SPF TXT, _dmarc, selected ._domainkey labels, _mta-sts, and _smtp._tls. Sender authorization, DMARC disposition, DKIM selector visibility, MTA-STS policy discovery, and SMTP TLS reporting.
DNSSEC visibility DNSKEY, DS, RRSIG, NSEC, NSEC3, and resolver AD evidence when available. Whether signing material and authenticated-data signals are visible through the selected recursive resolver path.
Service and host discovery SVCB, HTTPS, SRV, NAPTR, plus A/AAAA probes for configured labels. Public service hints and likely hostnames, without claiming complete subdomain enumeration.
Reverse DNS PTR for the derived in-addr.arpa or ip6.arpa name. Whether an IP address maps back to a hostname. Forward records for that hostname need a separate run.

Resolver responses are normalized for review. TXT strings are dequoted, MX rows keep preference and exchange, SOA rows keep the primary server and serial, CAA rows keep the tag and value, and service-binding rows preserve priority, target, and parameters. Authority and additional sections appear only when their controls are enabled.

Mail hardening checks parse specific TXT records. SPF lookup pressure counts DNS-mechanism terms such as a, mx, ptr, include:, exists:, and redirect=. DMARC reads the p= policy, MTA-STS expects a v=STSv1 policy ID record, and TLS-RPT expects a v=TLSRPTv1 report destination record.

Formula Core:

The radar scores are local summaries derived from the current evidence. Core DNS, mail authentication, DNSSEC, and similar boolean groups use the same pass-rate rule:

S = round ( Npassed Nchecks × 100 )

Reliability is successful NOERROR probes divided by total probes. Action Debt starts at 100 and subtracts more for high-priority recommendations than for medium or low recommendations:

Saction = clamp ( 100 - 25H - 12M - 6L , 0 , 100 )

Here H, M, and L are the number of high, medium, and low queued items. A score near 100 means the current query set produced fewer flagged actions. It does not certify DNS compliance or prove that all external service requirements are met.

Hardening queue triggers and priorities
Trigger Priority Technical reason
Missing apex NS or SOA. High Delegation and zone-administration visibility are baseline DNS evidence.
Missing SPF or missing DMARC when mail checks are included. High Receivers lose important sender-authorization and disposition guidance.
SPF DNS-mechanism count is greater than 10, or reaches 9 to 10. High or Medium SPF evaluation has a 10-lookup ceiling, so near-limit policies are fragile.
DMARC policy is missing or remains p=none. High or Medium Missing DMARC provides no policy record; p=none is monitoring rather than enforcement.
Missing CAA, MTA-STS, TLS-RPT, DS, DNSKEY, RRSIG, AD evidence, or successful query classes. Medium or Low The importance depends on whether the domain issues certificates, receives mail, or is expected to be DNSSEC-signed.

Privacy and Accuracy Notes:

The browser sends the active target and selected DNS questions to the chosen public DNS-over-HTTPS resolver. The page can also carry the target and options in the address bar for repeatable runs, so avoid entering internal names or private hostnames that you are not allowed to disclose.

  • Use the lookup for domains, hosts, and IP addresses you own or are authorized to review.
  • Resolver answers can differ because of cache state, propagation timing, DNSSEC validation behavior, provider policy, timeout limits, and blocked networks.
  • DNS evidence does not prove website availability, SMTP acceptance, mailbox deliverability, TLS certificate validity, or application health.

Worked Examples:

Zone migration check

A team moves example.com to new DNS hosting and runs Balanced with the resolver pinned for comparison. Probe Snapshot should show the normalized target, successful probes, a sensible TTL range, and the top queued action. If Hardening Queue flags missing NS or SOA, confirm the exact rows in Record Ledger before editing the zone.

Mail-provider cutover

A mail administrator uses Mail hardening with selectors such as default, google, and selector1. Useful evidence includes apex SPF, _dmarc, DKIM selector TXT rows, _mta-sts, and _smtp._tls. If DMARC policy reports p=none, the domain is monitoring alignment failures but not asking receivers to quarantine or reject them.

Signed-zone review

After enabling DNSSEC, a Deep audit run with the DNSSEC DO bit enabled should expose DNSKEY, DS, and RRSIG evidence when the chain is visible. If Resolver Evidence shows AD as No, repeat the run with another pinned resolver and check parent-side DS publication before assuming local signing failed.

Reverse lookup from an IP address

Entering 8.8.8.8 builds a PTR-only lookup. Probe Snapshot labels the target as an IP target, and Record Ledger shows any returned PTR rows. The run does not enumerate forward records or mail policy for the returned hostname; enter that hostname as a separate target when those records matter.

FAQ:

Why was my target rejected?

The target must normalize to an ASCII domain, hostname, URL host, email domain, IPv4 address, or IPv6 address. Check unsupported characters, spaces, missing dots, overlong labels, or an internationalized domain that needs its ASCII A-label form.

Why were extra pasted lines ignored?

Each run uses one target. The first nonblank line is kept so the query plan remains unambiguous, and Run Notes reports how many additional lines were skipped.

Does an AD flag prove DNSSEC is correct?

No. AD is a resolver-reported authenticated-data signal. Check DNSKEY, DS, and RRSIG rows, then compare another resolver when DNSSEC correctness matters.

Why did a record type return no rows?

The record type may not exist, the resolver may have returned a non-success DNS status, or an IP target may have switched to PTR-only mode. Open Resolver Evidence to separate empty answers, DNS statuses, timeouts, and provider failures.

Can this confirm that a website or mailbox works?

No. It confirms public DNS evidence from selected recursive resolvers. HTTP, TLS, SMTP delivery, mailbox acceptance, and application behavior need separate checks.

Glossary:

Recursive resolver
The DNS resolver that answers a user's DNS question, often from cache or by querying other name servers.
TTL
Time to live, the cache duration attached to a DNS record in seconds.
PTR
A reverse-DNS record that maps an IP address back to a hostname.
DO bit
A DNSSEC query flag used to request DNSSEC-related data from a resolver path.
CD bit
A DNSSEC query flag that asks a validating resolver to return data without enforcing its own validation result for that response.
AD flag
A resolver-reported indicator that returned data was considered authenticated by that resolver.
DKIM selector
The label before ._domainkey used to locate a domain's DKIM public key record.
CAA
A DNS record that publishes which certificate authorities may issue certificates for a domain.