Popular tools

Theme

DNS Health Check

Domain validation for DNS: the registry's delegation, every nameserver asked directly, SOA, DNSSEC and mail records. 40 checks, each with its fix.

Levels from Zonemaster and the RFCs · every nameserver asked over TCP · Google Public DNS · RDAP

Walks from a root server to the .nl registry, then asks each nameserver of sidn.nl directly · 40 checks · about 3 s.nl registry → every nameserver · 40 checks

Try
ExampleRecorded Oct 23, 2026 · from our server.nl3 NSDNSSEC signed

sidn.nl passes every check that ran, DNSSEC included

registered at SIDN·2.9 s

40 pass

A+: nothing above info. Every nameserver answered with authority and agreed with the others, the timers sit inside Zonemaster's range, and Google Public DNS validates the DNSSEC chain from the root.

Problems first

Asked over TCP from our server at Cloudflare's edge: the root, the .nl registry and every nameserver directly; Google Public DNS and Cloudflare for mail records and validation. We keep no log of what you check.

What does a DNS health check test?

A DNS health check follows a domain the way a resolver finds it and tests every step: the registry's delegation, each nameserver asked directly, whether those servers agree, the SOA record, DNSSEC and the mail records. This one runs 40 checks in seven groups and grades each at the level its authority sets.

Most checkers ask a resolver and grade what comes back. That hides the servers behind it: a resolver answers from whichever nameserver works, so a broken one stays invisible until the others fail too. Here every nameserver is asked over TCP with recursion off, the registry's copy of the NS records is compared with the zone's own, and the DNSSEC chain is verified from the DS at the registry to the signatures in the zone.

Use it as a DNS audit or a domain health check after any change: it goes further than a tool that lets you check DNS records one at a time: it tests the records a domain depends on, not only whether its website loads (for that, the Website Down Checker looks at the site itself). Copy report turns the result into a plain-text DNS report you can paste into a ticket.

Rooth.root-servers.net
.com.com registryh.gtld-servers.net
8 nameserversRoute 53 + NS1
The zonegithub.com
  • DNSSEC7 checksthe chain of trust from the root: github.com stops at .com (no DS)
  • Parent & delegation6 checksthe registry's referral: 8 names · 295 bytes · no glue needed
  • Nameservers14 checkseach server asked directly: 8 of 8 authoritative · over TCP · EDNS · no recursion
  • Consistency3 checksdo the servers agree: 2 SOA serials, one per DNS host · the same MX and SPF
  • SOA4 checkstimers under Zonemaster's floors: notices
  • CAA1 check7 records · 4 CAs allowed
  • Mail DNS5 checksMX at Microsoft 365 · SPF 10 of 10 lookups · DMARC quarantine
Where each group of checks looks, on github.com's real path (October 23, 2026): from the root through the .com registry to the zone's nameservers at Route 53 and NS1.
DNS health check result for github.com: grade A, 40 checks in seven groups and the path from the root to 8 nameserversDNS health check result for github.com: grade A, 40 checks in seven groups and the path from the root to 8 nameserversThe gradeFrom levels only: no critical, no error, two warnings make an A. The ring shows the score, 90 of 100.40 checks, one cell eachGrouped as the page lists them. Amber and blue cells are the warnings and notices; hatched cells couldn't run.Problems firstGroups with something to fix open at the top, each row with its authority and the fix.The pathA root server, the .com registry run by Verisign, then every nameserver asked directly: its answer, serial and EDNS.Chain of trustThe DNSSEC rail beside the path: green where it holds, dashed where it stops, red where it breaks.
A DNS health check of github.com. Select a number to see what each part shows.

How is the grade worked out?

The letter comes only from the levels of what failed, never from a points table: any critical problem is an F, two or more errors a D, one error or five or more warnings a C, three or four warnings a B, one or two warnings (or only notices) an A, and nothing above info an A+.

The levels are the cited authority's own: Zonemaster's default profile where it defines the test, the RFC's MUST or SHOULD where it doesn't. The number out of 100 only ranks domains inside a letter (100 − 30 per critical, 12 per error, 4 per warning, 1 per notice). Checks our server can't run are never held against a domain; when a quarter or more can't run, the grade says partial.

  1. A+100nothing above infoINFO “definitely does not indicate a problem”sidn.nl100
  2. A90–991–2 warnings, or notices onlyNOTICE “should be known by the zone's administrator but that need not necessarily be a problem at all”github.com90example.com95bücher.de90
  3. B75–893–4 warningsWARNING “will under some circumstances be a problem, but that is unlikely to be noticed by a casual user”cloudflare.com87google.com83
  4. C60–741 error, or 5 or more warningsERROR “very likely (or possibly certain) to negatively affect the function of the zone”none in the sample
  5. D45–592 or more errorsdnssec-failed.org55
  6. F0–44any critical problemCRITICAL “can reasonably be said not to exist”a .com domain44

