Guide

DNS monitoring: protect your website from DNS changes and outages

DNS Record Checker

Free, no sign-up. We only fetch the public URL you enter.

Short answer

DNS monitoring regularly resolves the DNS records of your domains – A, AAAA, CNAME, MX, NS, TXT, SOA, CAA and others – and compares the answers with the values you expect. When a record is modified, added, deleted or stops resolving, you get an alert, so accidental edits, broken email records and hijacking attempts are caught within minutes instead of after customers complain. Uptime checks alone often miss these issues because the server keeps responding. monitordefend does not offer DNS monitoring; its free DNS checker and record lookup tools show your current records on demand.

  • Define the expected value for each important record.
  • Alert on any modified, added, deleted or unresolvable record.
  • Watch A/AAAA for the website, MX/TXT for email and NS for delegation.
A DNS change detected
myshop.com · expected vs. current
A      93.184.216.34
MX     10 mail.myshop.com
MX     10 mx.unknown-host.example
TXT    v=spf1 include:_spf.mailprovider.example ~all
NS     ns1.dnsprovider.example, ns2.dnsprovider.example
The website still loads, so an uptime check stays green – but all incoming email now goes to a server you do not control.

DNS is the part of your infrastructure that everyone depends on and almost nobody watches. Every website visit, every email delivery and every API call starts with a DNS lookup, and a single wrong record can send visitors to the wrong server or make email vanish – while the server itself is perfectly healthy. DNS monitoring detects those problems before they reach your users. This guide explains which DNS records to monitor, what kinds of problems DNS monitoring catches, how to set it up with expected values, and how it differs from domain monitoring and manual lookup tools.

What is DNS monitoring?

DNS monitoring is the continuous checking of the DNS records that belong to your domains. A monitoring tool resolves each record on a schedule, records the answer and compares it with a known-good value. If an answer differs, disappears or cannot be obtained at all, the tool sends an alert. The result is an early-warning system for one of the most fundamental layers of every online service.

Two kinds of problems are in scope. The first is a change: a record now points somewhere else, a new record has appeared or an existing one has been deleted. The second is an outage: the authoritative nameservers do not answer, answer slowly or return errors such as SERVFAIL or NXDOMAIN. Both can make a website or email unreachable, and both are invisible to monitoring that only checks whether a web server responds once it is reached.

What is DNS and why do DNS records matter?

The Domain Name System translates names such as myshop.com into the IP addresses that computers use to connect. When someone opens your website, their browser asks a resolver, the resolver asks the authoritative nameservers for your domain, and the answer – an A or AAAA record – tells the browser which server to contact. Email works the same way through MX records, and many services verify your domain through TXT records.

From name to website
  1. Browser Asks for www.myshop.com
  2. Resolver Cached answer or recursive lookup
  3. Authoritative DNS Returns the A record
  4. Server Receives the request
If the authoritative answer is wrong, every later step goes to the wrong place – no matter how healthy the server is.

DNS records therefore control where traffic goes. If a record changes unexpectedly, through a typo, a migration that forgot one entry, an expired integration or a compromised account, websites and services break even though the servers themselves stay online. Because resolvers cache answers for the duration of the TTL, the effect also spreads gradually: some users are affected immediately, others only hours later, which makes DNS problems confusing to diagnose without monitoring.

Monitor all DNS records that matter

Not every record needs the same attention, but every record type can break something. The table summarises the DNS record types worth monitoring and what goes wrong when they change. Teams typically start with A and AAAA for website routing, MX for email delivery, NS for nameserver changes and TXT for SPF, DKIM, DMARC and domain verification, then add the rest as needed.

If you use DNSSEC, its records – DS at the parent zone, DNSKEY and the NSEC or NSEC3 records in your zone – deserve monitoring too. A DNSSEC mismatch, for example after changing DNS providers without updating the DS record, makes validating resolvers reject your domain completely, which looks like a total outage to a large share of users.

RecordWhat it controlsRisk when it changes
A / AAAAIPv4 / IPv6 address of a hostnameVisitors reach the wrong or no server
CNAMEAlias to another hostnameBroken subdomains, subdomain takeover
MXMail servers for the domainIncoming email bounces or is intercepted
NSAuthoritative nameserversWhole zone answered by someone else
TXT (SPF, DKIM, DMARC)Email authentication, verificationMail rejected or marked as spam
SOAZone serial and timing parametersSecondary servers serve stale data
CAAWhich CAs may issue certificatesRenewals blocked or unwanted issuers allowed
SRVServices such as SIP or XMPPClients cannot find the service
PTRReverse lookup of an IPMail servers distrust your outgoing mail
DS / DNSKEY / NSEC3DNSSEC chain of trustValidating resolvers reject the domain

