Why DNS deserves its own monitor
Every request to your service starts with a DNS lookup, which makes DNS a single point of failure that sits in front of everything else. When a record is wrong, expired, or hijacked, your servers can be perfectly healthy while users are sent to the wrong place — or nowhere at all. Because DNS answers are cached across resolvers with their own time-to-live, these problems can also appear intermittently, hitting some users and not others.
An HTTP check tells you the site is unreachable; a DNS monitor tells you why, by verifying the records that everything else depends on.
Which records to watch
Monitor the records that route your traffic and protect your domain. A and AAAA records point your hostnames at IP addresses; CNAME records alias one name to another and often point at a CDN or SaaS vendor; MX records direct your email; and TXT records carry SPF, DKIM, and domain-verification values that, if lost, silently break mail delivery and third-party integrations. PageLantern DNS monitoring verifies that a record resolves and matches the value you expect, so a change is caught rather than assumed.
Watch the records you rarely touch as much as the ones you do — the dangerous change is usually the one nobody remembered was load-bearing.
Catching propagation drift and hijacks
DNS monitoring compares what actually resolves against what you expect. That catches three classes of problem: a change that has not finished propagating, unintended drift where a record was edited or removed by mistake, and hostile changes where records are hijacked to point at an attacker. Because the check asserts on the expected value, any of these turns into an alert instead of a mystery.
Pair this with domain-expiry monitoring. A lapsed domain registration takes down DNS, web, and email at once, and it is one of the most preventable outages there is.
Reachability, not just resolution
Resolving to the right address is necessary but not sufficient — the address also has to accept connections. A TCP check confirms that a port is open and responding, which catches firewall changes, crashed services, and misconfigured load balancers that a name lookup alone would miss. Watching DNS resolution and raw port reachability together covers both "am I pointed at the right place" and "is that place actually listening".
A DNS monitoring checklist
Record the expected value of every load-bearing record — A, AAAA, CNAME, MX, and the TXT records for mail and verification. Monitor each one against that expected value. Add domain-registration expiry with generous lead time. Add a TCP reachability check for critical ports. Alert on any drift, and review the expected values whenever you make an intentional change so the monitor stays truthful.