Collect independently
Each record family is queried separately so a missing MX record does not erase address or nameserver evidence.
Direct answer: A DNS report checks the domain's address, mail, nameserver, text, certificate-authority and authority records together, then identifies missing or failed observations that need verification.
The server asks its recursive resolver for seven named DNS record families and records failures separately. Result responses are private, uncached and excluded from search indexing. Do not enter passwords or secrets. Read the lookup privacy policy.
What this dns report tells you
The DNS report asks this server's recursive resolver for seven record families: A, AAAA, MX, NS, TXT, CAA and SOA. It groups the answers, errors and TTLs in one snapshot, then flags missing apex addresses, mail exchangers, nameservers or authority data without pretending those omissions are always faults.
- Which of seven common record families this resolver can currently observe
- The returned values and remaining TTL for each available answer
- Whether address, mail, nameserver or SOA evidence is absent from this resolver's view
A recursive snapshot cannot prove parent and child delegation agree; follow the DNS delegation verification method before changing nameservers.
If the zone is signed, verify the parent DS and child DNSKEY relationship with the DS and DNSKEY check.
How the evidence is collected
Preserve resolver outcomes
Returned answers are kept apart from NXDOMAIN, NoAnswer, timeout and nameserver failures.
Verify before changing
A warning identifies the next question; confirm it with authoritative queries and another network before editing a zone.
Read the fields without overclaiming
| Signal | What it can establish | What it does not prove |
|---|---|---|
| A / AAAA | Apex IPv4 and IPv6 answers visible through this recursive resolver. | Proof that a website is healthy or that an address is an origin server. |
| NS / SOA | Nameserver and zone-authority records returned for the queried domain. | A parent-versus-child delegation comparison or a test of every authority. |
| MX | Mail exchangers published for the domain. | A complete mail delivery, SPF, DKIM or DMARC test. |
| TXT / CAA | Text policy records and permitted certificate issuers. | A universal security grade or DNSSEC validation result. |
The report shows NS and SOA but no A, AAAA or MX
The zone exists in this resolver's view, while the apex has no address and publishes no mail exchanger. That can be intentional when only subdomains serve traffic and the domain never receives mail. Check the intended hostnames and query the listed authorities directly before treating it as an outage.
Common mistakes
- Turning optional records into universal failures
- Calling every empty record family NXDOMAIN
- Treating one recursive cache as an authoritative audit
- Assuming this report validates DNSSEC or tests nameserver reachability
DNS Report FAQ
Is every warning an outage?
No. A warning marks missing evidence worth interpreting. Apex address records and MX records can be intentionally absent.
Does this compare parent and child delegation?
No. The report shows the NS answer visible through one recursive resolver. Use it as a starting point, then query the parent and every listed authoritative server directly.
Does the report validate DNSSEC?
No. It does not request or validate the DNSSEC chain. A dedicated validating resolver and parent-to-child checks are required for that conclusion.