DNS Monitoring: What to Track, Why It Breaks, and How to Set It Up

Every request your application serves starts with a DNS lookup. If that lookup fails — or returns the wrong IP — your perfectly healthy server is unreachable. The database is fine. The load balancer is fine. But users see a blank page because a record expired, a zone file has a typo, or a resolver is returning stale data.

Most outages traced to "DNS issues" were detectable hours before users noticed. The record was already wrong. Nobody was checking.

This guide covers what DNS monitoring tracks, why DNS breaks in production, the types of checks that catch real problems, and how to set it up with automated assertions.

What DNS monitoring tracks

DNS monitoring verifies that your domain's DNS infrastructure is healthy across five dimensions.

Resolution success. Can the domain be resolved at all? An NXDOMAIN response or a SERVFAIL means the domain is effectively offline for anyone whose cache has expired. This is the baseline — if resolution fails, nothing else matters.

Response time. A healthy DNS lookup completes in under 50 ms. When resolution crosses 200 ms, it adds perceptible latency to every new connection. Slow DNS is slow everything: every HTTPS handshake, every API call, every page load starts with a lookup. For a deeper dive into diagnosing resolution latency, see How to Fix Slow DNS Lookup.

Record accuracy. The resolved values need to be correct, not just present. An A record pointing to a decommissioned IP, a CNAME targeting a deleted CDN distribution, or a missing MX record silently breaks traffic routing, email delivery, or TLS certificate validation. Accuracy checks verify that A/AAAA records match expected IPs, CNAME records point to the right targets, and TXT records contain the correct SPF, DKIM, and domain verification strings.

TTL health. Time-to-live values control how long resolvers cache a record. A TTL that's too low (under 60 seconds) forces constant re-resolution, creating unnecessary load on authoritative servers and adding latency. A TTL that's too high (over 86,400 seconds) means changes take a day or more to propagate — dangerous during a migration or an incident. Monitoring TTL drift catches both extremes before they cause problems.

Propagation consistency. A record change that's visible in us-east might still be stale in eu-west for hours, depending on TTL and resolver cache behavior. Multi-region DNS checks detect propagation failures that single-location monitoring misses entirely.

Why DNS breaks

DNS failures rarely look like DNS failures. They look like "the site is down" or "email stopped arriving" or "the CDN is serving the old version." Here are the actual root causes.

Registrar expiry. The domain registration lapses because the renewal credit card expired. The registrar points the nameservers to a parking page. Every record disappears. This happens to large companies more often than anyone admits.

Zone file typos. A missing trailing dot on a CNAME target, a transposed octet in an A record, or a malformed SPF string in a TXT record. The change passes the registrar's syntax check but breaks resolution for specific record types.

TTL misconfiguration. Setting TTL to 60 seconds before a migration (to speed propagation) and forgetting to raise it afterward creates a thundering herd — every resolver re-queries your authoritative server every minute instead of every hour. Conversely, a 24-hour TTL on a record you're about to change means the old value persists in caches long after you've updated it.

DNS hijacking. An attacker modifies DNS responses — through cache poisoning, BGP hijacking, or compromised registrar credentials — to redirect traffic to a server they control. Without record-value assertions, you won't know until users report seeing a different site. Cloudflare's DNSSEC documentation covers how DNSSEC validation protects against some of these vectors, but DNSSEC misconfiguration is itself a common source of outages.

Provider outages. Your authoritative DNS provider has an incident. If you run a single-provider setup with no secondary, resolution fails for every domain hosted there.

Types of DNS checks

DNS monitoring maps to four categories, each catching a different failure class.

Resolution checks

The most basic assertion: does the domain resolve? A dns_resolves check queries the domain and passes if it gets a valid answer — no NXDOMAIN, no TIMEOUT, no SERVFAIL. This catches expired domains, deleted zones, and authoritative server outages.

Performance checks

DNS response time directly affects connection setup latency. A dns_response_time assertion fails when resolution exceeds a threshold (e.g., 500 ms), catching overloaded resolvers, network path degradation, or authoritative server issues before they compound into visible user-facing slowness. A dns_response_time_warn variant produces a warning instead of a failure for softer thresholds.

Accuracy checks

Record-value assertions verify that DNS returns what you expect:

