What every check means, and how to fix it.

Parent zone and delegation

Parent name servers

Before anyone can reach your name servers, a server of the parent zone — the registry of your extension — has to point at them. We query one of those registry servers directly, so the result is the delegation as the internet receives it, not a cached copy.

Delegation at the registry

The NS records stored at the registry. If they are missing, the domain resolves nowhere, no matter how well your own servers are configured: check that the domain is registered, paid for, and not on hold.

Number of name servers

Two is the minimum required by the standards, three or four is comfortable. One means any maintenance window takes your domain off the internet. More than seven only makes referral answers bigger.

Glue records

If your name servers live inside the domain they serve (ns1.example.com serving example.com), the registry must also publish their IP addresses. Without that glue a resolver would have to ask example.com where example.com is — an unsolvable loop. Glue is added at your registrar, in the same screen as the name servers.

Registry and zone agree

The NS list at the registry and the NS records inside your zone must be identical. When they differ, some resolvers use one list and some the other, and problems appear at random for a fraction of your visitors.

Registration (RDAP)

Registrar, creation and expiry dates and registry status, read over RDAP, the structured successor of WHOIS. Statuses containing "hold" or "redemption" mean the domain has stopped resolving for administrative reasons — usually an unpaid renewal.

Name servers

Answering servers

Each delegated server is queried directly, one packet at a time, from our network. The table lists the addresses used, the round trip time, the serial number each server reports and whether it answers authoritatively.

All name servers respond

Resolvers pick a name server more or less at random. One dead server does not break your domain, it makes it intermittently slow: a share of queries wait for a timeout before trying another. Remove servers that no longer exist from the delegation.

Authoritative answers

An authoritative answer carries the AA flag. A delegated server that answers without it does not host the zone — a classic leftover after a migration, or a zone that was never created on that server.

SOA serial is in sync

Secondary servers copy the zone when the serial number grows. Different serials mean a transfer is failing and some servers are answering with an older version of your zone. Check the primary logs, the notify list and the transfer ACLs.

NS records are identical

All your servers should publish the same NS set. Differences usually mean a zone file was edited by hand on one server only.

Recursion is disabled

An authoritative server must answer only for its own zones. If it also resolves arbitrary names for anybody, it can be abused to amplify denial-of-service attacks against third parties, and it will end up on abuse lists. Disable recursion, or restrict it to your own networks.

DNS over TCP

TCP is not a fallback, it is mandatory. Large answers — DNSSEC signatures, long TXT records, many addresses — do not fit in a UDP packet, and a firewall that only allows port 53 over UDP breaks them silently.

EDNS(0) support

EDNS lets a resolver announce that it accepts larger answers and understands DNSSEC. Servers or middleboxes that drop EDNS queries cause slow resolution and are incompatible with modern validation.

Name servers are not aliases

An NS record must point to a name that has an address record. Pointing it at a CNAME is forbidden by the standards and rejected outright by some resolvers.

Public addresses

A name server published with a private address (10.x, 192.168.x, 172.16-31.x) is unreachable from the internet and leaks your internal addressing.

Network diversity

Two name servers in the same rack, on the same switch and in the same /24 fail together. Real redundancy means different networks, ideally different providers and different cities.

IPv6 reachable name servers

At least one name server should have an AAAA record. Mobile networks are increasingly IPv6-only and reach IPv4-only servers through a translator, which adds latency to every lookup.

Response time

Measured from our servers, so absolute numbers depend on distance. What matters is the spread: one server far slower than the rest will slow down a share of your visitors.

Reverse DNS of the name servers

Informational. Reverse names help operators identify your servers in logs and abuse reports.

SOA record

The Start Of Authority record holds the identity of the zone: the primary server, the contact address, the version number and the timers that secondary servers and resolvers obey.

Primary server (MNAME)

The server considered the source of truth for the zone. It is normally also listed as an NS record; a hidden primary is a legitimate exception, but then dynamic updates must be pointed somewhere else explicitly.

Zone contact (RNAME)

The e-mail address of whoever maintains the zone, written with a dot instead of the @ sign: hostmaster.example.com means hostmaster@example.com. It should be an address someone actually reads.

Serial number

The version of the zone. It must increase with every change, otherwise secondaries never copy the update. The YYYYMMDDnn convention makes the last edit date obvious at a glance.

Refresh, retry, expire and minimum

Refresh: how often a secondary checks for a new serial. Retry: how soon it tries again after a failure, always smaller than refresh. Expire: how long a secondary keeps serving the zone while the primary is unreachable — days, not minutes, or a short outage takes your domain down. Minimum: how long resolvers cache the fact that a name does not exist.

TTL values

The TTL is how long resolvers may reuse an answer. Very short values multiply queries and add latency; very long ones make migrations slow. One hour is a good default, lowered to a few minutes a day before a planned change.

