What is a domain health check?

A domain health check tests the four independent layers that must all be true for a domain to work: registry delegation (the TLD hands out nameservers for the name), the DNS zone (those nameservers answer with records), the binding (the hostname is attached to something that serves it), and the content (something is actually deployed there). Checking only the last one — loading the page — tells you it is broken but not which layer to fix.

How do I check whether my domain's DNS delegation is broken?

Ask a public resolver rather than your own machine: dig NS example.com @8.8.8.8 +short, then confirm with a second independent source such as dns.google or cloudflare-dns over DoH. If both return nothing, or the DoH response carries Status 3 (NXDOMAIN), the delegation is missing at the registry — regardless of what your registrar's dashboard says.

What does NXDOMAIN mean for a domain that used to work?

It means the TLD's nameservers no longer have a delegation record for the name: from the internet's point of view the domain does not exist, rather than existing and resolving to the wrong place. Usual causes are an expired or held registration, a registry lock, or the registrar failing to push the delegation. Nothing you change in your DNS provider fixes it — the repair happens at the registrar.

My DNS provider says the zone is active but the site is down. What now?

Treat that status as a cached opinion and check the layer below it. A zone can read active long after the registry stopped delegating to it, because the provider re-checks nameservers on its own schedule. Query public DNS for the NS records yourself; if the delegation is gone or points elsewhere, the zone being active is irrelevant.

How often should a domain be monitored?

Often enough that an outage is measured in minutes, not days: delegation failures look like a deleted site to search engines, and de-indexing starts after a few days of failed crawls. Clize sweeps every managed domain from public DNS every 30 minutes and requires two consecutive failing rounds — about 25 minutes — before it emails, so jitter does not page you but a real outage does not wait.

Can I check a domain that is not registered with Clize?

The dig and curl checks on this page work on any domain, at any registrar — they only use public DNS. The one-command version, clize domain check, works on domains under Clize management, which includes external domains brought in with clize domain import; monitoring and alerts follow from that.

Domain health check: four layers, one command

Registry delegation, DNS zone, host binding, served content — how each one fails, how to test it yourself, and why every dashboard you own can be green while the domain is dead.

A domain health check is four separate tests, not one. A working domain requires four independent things to be true at the same time: the registry still delegates the name to your nameservers; those nameservers hold a zone with the right records; the hostname is bound to something that serves it, with a valid certificate; and there is content at that hostname. They fail independently and they all look the same from a browser — one unreachable page. Check them from the bottom up, because a broken lower layer makes every layer above it meaningless, and fix the lowest broken one first. The fast path: curl the domain's NS records from a public resolver, ask the delegated nameservers directly, inspect the TLS handshake, then request the page. Or run clize domain check example.com, which does all four and tells you which layer to fix.

The rule underneath all of this: every status field your providers show you is a cached opinion. Public authoritative DNS is the only thing that answers the question "is this domain alive to the rest of the world, right now".

Layer 1 · Registry delegation

What it is. The TLD's nameservers (the machines behind .com, .app, .io) hold one fact about your domain: which nameservers are authoritative for it. That record lives at the registry, is written by your registrar, and is the first thing any resolver in the world looks up. Nothing you configure anywhere else matters if this is wrong.

How it breaks. Three shapes. The delegation disappears — expiry, a registry hold, or a registrar-side failure to push it — and the name returns NXDOMAIN: not "wrong address", but "no such domain". The delegation points elsewhere, usually the registrar's default nameservers after a reset or transfer, so mail and hosting configured at your real provider are silently bypassed. Or the delegation is partial — some nameservers listed no longer serve the zone — and resolution becomes intermittent, which is the worst version to debug.

How to check it. Ask a public resolver, never your own. Local resolvers cache aggressively, and a VPN or split-DNS setup will happily invent an answer that no one else on the internet sees:

$ dig NS example.com @8.8.8.8 +short
$ dig NS example.com @1.1.1.1 +short   # second, independent source

Two sources matter because a single resolver having a bad day is not the same event as a domain being down. The same question over DoH, which is what a monitoring job would use, exposes the response code directly:

