How to hear when DNS records change
Published . Updated .
This guide explains how to notice when a domain's public DNS answers change, whether you made the edit, a vendor did, or someone who should never have had the password did.
DNS change monitoring compares a domain's answers (A, AAAA, CNAME, MX, NS, TXT) to a known baseline on a schedule and alerts when they differ. It catches registrar or DNS-host account takeovers, accidental edits, and expiring delegations before users notice.
DNS is the phone book. The website's address, the mail servers, and the rules that say which servers may send mail are all records under the name. A monitor that only requests the homepage will eventually go red if the address record changes to a dead host. It will stay green if mail records change and the website does not. You want the diff of the records, not only the HTTP result.
Which records are worth a baseline?
Start with the records that move money or mail.
The NS records say who is allowed to answer for the name. A change there is a change of custody. The apex A and AAAA records, or the CNAME that stands in for them, say where the website goes. MX records say where mail goes. TXT records carry SPF and DMARC, which say which servers may send mail as that domain. A quiet change to SPF is how a mailbox starts sending invoices you did not write, while the website looks normal.
Also note CAA records if you publish them. They limit which certificate authorities may issue for the name. They are not in the minimum set above, and they are worth a line if you set them on purpose.
You do not need every host record on day one. A shop with forty printer names will train you to ignore the alert. Baseline the delegation, the website, and the mail policy. Add a record when a client would notice it on a Monday.
| Record | What a surprise change usually means |
|---|---|
| NS | The delegation moved. Treat it as an account problem until someone you trust says they did it. |
| A or AAAA at the apex | The website's address moved. Confirm the new address before you call it a migration. |
| CNAME | The alias now points somewhere else. Follow it one step and compare. |
| MX | Mail delivery moved. New messages will follow the new servers. |
| TXT for SPF or DMARC | Sending policy moved. Check for a new include or a policy of none. |
What actually changes these records?
An account takeover at the registrar or at the DNS host is the ugly case. The password was reused, the two-factor prompt went to a former employee, or a support call reset the login. The attacker changes NS or MX, waits for caches to expire, and reads mail or presents a lookalike site.
The ordinary case is an edit. Someone added a verification TXT for a new tool and replaced the whole TXT set. A migration updated the website address and forgot mail. A CDN onboard changed the apex to their anycast and the old origin is now unreachable by name. An expiring registration starts to interrupt DNS, which looks like a record change or a sudden failure to resolve. The domain expiration timeline is the one to read when resolution itself disappears.
A daily comparison is a reasonable baseline. TTLs on these records are often minutes to hours, as the operator set them. RFC 1034 and RFC 2181 describe the TTL as the length of time a cache may reuse an answer. A check every few minutes will show you the change sooner and will also show you normal caching noise if you compare against a resolver that still holds the old answer. Comparing authoritative answers once a day catches the edits that matter and stays quiet overnight. Use a faster check only for a name you are migrating, and turn it back down.
What should you lock before you monitor?
A monitor tells you after the change. The lock is what makes the change harder.
Turn on the registrar lock so a transfer needs someone to release that lock. Turn on two-factor authentication on the registrar and on the DNS host, and store the backup codes somewhere two current employees can reach. Remove former staff from both accounts the week they leave, not at the next quarterly cleanup. If the DNS host is also the CDN, that login is the website. Treat it that way.
Write down who is allowed to edit the zone. A shared password in a ticket from 2022 is not a list of people.
How do you take a baseline with dig?
From a machine that is not the DNS server, ask for the records you decided to watch. Save the output next to the client name and the date. This gives you a snapshot to compare against later.
dig +short example.com NS
dig +short example.com A
dig +short example.com AAAA
dig +short example.com MX
dig +short example.com TXTReplace example.com with the client's domain. If a record is a CNAME, follow it with another query and save both lines. Run it again the next day and diff the two files. The first week will teach you which records flap because a host rotates addresses on purpose. Remove those from the alert, or alert only when the set of addresses changes membership in a way you did not document.
When you move a site, update the baseline in the same change as the record. An alert against a stale baseline is how a real migration gets ignored the third time.
What do you do when the diff is real?
Pause and compare. Ask the person who was supposed to be the only editor whether they made the change. If they did, update the baseline and write one line in the ticket about what moved.
If they did not, treat it as an account problem. Reset the registrar and DNS passwords, review the two-factor devices, and put the previous records back if you still have the baseline and you are sure it was good. Check MX and SPF before you check the homepage, because mail is the quieter theft. Tell the client what you found in plain language: which record changed, when you saw it, and what you put back.
Do not debug it only as an uptime event. A green homepage with a new MX is not a recovery.
- Save NS, apex address, MX, and mail-policy TXT for each client domain.
- Diff those answers once a day against the saved baseline.
- Lock the registrar and require two-factor on the DNS host.
- Update the baseline in the same change that edits the zone.
- On an unexplained diff, recover the account first and the record second.
Where does this leave the website check?
A homepage check and a DNS diff answer different questions. The check tells you the URL failed. The diff tells you a record moved, including records the homepage never uses. Read how false alarms get filtered before you page someone for a single failed request. Definitions of TTL, NS, MX, and TXT are in the glossary.
How The Watchbill helps
The Watchbill doesn't compare DNS records against a baseline, so keep the daily diff described above as its own task. It does catch two of the failures that DNS problems usually cause. If a site's address record moves to a host that doesn't answer, the HTTPS check on that site fails, and once two consecutive minutes agree you get a Down email. It also reads each site's domain expiry date over RDAP and marks the name as soon when it's inside 30 days, which warns you about the lapsed registration that makes every record stop resolving.
What it won't see is a change that leaves the website working, such as a new MX or SPF record. That's exactly why the record baseline still matters. Use the two together: the DNS diff for the records the homepage never touches, and a free Watchbill account for the site itself and its domain expiry date.
Sources
- RFC 1034, Domain names, concepts and facilities. Accessed October 10, 2026.
- RFC 2181, Clarifications to the DNS specification (TTL). Accessed October 10, 2026.