DNS Diagnostics Διάγνωση DNS

Full DNS domain analysis: Parent, Nameservers, SOA, MX and WWW — 45+ compatibility and best-practice checks.

What is Διαγνωστικό DNS?

The Διαγνωστικό DNS is a fully automated DNS infrastructure check — similar to the well-known intoDNS. It runs 43+ correctness, RFC compliance and best-practice checks across 5 sections: Parent, Nameservers, SOA, MX and WWW.

How to read the results

OK — Check passed. No action required.
WARN — Missing best practice or suboptimal configuration. Does not break functionality but is worth fixing.
FAIL — Serious problem likely causing malfunction. Fix immediately.
INFO — Informational only, no assessment (e.g. list of records, AS numbers).

Parent — TLD parent server

Communicates directly with the TLD root nameservers (e.g. .com, .org) to verify the domain's delegation.

NS records from Parent server (INFO) — Displays the nameservers as known by the TLD parent. Purely informational.
TLD Parent Check (OK / FAIL) — Verifies a parent server was found for the TLD. FAIL only for unknown TLDs or unreachable parent.
Nameservers registered at parent (OK / FAIL) — The NS declared by the registrar appear at the parent. FAIL = domain not properly registered or NS records missing entirely.
DNS Parent sent Glue (OK / FAIL) — Glue records are the A records of nameservers returned alongside NS records. Required when NS hostnames belong to the same domain (e.g. ns1.example.com for example.com). Without glue, resolvers cannot find the nameservers.
Nameservers have A records (OK / FAIL) — Every NS hostname resolves to at least one IP. FAIL = NS unreachable.

Nameservers (NS)

Checks each nameserver individually for correctness, security and RFC compliance.

NS records from authoritative servers (INFO) — List of NS records as reported by the domain's own authoritative nameservers.
Recursive Queries (OK / FAIL) — Checks whether any NS accepts recursive queries from anyone (open resolver). FAIL = serious security issue; the server can be abused for DNS amplification DDoS attacks.
Same Glue (OK / WARN) — The IPs in the parent's glue records match the A records returned by the NS servers. WARN = glue mismatch; some clients may fail to resolve.
Glue for NS records (INFO) — Informational: whether the parent returned A records alongside the NS records.
NS records consistent across servers (OK / WARN) — All authoritative NS return the same NS record set. WARN = inconsistency, possible misconfiguration or incomplete zone transfer.
Nameservers responded (OK / FAIL) — Every NS responds to a SOA query. FAIL = NS down or firewall blocking port 53.
Nameserver names valid (OK / FAIL) — NS hostnames follow RFC-valid format (letters, digits, hyphens). FAIL = typo in the registration.
Multiple Nameservers (OK / FAIL) — At least 2 NS (RFC2182). FAIL = single NS = single point of failure.
Nameservers authoritative (not lame) (OK / FAIL) — Every NS responds with the aa (Authoritative Answer) flag set. FAIL = lame delegation: the NS does not know the zone, causing increased latency and instability.
Missing NS at parent (OK / WARN) — NS found in the auth servers but not declared at the parent. Typical case: hidden secondary nameservers.
Missing NS at auth servers (OK / WARN) — NS declared by the parent but not announced by the auth servers. Indicates a mismatch between registrar and zone configuration.
Domain CNAME check (OK / FAIL) — No CNAME record exists at the apex (root) domain. FAIL = violates RFC1034 — a CNAME at the apex cannot coexist with NS or MX records.
NS CNAME Check (OK / FAIL) — No nameserver is defined as a CNAME. Explicitly forbidden by the RFCs.
Nameservers on different subnets (OK / WARN) — NS IPs are on different /24 subnets. WARN = all on the same subnet, reduced redundancy if the datacenter or network segment fails.
NS IPs are public (OK / FAIL) — No NS IP belongs to a private or reserved range. FAIL = NS unreachable from the public internet.
Nameservers accept TCP (port 53) (OK / FAIL) — NS responds over TCP in addition to UDP. Required for large DNS responses and zone transfers (RFC7766). FAIL = firewall blocking TCP/53.
Nameservers on different AS (OK / WARN) — NS IPs belong to different Autonomous Systems (networks/providers). WARN = same ISP/network for all, single point of failure at the routing or BGP level.
Stealth NS records (OK / WARN) — NS that exist only in the auth servers but are not declared at the parent. Valid configuration (hidden secondaries) but worth verifying intentionally.

SOA — Start of Authority

Evaluates the SOA record that controls synchronisation between primary and secondary nameservers.

