DNS Monitoring: The Blind Spot in Your Stack
Your DNS provider had three outages last year. You probably did not notice two of them. Here is why DNS monitoring deserves its own strategy.
The Invisible Dependency
Every request to your application starts with a DNS lookup. If DNS fails, nothing works — but most monitoring setups only check the application layer.
Think about your current monitors. They probably check:
- HTTP status codes
- Response times
- SSL certificates
- Maybe some API endpoints
But what happens when your DNS provider has a partial outage? Your HTTP monitor might see connection timeouts and blame your server, when the real issue is that DNS resolution is failing for half your users.
Real DNS Failures We Have Seen
The Partial Outage
A major DNS provider had an issue with their anycast routing that affected users in Asia-Pacific. European and US users were fine. The company's monitoring (from US-East) showed green across the board while 30% of their global users could not reach the site.
The Propagation Delay
A team migrated their DNS to a new provider. The migration went smoothly — or so they thought. Two days later, they discovered that a subset of ISPs in South America were still resolving to the old provider's nameservers due to aggressive TTL caching by intermediate resolvers.
The DNSSEC Validation Failure
A routine key rotation broke DNSSEC validation. Resolvers that enforced DNSSEC (a growing number) returned SERVFAIL. Resolvers that did not enforce it worked fine. The result: some users could reach the site, others could not, with no clear pattern.
What to Monitor
Resolution Time
Track how long DNS resolution takes from multiple regions. A spike from 20ms to 200ms is a leading indicator of DNS infrastructure problems.
Record Accuracy
Verify that your A, AAAA, CNAME, and MX records resolve to the expected values. Catch unauthorized changes or propagation issues early.
Nameserver Health
Monitor each of your authoritative nameservers independently. If one of four nameservers is down, you might not notice degradation until a second one fails.
DNSSEC Chain Validity
If you use DNSSEC, validate the entire chain of trust regularly. A broken chain will silently block users on validating resolvers.
Setting Up DNS Monitoring
At minimum, check these from at least three regions:
- A record resolution — Does your domain resolve to the correct IP?
- Resolution time — Is DNS getting slower?
- SOA record — Has someone modified your zone without authorization?
If you use DNSSEC, add chain validation checks. If you have MX records, verify those too — email delivery depends on them.
The goal is not to replace your DNS provider's own monitoring. It is to have an independent view that catches issues your provider might not report promptly.
Written by
James Park
Security Engineer. OSCP certified.
Related articles
Cron Job Monitoring: How to Know When Your Scheduled Tasks Fail
Cron jobs fail silently. Backups don't run, reports don't send, data doesn't sync — and nobody notices for days. Here's how heartbeat monitoring fixes that.
Read morePort Monitoring Explained: Protect Your Databases, Mail Servers, and More
Not everything runs on HTTP. Your databases, mail servers, and custom services need monitoring too. Port monitoring catches failures that web checks can't.
Read moreChoosing the Right Check Interval: 30 Seconds vs 5 Minutes Matters More Than You Think
The difference between checking every 30 seconds and every 5 minutes is the difference between catching an outage in under a minute and missing it for up to 10 minutes.
Read more