{{ summaryHeading }} {{ summaryFigure }} {{ summaryLine }} {{ summaryStateLabel }} · {{ resolverLabel }}
Use a public name or address. Public resolvers receive each generated DNS query.
Fast checks A, AAAA, NS, MX and TXT. Deep adds CAA, SOA, DNSSEC, SVCB, HTTPS, SRV, NAPTR and mail-policy names.
Results are recursive-resolver observations and may differ from authoritative data while caches or policies change.
Ignored {{ ignoredExtraLines }} additional nonblank {{ ignoredExtraLines === 1 ? 'line' : 'lines' }}; this is a single-target workflow.
Opening Advanced with the default unchanged is neutral and never starts a request.
TypeNameRecord dataTTLResolverCopy
{{ row.type }}{{ row.name }}{{ row.data }}{{ row.ttl }} s{{ row.resolver }}
SignalStateEvidenceNext actionCopy
{{ row.signal }}{{ row.state }}{{ row.evidence }}{{ row.action }}
TLS-RPT Record Validator Validate a TLS-RPT policy from live DNS or pasted text, check report destinations and RFC rules, then build a reviewable TXT record.
DNS Propagation Checker Check DNS propagation across public resolvers, compare the intended record set, and identify cache holdouts with TTL and failure evidence.
DKIM DNS Record Generator Build a DKIM TXT record from a selector and public key with validation and DNS string splitting, plus rollout checks before publishing.
Reverse DNS Zone Generator Generate an IPv4 reverse DNS zone with PTR records and SOA validation plus RFC 2317 classless delegation and parent-zone CNAME guidance.

A domain name can resolve correctly while its mail route, nameserver set, certificate policy, or service records have drifted. A useful DNS inventory therefore asks several typed questions and keeps the answers, time-to-live values, response status, and resolver view together.

DNS records describe different parts of a public namespace. Address records point names to IP addresses, MX records route mail, NS and SOA records describe authority, TXT records carry policies and verification values, and newer HTTPS or SVCB records advertise service parameters. No single record family is a complete health check.

Record family Useful evidence What it cannot prove alone
A and AAAAPublished IPv4 and IPv6 addressesThat the web or application service responds
NS and SOADelegation and zone-administration cluesThat every authoritative server has identical current data
MX and TXTMail routing, SPF, DMARC, and verification textMailbox delivery or correct policy semantics
DS, DNSKEY, and RRSIGVisible DNSSEC materialA complete valid chain of trust
PTRReverse mapping from an IP addressMatching forward DNS or ownership

Recursive resolvers answer from their cache and policy view. During a DNS change, Cloudflare and Google can temporarily return different values or TTLs without either view matching the authoritative servers at that exact moment. The resolver and completion time are therefore part of the evidence.

Blank answers also need context. A successful response with no records differs from a nonexistent name, a timeout, or another DNS error. Some absences are intentional, such as no AAAA record for an IPv4-only service or a null MX declaration for a domain that accepts no mail.

Enumeration shows what public DNS returned for the selected questions. It does not discover every subdomain, validate every policy, test application availability, or authorize changes to a zone.

How to Use This Tool:

Choose one public target and a query plan that matches the question you are trying to answer.

  1. Enter a domain, hostname, URL, email-style address, IPv4 address, or IPv6 address. URLs are reduced to their hostname, email-style input to its domain, and IP addresses to a reverse-DNS PTR question.
  2. Select Fast for common address, authority, mail, and text records; Balanced to add CNAME, CAA, and SOA; Mail for mail-policy names; or Deep for service and DNSSEC families.
  3. Choose Cloudflare DNS, Google Public DNS, or automatic fallback, then run the enumeration explicitly. Automatic fallback tries the second public resolver only when the first request fails; it is not a simultaneous comparison. If target validation fails, remove paths, spaces, extra labels, or private single-label hostnames.
  4. Review Record ledger for exact answers and TTLs, then use Type coverage and Action flags to decide which records need a dedicated follow-up check.

Interpreting Results:

Read the ledger as a timestamped resolver observation. Confirm the owner name, type, record data, TTL, and resolver against the intended DNS change or service inventory before editing anything.

Observed means matching evidence was returned. Review means a queried signal was absent or needs a more specific check. Not checked means the selected preset did not ask the relevant question. These states are prompts for investigation, not security or compliance verdicts.

DNSSEC material or an authenticated-data flag is only a clue. Use a chain validator with a known-good and known-broken control before concluding that a resolver validates DNSSEC correctly.

Technical Details:

Enumeration begins by normalizing one target. Hostnames are lowercased, a trailing dot is removed, and only the first nonblank line is used. Domain-like targets follow a preset query plan; IP addresses are expanded into the corresponding in-addr.arpa or ip6.arpa owner and queried only for PTR.

Lookup Core

Preset Apex record types Additional owner names
Fast A, AAAA, NS, MX, TXT None
Balanced Fast types plus CNAME, CAA, SOA None
Mail A, AAAA, MX, TXT _dmarc, _mta-sts, _smtp._tls, and default._domainkey TXT
Deep Balanced types plus HTTPS, SVCB, SRV, NAPTR, DNSKEY, DS, RRSIG, NSEC, NSEC3 The same four mail-policy owner names

Each question is sent to the selected public DNS-over-HTTPS resolver with a 6.5-second timeout. Automatic fallback uses Cloudflare first and tries Google only after a request failure. Answers retain record type, owner, cleaned record text, non-negative TTL, resolver label, response code, authenticated-data flag, and measured request latency.

Formula Core

Coverage measures the share of issued questions that returned at least one answer. The result is rounded to one decimal place.

C= QansweredQtotal ×100

A question counts as answered when at least one answer row is present. Response codes 0 and 3 are not counted as request failures; other response codes and transport failures are. A completed run is partial when any question failed, complete when at least one question was answered and none failed, and empty otherwise.

Median latency is the middle non-negative request time after sorting. For an even number of questions, it is the rounded average of the two middle values. Because queries run one after another and may use fallback, this metric describes the observed lookup sequence rather than raw resolver capacity.

Flag Observed condition Required follow-up
NameserversAt least one NS answerCompare the complete set with the intended delegation.
SPFA returned TXT value contains v=spf1Validate mechanisms, includes, lookup count, and final qualifier separately.
DMARCThe dedicated TXT query contains v=DMARC1Review alignment, policy, percentage, and report destinations.
DNSSECDNSKEY, DS, RRSIG, or an authenticated-data flag is visibleValidate the chain of trust independently.
CAAAt least one CAA answerConfirm issue and issuewild values against the intended CA policy.

Privacy and Accuracy Notes:

The selected public resolver receives each generated owner name and record type. Avoid private, customer-only, or unauthorized names because the lookup discloses them outside the browser.

  • Cached answers can differ from authoritative data during propagation or policy changes.
  • A missing record can be correct for the domain's intended role.
  • One default DKIM selector check cannot discover every selector in use.
  • DNS answers do not prove website availability, mail delivery, certificate validity, or application health.

References: