DNS failures are one of the most common causes of website downtime — and one of the most frequently misattributed. When a DNS issue hits, users see connection errors, "server not found" messages, or timeouts. They report the website as down. The website's servers are running fine. The application logs show nothing. The internal uptime monitor — checking from inside the same network — shows all green.
This is why DNS monitoring matters, and why it must run from external locations.
What Is DNS Monitoring?
DNS monitoring is the practice of continuously verifying that your domain's DNS records resolve correctly from external locations. A DNS monitor makes real DNS queries — the same kind a user's browser makes — and alerts you when:
- A domain fails to resolve (NXDOMAIN or timeout)
- A record returns an unexpected value
- Resolution takes longer than expected
- DNS propagation has not completed after a change
DNS monitoring is distinct from uptime monitoring, though both are necessary. An HTTP uptime monitor can only check a URL if DNS resolves first. A DNS monitor checks the resolution layer directly.
Types of DNS Failures
NXDOMAIN (Non-Existent Domain)
The DNS server confirms that the queried domain or record does not exist. Common causes:
- Domain registration expired
- DNS record accidentally deleted
- Misconfigured DNS zone after a migration
- Typo in a DNS record update
NXDOMAIN responses are definitive — the DNS server is working, but the record is gone.
DNS Timeout
The query is sent but no response is received within the timeout period. Common causes:
- DNS server is down or unreachable
- Network routing issue between the resolver and authoritative nameserver
- Firewall blocking port 53 (DNS)
- DDoS attack against the authoritative nameserver
Timeouts are harder to diagnose because they look the same whether the problem is the DNS server, the network, or the resolver.
Wrong Record Value
The domain resolves — but to the wrong IP address or target. This happens after:
- A migration where old records were not updated
- A CDN or cloud provider change where the CNAME still points to the old endpoint
- Accidental DNS record modification
- DNS cache poisoning (rare but serious)
Wrong record failures are particularly insidious because the DNS monitor "succeeds" (the domain resolved) but users reach the wrong server. Value-checking monitors catch this.
Propagation Delays
DNS changes do not take effect instantly. After updating a record, the old value persists in caches globally for up to the TTL (Time To Live) of the previous record. During this window, some users see the new record while others see the old one — inconsistent behaviour that's difficult to debug without external multi-location DNS checks.
Why DNS Issues Look Like Downtime (But Aren't Caught by Standard Monitors)
Most uptime monitors check HTTP endpoints — they make an HTTP request and verify the response. But HTTP depends on DNS. If DNS fails, the HTTP request never connects to a server.
The result: an HTTP uptime monitor fires a "site down" alert, but your servers are healthy. The alert is correct (users can't reach the site), but the cause diagnosis is wrong (the server is not the problem; DNS is).
Worse, if your monitoring infrastructure shares DNS with the monitored service — for example, both run behind the same authoritative nameserver — a DNS failure affecting that nameserver may prevent your monitor from working too. External, independent DNS monitoring bypasses this single point of failure.
DNS Propagation Monitoring
When you change a DNS record, you need to know when the change has propagated to major resolvers worldwide. DNS propagation monitoring checks your record from multiple geographic locations and reports what value each region sees. This helps you:
- Confirm a migration is complete before decommissioning the old server
- Identify regions where the old record is still cached
- Estimate when full propagation will complete based on observed TTL drain
Without propagation monitoring, you're guessing — and premature decommissioning of old infrastructure during a DNS migration is a well-documented cause of outages.
Setting Up DNS Monitoring in Vigilmon
Vigilmon includes DNS monitoring alongside HTTP, TCP, and SSL checks.
To add a DNS monitor:
- Log in to your Vigilmon dashboard
- Click Add Monitor and select DNS
- Enter the domain to monitor (e.g.,
example.com) - Select the record type: A, AAAA, CNAME, MX, TXT
- Optionally enter the expected value — Vigilmon will alert if the resolved value changes
- Set your check interval (1 minute on Pro; 5 minutes on free)
- Add notification channels: email, Slack, webhook, PagerDuty
Vigilmon checks DNS from multiple regions simultaneously. If a DNS failure is only visible from certain geographic locations — common during partial propagation or regional routing issues — Vigilmon's multi-region probes surface it where a single-location monitor would not.
DNS Monitoring Best Practices
Monitor critical records only. Focus on records that affect user-facing services: your primary domain A record, MX records (mail delivery), and any CNAME records used by critical subdomains like api., app., or www..
Set expected values for stability. If your A record should always resolve to a specific IP, configure that expected value in your DNS monitor. An unexpected change — even to another valid IP — warrants investigation.
Keep TTLs low before planned changes. If you're planning a DNS migration, lower the TTL of the relevant record 24–48 hours in advance. This reduces cache duration and makes propagation faster when you make the change.
Alert on both failure and unexpected change. DNS failures are urgent; unexpected record changes are security-relevant. Both deserve notifications.
Check from multiple locations. A DNS failure that only affects users in one region still affects those users. Multi-region DNS monitoring surfaces geographically partial failures that single-point checks miss.
What Vigilmon DNS Monitoring Covers
| Check type | What it detects | |---|---| | Resolution failure | NXDOMAIN, timeout, server error | | Record value change | Unexpected IP, CNAME target, or MX host | | Multi-region checks | Regional propagation and partial failures | | Alert channels | Email, Slack, webhook, PagerDuty |
DNS is the foundation everything else depends on. Monitor it explicitly — don't rely on HTTP checks to catch DNS failures indirectly.
Add DNS monitoring to your Vigilmon account — free tier includes DNS monitors with 5-minute check intervals.