DNS monitoring vs uptime monitoring: what each one catches
Uptime monitoring checks if your site responds. DNS monitoring checks if your records are what you set. What each catches, what each misses, and why both.
Uptime monitoring checks whether your service responds. DNS monitoring checks whether your DNS configuration is still the one you set. The first watches the symptom: a page that loads, an endpoint that returns 200. The second watches one of the sneakiest causes of outages and hijacks: records that changed when nobody meant to change them. The overlap between the two is small. A hijacked A record can leave your uptime dashboard green while traffic flows to someone else's server, and a crashed application can leave your DNS pristine while customers stare at an error page. Teams whose business runs on their domain end up with both, each covering its own perimeter.
What each type of monitoring does
Uptime monitoring sends periodic HTTP requests or pings to your endpoints, usually every minute or so, and alerts when a request times out or returns an error code. It answers one question: is the service reachable right now?
DNS monitoring takes periodic snapshots of your DNS records (A, AAAA, MX, TXT, CNAME, NS) and compares each snapshot to the previous one. It alerts on any difference. It answers a different question: is my configuration still what I intended?
| Uptime monitoring | DNS monitoring | |
|---|---|---|
| What is checked | HTTP response, ping, response time | DNS record values |
| Typical frequency | Every 30 seconds to 5 minutes | Once or a few times per day |
| Alert trigger | Timeout, error code, slow response | Any record that differs from the last snapshot |
| Protects against | Server crashes, app errors, expired certificates | Hijacked records, broken email config, silent drift |
| Blind spot | Changes that keep the site responding | Failures that leave records untouched |
The frequency gap is not a weakness on either side. Availability changes by the second, so uptime checks run constantly. DNS records change rarely, so a daily diff catches almost every unauthorized or accidental edit while it is still recent enough to trace.
What uptime monitoring does not see
Three incident types slip straight past an availability check.
Broken email
A modified MX record or a mangled SPF entry takes down zero web pages. Your site loads, every uptime check passes, and your outbound mail lands in spam or disappears. Nobody pings an MX record. If you rely on email for signups, invoices, or support, monitoring SPF, DKIM, and DMARC records is the only automated way to hear about this before your customers do.
The clean hijack
An attacker who redirects your A record to a server they control has no reason to serve errors. They serve a working site, often a pixel-perfect copy of yours, and harvest credentials or payment details. Every HTTP check returns 200. From the uptime tool's point of view, nothing happened. Only a record-level diff shows that your domain now points somewhere it never pointed before. This is the core scenario behind detecting DNS hijacking.
Configuration drift
Someone on the team deletes a TXT record during a cleanup. A CNAME gets overwritten by an automation script. Nameservers change during a provider migration and nobody documents it. None of this breaks the site today. It surfaces weeks later as a failed domain verification, a dead subdomain, or an email authentication failure, at which point nobody remembers what changed or when. A record diff turns each of these into a dated, specific alert.
What DNS monitoring does not see
The symmetry cuts both ways. A server that crashes, a certificate that expires, an application that starts returning 500s, a database that slows every page to a crawl: your DNS records can be flawless through all of it. Record snapshots say nothing about whether the machine behind the IP address is alive, fast, or serving the right content. That territory belongs to uptime monitoring and application monitoring, and no DNS tool replaces them.
Building both layers
The practical setup is straightforward. Put an uptime monitor on your critical endpoints; there are plenty of solid options, and several are free at small scale. Put DNS monitoring on the domains that carry your production traffic and your email.
Domain Sentinel covers that second layer. It takes daily snapshots of your DNS records, diffs them against the previous day, and emails you when anything changes, for the apex and www by default plus any custom hostnames you add. It also watches the registry side over RDAP: EPP statuses, expiration dates, and declared nameservers, which catches problems at the registrar level before they reach DNS at all.
To be explicit about the boundary: Domain Sentinel does not do uptime monitoring. It sends no pings, makes no HTTP checks, and measures no availability or response times. If your server goes down, a dedicated uptime tool is what tells you, and you should run one alongside it.
Two questions to audit your coverage
If my MX record changed tonight, who would tell me? If my server went down tonight, who would tell me? Answer both honestly. Any answer that amounts to "a customer, eventually" marks the layer you are missing, and each one takes a few minutes to add.
Start with a domain you care about
Look it up for free. If you want alerts when status changes or expiry gets close, create an account. Takes about 30 seconds.