Domain Health
Domain Health helps you comprehensive domain configuration and health check, for authoritative DNS validation, resolver checks, and faster troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
Domain Health runs four foundational DNS checks against the domain you enter and rolls them into one verdict: it resolves the apex A records, lists the delegated NS servers, fetches the SOA record and looks up the MX set. Each sub-check is sorted into Passed, Warnings or Issues, and the overall status is the worst of the three. It is a quick triage of whether the zone is delegated, answering and able to route web and mail traffic.
Why It Matters
- →Registrar transfers: After moving a domain between registrars, a missing NS or SOA answer is the first sign the delegation was not carried over.
- →Single points of failure: A zone served by one nameserver or one MX host goes dark completely when that machine or provider has an outage.
- →Expired or parked domains: When A, NS and SOA all fail together, the domain has usually lapsed or been pulled from the registry, not merely misconfigured.
- →Pre-launch sanity check: Before pointing customers, payment gateways or email campaigns at a new domain, one pass confirms the basic records exist.
- →Escalation triage: A green result here lets you skip DNS and move on to TLS, HTTP or SMTP diagnostics when a site or mailbox is failing.
How to Read Results
- Overall status: FAIL if any item landed in Issues, WARN if only Warnings exist, PASS when every sub-check succeeded; the headline counts how many items fell into each bucket.
- Passed list: Plain confirmations such as 'A records configured', 'Nameservers configured', 'SOA record valid' and 'Email (MX) configured'.
- Issues (critical): Missing A records at the apex, no NS answer, or no SOA record. Any of these can make the domain unreachable for some or all users.
- Nameserver redundancy issue: Shown as a warning when fewer than two NS records are published for the zone.
- MX warnings: 'No email (MX) records' is a warning, not a failure, because web-only domains are legitimate; 'MX configuration issues' means only one MX host exists or several hosts share the same priority value.
- Scope: This tool does not test SPF, DMARC, DNSSEC or certificates; a domain can pass here and still fail email authentication or TLS checks run with the dedicated tools.
Technical Background
Every lookup on the internet depends on an unbroken chain of delegation described in RFC 1034 and RFC 1035. The parent zone (for example the .com registry) publishes NS records that point to your authoritative servers, and those servers must answer for the zone with an SOA record that marks the start of authority. If the parent delegation exists but your servers do not answer authoritatively, resolvers return SERVFAIL; if the delegation itself is gone, they return NXDOMAIN. Domain Health asks for NS and SOA first-hand so both situations show up as critical issues rather than vague timeouts.
The SOA record carries more than a formality. Its fields are the primary master name (MNAME), the responsible mailbox (RNAME, with the first dot standing in for @), a serial number, and the refresh, retry, expire and minimum timers. RFC 2308 redefined the last field as the negative-caching TTL, so a value of 86400 means a typo that once returned NXDOMAIN may be remembered by resolvers for a full day. A typical modern SOA looks like: ns1.example.net. hostmaster.example.com. 2026101001 7200 3600 1209600 3600.
Redundancy is a standing requirement, not a recommendation. RFC 1034 calls for at least two nameservers, and RFC 2182 adds that they should sit on separate networks and ideally in different geographic locations. Two NS names that resolve to the same IP address or the same anycast provider satisfy the count but not the intent. The tool flags a zone with fewer than two NS records; whether those servers are truly independent is something to verify by checking their addresses and autonomous systems.
On the mail side, RFC 5321 section 5.1 says a sender looks up MX records, sorts them by preference and tries them in order; when no MX exists it falls back to the A or AAAA record of the domain itself (the implicit MX). That fallback is why a web-only domain with no MX can still receive spam attempts on its web server. Domains that never send or receive mail can publish a Null MX, defined in RFC 7505 as MX 0 '.', to tell senders to bounce immediately. Our checker reports a missing MX as a warning and treats a single MX host or duplicate priority values as configuration notes worth reviewing.
Use this check as the first layer of a diagnosis. Once A, NS, SOA and MX are healthy, continue with SPF, DKIM and DMARC for mail authentication, DNSSEC for integrity, and the SSL tools for certificate validity, since none of those are evaluated here.
Common Errors and How to Fix Them
- ProblemOnly one nameserver is listed at the registrar, so the zone disappears whenever that server is rebooted.
- FixAdd a second NS from a different network or provider at the registrar and make sure it serves the same zone (via zone transfer or the provider's secondary DNS feature).
- ProblemSOA serial numbers differ between nameservers, so some users see old records hours after a change.
- FixCompare the serial on each NS with dig @ns SOA. Increment the serial on the primary and confirm NOTIFY/AXFR or the provider sync is working for every secondary.
- ProblemThe apex has no A record because the site lives on www, so typing the bare domain fails.
- FixAdd an A record (or the provider's ALIAS/ANAME flattening) at the apex pointing to a host that redirects to www.
- ProblemNS records at the registrar still point to the old DNS host after a migration (lame delegation).
- FixUpdate the nameserver set at the registrar to the new provider, wait for the parent TTL (often 48 hours for .com NS), then remove the zone from the old host.
- ProblemA domain used only for a website receives spoofed mail and bounce floods because it has no MX.
- FixPublish a Null MX (MX 0 .) together with an SPF record of v=spf1 -all and a DMARC p=reject record to declare the domain non-mailing.
Frequently Asked Questions
Why does Domain Health pass while my website is still down?
This check only confirms that DNS answers exist: apex A records, nameservers, SOA and MX. It does not connect to your web server, test HTTPS or validate certificates. If DNS passes, the outage is likely in the web server, firewall, CDN or TLS configuration. Run the HTTP and SSL checks next to find where the request actually breaks.
How many nameservers should a domain have?
At least two, as required by RFC 1034, and RFC 2182 recommends placing them on different networks so a single provider or data-center outage cannot take the zone offline. Many operators use three or four. More important than the count is independence: two names that resolve to the same IP address add no real redundancy.
Is it a problem if my domain has no MX record?
Not if the domain never receives email. Without MX, senders fall back to the domain's A record, so it is cleaner to publish a Null MX (MX 0 .) as defined in RFC 7505, which tells servers to reject mail immediately. Pair it with SPF v=spf1 -all and DMARC p=reject to discourage spoofing of the unused domain.
How long do nameserver changes take to propagate?
Changes at the registrar update the parent zone within minutes to a few hours, but resolvers may keep the old NS set until its TTL expires. For .com and .net the delegation TTL is 172800 seconds, so allow up to 48 hours. Keep the old DNS host serving identical records during that window to avoid split answers.
What does the SOA serial number mean?
It is a version counter for the zone. Secondary nameservers compare it with their copy and pull a fresh transfer when the primary's number is higher. A common convention is YYYYMMDDnn, such as 2026101001. If you edit records but forget to increase it on a self-hosted primary, secondaries keep serving the old data.
Academic Documentation
Protocol context and primary references
REST API Documentation
v1.0GET /api/tools/domain-health
curl -X POST https://epcybertools.com/api/tools/domain-health \
-H "Content-Type: application/json" \
-d '{"domain":"google.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Delegation as seen from the parent zone
dig NS example.com +trace | tail -n 20
# SOA, A and MX in one go
dig example.com SOA +short; dig example.com A +short; dig example.com MX +short