DNS Monitoring: Why Your Domain's Health Matters

Most uptime monitoring works by making an HTTP request to a URL and checking the response. That works well for detecting when your app crashes or your server goes down. But it misses a class of failures that are arguably worse: DNS problems.

When DNS fails, it's not just one URL that breaks. It's your entire domain. Your website, your API, your email — everything that lives under yourdomain.com becomes unreachable simultaneously. And because DNS failures often manifest as timeouts rather than error responses, they can be harder to diagnose than a straightforward HTTP 500.

---

What is DNS monitoring?

DNS monitoring checks that your domain's DNS records resolve correctly and consistently. Instead of making an HTTP request to your URL, a DNS monitor queries the DNS system directly — asking "what IP address does this domain resolve to?" — and verifies that the answer matches what you expect.

A DNS monitor catches problems that HTTP monitoring doesn't:

• Your DNS records were accidentally changed or deleted
• Your domain expired and DNS stopped resolving
• A DNS propagation issue is causing some users to reach the wrong server
• Your DNS provider is having an outage
• A subdomain was misconfigured during a deployment
• DNS hijacking — your records were changed maliciously

---

DNS record types worth monitoring

A and AAAA records

Your primary A record maps your domain (yourdomain.com) to an IPv4 address. AAAA records do the same for IPv6. These are the most fundamental records — if they're wrong, your domain doesn't resolve at all.

What to monitor: verify the A record resolves to your expected IP address. If it changes unexpectedly — pointing to a different IP — that's an alert-worthy event. It could be a legitimate infrastructure change you forgot about, or it could be something worse.

CNAME records

CNAME records alias one domain to another. Common uses: www pointing to your apex domain, status pointing to your status page provider, api pointing to your API gateway.

CNAME breakage is common during infrastructure migrations. When you move from one CDN to another, update a load balancer, or change hosting providers, the CNAME needs to be updated. Monitoring catches the gap between "old record" and "new record."

MX records

MX records control where email for your domain is delivered. A misconfigured or missing MX record means inbound email silently disappears — senders get no bounce, your mail just doesn't arrive.

This is a particularly dangerous failure mode because it's invisible. Your website might be working fine while your email has been silently broken for days. Customer inquiries, password resets, and transaction emails from external services all stop arriving without any obvious indication.

TXT records

TXT records are used for domain ownership verification (Google Search Console, email providers), SPF records (which servers can send email on your behalf), and DKIM (email authentication). If your SPF or DKIM records are misconfigured, your outgoing emails start landing in spam folders — often without any obvious error.

---

How DNS failures happen in practice

Most DNS failures aren't attacks. They're accidents. The most common causes:

Domain expiry

Domain registrations need to be renewed annually (or multi-year). When a domain expires, the registrar removes its DNS records and the domain stops resolving. This happens to established companies more often than you'd think — the person who registered the domain left, the renewal email went to a dead inbox, or auto-renew failed because a credit card expired.

DNS monitoring with expiry alerting gives you advance warning. PingBase monitors check not just whether DNS resolves, but can alert you before records change unexpectedly.

Deployment mistakes

Infrastructure-as-code tools like Terraform and Pulumi manage DNS records alongside other infrastructure. A misconfigured deployment can overwrite, delete, or point records at the wrong destination. Without DNS monitoring, you won't know until users start reporting that your site is unreachable.

DNS provider outages

Your DNS provider is a single point of failure for your entire domain. When Dyn was attacked in 2016, major websites including Twitter, Reddit, and GitHub became unreachable for hours — not because those companies' servers were down, but because their DNS provider was under a DDoS attack.

DNS monitoring from multiple regions detects when your domain stops resolving from specific geographic areas — often the first sign of a DNS provider issue.

TTL and propagation issues

When you change a DNS record, the change doesn't propagate instantly. The old record is cached by DNS resolvers worldwide for up to the TTL (time to live) value of the record — sometimes hours. During propagation, some users see the old record and some see the new one.

This creates difficult debugging scenarios: your site works fine from your office (cached on your local resolver) but is broken for customers in other regions (they're hitting an expired cache of the old record). DNS monitoring from multiple geographic locations surfaces this pattern.

---

How PingBase DNS monitoring works

PingBase added DNS monitoring as a first-class monitor type alongside HTTP, heartbeat, and SSL monitoring. Setting up a DNS monitor takes about 30 seconds:

1. Choose "DNS" as the monitor type
2. Enter your domain or subdomain
3. Select the record type (A, AAAA, CNAME, MX, TXT)
4. Optionally: enter the expected value — PingBase alerts you if the resolved value changes from what you recorded at setup

PingBase checks DNS from multiple locations. If your domain resolves correctly in Europe but not in North America, that's reported as a regional failure — useful for catching propagation issues and provider problems before they affect all your users.

DNS monitors appear on your status page alongside HTTP monitors. If your DNS is down, your status page reflects it — even though the DNS failure would prevent users from reaching your main site, the status page is served from Cloudflare's edge and remains accessible.

---

What to monitor

A practical DNS monitoring setup for a typical SaaS or web app:

Add DNS monitors for any subdomain that's critical to your product. Don't forget subdomains that are less visible but high-impact — mail delivery subdomains, webhook endpoints, CDN origins.

---

DNS monitoring vs HTTP monitoring: use both

DNS monitoring and HTTP monitoring are complementary, not alternatives. HTTP monitoring confirms that your application is running and returning the right responses. DNS monitoring confirms that users can reach your application in the first place.

A complete monitoring setup has both. HTTP monitors catch application-level failures — crashes, errors, slow responses. DNS monitors catch infrastructure-level failures — records changed, domain expired, provider down. Together they give you coverage of the full stack from domain resolution to application response.