score = 100 − 30 × critical − 12 × error − 4 × warning − 1 × notice, kept inside the letter's band

partiala quarter or more of the checks couldn't run from our server, so the grade says so

The ladder, with the domains we checked on October 23, 2026 placed on it by their recorded grade. Levels quoted from Zonemaster's severity definitions.

Do the parent and child NS records match?

They should: the registry (the parent) and the zone (the child) each publish an NS set, and RFC 1912 §2.8 says to keep them the same. When the registry points at a server that doesn't answer for the zone, that's a lame delegation: the server answers REFUSED, or answers without the authoritative (AA) flag.

Resolvers move on to the next server, so one lame server costs time; when every listed server is lame, the domain stops resolving. Zonemaster rates names only the registry lists as an error (EXTRA_NAME_PARENT), names only the zone lists as a notice, and no working server at all as critical.

github.commatch

Registry .com
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
The zone
  • the same 8

8 of 8 answer with AA

a .net domainmismatch

Registry .net
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
The zone
  • ns1.hover.com
  • ns2.hover.com

no name in common · ns2.domaindirect.com REFUSED · 2 errors

a .com domainlame delegation

Registry .com
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
The zone
  • nobody answersSERVFAIL

every server REFUSED · resolvers answer SERVFAIL · CRITICAL

Three delegations recorded on October 23, 2026. The names of the two broken ones are withheld; their nameservers and answers are real.

How many nameservers does a domain need?

At least two, and three is the recommendation. RFC 1034 §4.1 requires every zone to be available on at least two servers, and RFC 2182 §5 recommends three for most organisation-level zones. One nameserver is an error in Zonemaster; two pass with an info note.

Where they are matters more than how many, so the nameserver check looks at their networks too. Servers in one network fail together: Zonemaster warns when every address sits in one autonomous system (IPV4_ONE_ASN), even for anycast hosts like Google, Cloudflare or Akamai, whose addresses each answer from many sites. Anycast spreads the load; it's still one operator.

  • google.com4 NS · 1 networkone network
  • github.com8 NS · 2 networksspread
  • sidn.nl3 NS · 2 networksspread
  • cloudflare.com5 NS · 1 networkone network
  • nasa.gov6 NS · 1 networkone network
  • example.com2 NS · 1 networkone network

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

“It is recommended that three servers be provided for most organisation level zones, with at least one which must be well removed from the others.” RFC 2182 §5
One dot per nameserver, coloured by the network (AS) its address is announced from, from the runs recorded on October 23, 2026. A single network is Zonemaster's IPV4_ONE_ASN warning, anycast or not.

Are your SOA record values right?

If a large DNS host set them, they're almost certainly fine, even when a checker flags them. Refresh, retry and expire only steer secondary servers that copy the zone by zone transfer. Minimum is the negative-caching TTL (RFC 2308): how long resolvers remember that a name doesn't exist.

RIPE-203 (1999) recommends refresh 86400, retry 7200, expire 3600000 and minimum 172800, the last from before RFC 2308. Zonemaster sets lower floors: refresh 14400 and retry 3600 (notices), expire 604800 (the only warning), minimum between 300 and 86400 (a notice). Cloudflare's, Route 53's and Azure's defaults sit under the refresh and retry floors; Google Cloud DNS's 3-day expire is the one warning among the big hosts.

refreshZonemaster ≥ 4 hr · ◆ 1 dayretryZonemaster ≥ 1 hr · ◆ 2 hrexpireZonemaster ≥ 7 days · ◆ 41.7 daysminimumZonemaster 5 min – 1 day · ◆ 2 days
Cloudflare2.8 hr40 min7 days30 min2 notices
Amazon Route 532 hr15 min14 days1 day2 notices
Google Cloud DNS6 hr1 hr3 days5 min1 warning
Azure DNS1 hr5 min28 days5 min2 notices
GoDaddy8 hr2 hr7 days1 hrpass
Namecheap BasicDNS12 hr1 hr7 days1 hrpass
google.com (its own)15 min15 min30 min1 min1 warning · 3 notices

under Zonemaster's floorpassnoticewarningRIPE-203 (1999)

Each host's values as its zones served them over dig on October 23, 2026: Cloudflare, Route 53 and Google Cloud DNS match their documentation; GoDaddy's help page says minimum 600, its example zones serve 3600; we found no published defaults for Azure DNS or Namecheap BasicDNS, so theirs are their zones' values. Log scale from 1 minute to 6 weeks.

DNSSEC check: DS, DNSKEY and signatures

A DNSSEC check walks the chain of trust: the DS record at the registry must be the digest of a key (DNSKEY) in the zone, that key must sign the zone's key set, and every signature (RRSIG) must verify and be inside its validity window. This check computes the digest and verifies each signature itself, then asks Google Public DNS whether it validates.