$ curl -s 'https://dns.google/resolve?name=example.com&type=NS'
$ curl -s -H 'accept: application/dns-json' \
    'https://cloudflare-dns.com/dns-query?name=example.com&type=NS'

Read "Status" in the JSON: 0 is a normal answer, 3 is NXDOMAIN — the delegation is gone. To watch the referral chain itself, from the root to the TLD to your provider, use dig +trace example.com: the last referral you see before the answer is the registry telling you what it knows. And confirm the registration state separately, since expiry and locks live there rather than in DNS:

$ dig +trace example.com
$ curl -sL https://rdap.org/domain/example.com | head -40   # status, expiry, registrar

Who fixes it. Only the registrar. No amount of editing records at your DNS provider will restore a delegation the registry does not have.

Layer 2 · The DNS zone

What it is. The delegation says who answers; the zone is what they answer. It lives at your DNS provider and holds the A/AAAA, CNAME, MX, and TXT records that point the name at real machines.

How it breaks. The zone was never created, or was deleted, or is suspended, or exists but is missing the record you need — apex A record gone after a migration, MX records dropped when a mail provider changed, the www host never created. A subtle one: the zone is fine at provider A while the delegation now points at provider B, so you are editing records nobody reads.

How to check it. Skip the resolver and ask the authoritative nameservers themselves — the ones layer 1 just gave you:

$ dig SOA example.com @ns1.example-dns.com
$ dig A example.com @ns1.example-dns.com +short
$ dig A www.example.com @ns1.example-dns.com +short

REFUSED or SERVFAIL means that nameserver is not serving a zone for your domain at all — the delegation and the zone have drifted apart. A clean NOERROR with an empty answer section means the zone is there and the record is not. Compare each authoritative nameserver against the others: they should agree, and when they do not you have found your intermittent bug.

The trap. A provider dashboard that says active is reporting the last time it checked, not the current state of the registry. Believe layer 1 over layer 2, always.

Layer 3 · The binding

What it is. DNS gets a visitor to an IP address. Something at that address still has to recognise the hostname and agree to serve it — a virtual host, a load balancer rule, an edge platform's custom-domain entry — and, for HTTPS, present a certificate issued for that exact name.

How it breaks. Records point at an edge where the domain was never registered, so you get a generic 404 or a platform placeholder from an otherwise healthy server. A certificate is still being issued, so the connection fails before any HTTP status exists. The apex works and www does not, because only one of them was bound. Or the domain was moved between projects and the old binding was never removed.

How to check it. Look at the response before the page:

$ curl -sI https://example.com
$ curl -sI https://www.example.com
$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -dates

A TLS handshake error, or a certificate whose subject does not cover the name you asked for, is a binding problem — not a DNS problem, and not a content problem. If curl -sI http://example.com succeeds while HTTPS fails, you have narrowed it to certificate issuance.

Layer 4 · The content

What it is. The last layer, and the only one most people check: is anything actually published at that hostname?

How it breaks. A deploy that uploaded to a different hostname than the one you are visiting. A build that produced no index.html. A redirect loop from a half-configured www-to-apex rule. An origin that returns 500 for reasons of its own.

How to check it. Read the status code and follow the redirects:

$ curl -s -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://example.com/
$ curl -s https://example.com/ | head -20

A 404 with the first three layers healthy is a genuinely good outcome: the domain works, and you have a deploy to run. That is the whole point of separating the layers — the same blank browser tab means four different jobs, and knowing which one saves the afternoon.

A nameserver list that looks right proves nothing

This is the failure that made us build all of the above, and it is worth the retelling because every instinct points the wrong way.

Four domains, registered through the same registrar, went dark for roughly four days. Nothing had been deployed, nothing reconfigured, no records touched — the platform's own audit log for that week shows only routine deploys, every one of them returning a live URL and a green checkmark. What had happened was at the registry: the nameserver delegation for those names had been dropped, and the TLD had stopped answering for them altogether. NXDOMAIN.

