DNS Configuration Report
Audit a domain's public DNS for authority, address and mail-policy gaps while comparing TTL horizons and resolver-visible evidence across common records.{{ summaryTitle }}
{{ summaryLine }}
| Record | Owner | State | Answers | TTL | Preview | Copy |
|---|---|---|---|---|---|---|
| {{ row.type }} | {{ row.name }} | {{ row.status }} | {{ row.answerCount }} | {{ row.ttlLabel }} | {{ row.preview }} |
| Check | Status | Evidence and next step | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.status }} | {{ row.note }} |
The chart renderer is unavailable. The same TTL values remain available in Record inventory.
| Record | Owner | DNS status | Elapsed | Resolver evidence | Copy |
|---|---|---|---|---|---|
| {{ row.type }} | {{ row.name }} | {{ row.dnsStatus }} | {{ row.elapsedLabel }} | {{ row.evidence }} |
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.
| Record | Operational question |
|---|---|
| SOA and NS | Does the resolver see a basic authority and delegation baseline? |
| A and AAAA | Does the apex publish an IPv4 or IPv6 destination? |
| MX | Where should mail be delivered, or is a no-mail design intended? |
| Apex TXT and DMARC TXT | Are SPF and DMARC policy markers visible at their expected owners? |
| CAA | Does 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.
- 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.
- Select Complete configuration, Web & authority, or Mail & policy according to the records you need to review.
- Choose Cloudflare DNS or Google Public DNS, then generate the report. Changing an input invalidates the previous snapshot.
- 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
| Scope | Queried targets |
|---|---|
| Complete configuration | SOA, NS, MX, A, AAAA, apex TXT, _dmarc TXT, and CAA |
| Web & authority | SOA, NS, A, and AAAA |
| Mail & policy | MX, 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
| Finding | Healthy | Review or attention |
|---|---|---|
| Authority baseline | Both NS and SOA have at least one answer. | A missing NS or SOA answer is Attention. |
| Apex address coverage | At least one A or AAAA answer. | No apex address is Review because another hostname may serve web traffic. |
| Mail routing | At least one MX answer. | No MX answer is Review; confirm an intentional no-mail design or the expected route. |
| SPF publication | Exactly one v=spf1 marker in the apex TXT preview. | None is Review; more than one is Attention. |
| DMARC publication | Exactly one v=DMARC1 marker at _dmarc. | None is Review; more than one is Attention. |
| CAA publication | At least one CAA answer. | No answer is Review and means issuance is not constrained by CAA at this owner in this resolver view. |
| TTL consistency | All 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.
References:
- RFC 1035: Domain Names — Implementation and Specification, RFC Editor, November 1987.
- RFC 7208: Sender Policy Framework, RFC Editor, April 2014.
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance, RFC Editor, May 2026.
- RFC 8659: DNS Certification Authority Authorization Resource Record, RFC Editor, November 2019.