Quick Answer: Monitor DNS records by storing a baseline for each critical record (A, AAAA, MX, NS, TXT) and checking authoritative nameservers on a fixed interval. Alert when live values differ from the baseline or when a record disappears. Uptime monitoring cannot catch DNS hijacking because your servers may stay online while traffic routes somewhere else.
Why doesn't my uptime monitor catch DNS problems?
Your uptime monitor hits a URL and checks the HTTP response. If the server answers, the monitor reports success. That tells you nothing about whether your users resolve the same IP address you expect.
DNS failures and hijacks are a different failure mode. A compromised registrar account, a stolen DNS API token, or a fat-fingered record edit can point your apex A record at an attacker-controlled host. Your origin server keeps running. Your internal health checks pass. Customers land on a phishing page or a blank parking site.
The same gap applies to email. An MX record that disappears or changes priority can silently break inbound mail. Your web stack looks fine. Support tickets about missing password resets show up hours later.
Uptime monitoring answers "is the service responding?" DNS monitoring answers "is traffic still going to the right place?" You need both layers.
Which DNS records should I monitor?
Not every record needs a monitor on day one. Prioritize records where a wrong value has immediate customer or security impact.
NS (nameserver) records are the highest priority. If delegation changes to nameservers you do not control, an attacker can rewrite every other record. Page on-call for unexpected NS changes.
A and AAAA records control where web traffic lands. Monitor the apex domain and any customer-facing subdomains (www, api, app). A sudden IP change without a deploy is worth investigating immediately.
MX records control email delivery. A missing MX record stops inbound mail. A new MX with higher priority can intercept messages. Monitor primary MX targets and alert on any change.
TXT records matter for deliverability and verification. SPF, DKIM, and DMARC TXT records affect whether your mail reaches inboxes. Domain verification TXT records (for Google Workspace, Stripe, etc.) break integrations when they disappear.
CNAME records for third-party services (docs hosts, status pages, CDNs) break when vendors change endpoints. Monitor CNAMEs that point outside your direct control.
| Record | What breaks when it changes | Alert priority |
|---|---|---|
| NS | Entire zone can be hijacked | Critical |
| A / AAAA | Web traffic redirects | High |
| MX | Email delivery fails or diverts | High |
| TXT (SPF/DKIM) | Mail goes to spam | Medium |
| CNAME | Subdomain stops resolving | Medium |
How do I set up DNS monitoring step by step?
Step 1: Document your current DNS state. Export records from your DNS provider or run dig against each hostname. Save the values you expect. This becomes your baseline.
dig +short A example.com
dig +short MX example.com
dig +short NS example.com
dig +short TXT example.com
Step 2: Create one monitor per critical record. Do not lump your apex A record and your MX record into a single check. Separate monitors mean separate alert messages and faster triage.
In Overwatch, create a DNS check for each record type you care about. Set the domain, pick the record type (A, AAAA, CNAME, MX, NS, or TXT), and configure the check interval. Overwatch compares live authoritative answers against your expected values and marks the check as present, missing, or changed.
Step 3: Route severity by record type. NS and MX changes should page someone. TXT changes for SPF might go to a lower-priority channel. Match alert urgency to blast radius.
Step 4: Lower TTL before planned changes. If you are migrating hosts, drop the record TTL to 300 seconds at least one full old-TTL period before the cutover. Make the change, verify from multiple resolvers, then raise TTL again. Your DNS monitor confirms the authoritative value flipped even while caches propagate.
Step 5: Pair DNS checks with HTTP and TLS monitors. A complete stack watches resolution (DNS), reachability (HTTP/TCP), and certificate health (TLS) as independent signals. Partial failures are common: DNS is correct but the cert expired, or the server is up but DNS points at the wrong load balancer.
How do I tell a hijack from a planned migration?
Every DNS monitor alert is a question: "Did we expect this?" Build a habit of answering it quickly.
Planned changes come with a ticket, a maintenance window, and a human who knows the new values. Acknowledge the alert, confirm the new record matches the plan, and update your baseline if your tool requires it.
Unauthorized changes show up without context. A new A record pointing at a hosting provider you do not use. An NS delegation to nameservers you have never configured. A TXT record you did not add. Treat these as security incidents: rotate DNS API tokens, enable MFA on the registrar, and file an incident report.
Registrar protections reduce risk before monitoring ever fires: enable registry lock, require MFA on the registrar account, and scope API tokens to least privilege. Monitoring does not prevent hijacking. It bounds how long a successful hijack goes unnoticed.
What are common DNS monitoring mistakes?
Only monitoring the apex A record. Teams watch example.com and forget that mail, subdomains, and authentication all depend on other record types. MX and TXT failures are quieter but expensive.
Checking public resolvers instead of authoritative nameservers. Cached resolver answers can lag behind authoritative changes by hours. Query the authoritative source so you see changes on the next check cycle, not after TTL expiry across the internet.
Ignoring NS records because they "never change." That is exactly why they matter. NS records should be the most stable entries in your zone. Any unexpected change is a red flag.
Alert fatigue from migration noise. If every planned deploy triggers a DNS alert nobody reads, the channel becomes useless. Use separate routing for migration windows or snooze non-critical record types during cutovers.
Assuming HTTPS uptime covers DNS. A monitor that connects directly to a known IP or follows a hardcoded URL bypasses the resolver path your users take. External DNS checks simulate what the internet sees.
Frequently Asked Questions
What is DNS monitoring and how is it different from uptime monitoring?
DNS monitoring watches your domain's DNS records (A, MX, NS, TXT, and others) and alerts when values change or disappear. Uptime monitoring asks whether a server responds at a URL. DNS monitoring asks whether traffic still resolves to the right destination. Your origin can be healthy while a hijacked A record sends every visitor elsewhere.
Which DNS records should I monitor first?
Start with NS records (nameserver delegation), apex A/AAAA records (where web traffic goes), MX records (email routing), and TXT records for SPF and DKIM. NS and MX changes are the highest severity because they can indicate full domain takeover or silent email interception.
How often should DNS records be checked?
Every 5 to 15 minutes is a practical baseline for production domains. DNS records change infrequently compared to server uptime, but unauthorized changes need fast detection. Daily checks are too slow for hijacking scenarios where every hour of delay expands the attack window.
Can DNS monitoring catch registrar hijacking?
Yes. When an attacker changes your nameserver delegation, your NS records change at the authoritative level. A DNS monitor that tracks NS records against a known baseline will alert on the change even if your web servers never go down and your uptime dashboard stays green.
Will DNS monitoring alert during planned migrations?
It will alert on any change, including planned ones. Treat that as a feature: acknowledge the alert, verify the new values match your migration plan, and update the monitor baseline. For large cutovers, temporarily widen alert routing to a migration channel so on-call is not paged for expected changes.
DNS hijacking and misconfigured records fail quietly while your servers look healthy. Overwatch monitors A, AAAA, CNAME, MX, NS, and TXT records alongside HTTP, TCP, TLS, and scheduled heartbeat checks, with alerts to Slack, Discord, Teams, email, or any webhook. Cover resolution and reachability in one dashboard. Get started free →