DNS Monitoring: Catch Record Changes Before They Cause Outages

DNS monitoring is the practice of automatically checking that DNS records for your domains return the expected values and alerting you when they change. Most uptime monitoring catches what happens after a DNS lookup succeeds. DNS monitoring catches failures and changes in the lookup itself.

When your A record points to the wrong IP, your CNAME breaks, or your MX record disappears, your service goes offline from the network layer down. HTTP monitoring sees a timeout or connection refused. DNS monitoring tells you exactly what changed and when.

Why DNS Failures Are Different

An HTTP monitor pinging your API endpoint can only run its check after DNS resolves the domain to an IP. If DNS fails, the HTTP check fails too — but the error is indistinguishable from a server outage, a network issue, or a timeout. The monitoring tool sees a failure; it does not know the root cause is DNS.

DNS monitoring runs separately from HTTP checks. It queries your DNS records directly and compares the response against expected values. When the A record for api.yourdomain.com changes from 203.0.113.42 to 203.0.113.99, DNS monitoring catches that change within the next check interval. HTTP monitoring might not — if the new IP happens to serve a response, the HTTP check passes.

This distinction matters most in three scenarios:

1. Unauthorized DNS changes. DNS hijacking and account compromise can redirect traffic to attacker-controlled servers. HTTP monitoring may not catch this if the attacker's server returns valid HTTP responses.
2. Misconfigured DNS migrations. During a migration (new hosting, new CDN, new IP), DNS records are updated manually. A typo in an IP, a missing record, or a TTL too short or too long causes partial outages that HTTP monitoring shows inconsistently depending on DNS caching state.
3. Expiring or vanished records. Some DNS providers automatically remove records after a certain period. MX records that disappear silently stop email delivery. CNAME records pointing to decommissioned services return NXDOMAIN.

DNS Record Types to Monitor

A and AAAA Records

A records map domain names to IPv4 addresses. AAAA records map to IPv6 addresses. These are the foundational records for any web service.

What to monitor:

• The expected IP address(es)
• Record count (if you use multiple A records for load balancing, monitor that the expected count returns)
• TTL value (unexpectedly low TTL is sometimes a sign of a planned change or an attack)

Alert on: Any change to the IP address, any unexpected record disappearance.

CNAME Records

CNAME records map a subdomain to another domain name. Common uses: pointing app.yourdomain.com to a CDN endpoint, or routing mail.yourdomain.com to an email provider.

What to monitor:

• The expected target hostname
• That the target hostname itself resolves correctly

Alert on: Target hostname change, target hostname stops resolving.

MX Records

MX records route email. If your MX records are wrong or missing, incoming email delivery fails silently for every sender who tries to reach your domain.

What to monitor:

• All expected MX hostnames and their priorities
• That each MX host resolves to a reachable mail server

Alert on: Any MX record change, any MX host going unresolvable.

NS Records

NS records specify the authoritative nameservers for your domain. These change only during DNS provider migrations. An unexpected NS record change is one of the strongest signals of DNS hijacking.

What to monitor:

• The expected nameserver hostnames

Alert on: Any change. NS records almost never change legitimately without advance planning.

TXT Records

TXT records serve multiple purposes: domain verification (Google Search Console, Stripe, etc.), SPF and DKIM email authentication, and DMARC policies.

What to monitor:

• SPF record (if it changes, email from your domain may start failing spam filters)
• DMARC record (changes affect email security policy)
• Verification tokens for critical third-party services

Alert on: SPF or DMARC changes, unexpected additions to TXT records.

The DNS Hijacking Threat

DNS hijacking redirects traffic at the DNS layer. An attacker who gains access to your DNS provider account — through credential theft, a support social engineering attack, or a DNS provider vulnerability — can point your domain to a server they control.

From your HTTP monitoring's perspective, the service appears "up" if the attacker's server returns HTTP responses. Your users, however, are sending their credentials and data to the wrong server.

Specific attack patterns to monitor for:

• A record modification: Your domain now points to a different IP. If you monitor the expected IP value, this triggers an alert within one check interval.
• NS record modification: A new nameserver is added or replaces the existing ones. This gives the attacker full control of DNS for your domain.
• New subdomain creation: A new login.yourdomain.com or secure.yourdomain.com appears that you did not create.