What kinds of problems does DNS monitoring catch?

DNS monitoring catches the class of problems where the server is still online but the DNS records pointing to it are wrong. An A record left on an old IP address after a hosting migration sends some visitors to a retired server. A broken or deleted MX record makes incoming email bounce. A missing TXT record breaks SPF or DMARC authentication, so outgoing email starts landing in spam. An outdated CNAME pointing to a deleted cloud resource can allow a subdomain takeover, where an attacker claims the resource and serves content under your name.

Problems DNS monitoring catches
A record points to an old IP
Visitors reach the retired server
MX record removed
Incoming email bounces
SPF / DMARC TXT missing
Outgoing mail lands in spam
Dangling CNAME
Subdomain takeover possible
NS delegation changed
Possible hijacking
Each of these leaves the web server running – which is exactly why uptime monitoring does not see them.

It also catches deliberate attacks. DNS hijacking – changing NS or A records after compromising a registrar or DNS provider account – redirects traffic to an attacker’s server, often to steal logins or intercept email. In many of these cases, standard uptime monitoring still reports the service as online, because whatever answers on the new address responds normally. DNS monitoring compares the records themselves, so it notices the change regardless of what the destination does.

Instant alerts on DNS record changes

The core of DNS monitoring is comparison with expected values. For each record you define what the answer should be – a specific IP address, a set of mail servers, a TXT string. The monitor resolves the record, compares the answer and alerts when a record is modified, added or deleted. Some tools instead learn the current state and alert on any change, which is convenient but means the first state must be correct.

Two details make alerts reliable. First, query the authoritative nameservers directly in addition to a public resolver, because resolvers cache answers and may show an old value for the length of the TTL. Second, handle legitimately changing records: services such as CDNs and load balancers may rotate IP addresses, so for those records it is better to check that the answer belongs to an allowed set, or that the CNAME target is correct, than to pin a single address. Planned changes should be reflected in the expected values immediately so that the alert stays meaningful.

Prevent downtime and security risks

Fast detection matters because DNS problems compound over time. As soon as a wrong record is published, resolvers around the world start caching it, and even after you correct the mistake, the wrong answer survives until the TTL runs out. Catching a change within minutes rather than hours limits how many users ever see it. For security incidents, speed is even more important: every minute an attacker controls your MX or A records is a minute in which email can be read or credentials collected.

Setting up DNS monitoring
  1. Inventory Domains, subdomains, record types
  2. Expected values What each record must return
  3. Schedule Resolve every few minutes
  4. Alert Changed, added, deleted, failed
Expected values turn a lookup into a check: anything that differs is worth an alert.

DNS monitoring also improves change management. When every modification triggers a notification, unplanned changes stand out immediately, and planned changes are confirmed as soon as they are live. Over time, the alert history becomes a log of who changed what and when – useful for audits and for understanding incidents after the fact.

How to set up DNS monitoring

Setting up DNS monitoring is quick once you know what to watch. Start with an inventory of your domains and important subdomains: the website, www, the shop, API and app hostnames, mail-related records and any hostnames used for verification. For each, list the record types that matter and the values they should return. Your DNS provider’s zone export is a good starting point.

Checking records with dig
$ dig +short A www.myshop.com
93.184.216.34
$ dig +short MX myshop.com
10 mail.myshop.com.
$ dig +short NS myshop.com
ns1.dnsprovider.example.
$ dig @ns1.dnsprovider.example SOA myshop.com +short
ns1.dnsprovider.example. hostmaster.myshop.com. 2026101601 7200 3600 1209600 300
Querying the authoritative nameserver directly bypasses caches and shows what the zone really contains.

Then choose a monitoring method, enter the hostname, pick the record type and enter the expected value; you can add multiple records per domain. Decide how often to check – every few minutes for critical records, hourly for the rest – and where alerts should go. Finally, make updating the expected values part of every planned DNS change, so the monitor reflects the intended state rather than producing false alarms after each migration.

Check DNS records by hand with dig and nslookup

Every DNS alert should be confirmed with a manual lookup, and the standard tools for that are dig and nslookup. dig with +short prints just the answer, which makes it easy to compare with the expected value. Adding @ and a nameserver queries that server directly, so you can check the authoritative answer without cache effects, while querying public resolvers shows what users currently see.

The SOA record’s serial number is especially useful: it increases with each zone change, so comparing serials across your authoritative servers reveals whether a secondary server has fallen behind. On Windows, nslookup -type=MX and Resolve-DnsName in PowerShell do the same job. Web-based DNS checkers show the records without a terminal and are handy when you are not at your own machine.

Automate DNS monitoring with standard tools