Break any link and validating resolvers answer SERVFAIL: the domain disappears for everyone behind them. dnssec-failed.org, a test zone kept broken on purpose, shows two breaks at once. Algorithms are judged by IANA's registry (RFC 9904): 8, 13 and 15 are recommended, while 5 and 7, which sign with SHA-1, must no longer be used (RFC 9905) and Zonemaster rates them an error.

cloudflare.comsecure

  1. DS 2371 at .comalgorithm 13 · SHA-256 · 329968…26F2B9
  2. the digest matches key 2371
  3. DNSKEY 2371 · KSKflags 257 · ECDSA P-256 (13)
  4. signs the key set · 50.8 days left of 61 days
  5. DNSKEY 34505 · ZSKflags 256 · ECDSA P-256 (13)
  6. signs the records · SOA: 1 day left of 2 days
  7. Google Public DNSAD flag set: secure

dnssec-failed.orgbogus

  1. DS 42069 at .orgalgorithm 13 · SHA-256
  2. no key 42069 in the zone
  3. DNSKEY 50719 · KSKthe zone's real key-signing key
  4. its signature on the key set expired 112 days ago
  5. DNSKEY 32784 · ZSKsigns the SOA: valid, 5.7 days left of 7 days
  6. nothing trusted reaches it
  7. Google Public DNSSERVFAIL; answers once CD is set: bogus