A 2023 Infoblox DNS threat report found that DNS-based attacks are involved in 72% of significant network security incidents. Most of these attacks go undetected for hours because HTTP monitoring does not inspect DNS record values.

DNS Propagation Monitoring

DNS changes propagate through resolver caches worldwide over a period defined by the TTL of the changed record. A record with a 3600-second TTL takes up to an hour to propagate globally after a change. During that window, different users get different DNS responses depending on which resolver they use and whether it has cached the old record.

DNS monitoring from multiple geographic regions lets you observe propagation state:

This view tells you a migration is in progress and which regions still serve old records. Without it, you're guessing why some users report issues and others don't.

SOA Record and TTL Monitoring

The SOA (Start of Authority) record contains your zone's serial number, which increments every time DNS records are updated. Monitoring for SOA serial number changes gives you a lightweight signal that something in your DNS zone changed — even before you know which record.

What to monitor:

• SOA serial number (alert on any increment that wasn't planned)
• TTL values for critical records (unexpectedly low TTL, e.g., a record that normally has 3600s TTL drops to 60s, can indicate an impending change)

Setting Up DNS Monitoring

For each domain you care about, create DNS monitors for:

Check interval: 5 minutes for most DNS records is sufficient. DNS propagates slowly; a 5-minute detection window is fast enough to catch most issues before significant user impact.

For NS record changes and MX record changes, treat alerts as high priority. These failures affect all users and cannot self-resolve.

DNS Monitoring vs. Uptime Monitoring

DNS monitoring and HTTP uptime monitoring complement each other. Neither replaces the other.

Run both. When an HTTP check fails, DNS monitoring tells you whether it's a DNS problem or an application problem — information that cuts diagnosis time from 30 minutes to 2.

Common DNS Monitoring Mistakes

Monitoring only the primary domain. Subdomains often have different DNS records, different TTLs, and different risk profiles. api.yourdomain.com, app.yourdomain.com, and mail.yourdomain.com each need their own monitors.

Ignoring MX records. Email failures are silent from an HTTP monitoring perspective. Your service can appear fully operational while incoming email has been silently bouncing for hours.

Not monitoring NS records. NS record changes are rare — which is exactly why an unexpected change is significant. Monitor them with a simple "alert on any change" rule.

Treating DNS alerts as low priority. A DNS change that isn't caught within minutes can cascade into a full outage. Set DNS alerts to the same priority as uptime alerts.

Frequently Asked Questions

What is DNS monitoring?

DNS monitoring is the automated checking of DNS record values for a domain. A DNS monitoring tool queries your domain's DNS records at regular intervals and compares the response to expected values. When a record changes, disappears, or returns an error, the tool sends an alert. This catches DNS hijacking, misconfigured migrations, and record propagation issues before they cause extended outages.

How is DNS monitoring different from uptime monitoring?

Uptime monitoring sends HTTP requests to your service URL and checks if the application responds. DNS monitoring queries the DNS system directly and validates that your domain's records point where they should. An uptime monitor cannot distinguish a DNS failure from an application failure; a DNS monitor catches changes to your records before they affect HTTP availability.

Which DNS records should I monitor?

At minimum: A records for your main domain and critical subdomains, MX records for email delivery, and NS records for hijacking detection. For complete coverage, add CNAME records for subdomains, TXT records for SPF and DMARC, and SOA serial number monitoring as a change-detection signal.

How quickly does DNS monitoring detect changes?

With a 5-minute check interval, DNS changes are detected within 5 minutes. Most DNS monitoring tools run checks from multiple geographic regions, so you also see propagation state across different resolver locations — useful during planned migrations.

Can DNS monitoring detect DNS hijacking?

Yes. DNS hijacking changes your A record, CNAME, or NS records to attacker-controlled values. A DNS monitor that checks for the expected IP address or nameserver value detects this change within the next check interval. The critical configuration is asserting expected record values, not just checking that the record exists. A record pointing to an attacker's IP still "exists"; only value matching catches the substitution.