What Is Domain Monitoring? Expiry, DNS, and Resolution Checks Explained
Domain monitoring is the continuous automated checking of a domain's registration status, DNS configuration, and resolution behavior so you learn about expiry, hijacking, or resolution failure before users do. It applies to any organization that depends on a domain resolving correctly — and it becomes essential once you hold more than a handful of domains, since manual WHOIS checks cannot catch a nameserver change that happens at 3 a.m.
It is not the same as uptime monitoring. Uptime monitoring asks "is my server responding?" Domain monitoring asks "does my name still point to that server, and do I still own the name?" A site can be perfectly healthy at the origin while the domain is one day from expiry or its DNS records have been rewritten.
What domain monitoring actually watches
| Layer | What is checked | Failure it catches |
|---|---|---|
| Registration | Expiry date, registrar lock (clientTransferProhibited), registrant/contact changes | Lapsed renewal, unauthorized transfer, ownership change |
| WHOIS/RDAP | Registrant, admin, tech contacts; nameserver delegation | Silent registrant edits, delegation hijack |
| DNS configuration | Record set (A, AAAA, CNAME, MX, TXT, NS), TTL, DNSSEC status | Record tampering, accidental deletion, missing AAAA for IPv6 |
| Resolution | Query success rate and answer correctness from multiple locations | NXDOMAIN, SERVFAIL, wrong IP returned, regional resolution failure |
| Certificate (adjacent) | TLS expiry and chain validity | Browser warnings that look like domain problems |
The distinction matters because each layer fails differently. An expired registration takes the whole name offline. A tampered A record redirects traffic while the domain remains valid. A missing AAAA record breaks only IPv6 visitors — a failure mode that is easy to miss if your probes are IPv4-only.
How the checks work technically
A monitoring service runs scheduled queries against your domain from distributed probe nodes and compares the answers to an expected baseline.
- Recursive vs. authoritative queries. A recursive query (through a public resolver) shows what a typical user sees, including cached answers. An authoritative query (directly to your nameservers) shows the current zone data. Running both separates "the zone is wrong" from "a resolver is serving a stale answer."
- Probe nodes. Checks from several geographic and network locations catch regional failures and split-horizon DNS problems that a single vantage point would report as healthy.
- Check frequency. Common intervals range from one minute to one hour. Higher frequency shortens detection time but increases query volume; low-TTL records need more frequent checks to be meaningful.
- Alert thresholds. Rather than alerting on a single failed query, most setups require N consecutive failures before firing. This suppresses transient blips at the cost of a few minutes of detection delay.
For a domain portfolio, prioritize by blast radius: customer-facing and revenue domains first, then email (MX) domains, then redirect and defensive registrations. Route alerts by ownership — registration alerts to whoever controls the registrar account, DNS alerts to the team that manages the zone — so the first responder can actually act.
Common failure signals and false positives
Not every alert means an attack. Before escalating, rule out these:
- Cached DNS and TTL. After a legitimate record change, resolvers keep serving the old answer until TTL expires. A "wrong IP" alert immediately after a planned change is expected, not an incident.
- Registrar grace periods. Many registrars allow renewal for a period after the stated expiry date, and some auto-renew. An expiry alert does not always mean the domain is already down — but treat it as urgent, because the grace window is not guaranteed.
- Propagation delay. New records take time to appear across all nodes; a partial mismatch during the first minutes is normal.
- Probe-side issues. A single node failing while others succeed usually points to that node's network, not your domain.
What to do when an alert fires
- Verify from multiple locations. Query the domain through at least two independent public resolvers and one authoritative nameserver. This tells you whether the problem is global or resolver-specific.
- Check the registrar console. Confirm expiry date, lock status, and that no unauthorized contact or nameserver changes were made.
- Check the DNS console. Compare live records against your expected baseline; look for records you did not change.
- Escalate by type. Registration or ownership anomalies go to the registrar and, if a transfer is in progress, trigger a transfer lock dispute. DNS tampering goes to your DNS provider and security team. Resolution failures with correct records point to the provider or network path.
- Document the timeline. Detection time, verification steps, and resolution feed back into your check frequency and thresholds.
A monitoring tool such as 国科云's cloud probing (云拨测) is described as providing DNS plus application full-link visibility for business continuity, which illustrates the combined approach: watch the name and the service behind it together, because users experience them as one thing.