DNS Monitoring: Catch Record Changes Before They Take You Offline

DNS monitoring means querying your domain's DNS records on a schedule and alerting when an answer changes from what you expect or stops resolving. The records worth watching are the A, AAAA or CNAME records that point visitors at your site, the MX records and the SPF and DMARC TXT records that make email work, the NS records that say which provider serves the zone, and CAA records that control which certificate authorities may issue certificates. For each one, write down the value it should have, and treat any difference as an incident until you know why it happened.

DNS problems are easy to cause and slow to undo. A wrong record takes seconds to save and can stay cached across the internet for hours. Catching the change before caches fill up is the whole point.

Which records matter

Records for the website

• A maps a name to an IPv4 address.
• AAAA maps a name to an IPv6 address.
• CNAME makes a name an alias for another name, common for CDNs, hosted platforms and subdomains like www or shop.

Monitor the apex (example.com) and every host name customers use (www, app, api, shop). An AAAA record is easy to forget: if one exists and points to an address that no longer serves your site, users on IPv6 networks fail while IPv4 users and many monitors see nothing wrong.

Records for email

• MX lists the servers that accept mail for the domain. If it changes or disappears, incoming mail bounces or goes elsewhere.
• SPF is a TXT record starting with v=spf1 that lists who may send mail as your domain (RFC 7208). A domain must have only one; adding a second during a migration invalidates both.
• DMARC is a TXT record at _dmarc.example.com starting with v=DMARC1. If it is removed, receivers stop applying your policy and you lose the reports.

Email records break quietly. The site stays up, and you find out days later that invoices went to spam.

Records for the zone

• NS records name the authoritative nameservers. The ones that count are the NS records the parent registry publishes (set at your registrar), which delegate the zone to your DNS provider. If they change, every other record is suddenly served by someone else, or by no one.

Records for certificates

• CAA records (RFC 8659) list the certificate authorities allowed to issue for the domain. If you add one that does not include the CA your hosting provider or CDN uses, the next automatic renewal fails, and the site breaks weeks later when the old certificate expires. See SSL certificate monitoring for the certificate side of this.

How DNS outages actually happen

The domain expires

When a registration lapses, the registry or registrar typically stops publishing your nameservers or points them at a parking page. Lookups start returning NXDOMAIN or the wrong address. The fix is a renewal, but caches and the registry's own processing add delay. What happens when a domain expires walks through the stages, and the domain expiry checker shows any domain's date.

A provider migration goes wrong

Moving DNS from one provider to another is the riskiest routine change. The usual failures:

• Records not copied: the new zone lacks a TXT verification record, a subdomain or the MX.
• NS changed at the registrar before the new zone was complete.
• DNSSEC left enabled with the old provider's DS record at the registrar, so validating resolvers return SERVFAIL for the whole domain.
• The old provider's account closed while resolvers still had the old NS cached.

Accidental edits and deletions

Someone deletes the "unused" CNAME that a payment provider relied on, replaces the SPF record instead of extending it, or edits the apex A record while setting up a new subdomain. Infrastructure-as-code reduces this, but only for zones managed that way.

Hijacking

An attacker who gets into your registrar or DNS provider account can change NS or A records to send traffic and mail to their servers. This is rarer than mistakes, but the damage is worse, and a monitor that alerts on unexpected changes is one of the few ways to notice quickly. Use strong, unique credentials and two-factor authentication on registrar and DNS accounts, and turn on registrar lock.

Dangling records

A CNAME that points at a deleted cloud resource or a cancelled SaaS account can sometimes be claimed by someone else, who then serves content on your subdomain. Monitoring the expected target helps, and so does deleting records when you decommission what they point to.

TTL: why fixes take time

Every record carries a TTL (time to live) in seconds. Recursive resolvers cache an answer for that long before asking again. That has three consequences:

• A bad change spreads gradually. Resolvers pick it up as their cached copies expire, so some users break before others.
• A fix spreads gradually too. If a wrong record had a TTL of 3,600, some resolvers keep serving it for up to an hour after you correct it.
• Negative answers are cached. An NXDOMAIN is cached for a period derived from the zone's SOA record (RFC 2308), so a briefly missing record can stay "missing" for a while after you restore it.

Before a planned change, lower the TTL of the records involved to something like 300 seconds, wait for the old TTL to pass, make the change, and raise the TTL again once it is confirmed. Note that NS records at the parent zone carry the registry's TTL, which you usually cannot change, often a day or more.

Checking records with dig

Query the current answer from a public resolver:

dig +short A example.com @1.1.1.1
dig +short AAAA example.com @1.1.1.1
dig +short CNAME www.example.com @1.1.1.1
dig +short MX example.com @1.1.1.1
dig +short TXT example.com @1.1.1.1
dig +short TXT _dmarc.example.com @1.1.1.1
dig +short CAA example.com @1.1.1.1

See the remaining TTL in a resolver's cache (the second column):

dig A example.com @8.8.8.8 +noall +answer

Ask the authoritative nameservers directly, bypassing caches:

dig +short NS example.com
dig A example.com @ns1.your-dns-provider.com +norecurse

Follow the delegation from the root, which shows the NS records the registry actually publishes:

dig +trace example.com

Check DNSSEC status. A SERVFAIL here that disappears with +cd (checking disabled) points to a DNSSEC problem:

dig A example.com @1.1.1.1
dig A example.com @1.1.1.1 +cd

If you do not have dig handy, the DNS lookup tool runs the same queries in the browser.

Setting expected values

A DNS monitor is most useful when it knows what the answer should be, not only that there is one.

1. Record today's answers with the dig commands above, once things are known to be working.
2. Decide what counts as a change. For an A record behind a CDN that rotates addresses, an exact value will flap; monitor the CNAME the CDN gave you instead, or only check that the record resolves.
3. Allow for multiple values. MX and NS records usually return several entries, and a resolver may return them in any order. Compare the set, not the first line.
4. Match TXT records carefully. A domain often has several TXT records for verification tokens. Expect the specific record you care about (the one starting v=spf1) rather than the whole list.
5. Update the expected value as part of every planned DNS change, so the monitor alerts on surprises, not on your own work. Schedule the change inside a maintenance window if your tool supports one.

PingRobot's DNS monitors cover A, AAAA, CNAME, MX, NS, TXT and CAA records, with optional expected values, so a changed nameserver or a missing SPF record raises an alert like any other outage.

A minimal DNS monitoring set

For a typical small business domain:

Pair it with an HTTP monitor on the site and a domain expiry reminder, and the three most common ways a domain takes you offline are all covered. If you are already seeing lookups fail, start with DNS_PROBE_FINISHED_NXDOMAIN.

Start monitoring free — 10 monitors, no credit card.