How to Monitor DNS Records and Detect Unauthorized Changes

Your DNS records are the foundation of your online presence. If someone changes your A record, swaps your MX records, or hijacks your nameservers, your website disappears — and you might not notice for hours. Unlike a server crash that immediately returns errors, a DNS failure is insidious: your site works perfectly for anyone with cached DNS (including you and your team), while being completely unreachable for new visitors. The longer it takes to detect, the more customers you silently lose. DNS monitoring catches these changes within minutes.

Why DNS Monitoring Matters

DNS changes are silent. A misconfiguration propagates slowly across global resolvers. Depending on TTL values, some users see the old (working) records while others see the new (broken) ones. This makes DNS issues notoriously difficult to diagnose — your monitoring dashboard shows green, your team can load the site, but your support inbox fills with "your site is down" reports from a specific geography or ISP.

Common Scenarios That DNS Monitoring Catches

• Accidental deletion — a team member removes the wrong record during a migration. This is more common than anyone admits, especially when managing dozens of subdomains.
• TTL expiry — a temporary record expires and traffic routes to the wrong server. Common during infrastructure migrations where temporary DNS records are set up and forgotten.
• DNS hijacking — an attacker gains access to your registrar account or exploits a vulnerability to modify nameservers. The attacker can intercept traffic, serve phishing pages, or steal data — all while your server runs normally.
• Registrar issues — your registrar changes records during a domain transfer, or a billing failure causes the registrar to park your domain on a generic landing page.
• CDN misconfiguration — CNAME records pointing to decommissioned CDN endpoints. When you switch CDN providers and forget to update DNS, traffic routes to a dead endpoint.
• Subdomain takeover — a CNAME points to a third-party service you no longer use (a Heroku app, an S3 bucket, a GitHub Pages site). An attacker claims that resource and now controls your subdomain.

Real-World DNS Failures

DNS failures are not theoretical. In 2021, Facebook's BGP misconfiguration made their DNS servers unreachable, taking down Facebook, Instagram, and WhatsApp for over six hours. Cloudflare has had DNS outages that affected millions of websites. Even smaller incidents — a registrar auto-renewal failure at GoDaddy, an accidental zone file deletion at a hosting provider — take sites offline completely.

The reason DNS failures are so damaging is that DNS sits below every other layer of your infrastructure. Your HTTP monitors, your SSL checks, your API monitors — they all depend on DNS resolution working correctly. When DNS breaks, every other monitor may fail simultaneously, flooding your alert channels with noise while the root cause (a single DNS record change) goes unidentified.

Setting Up DNS Monitoring in Monitorion

Creating a DNS monitor takes 30 seconds. Go to Monitors → New Monitor → DNS and configure:

• Domain — the domain name to query (e.g., example.com)
• Record Type — A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, or CAA. Select multiple types to monitor all of them in one monitor.
• Expected Value (optional) — the value you expect the record to resolve to. If set, Monitorion alerts you when the actual value differs. This is the most powerful feature — it does not just check that DNS resolves, it verifies that DNS resolves to the correct target.
• Nameserver (optional) — query a specific nameserver instead of the system default. Useful for verifying propagation or checking authoritative nameservers directly.

What to Monitor

For a typical web application, set up these DNS monitors as a baseline:

Critical Records

1. A record for your apex domain — example.com → your server IP. Set the expected value to your server's IP address. Alert immediately if it changes — this is the most common target for DNS hijacking.
2. CNAME for www — www.example.com → your CDN or load balancer hostname. Critical for traffic routing. A misconfigured CNAME can silently route all www traffic to a dead endpoint.
3. NS records — monitor your nameservers themselves. Changes to NS records indicate a domain transfer or hijacking attempt. This is the earliest possible warning sign of a domain takeover.

Email Records

1. MX records — ensure your email routing stays intact. A wrong MX record means lost emails — not bounced, but routed to someone else's mail server. For businesses that rely on email for customer communication, this is catastrophic.
2. TXT records for SPF — your SPF record authorizes which servers can send email on your behalf. If deleted or modified, your outbound emails start landing in spam folders. Monitor for the presence of your v=spf1 record.
3. TXT records for DKIM — DKIM signing keys published in DNS. If these records disappear, email authentication fails and deliverability drops immediately.

Infrastructure Records

1. API subdomain — api.example.com A or CNAME record. If your API runs on separate infrastructure, monitor its DNS independently.
2. CDN subdomain — cdn.example.com or static.example.com CNAME. Verify it points to your active CDN provider.
3. SRV records — if you use SRV records for service discovery (common with VOIP, XMPP, or custom service meshes), monitor them for unexpected changes.

Advanced DNS Monitoring Strategies

Use expected values on every monitor. Without an expected value, the DNS monitor only checks that the record exists and resolves. With an expected value, it alerts you when the value changes — catching unauthorized modifications instantly. Always set expected values for your A records, CNAME targets, and NS records.

Set up redundant monitoring. DNS results are globally consistent, so multi-region consensus is not needed — but Monitorion automatically retries failed DNS checks on a different worker, ensuring transient network issues at one checkpoint do not trigger false alerts.

Query authoritative nameservers directly. By specifying your authoritative nameserver in the monitor configuration, you bypass resolver caches and check the source of truth. This catches problems at the zone file level before they propagate to recursive resolvers that your users query.

Set a 5-minute interval. DNS changes are rare but critical. A 5-minute check interval gives you rapid detection without excessive queries. For NS records specifically, consider 1-minute intervals — a nameserver change is the highest-severity DNS event possible.

Combining DNS With Other Monitor Types

DNS monitoring is most powerful when combined with other checks. Set up a DNS monitor alongside your HTTP monitor for the same domain. If both fail simultaneously, the root cause is almost certainly DNS. If only the HTTP monitor fails while DNS resolves correctly, the problem is at the server or application layer. This diagnostic layering saves significant troubleshooting time during incidents.

Pair DNS monitoring with domain expiry monitoring to cover both record integrity and domain ownership. And use WHOIS change detection to catch registrar-level changes (nameserver updates, registrant modifications) that precede DNS record changes.

DNS monitoring is one of the most underrated types of uptime monitoring. Most teams only realize they need it after a painful incident — an accidental deletion, a hijacking attempt, or a migration that broke email for an entire day. Set it up now — it takes 30 seconds per record and could save you hours of debugging and thousands in lost business.