"DNS Monitoring: Why Your Site Can Be Down Even When Your Server Is Up"

Your server is humming along, CPU at 5%, all services green. But users are seeing "site can't be reached." You check the logs — nothing. You curl the IP directly — it responds instantly.

The problem isn't your server. It's DNS.

How DNS failures cause invisible outages

Every time someone types your domain into a browser, their device asks a DNS server to translate that name into an IP address. If that translation fails, the browser can't connect — and it doesn't matter that your server is perfectly healthy.

DNS failures are invisible to traditional HTTP monitoring because most uptime monitors resolve your domain once and connect directly. If they already have the IP cached, they'll report "up" while real users who can't resolve the domain see nothing but an error page.

Common DNS failure scenarios:

Expired domain — you forgot to renew and the registrar stopped serving records
Misconfigured nameservers — you migrated DNS providers but didn't update the NS delegation at your registrar
TTL-related propagation delays — you changed an A record but the old IP is cached for hours across the internet
DNS provider outage — even major providers like Cloudflare, Route 53, and Google Cloud DNS have had outages
Deleted or overwritten records — someone on your team accidentally removed the A record during a cleanup

The TTL trap

DNS records have a TTL (Time To Live) that tells resolvers how long to cache the result. If your A record has a TTL of 3600 (one hour), DNS resolvers worldwide will cache that record for up to an hour.

This means:

If you change an IP, some users will hit the old address for up to an hour
If you delete a record, cached copies keep working — then suddenly stop
If you lower TTL after an incident, it's too late — resolvers already cached the old value

The fix: always lower your TTL before making DNS changes. Set it to 60–300 seconds at least a day in advance. After the change propagates, you can raise it back.

What DNS monitoring actually checks

A DNS monitor queries your domain's records at regular intervals and verifies the response matches what you expect. Unlike HTTP monitoring, it catches problems at the resolution layer before a connection is even attempted.

A good DNS monitor verifies:

Record existence — the A, AAAA, CNAME, or MX record actually returns a result
Record value — the IP address or target matches what you configured
Response time — DNS resolution is fast (typically under 100ms)
Multiple record types — A records for your site, MX records for email, TXT records for SPF/DKIM

Real-world DNS disasters

DNS problems hit everyone. Some examples:

Cloudflare (2022) — A misconfigured BGP announcement made Cloudflare's DNS unreachable for millions of websites. Servers were running fine. DNS was dead.

Microsoft 365 (2023) — A DNS configuration error made outlook.com and related services unreachable for hours. The underlying infrastructure was healthy.

Squarespace/Google Domains (2024) — After Google sold its domain registrar business to Squarespace, some domains temporarily lost DNS resolution during the migration.

In every case, the servers were up. The DNS was the single point of failure.

HTTP monitoring vs. DNS monitoring

HTTP monitors answer: "Can a user load this page?"

DNS monitors answer: "Can a user even find this server?"

They're complementary. HTTP monitoring catches application errors, SSL problems, and performance issues. DNS monitoring catches resolution failures, wrong records, and propagation problems.

Check type	What it catches	What it misses
HTTP only	Server errors, slow responses, SSL issues	DNS failures (if IP is cached)
DNS only	Missing records, wrong IPs, slow resolution	Application errors, SSL problems
Both	Everything	Nothing significant

For any site that matters, run both.

How to set up DNS monitoring

With PoppaPing, you can add a DNS monitor in under a minute:

Create a new monitor and select "DNS" as the type
Enter your domain (e.g., example.com)
Choose the record type — A for website IP, MX for email routing, CNAME for aliases, TXT for SPF/DKIM
Set the expected value — the IP address or target you expect to see (optional — leave blank to just check the record exists)
Pick a check interval — every 1–5 minutes depending on how critical the domain is

When the DNS response changes or disappears, you'll get alerted through whatever channels you've configured — email, Slack, Discord, Telegram, webhooks, or PagerDuty.

DNS monitoring checklist

If you're responsible for a production domain, monitor these:

A/AAAA records for your main domain and www subdomain
MX records if you receive email on that domain (broken MX = silently lost emails)
CNAME records for CDN-fronted subdomains (api.example.com, cdn.example.com)
TXT records for SPF and DKIM (changes here can send your emails to spam)
NS records for the domain itself (catches registrar/nameserver misconfiguration)

Set expected values where possible. Monitoring that a record exists is good. Monitoring that it returns the correct value is better.

Don't let DNS be your blind spot

Most teams only monitor HTTP. They find out about DNS problems from users — sometimes hours after the issue started. By then, email might have bounced, search crawlers might have flagged your site as unreachable, and customers might have found a competitor.

DNS monitoring is cheap insurance. Add it to every domain you care about, and you'll catch problems at the layer where they actually start.