Domain monitoring vs DNS monitoring: what each catches
Domain monitoring and DNS monitoring watch two different layers of the same name. Domain monitoring tracks the registration: who owns the name, when it expires, and where it is registered. DNS monitoring tracks the resolution: which records the name hands out and whether they answer at all. You need both because each one is blind to the failures the other is built to catch.
The names are close enough that they get treated as one "domain health" checkbox, and that is the mistake. They read different data, from different systems, on different schedules. Confusing them leaves a gap exactly where an outage tends to come from.
Two layers of the same name
A working domain depends on two independent things being true at once: the name is still registered to you, and the name resolves to the right place. Those are separate systems with separate failure modes.
| Domain monitoring | DNS monitoring | |
|---|---|---|
| Layer | registration and ownership | resolution |
| Data source | WHOIS or RDAP at the registry | DNS records from the nameservers |
| Answers the question | is the name still ours, and for how long | what does the name point to, and does it respond |
| Typical failure | expired domain, unauthorized transfer | wrong record, broken DNSSEC, propagation gap |
| How often it changes | rarely, on the scale of months or years | often, on every deploy or failover |
That last row drives a difference most write-ups miss. Registration data barely moves, so any change is worth a hard look. DNS records change constantly, so the hard part is telling a real problem apart from a routine deploy. The two layers need different alerting instincts, not the same threshold applied twice.
Both layers sit underneath uptime monitoring, which only begins once the name resolves. An uptime check assumes the domain is registered and the records are correct, then tests the application behind them. When uptime monitoring reports the site as down while the server is plainly healthy, the cause is usually one layer below, in DNS or the registration itself, which makes an uptime alert a symptom rather than a diagnosis. Picking the right check interval is a separate question, covered in how often you should check uptime.
What domain monitoring catches
Domain monitoring reads the registry record and watches the fields that decide whether the name is still yours. The failures it catches are rare and almost always meaningful:
- A renewal that did not happen, before the name lapses into redemption. This is the whole subject of domain expiry monitoring.
- A transfer lock removed, a registrar change, or a registrant rewrite, the trail an unauthorized transfer leaves. That is covered in how to detect domain hijacking early.
- An expiry date that quietly moves, which can mean either a renewal you forgot you set or tampering you did not authorize.
None of this is visible to a DNS check. A domain can resolve perfectly on the morning it expires, and a clean set of DNS records tells you nothing about who now controls the registration.
What DNS monitoring catches
DNS monitoring queries the nameservers and watches what the name actually returns. The failures here are more frequent and often self-inflicted:
- Records pointing at the wrong server after a deploy, a failover, or a fat-fingered edit. The mechanics are in how to detect DNS record changes.
- DNSSEC that breaks and starts returning SERVFAIL, taking the whole name down for validating resolvers.
- Email authentication records (SPF, DMARC, MX) changing and quietly breaking delivery.
- Nameservers that disagree with each other or fail to propagate. The full list of what this layer does and does not cover is in what DNS monitoring catches.
A registration check is silent on all of it. The name can be paid up through 2030 and still hand out a poisoned A record to every visitor.
The nameserver is where the two layers meet
There is one field that lives in both worlds, and it causes most of the confusion: the nameserver. The set of nameservers is recorded twice, once as the delegation at the registry (part of the registration record) and once as the NS records served by the zone itself. For a healthy domain they agree. Here is the same domain seen from both sides:
whois example.com | grep "Name Server"
# Name Server: ELLIOTT.NS.CLOUDFLARE.COM
# Name Server: HERA.NS.CLOUDFLARE.COM
dig example.com NS +short
# hera.ns.cloudflare.com.
# elliott.ns.cloudflare.com.Because the nameserver sits on the boundary, a nameserver change shows up in both layers, which is exactly why it is dangerous. An attacker who repoints your delegation is committing a registration-level change that immediately becomes a resolution-level one: every record under the name is now served by infrastructure they control. Watching only one layer can still miss the moment the two drift apart, when the registry delegation and the live zone stop agreeing. That split has a name, lame delegation, and it produces intermittent failures that are maddening to debug, because the name resolves from some resolvers and not from others.
Which layer catches your outage
The practical question is not which tool is better, it is which one would have caught the specific way your name broke. Mapped out:
| Symptom | Which layer catches it |
|---|---|
| Site and email both vanish on the renewal date | domain |
| Visitors land on the wrong server or a parked page | DNS |
| The name moved to another registrar without you | domain |
| Resolvers return SERVFAIL after a DNSSEC change | DNS |
| Email delivery silently stops | DNS |
| The transfer lock came off overnight | domain |
| The nameservers were replaced | both |
Read the table top to bottom and the conclusion is hard to avoid: neither column is a subset of the other. Running one and skipping the other does not give you partial coverage of the same surface, it gives you full coverage of half the surface and none of the rest.
Where this fits with WebPixie
WebPixie runs both layers from one place. Domain monitoring watches the registry record (WHOIS or RDAP, expiry, registrar and status-flag changes), and DNS monitoring watches the resolution layer (record changes across multiple resolvers, DNSSEC, and email authentication). The point of having them together is the nameserver case above, where the answer is "both" and a single dashboard sees the change from each side at once.