Signing algorithms (IANA registry, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519use these
  • MAY14 ECDSAP384SHA384 · 16 ED448allowed
  • NOT RECOMMENDED10 RSASHA512Zonemaster WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster ERROR

both chains above sign with 13

Two chains recorded on October 23, 2026: cloudflare.com's holds; dnssec-failed.org's breaks at the DS and again at an expired signature.

Mail DNS: MX, SPF and DMARC

The mail checks read what receiving servers read: the MX records (or a null MX that says the domain takes no mail, RFC 7505), one SPF record within RFC 7208's limit of 10 DNS lookups, and a DMARC policy (RFC 9989, which replaced RFC 7489 in May 2026).

SPF is evaluated, not just found: every include is followed and counted. github.com's record needs exactly 10 lookups plus one void lookup: valid, with no room left. A domain that never sends mail should say so: example.com publishes the parked set, a null MX, v=spf1 -all and p=reject. For the details, the SPF checker and DMARC checker go further.

github.comsends and receives

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 1 host · not an alias
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all10 of 10 DNS lookups1 of 2 void lookups · valid, no room left
DMARC
p=quarantine; sp=rejectreports to 1 address · subdomains: reject

example.comparked set

MX
0 .null MX: takes no mail (RFC 7505)
SPF
v=spf1 -allsends no mail · 0 lookups
DMARC
p=reject; sp=rejectanything claiming to be example.com is refused
github.com and example.com, as published on October 23, 2026.

Check DNS health from the command line (dig)

Four steps with dig and delv repeat the core of this check: follow the delegation from the root, ask one nameserver directly with recursion off, compare the DS at the registry with the zone's keys, and let a validating resolver judge the chain.

Add +tcp to see what our server sees; leave it off to test UDP, which a web tool on Cloudflare's network can't. In the reply's header, aa marks an authoritative answer; REFUSED, or no aa flag from a server the registry lists, is a lame delegation.

Terminal · dig 9.20

$ dig +trace +tcp github.com NS
;; (shortened)
com.          172800 IN NS a.gtld-servers.net.   ;; from h.root-servers.net 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; from h.gtld-servers.net: 8 NS 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; no DS: unsigned 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. The root refers .com to its 13 servers
  2. The registry's NS set for github.com, kept 2 days
  3. aa: an authoritative answer, not a cache
  4. SOA: serial 1, then refresh, retry, expire, minimum
  5. No DS at .com: nothing for DNSSEC to verify
  6. delv validated the chain from the root
Real answers for github.com and cloudflare.com (October 23, 2026), shortened. The numbered marks match the notes.

Why do DNS checkers disagree?

Because they grade against different numbers. Classic checkers flag providers' defaults: intoDNS calls google.com's expire of 1800 seconds “NOT OK” and errors on github.com's two serials, which are normal for two DNS hosts. Zonemaster rates the serials a warning and recognises a null MX; our own first version got neither right.

And they see the network from different places. Zonemaster (AFNIC and the Swedish Internet Foundation) asks over UDP and TCP, on IPv4 and IPv6. This check runs on Cloudflare's edge: it asks over TCP only, doesn't dial IPv6, and can't connect to Cloudflare's own addresses, so those servers are read through 1.1.1.1 and their checks are marked not tested, never failed. As an intoDNS alternative, it shows the authority behind every level instead of a bare OK or NOT OK.

CaseintoDNSZonemasterDNS Robot v1This check
github.comtwo SOA serials (two DNS hosts)error“Looks like your nameservers do not agree on the SOA serial.”warningMULTIPLE_SOA_SERIALSfail“Serial mismatch detected: 1656468023 vs 1.”warningexplained: one serial per DNS host
google.comSOA expire 1,800 snot ok“Your SOA EXPIRE number is: 1800. That is NOT OK”warningEXPIRE_MINIMUM_VALUE_LOWERfail“too low (min recommended: 14 days)”warningwith what expire affects
example.comnull MX (0 .)error“0 No A Record (no glue either)”infoZ09_VALID_NULL_MXpass“Found 1 MX record(s)”passnull MX recognised
cloudflare.comSOA retry 2,400 s—not quotednoticeRETRY_MINIMUM_VALUE_LOWERfail“too high (max recommended: 15min)”noticeCloudflare's default
cloudflare.comsigned with DNSSECnot checkedno DNSSEC testpassDNSSEC02 · 05 · 08: chain verifiedwarn“DNSSEC does not appear to be enabled for this domain.”passDS → KSK → RRSIG verified, Google validates
The same domains in four checkers. intoDNS and v1 results quoted from their pages and answers on October 22 – 23, 2026; Zonemaster's levels from its test specifications. The last column is this check: an intoDNS alternative that grades each finding at the level its authority sets.

DNS health check: questions

What is a DNS health check?

A DNS health check, or DNS validation check, tests whether a domain's DNS is set up so the whole internet can reach it: the registry's delegation, every nameserver, the SOA record, DNSSEC and the mail records. Each finding is graded by how much it can hurt, from info to critical, and this DNS validator shows the rule it applies (a Zonemaster test or an RFC section) and the fix.

Is domain validation the same as a DNS health check?

Not always. “Domain validation” also names the check a certificate authority makes before issuing a DV certificate, and the TXT record Google Workspace or Microsoft 365 asks for to prove you own a domain. This domain validator checks the domain's DNS: delegation, nameservers, SOA, DNSSEC and mail records. For a certificate, see the SSL checker.

What is a lame delegation and how do I fix it?

A lame delegation is a nameserver the registry lists that doesn't answer for your domain: it says REFUSED or answers without authority. Fix it where the mismatch is: add the zone at that DNS host, or change the nameservers at your registrar to the ones that have the zone. If every listed server is lame, the domain doesn't resolve at all.

My DNS host is anycast. Why the warning for one network?

Because one operator is one failure domain. Anycast lets each address answer from many sites, which protects against a site going down, not against the provider's own outage or a mistake in its configuration. Zonemaster keeps IPV4_ONE_ASN at warning for that reason, and RFC 2182 asks for servers on diverse networks. A second DNS host on another network clears it.

My SOA timers are flagged. Do I need to change them?

Usually not. Refresh, retry and expire matter only to secondary servers that copy your zone by zone transfer; large hosts like Cloudflare and Route 53 don't use them for your zone, and their defaults are fine. Expire under a week is the one Zonemaster calls a warning. Change values only if you run your own primary and secondaries.

Why are some checks marked “not tested”?

Because our server couldn't run them, not because something is wrong. It runs on Cloudflare's network, which can't open connections to Cloudflare's own addresses, and it asks over TCP only and doesn't dial IPv6. Those servers are read through Cloudflare's resolver 1.1.1.1 instead. Untested checks never lower the grade; a quarter or more marks it partial.

Why do my nameservers report different SOA serials?

Either a secondary hasn't caught up with a change yet, or your domain uses two DNS hosts that don't transfer the zone between them, so each keeps its own serial. The second is normal: github.com's Route 53 servers say 1 and its NS1 servers 1656468023. Zonemaster lists any difference as a warning; we explain which case it is.

Is this a DNSSEC checker, and does no DNSSEC lower the grade?

Yes: it checks the DS at the registry against the zone's keys and verifies every signature, then asks Google Public DNS. An unsigned zone is one Zonemaster warning (DS07_NOT_SIGNED), so the grade stays at A at most. A broken chain is far worse than none: validating resolvers refuse the domain, an error that drops the grade to C or below.

How often should I run a DNS health check?

After every change to nameservers, DNSSEC or mail records, and before and after moving to a new DNS host or registrar. Otherwise once a month is enough to catch an expiring signature, a nameserver that stopped answering or a registry change you didn't make. Each result has its own link, so you can compare runs.

Do you keep the domains I check?

No. The check runs on our server at Cloudflare's edge and asks the root, the registry, your nameservers, Google Public DNS and Cloudflare's resolver; nothing is logged with your address. A finished run is kept for 10 minutes so a repeat or a shared link answers at once, then dropped. Your nameservers see about 20 questions from our server per run.

Missing something?Suggest a feature or a new tool

Related tools