What a DNS Report Checks
Our DNS Report walks through a domain’s DNS from the top-level domain down to its mail and web records. Results are marked as pass, warning or error. Errors can break resolution or email; warnings usually point to weaker redundancy or unusual settings.
Parent (Delegation) Checks
These checks ask the top-level domain servers (for example the .com servers) which nameservers your domain uses.
- Nameservers listed by the parent and by your own nameservers should match. A mismatch (“missing nameservers reported by parent” or “by your nameservers”) usually happens after a DNS provider change where only one side was updated.
- Glue records are addresses for nameservers that live inside the domain itself, such as
ns1.example.com. Without correct glue, resolvers cannot reach them.
Nameserver Checks
- Nameservers respond: every listed nameserver must answer. A lame nameserver is listed but does not answer authoritatively for the domain — often an old provider that deleted the zone. Remove it from the delegation.
- Multiple nameservers on different subnets and networks: recommended for resilience. If all nameservers share one network, a single outage takes the domain offline. Many managed DNS providers use anycast, which provides redundancy even when addresses look similar.
- Recursive queries: authoritative nameservers should not answer recursive queries for other domains. Open recursion can be abused for amplification attacks.
- TCP connections: DNS also uses TCP for large answers. Nameservers must accept it.
SOA Checks
The SOA (Start of Authority) record holds zone-wide settings:
- Serial: all nameservers should report the same serial. Different serials mean a secondary has not received the latest zone.
- Refresh, retry, expire: control how secondary nameservers synchronize. Values outside commonly recommended ranges trigger warnings but rarely cause visible problems with managed DNS.
- Minimum TTL: today it sets how long “name does not exist” answers are cached — see negative caching in why DNS changes are not showing.
Mail (MX) Checks
- MX records should exist if the domain receives email.
- Each MX hostname must resolve to an address, and MX must not point to an IP address directly.
Our guide How to look up MX records explains how to read them, and SPF, DKIM and DMARC explained covers the email authentication records.
Web (WWW) Checks
The report checks whether www resolves, either with an A record or a CNAME. A missing www record breaks links that include it, so most sites should have one.
Which Warnings to Fix First
- Errors in delegation and lame nameservers — they cause intermittent failures that are hard to diagnose.
- Missing or broken MX records — they lose email.
- Single-network nameservers — a resilience risk.
- SOA timing warnings — lowest priority.