| Lookup | Status | Answer preview | TTL | Time |
|---|---|---|---|---|
|
{{ row.label }}
{{ row.name }}
|
{{ row.status }} | {{ row.preview }} | {{ row.ttl }} | {{ row.timeLabel }} |
| Check | Status | Notes |
|---|---|---|
| {{ row.label }} | {{ row.status }} | {{ row.note }} |
| Lookup | Target | Time | % of total |
|---|---|---|---|
| {{ row.label }} | {{ row.name }} | {{ row.timeLabel }} | {{ row.shareLabel }} |
Domain Name System records tell the rest of the internet which servers answer for a domain, where traffic should go, and how mail or security policy should be interpreted. A zone can look healthy in a dashboard and still fail in practice because delegation is incomplete, a critical host does not resolve, or a mail policy record is missing. This report turns those checks into a readable snapshot for the domain you manage.
It is especially useful after a registrar change, DNS provider migration, CDN cutover, mail rollout, or DNSSEC change. In those moments you often need a quick answer to a simple question: does the live record set still hang together as a system, or did one small omission break the chain?
The package gathers common DNS record types, times each lookup, and then applies a conservative set of health rules around nameserver redundancy, SOA values, address reachability, mail policy, certificate authorization, and DNSSEC signals. That makes it good for first-pass review when you want something more concrete than guessing from a single dig command.
A report like this is most helpful when you already know the intended shape of the zone. If you expect a website at the apex, you care about A or AAAA answers and the absence of an apex CNAME. If the domain receives mail, you care about MX host resolution, SPF, and a DMARC policy that does more than observe.
A passing result does not mean global propagation is complete or that every recursive resolver sees the same data. This slug queries one browser-accessible resolver path and measures timing from your current network, so treat the report as a focused operational check, not as the only evidence you use for a high-risk cutover.
Run the report against the zone apex when you have changed delegation, web hosting, or mail policy and want a compact before-and-after snapshot. The fastest useful first pass is simple: make sure the domain has NS records, at least one A or AAAA answer for the apex, and no apex CNAME.
This tool is a strong fit for quick zone hygiene and migration review. It is not a full propagation monitor or registrar debugger, so before you act on a failure, compare the exact check label with the underlying record row and decide whether the failed item is a true outage, a hardening gap, or simply a policy this domain does not use.
The browser queries Cloudflare's DNS-over-HTTPS JSON endpoint for NS, SOA, A, AAAA, CNAME, MX, TXT, CAA, and DNSKEY, then performs one additional TXT lookup at _dmarc.<domain>. Each row stores the joined answer text, the first returned TTL value, the per-query duration in milliseconds, the resolver status code, and whether the resolver asserted the AD validation flag.
The health view is rule-based rather than score-based. Some rules reflect protocol meaning, such as DMARC living under the _dmarc label, SPF being carried in TXT data that starts with v=spf1, and apex CNAME records conflicting with other apex data. Others are operational heuristics chosen by the package, including the TTL and SOA timer bands used for pass and fail states.
That distinction matters when you read the output. A fail on A or AAAA present usually points to a direct reachability problem. A fail on CAA records present or DNSSEC keys present may simply mean the zone is not using that hardening layer. Timing is even more contextual: Total query time is the sum of individual browser-to-resolver lookups, so cache state and network path affect it immediately.
The checker groups its logic around delegation, authority data, address reachability, mail policy, and security signals.
| Rule family | Package condition | What a failure usually means |
|---|---|---|
| Delegation presence | NS records present, At least two name servers, Unique NS hostnames | The zone is under-delegated or depends on weak redundancy. |
| Delegation reachability | NS hosts resolve to A/AAAA | Nameserver hostnames are published but their own addresses are missing or broken. |
| SOA sanity | Serial matches 8 to 10 digits, refresh 900 to 86400, retry 180 to 7200, expire 604800 to 2419200, minimum 0 to 86400 | The package sees unusual authority timer values, not necessarily a protocol violation. |
| Apex structure | No CNAME at apex and A or AAAA present | The zone apex cannot serve ordinary web traffic cleanly with the current data. |
| Address cache behavior | A TTL reasonable and AAAA TTL reasonable require 60 to 86400 seconds when those records exist | The package considers the cache lifetime unusually short or long for ordinary operations. |
| Mail delivery and policy | When MX exists, MX hosts must resolve, apex TXT must include SPF, DMARC must exist, and DMARC policy must not be none |
Mail routing or mail policy is incomplete, or DMARC is reporting only. |
| Certificate control | CAA records present | The zone has no explicit CA authorization policy in DNS. |
| DNSSEC signal | DNSSEC keys present and DNSSEC validated by resolver | Key publication or validated resolution is missing from this resolver view. |
Total query time is simply the sum of all measured lookup durations for the queried record set. It is useful for comparing one run to another through the same resolver path, but it is not authoritative server latency and it is not a guaranteed proxy for user-facing web performance.
| Field | Accepted format | Package boundary | Operational note |
|---|---|---|---|
| Domain | ASCII hostname with a TLD | 1 to 253 characters, no trailing dot, no raw Unicode labels | Enter Punycode for internationalized names and use the apex when you want SOA, MX, and delegation checks to be meaningful. |
| Records table | Resolver answers with first TTL and query ms | Empty answers display as dashes | The answer text is shown as returned by the resolver, joined into a single row per record type. |
| Health table | Boolean pass or fail by rule label | MX-dependent checks are skipped when no MX exists | Some failures mark hardening gaps rather than outages. |
The entered domain is transmitted from your browser to Cloudflare's resolver endpoint. No separate application server or slug-specific backend is present, so the network behavior is limited to those resolver requests and the derived tables built in the page itself.
Use the report as a structured first pass after a DNS change, not as a replacement for authoritative troubleshooting.
Please enter a valid domain name such as example.com, remove any trailing dot and use ASCII or Punycode labels.NS, SOA, A, AAAA, MX, TXT, CAA, and DNSKEY look plausible for the zone you intended to publish.A useful final pass shows that the raw rows match your intended zone design and that the remaining failures, if any, are deliberate exceptions rather than surprises.
The most important distinction is between outage signals and policy signals. Missing apex addresses, unresolved NS hosts, or broken MX targets usually point to something immediately operational. Missing CAA or DNSSEC-related signals often point to absent hardening rather than a live service outage.
A clean Health table does not prove worldwide propagation or universal resolver agreement. Verify important changes from another recursive resolver or an authoritative source before declaring a migration complete.
Suppose example.com returns two NS hosts, an A record with TTL 300, no apex CNAME, and no MX. Health passes NS records present, A or AAAA present, and A TTL reasonable. If CAA records present fails, the site can still work; the failure simply means the zone has not published an explicit CA authorization record.
A domain publishes resolving MX hosts, an apex SPF TXT record, and a DMARC record with p=none. The mail-routing checks pass, but DMARC policy not "none" (if DMARC present) fails. That result means receivers are being asked to report, not to quarantine or reject, so the domain has visibility without enforcement.
After a DNS provider move, the NS row shows the expected nameserver hostnames, yet NS hosts resolve to A/AAAA fails and the zone still misbehaves. That pattern usually points to missing glue or broken address records for the nameserver hosts themselves. Fix the host resolution issue first, then rerun and confirm that the delegation checks turn green.
No. The page sends DNS-over-HTTPS requests from your browser to Cloudflare's resolver endpoint, so the answers, AD flag, and timing all reflect that resolver path and its cache state.
CAA is a DNS control that lets a domain publish which certificate authorities may issue for it. A missing CAA record does not break an already working site, but the package marks it as a hardening gap because no explicit issuance policy is present.
The package only enforces SPF, DMARC, and MX host resolution when MX records exist. A domain that does not receive mail should not fail those mail-specific checks just because the record family is absent.
Because those checks are package heuristics, not protocol validity tests. DNS itself allows broader ranges than the report prefers, so a fail here means unusual operational tuning, not necessarily invalid syntax.
Publishing DNSKEY records and receiving a validated answer are different states. The resolver must be able to validate the chain and return the AD flag for the package to pass that final check.