Uptime
DNS check
DNS check is a probe that asks a resolver for a record and confirms the answer is right. A site can have a healthy origin and still be down because its name stopped resolving.
How it is measured
Query A, AAAA, CNAME, MX, and NS records against the authoritative nameservers and a public resolver such as 1.1.1.1. Pass when the response arrives in under 500 ms and the answer matches the expected value or set.
Check each authoritative server separately and compare serial numbers on the SOA. Record the TTL too: a 24-hour TTL means a wrong record lingers for a day.
Worked example
A bakery's WordPress site moves from one registrar to another on Tuesday. The new zone lacks the www CNAME. The DNS check queries www every minute and expects 203.0.113.40. At 09:12 it gets NXDOMAIN from ns2 and the correct answer from ns1.
Half of visitors resolved fine and half got a browser error, which an HTTP check run from one office would have shown as green. The record was added at 09:31, and caches cleared over the next 30 minutes given a 1800-second TTL.
How it differs
DNS check tests name resolution. HTTP check tests that the server responds after the name resolves. A DNS check excludes status codes and page content. An HTTP check excludes which nameserver gave the answer and can hide partial resolution failures behind a cached result.
Common errors
Checking only through the local resolver cache. Testing one nameserver. Ignoring MX records and then losing mail. Letting domain registration expire unwatched. Not alerting on an unexpected change to a record, which can mean hijack.
In practice
Add a DNS check for the apex, www, and MX of each domain, aimed at all authoritative nameservers. Alert on a changed value as well as a missing one. Put registrar expiry dates on the same calendar as certificate expiry.