The operational problem with DNS
DNS issues masquerade as outages. The site is up, the origin is healthy, the cert is valid — but users get connection errors because their resolver returned the wrong answer, an old answer, or no answer at all. Without DNS monitoring you spend the first thirty minutes of every incident proving it isn't DNS. With it, you know in one poll.
The records worth monitoring
- A / AAAA — the foundation. Alert if the value changes unexpectedly.
- MX — email-dependent businesses lose money silently when MX records drift.
- CNAME — third-party services (CDNs, status pages, marketing platforms) frequently change their underlying targets.
- NS — nameserver delegation. A change here is almost always either intentional or catastrophic.
- TXT (SPF, DKIM, DMARC) — broken records here don't bring the site down, they quietly destroy email deliverability.
A calm DNS troubleshooting workflow
- Run a DoH lookup with the tool above. Confirm the record exists and matches expectations.
- If the value is wrong, check the registrar — a recent change may not have propagated yet.
- If the value is correct but users complain, the issue is downstream (their resolver, ISP cache, or local DNS).
- If the lookup itself fails, check your nameservers directly via the NS record path.
- Save the hostname as a recurring DNS monitor so the next drift is caught automatically.
Pairing DNS monitoring with uptime
Uptime tells you the site is unreachable. DNS monitoring tells you why. Running them side by side reduces mean-time-to-diagnosis from twenty minutes to one — and that's true whether you're a one-person team or a 50-person operations group.