Web and address records

Address of the domain

The A and AAAA records of the bare domain, without www. If they are missing, typing example.com in a browser leads nowhere even when www.example.com works.

No CNAME at the zone apex

A CNAME cannot coexist with other records, and the apex always has SOA and NS records, so a CNAME there is invalid and breaks mail and name server lookups. Providers offer ALIAS, ANAME or flattened CNAME records for this exact case.

www subdomain

Publish both the bare domain and www, and redirect one to the other at the web server. Visitors and link builders use both forms whatever you prefer.

IPv6 (AAAA)

An AAAA record makes your site reachable natively over IPv6. Most CDNs and hosting panels enable it with one switch.

HTTPS (SVCB) record

A newer record type that tells the browser, before the first connection, that the site speaks HTTPS and which protocol versions it supports. It removes the initial plaintext redirect and is required for Encrypted Client Hello.

Wildcard record

A wildcard answers for every name that does not exist. Convenient for multi-tenant setups, but it hides typos, breaks negative caching and can make subdomain takeover harder to notice.

Web server answers

One HTTP request to the domain, so that a perfect DNS configuration in front of a dead web server is not reported as healthy. It does not affect the DNS score.

Mail delivery

MX records

Where mail for your domain is delivered, in priority order: the lowest number is tried first. If a domain never receives mail, publish a null MX (priority 0, target ".") so senders fail immediately instead of queueing for days.

Mail server redundancy

A second MX at a different provider keeps mail queued instead of bounced while your primary is down. Note that a backup MX must also know which mailboxes exist, or it becomes a spam relay.

MX hosts resolve

An MX target must resolve to an address. A typo here means every message sent to your domain bounces.

MX hosts are not aliases

An MX record must point to a name with an address record, never to a CNAME. Several mail servers refuse such domains outright.

Reverse DNS of the mail servers

Receiving servers check that the sending IP has a PTR record and that it matches the name the server introduces itself with. No PTR is one of the fastest ways to land in the spam folder. The PTR is created by whoever owns the IP address: your hosting provider.

DANE / TLSA

A TLSA record publishes the certificate your mail server will present, validated through DNSSEC. It makes downgrade attacks on SMTP impossible, and requires a signed zone.

Blocklists (DNSBL)

Your mail and web addresses are checked against public anti-spam lists. A listing means messages are rejected or filtered by many receivers; each list publishes its own removal procedure.

Mail authentication

SPF

A TXT record listing the servers allowed to send mail with your domain in the envelope. Exactly one SPF record is allowed, and it may cost at most ten DNS lookups to evaluate: every include, a, mx and redirect counts, including the ones inside your provider's record. Finish with -all (reject) or ~all (mark), never +all.

DKIM

Your mail server signs each message with a private key; the public half lives in DNS under selector._domainkey. Unlike SPF, the signature survives forwarding. Selectors are chosen by each provider, so we probe the common ones — a missing result here does not prove DKIM is off.

DMARC

Published at _dmarc.example.com, it tells receivers what to do when SPF and DKIM fail, and where to send reports. Start at p=none with a rua address, read the reports for a few weeks, then move to quarantine and finally reject. Without DMARC, anyone can send mail as your domain.

MTA-STS

A TXT record plus a policy file served over HTTPS at mta-sts.example.com. It tells other mail servers that TLS is mandatory for your domain, which prevents an attacker from stripping encryption between servers.

TLS-RPT

The reporting side of MTA-STS and DANE: senders mail you a daily summary of failed TLS connections, so a broken certificate does not go unnoticed for weeks.

BIMI

Publishes your logo so supporting inboxes show it next to authenticated messages. It requires DMARC at quarantine or reject first, and some providers also require a verified mark certificate.

Security

DNSSEC

DNSSEC signs your zone so resolvers can detect forged answers. It needs two halves: signatures published by your name servers (DNSKEY, RRSIG) and a DS record uploaded to the registry. A DS without a signed zone is worse than no DNSSEC at all — validating resolvers will refuse to resolve your domain entirely.

CAA

A CAA record names the certificate authorities allowed to issue certificates for your domain. Authorities are required to check it, so it is a cheap way to stop a certificate being issued elsewhere. Add an iodef entry to be told when someone tries.

Zone transfer (AXFR)

A zone transfer hands out every record you have. Open to the world it is a free map of your infrastructure: internal hosts, staging servers, backup systems. Restrict transfers to your secondary servers, ideally with a TSIG key.

Software version disclosure

Name servers answer a special query with their software version by default. Hiding it does not fix anything on its own, but it stops your servers appearing in automated scans for a specific vulnerable release.

TXT records

Verification tokens accumulate for years. Old ones enlarge every answer, can push responses past the UDP limit, and occasionally keep an abandoned service authorised over your domain.