A basic DNS monitor needs nothing more than a shell script and a scheduler: resolve each record with dig +short, sort the output, compare it with a stored expected file and send an email when they differ. Run it from cron every few minutes, and you have change detection for the records you care about. Prometheus users can probe DNS with the blackbox exporter’s DNS module, which checks answers against regular expressions and exposes lookup time as a metric, and classic infrastructure monitors provide DNS check plugins with expected-address options.

Many DNS providers also offer audit logs or change notifications for their own zones, and some registrars notify you when nameservers change. These are valuable additions but not replacements: they report changes made through that provider, while an independent monitor sees the result from outside, including changes that happen through a compromised account or at a different provider entirely. Whatever you build, check that resolution failures – timeouts, SERVFAIL – also trigger alerts, not only changed values.

DNS monitoring vs. domain monitoring

DNS monitoring and domain monitoring are often confused because both concern your domain name. DNS monitoring watches the records inside the zone – A, MX, CNAME, TXT and the rest – for unexpected changes and resolution failures. Domain monitoring, usually domain expiration monitoring, watches the registration itself and warns before the domain expires.

The risks they cover are different. DNS monitoring detects traffic being routed to the wrong server or email delivery breaking; domain monitoring prevents the outage that follows an expired registration. Because a lapsed domain also changes its DNS, a DNS monitor will notice the consequences, but only after expiry, when the damage is already happening. Many teams therefore use both.

DNS monitoring vs. manual DNS lookup tools

DNS lookup and propagation checkers are designed for manual use: you enter a domain and see how its records resolve at that moment, sometimes from several locations. They are ideal for troubleshooting a change you just made or answering “has my new record propagated yet?”. Their limitation is that they only tell you what is true right now, when you think to ask.

DNS monitoring works continuously in the background. It compares records against the values you defined and alerts you automatically when something changes, at three in the morning as well as during office hours. One is a troubleshooting tool, the other a watchman; most teams need both, using the monitor to learn that something changed and the lookup tool to investigate what exactly happened.

Monitor multiple domains and records

Most organisations own more domains than they think: country variants, product names, campaign domains, typo-protection domains and domains used only for email. Each can carry MX and TXT records that matter, and forgotten domains are favourite targets for abuse because nobody notices changes. Monitoring should cover all of them from one place, with the most important records of each domain tracked individually.

For larger estates, group domains by importance. Main domains and anything handling email or payments deserve frequent checks on every relevant record type; secondary domains may only need NS and MX monitoring to confirm they are still under your control. Combining DNS monitoring with registrar lock, two-factor authentication on DNS and registrar accounts, and careful TTL management – lower the TTL a day before a planned change, raise it again afterwards – gives you a DNS setup that is both stable and recoverable.

Where monitordefend fits

monitordefend is a hosted website monitoring service and does not provide DNS monitoring or alerts on DNS record changes. Its free DNS checker shows a domain’s A, AAAA, CNAME, MX, NS and TXT records on demand, and dedicated lookup tools cover single record types such as MX, TXT, CAA or nameservers. If a DNS problem makes the website unreachable, monitordefend’s uptime check, which requests the homepage every five minutes, reports the outage by email.

Frequently asked questions

What is DNS monitoring?

DNS monitoring regularly resolves your domains’ DNS records and compares the answers with expected values. It alerts you when a record is modified, added, deleted or fails to resolve, so misconfigurations and hijacking attempts are caught quickly.

Which DNS records should I monitor?

Start with A and AAAA for website routing, MX for email delivery, NS for nameserver delegation and TXT for SPF, DKIM, DMARC and verification. Add CNAME, SOA, CAA, SRV, PTR and DNSSEC records (DS, DNSKEY, NSEC3) where you use them.

What problems does DNS monitoring catch that uptime monitoring misses?

Cases where the server is fine but DNS is wrong: an A record pointing to an old IP, a deleted MX record, missing SPF or DMARC entries, a dangling CNAME or a hijacked nameserver delegation. The destination may still respond, so uptime checks stay green.

How do I set up DNS monitoring?

List your domains and important records, define the expected value for each, choose a tool or script that resolves them every few minutes, query authoritative servers as well as a public resolver, and send alerts on any difference or failure.

What is the difference between DNS monitoring and domain monitoring?

DNS monitoring watches the records in your zone for changes and failures. Domain monitoring watches the registration and warns before the domain expires. They cover different risks and work best together.

How is DNS monitoring different from a DNS lookup tool?

A lookup tool shows the current records when you ask. DNS monitoring checks continuously against expected values and alerts you automatically when something changes.

Does monitordefend offer DNS monitoring?

No. monitordefend offers no DNS monitoring or DNS change alerts. Its free DNS checker and record lookup tools show current records on demand, and its uptime check reports when a DNS problem makes the website unreachable.

Look up your DNS records now

Start for free and set up your first check in minutes.

Start for free