SOA record (INFO / FAIL) — Displays the full SOA (MNAME, RNAME, Serial, Refresh, Retry, Expire, Minimum). FAIL = no SOA found, serious zone configuration problem.
SOA Serial consistent across NS (OK / FAIL) — All NS have the same serial number. FAIL = zone transfer failure; secondary NS is serving a stale zone.
SOA MNAME registered at parent (OK / INFO) — The primary NS in the MNAME field appears in the parent's NS records. INFO = likely a hidden primary nameserver (valid configuration).
SOA Serial format (OK / WARN) — Serial in YYYYMMDDnn format (RFC1912 recommendation, e.g. 2024031501). WARN = valid but does not follow best practice, making troubleshooting harder.
SOA REFRESH (OK / WARN) — How often (in seconds) secondary NS check for zone changes. Recommended: 3600–86400s (1–24 hours).
SOA RETRY (OK / WARN) — How long secondary NS wait after a failed refresh before retrying. Recommended: 600–3600s (10 minutes–1 hour).
SOA EXPIRE (OK / WARN) — When secondary NS stop serving the zone if contact with the primary is lost. Recommended: ≥604800s (7 days). Low value = risk of SERVFAIL if primary goes down.
SOA MINIMUM TTL (OK / WARN) — TTL for negative responses (NXDOMAIN cache). Per RFC2308: recommended 300–10800s (5 minutes–3 hours). Too low = excess load on root servers; too high = slow recovery after record deletion.

MX — Mail Exchange

Checks the email configuration. If no MX records exist, returns INFO and skips the remaining checks.

MX records (INFO) — Lists MX records with their priority (e.g. 10 mail.example.com). INFO with no records = domain does not accept email.
MX records consistent across NS (OK / WARN) — All NS return the same MX records. WARN = inconsistency, possible zone transfer issue.
MX names valid (OK / FAIL) — MX hostnames follow RFC-valid format. FAIL = typo that prevents email delivery.
MX IPs are public (OK / FAIL) — Mail servers do not use private/internal IPs. FAIL = mail server unreachable from external networks.
MX CNAME Check (OK / FAIL) — MX records are not defined as CNAMEs (RFC2181). FAIL = forbidden; causes delivery failures with compliant mail servers.
MX is not an IP (OK / FAIL) — MX uses a hostname rather than a bare IP (RFC5321). FAIL = MX pointing directly to an IP, violates the RFC.
Number of MX records (OK / WARN) — At least 2 MX for redundancy. WARN = 1 MX = if the mail server fails, incoming email is lost.
Duplicate MX IPs (OK / WARN) — Multiple MX records with different hostnames but the same IP. WARN = fake redundancy, practically a single point of failure.
Reverse DNS (PTR) for MX IPs (OK / WARN) — Every mail server IP has a PTR record. WARN = without PTR, many receiving mail servers reject or penalise messages as spam.

WWW

Basic resolution check for the www subdomain.

WWW A record (INFO) — IP(s) that www.example.com resolves to, or the CNAME if one is used instead of an A record.
WWW IPs are public (OK / FAIL) — The www IPs are not in a private range. Only shown when A records are found.
WWW CNAME (INFO) — Whether www uses a CNAME or direct A records. Informational only.

When do you need Διαγνωστικό DNS?

After transferring a domain to a new registrar or DNS provider
When email ends up in spam or is not delivered at all
After changing nameservers — to confirm everything is correctly configured
For a security audit — detecting open resolvers or lame delegation
For RFC compliance auditing before going live with a new domain
When experiencing intermittent DNS issues you cannot pinpoint

Frequently Asked Questions

What is the difference from Έλεγχος DNS?

The Έλεγχος DNS queries multiple resolvers and returns the records it finds — useful for checking DNS propagation. The Διαγνωστικό DNS goes much deeper: it evaluates the quality and correctness of the DNS setup through 43+ automated checks with OK/WARN/FAIL ratings.

What is lame delegation?

Lame delegation means the TLD parent server declares a nameserver as responsible for the domain, but that NS does not respond authoritatively — it does not hold the zone. This causes increased DNS query latency and potential service outages.

What is an open resolver and why is it dangerous?

An open resolver answers recursive queries from anyone on the internet — not just the provider's own clients. This makes it a tool for DNS amplification attacks, where attackers send small queries that generate large responses directed at a victim.

Why are PTR records important for mail?

Many mail servers reject or penalise email from IPs without reverse DNS (PTR). It is a fundamental reputation signal for email deliverability and must be configured at the ISP or hosting provider level.

How often are results cached?

Results are cached for 3 minutes. If you have just made DNS changes, wait a few minutes before running the diagnostic again.

What is a hidden primary nameserver?

A hidden primary is the main NS (listed in the SOA MNAME field) that is not declared at the TLD parent — so it does not serve queries directly from the internet. It is used for security or to control zone transfers to secondaries. This is a valid and common configuration.

📖 Read the full guide: What Is Reverse DNS (PTR Record)? →