• IP matching (dns_expected_ips) — A/AAAA records resolve to addresses in your configured allow-list. Catches migrations where old IPs linger and hijacking where IPs change without authorization.
• CNAME verification (dns_expected_cname) — CNAME records point to the expected target. Critical for CDN configurations where a wrong CNAME means serving from the wrong origin.
• TXT validation (dns_txt_contains) — TXT records contain the correct SPF, DKIM, or domain verification strings. A broken SPF record means your email gets flagged as spam.
• Exact match (dns_record_equals) and substring match (dns_record_contains) — verify any record type against an expected value.
• Record count (dns_min_answers, dns_max_answers) — verify records haven't been silently deleted or duplicated. A domain that should have two A records for failover dropping to one is a signal, even though DNS still "works."

Health checks

TTL assertions monitor cache hygiene. dns_ttl_low warns when any record's TTL drops below a floor (catching the "forgot to raise TTL after migration" pattern), while dns_ttl_high warns when TTL exceeds a ceiling (catching stale-cache risk before a planned change).

Multi-region DNS monitoring

DNS propagation is not instant. When you update a record, the old value persists in every resolver's cache until its TTL expires. A record change at 14:00 UTC with a 3,600-second TTL won't be fully propagated until 15:00 UTC — and that's the optimistic case. Some resolvers ignore TTL or cap it at their own maximum.

Running DNS checks from a single location tells you whether that resolver sees the correct value. It says nothing about what users in other regions see. Multi-region monitoring catches the scenarios that actually cause user-facing incidents: a propagation failure that affects Frankfurt but not Virginia, a geo-DNS rule returning wrong IPs for Asian resolvers, or a CDN CNAME that's correct in one region and stale in another.

Setting up DNS monitoring

DevHelm's DNS monitor type supports stacking multiple assertions on a single check, so you can verify resolution, performance, accuracy, and TTL health in one monitor running from multiple regions.

YAML configuration

A monitoring-as-code configuration covering the most common assertions:

monitors:
  - name: "Production DNS - example.com"
    type: dns
    target: example.com
    frequency_seconds: 300
    regions:
      - us-east
      - eu-west
      - ap-southeast
    assertions:
      - type: dns_resolves
      - type: dns_response_time
        max_ms: 500
      - type: dns_expected_ips
        values:
          - "203.0.113.10"
          - "203.0.113.11"
      - type: dns_ttl_low
        min_ttl: 120
      - type: dns_ttl_high
        max_ttl: 43200

CLI

Create the same monitor from the command line:

devhelm monitor create \
  --type dns \
  --target example.com \
  --frequency 300 \
  --region us-east --region eu-west --region ap-southeast \
  --assertion dns_resolves \
  --assertion "dns_response_time<500" \
  --assertion "dns_expected_ips=203.0.113.10,203.0.113.11" \
  --assertion "dns_ttl_low>120" \
  --assertion "dns_ttl_high<43200"

Common configurations

Domain migration monitoring. Before cutting DNS to a new provider, add dns_expected_ips with the new IP addresses and run checks from all regions. Once every region returns the new IPs consistently, the migration is complete.

Email deliverability. Monitor your SPF and DKIM records to catch silent breakage:

devhelm monitor create \
  --type dns \
  --target example.com \
  --assertion dns_resolves \
  --assertion "dns_txt_contains=v=spf1" \
  --assertion "dns_min_answers:mx>=1"

CDN CNAME verification. Verify that your CDN CNAME hasn't drifted:

devhelm monitor create \
  --type dns \
  --target cdn.example.com \
  --assertion "dns_expected_cname=d1234.cloudfront.net"

When DNS monitoring fires

When an alert triggers, the assertion type tells you where to look:

• dns_resolves fails — check authoritative nameserver health, domain registration status, and zone file presence. Run dig +trace example.com to find where the resolution chain breaks.
• dns_response_time exceeds threshold — compare response times across resolvers. If slow from all regions, the authoritative server is overloaded or rate-limiting. If slow from one region, it's a network path issue.
• dns_expected_ips mismatch — verify the zone file. If the IP is one you don't recognize, investigate immediately — this is a hijacking signal.
• dns_ttl_low fires — someone set a low TTL during a migration and forgot to raise it. Update the TTL in your DNS provider.
• dns_txt_contains fails — check whether a recent zone change removed or modified your SPF/DKIM records. Email deliverability may already be degraded.

A well-configured DNS monitor with stacked assertions turns these from "something feels off" into a specific, actionable alert within minutes — not hours after users start complaining. For more on building an API monitoring layer alongside DNS checks, see our guide on the tools developers actually use.

---

DevHelm's DNS monitors check resolution, response time, record values, and TTL health from multiple regions — catching propagation failures and hijacking before users notice. Start at app.devhelm.io, free for your first 50 monitors.

---

Originally published on DevHelm.