{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}{{ badge.value }}
{{ summaryAnnouncement }}
DOMAIN{{ stageDomainMarker }}{{ family.label }}{{ family.marker }}
DNS configuration report setup
Enter one zone apex such as example.com. The public resolver receives this name and selected subdomain lookups.
Choose the evidence set that matches the change or incident you are reviewing.
Compare Cloudflare and Google views after a DNS change; neither is an authoritative-server query.
RecordOwnerStateAnswersTTLPreviewCopy
{{ row.type }}{{ row.name }}{{ row.status }}{{ row.answerCount }}{{ row.ttlLabel }}{{ row.preview }}
{{ tableExportAnnouncement }}
CheckStatusEvidence and next stepCopy
{{ row.label }}{{ row.status }}{{ row.note }}
{{ tableExportAnnouncement }}
{{ chartExportAnnouncement }}

The chart renderer is unavailable. The same TTL values remain available in Record inventory.

RecordOwnerDNS statusElapsedResolver evidenceCopy
{{ row.type }}{{ row.name }}{{ row.dnsStatus }}{{ row.elapsedLabel }}{{ row.evidence }}
{{ tableExportAnnouncement }}

A domain's DNS configuration is a collection of records with different jobs. Some establish who is authoritative, some direct web or mail traffic, and others publish policy. An incident can look like a single DNS failure even when only one record family is missing, duplicated, stale in cache, or inconsistent with the intended design.

A useful configuration review starts at the zone apex, the base owner such as example.com. It then checks the small set of records that answer common operational questions.

Common DNS record families and their roles
RecordOperational question
SOA and NSDoes the resolver see a basic authority and delegation baseline?
A and AAAADoes the apex publish an IPv4 or IPv6 destination?
MXWhere should mail be delivered, or is a no-mail design intended?
Apex TXT and DMARC TXTAre SPF and DMARC policy markers visible at their expected owners?
CAADoes the apex constrain which certificate authorities may issue certificates?

Time to live (TTL) values add a second dimension. A resolver may retain an older answer until its cache expires, so a long TTL can extend the period in which two observers see different configurations. TTLs describe caching horizons; they do not guarantee how quickly every resolver or client will refresh.

One recursive-resolver snapshot cannot prove the contents of every authoritative server, global propagation, website reachability, mail delivery, or certificate issuance. Missing apex addresses can be intentional when web traffic uses another hostname, and an absent CAA record can be a deliberate choice. Findings need to be compared with the planned architecture before records are added or removed.

How to Use This Tool:

Choose the narrowest report scope that covers the change or incident, then capture one current public resolver view.

  1. Enter one public zone apex. A URL or email-style value is reduced to its hostname, and only the first non-blank pasted line is checked.
  2. Select Complete configuration, Web & authority, or Mail & policy according to the records you need to review.
  3. Choose Cloudflare DNS or Google Public DNS, then generate the report. Changing an input invalidates the previous snapshot.
  4. Resolve Attention findings first, confirm Review findings against the intended zone design, and use the TTL profile to plan when a second observation will be meaningful.

Interpreting Results:

Healthy means the snapshot met the report's publication rule for that item. Review usually means an optional or design-dependent record is absent, or returned TTLs differ enough to affect coordinated change timing. Attention is reserved for missing authority-baseline evidence or duplicate SPF or DMARC markers.

Read the record inventory and finding note together. A NOERROR response with no answer is different from a returned record, and a recursive resolver can keep cached data that no longer matches the authority. After a recent edit, compare the other resolver and query authoritative servers before declaring propagation complete.

Technical Details:

Each selected target produces an owner name, record type, DNS response code, answer count, first returned TTL, elapsed query time, and compact answer preview. TXT character strings are joined before SPF or DMARC markers are counted. The status model classifies publication evidence; it does not fully parse SPF mechanisms or DMARC policy syntax.

Lookup Core

DNS report scopes and queried records
ScopeQueried targets
Complete configurationSOA, NS, MX, A, AAAA, apex TXT, _dmarc TXT, and CAA
Web & authoritySOA, NS, A, and AAAA
Mail & policyMX, apex TXT, _dmarc TXT, and CAA

Every lookup in one run uses the same selected DNS-over-HTTPS recursive resolver. The resolver receives the apex and, for DMARC, the _dmarc owner name. The report records one returned TTL per target when an answer supplies one; unavailable TTLs are excluded from the chart and TTL-range rule.

Rule Core

DNS configuration classification rules
FindingHealthyReview or attention
Authority baselineBoth NS and SOA have at least one answer.A missing NS or SOA answer is Attention.
Apex address coverageAt least one A or AAAA answer.No apex address is Review because another hostname may serve web traffic.
Mail routingAt least one MX answer.No MX answer is Review; confirm an intentional no-mail design or the expected route.
SPF publicationExactly one v=spf1 marker in the apex TXT preview.None is Review; more than one is Attention.
DMARC publicationExactly one v=DMARC1 marker at _dmarc.None is Review; more than one is Attention.
CAA publicationAt least one CAA answer.No answer is Review and means issuance is not constrained by CAA at this owner in this resolver view.
TTL consistencyAll known TTLs are zero, or the largest is at most four times the smallest positive TTL.A wider non-zero range is Review because coordinated edits may have different cache horizons.

The overall result is Attention when any finding needs attention. Otherwise it is Review when any finding needs review, and Healthy only when every applicable finding is healthy. Query latency is retained as evidence but does not affect classification.

Accuracy and Privacy Notes:

Recursive resolver caches, filtering, and policy can produce a view that differs from the authoritative servers or another resolver. Answer previews are deliberately compact, so use a record-specific lookup or authoritative query when full RDATA matters.

The selected public resolver can observe each queried public owner name. The browser keeps the resulting snapshot for the current interaction, but copied or downloaded evidence should still be handled according to the domain owner's operational policy.