DNS Monitoring Explained: Detect Changes, Prevent Hijacking, Protect Your Site

What DNS Monitoring Is

DNS monitoring is the automated process of tracking your domain's DNS records for changes and verifying that they resolve correctly. When a record changes, whether intentionally or not, monitoring detects it and alerts you.

DNS is the phonebook of the internet. It translates human-readable domain names into the IP addresses that computers use to find each other. When someone types your domain into a browser, DNS tells the browser which server to connect to. When someone sends you an email, DNS tells the mail server where to deliver it.

If DNS is wrong, everything breaks. Not partially. Completely. Your website shows someone else's content, your email goes to someone else's inbox, and your users have no way to reach you. Unlike a server crash, where the browser shows an error, a DNS hijack can silently redirect your users to a malicious site without any visible warning.

DNS Record Types You Need to Monitor

DNS is not a single record. It is a collection of record types, each serving a different purpose. Comprehensive DNS monitoring watches all of them.

A and AAAA Records

These are the most fundamental records. They map your domain to an IP address. When you type example.com into a browser, the browser looks up the A record to find the server's IP address.

An unauthorized A record change redirects all web traffic to a different server. This is the most direct form of DNS hijacking. Monitor A records for every domain and subdomain you operate.

CNAME Records

CNAME records alias one domain to another. For example, blog.example.com might have a CNAME pointing to example.ghost.io if you host your blog on Ghost. A changed CNAME redirects that subdomain to an entirely different service.

CNAME changes are common during legitimate service migrations but are also exploited in subdomain takeover attacks. If you decommission a service but leave the CNAME pointing to it, an attacker can claim the service endpoint and serve content on your subdomain.

MX Records

MX records control email routing. They tell mail servers which server handles email for your domain. An unauthorized MX change redirects your email to an attacker's server, giving them access to every email sent to your domain, including password resets, confidential communications, and two-factor authentication codes.

MX record changes are particularly dangerous because they are silent. Your website continues to work normally. You simply stop receiving email, or worse, an attacker receives copies of it.

TXT Records

TXT records store arbitrary text data and are used for email authentication (SPF, DKIM, DMARC), domain verification (Google Search Console, Microsoft 365), and various security policies.

An altered SPF record can either break your email delivery (if legitimate sending servers are removed) or enable phishing (if an attacker adds their server to your SPF policy). DMARC record changes can disable the policy that protects your domain from spoofing.

NS Records

NS records delegate your domain's DNS to specific nameservers. This is the highest-severity change possible because whoever controls your nameservers controls all of your DNS records. An unauthorized NS change gives an attacker complete control over your domain's resolution.

NS changes should be exceedingly rare in normal operations. Any unexpected NS change is a critical security event.

Why DNS Changes Matter

DNS changes fall into three categories, and monitoring needs to catch all of them.

Intentional Changes Gone Wrong

The most common DNS issues are self-inflicted. A developer changes a CNAME during a service migration and accidentally breaks email by modifying the wrong record. An ops team updates an A record and introduces a typo in the IP address. A DNS zone is edited, and a critical TXT record is accidentally deleted.

These changes are intentional in the sense that someone meant to make a change. They are unintentional in their consequences. DNS monitoring catches the mistake the moment it propagates, rather than when users start reporting issues hours later.

Unauthorized Changes

DNS records can be changed by anyone with access to your DNS provider's control panel. If a team member's account is compromised, or if a former employee retains access, your DNS can be modified without authorization. Some DNS attacks exploit registrar-level vulnerabilities to modify records without needing account access at all.

Monitoring detects unauthorized changes regardless of how they were made. You get an alert saying "your A record changed from 203.0.113.50 to 198.51.100.23" and can immediately investigate whether the change was authorized.

DNS Hijacking and BGP Attacks

Sophisticated attackers can intercept DNS queries through BGP hijacking (redirecting network routes) or DNS cache poisoning (injecting false records into DNS resolver caches). These attacks are harder to execute but also harder to detect because they can affect only specific geographic regions or specific DNS resolvers.

Multi-location DNS monitoring detects these attacks by querying DNS from multiple vantage points. If your domain resolves to different IP addresses from different locations, monitoring flags the inconsistency.

How DNS Propagation Affects Monitoring

When you change a DNS record, the change does not take effect instantly. DNS uses a distributed caching system, and records are cached by resolvers worldwide for a duration specified by the record's TTL (Time to Live).

If your A record has a TTL of 3600 seconds (one hour), DNS resolvers that have cached the old record will continue to return it for up to an hour after you make a change. During this propagation period, some users see the new record and some see the old one.

This has implications for monitoring:

False alerts during planned changes. If you intentionally change a DNS record, monitoring will detect the change during propagation. Good monitoring tools let you acknowledge planned changes to suppress alerts.

Propagation verification. After making a change, monitoring from multiple locations confirms that the new record has propagated globally. If a record has propagated to US resolvers but not European ones, monitoring shows the inconsistency.

TTL optimization. Before making planned DNS changes, lower the TTL to 60-300 seconds 24-48 hours in advance. This ensures the old record expires from caches quickly, minimizing the transition period. After the change has fully propagated, raise the TTL back to a normal value (3600-86400 seconds) to reduce query load on your DNS servers.

Subdomain Takeover: A Growing Threat

Subdomain takeover is an increasingly common attack vector that DNS monitoring directly prevents.

Here is how it works:

1. You create staging.example.com with a CNAME pointing to your-app.herokuapp.com.
2. Later, you decommission the Heroku app but forget to remove the CNAME record.
3. An attacker creates a new Heroku app at your-app.herokuapp.com.
4. Now staging.example.com serves the attacker's content, hosted on your subdomain.

This works with any cloud service that allows custom domains: Heroku, GitHub Pages, AWS S3, Azure, Netlify, and dozens of others. The attack is trivial to execute and devastating in impact because the attacker controls content served under your domain, which means valid SSL certificates, trusted by browsers, and indistinguishable from your legitimate site.

DNS monitoring catches dangling CNAMEs by detecting when a CNAME points to a service endpoint that returns an error (like Heroku's "No such app" page). This early detection gives you time to remove the record before an attacker claims the endpoint.

Setting Up DNS Monitoring

DNS Monitoring and Email Security

DNS monitoring is inseparable from email security. Three critical email authentication mechanisms live entirely in DNS:

SPF (Sender Policy Framework) is a TXT record that lists which servers are authorized to send email from your domain. If your SPF record is deleted or modified, attackers can send email that appears to come from your domain and passes basic authentication checks.

DKIM (DomainKeys Identified Mail) uses TXT records to publish public keys that verify email signatures. If DKIM records are altered, your outgoing email signatures will not validate, and receiving servers may reject or quarantine your legitimate email.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a TXT record that tells receiving servers how to handle email that fails SPF or DKIM checks. If your DMARC record is weakened (changed from "reject" to "none"), phishing emails spoofing your domain will be delivered to inboxes instead of being blocked.

Monitoring these TXT records is not optional if you care about email deliverability and brand protection. A single unauthorized change to your SPF record can enable a phishing campaign that uses your actual domain.

DNS Monitoring Tools: What to Look For

DNS is invisible when it works and catastrophic when it does not. Monitoring is the only way to see the invisible layer that your entire web presence depends on.