Meanwhile: the DNS provider's zone page said active. The registrar's API said the nameservers were correct and the domain was verified. Both were reporting cached state, and both were confidently wrong for four days. Re-submitting the same nameservers through the registrar's API returned a success code and changed nothing, because the values already matched — the values were never the problem; the registry simply had no delegation to hand out. When the registrar eventually pushed the delegations back, half of them came back pointing at its own default nameservers instead of ours, which is a second, quieter outage wearing the costume of a fix.

The cost was not four days of downtime. Search engines treat a delegation failure as a site that no longer exists, and after several days of failed crawls they de-index rather than retry: the recovery took weeks, sitemap fetch schedules stayed frozen for a month afterwards, and re-submitting them by hand turned out to be mandatory rather than optional.

Three things generalise from it, whatever registrar you use:

"The NS records are correct" and "the delegation exists" are different claims. Reading the nameserver list back from your registrar tells you what it intends. Querying public DNS tells you what the world sees. Only the second one is a health check.
A successful deploy is not evidence the domain works. Publishing and reachability are separate systems; ours now probes the domain after every deploy and returns a warning alongside the success when the two disagree.
Unmonitored delegation is measured in days. A silent failure produces nothing to notice — no error, no alert, just an absence. Ours was found by hand, days in, by someone who went looking; the crawlers had already drawn their conclusions. Detection time is the entire cost.

The one-command version

Running four checks by hand is fine once. For a domain you actually depend on, this is what clize domain check automates — the same four layers, in the same order, with the delegation probed from public DoH resolvers rather than from any provider's status field:

$ clize domain check example.com   # four layers, deep
$ clize domain check               # every domain, fast sweep

Each layer comes back with its own verdict and note — which nameservers the registry is publishing, whether the zone is active (and a warning when that contradicts the layer below it), whether the hostname is bound, whether content exists — plus a fix list ordered bottom-up. When the delegation returns NXDOMAIN it says so in those terms, because that specific shape means "talk to your registrar", not "check your DNS records".

One more thing it deliberately does not do: clize domain list shows a status field, and that field describes how a domain got here — registered through Clize, imported from outside, still pending — not whether it is healthy. It never changes when a domain goes down. Anything that looks like a health signal but never probes the network is a status field, and status fields are exactly what lied for four days.

From a spot check to monitoring

A check you have to remember to run is not monitoring. The version that catches the failure above runs without you: every managed domain is probed from public DNS every 30 minutes, and an alert email goes out after two consecutive failing rounds — about 25 minutes — so ordinary DNS jitter stays quiet while a real outage surfaces the same hour. Recovery sends its own message. Set the destination with clize account email [email protected].

Who gets paged matters as much as when, and this is where most monitoring quietly dies. A domain registered through Clize always alerts — the delegation and the renewal are ours. An external domain carrying a site or an inbox on Clize alerts, because your things are running here. An external domain with nothing running on Clize is recorded but never emailed: pointing its nameservers elsewhere is the owner's decision, not a fault. We learned that second rule the expensive way, by sending one alert a day about two such domains for fifty consecutive days until the alerts became furniture. A persistent real fault backs off on a widening interval instead — daily, then every three days, then weekly — because a reminder nobody reads is the same as no monitoring at all.

The full product these checks belong to is Agent Domains: registration behind a money gate, DNS your agent can edit, and this check running on a schedule. If you are choosing where to register in the first place, the honest comparison is programmatic domain registration: the real options.

The 60-second checklist

1. dig NS example.com @8.8.8.8 +short — empty or NXDOMAIN → registry delegation, call your registrar. Nothing else matters yet.
2. dig A example.com @<delegated-ns> +short — REFUSED → the zone is not on that provider; empty → the record is missing.
3. curl -sI https://example.com — TLS error or platform 404 → the hostname is not bound, or the certificate has not been issued.
4. curl -s -o /dev/null -w '%{http_code}\n' https://example.com/ — 404 with layers 1–3 healthy → nothing deployed; run your deploy.
5. Whatever the answer, check it again in 30 minutes from somewhere that is not your laptop — or let something else do it every 30 minutes forever.

Is your domain actually healthy? Check all four layers