DNS Change Monitoring: What Changes, When, and Why It Matters
An agency gets a support call. A client’s email has been broken for three days. They dig in and find the MX records changed, quietly, a few days earlier. Not a hack, just an edit by someone at the client’s end who thought they were fixing something. Three days of missed business emails because no one was watching.
The change wasn’t the catastrophe. The gap between the change and the discovery was. That’s the problem DNS change monitoring is built to close.
What DNS records actually control
DNS is the part of the internet that translates names into destinations. Change a record, and you change where traffic goes. The consequences vary enormously by record type.
IANA’s DNS parameter registry covers dozens of record types. In practice, a handful carry the most risk:
A and AAAA records point a domain to a server’s IP address. Change these and you move the site.
MX records direct email to the right mail server. Change them incorrectly and email stops working, or starts going somewhere it shouldn’t.
CNAME records create aliases, often used for third-party integrations like payment processors, live chat tools, and email platforms. Removing one can break a critical user-facing service while your main server continues to report everything is fine.
TXT records carry verification strings for services like Google Search Console, and the SPF and DKIM policies that affect whether your email gets delivered. Easy to add, easy to accidentally delete.
NS records hand over control of the entire DNS zone to a nameserver. Whoever controls the NS records controls everything. A change here is the highest-risk change in DNS.
How DNS records change without anyone telling you
Most DNS changes aren’t malicious. They’re just quiet.
A developer migrates a site to a new host and updates the A record. They don’t document it. Six months later, nobody can remember which IP the domain should point at. A client adds a new marketing tool that requires a TXT record for verification, then stops using the tool and removes the record, not realising it was also doing something else. A hosting company gets acquired and nameservers change as part of the transition. Nobody on the technical side gets an email.
The pattern is the same each time: a change is made, the person who made it moves on, and the record becomes part of the ambient state of the domain. Nobody tracks it. Until something breaks.
Transfers at the registrar level are the most dangerous version of this. DNS, as defined in RFC 1034, has no built-in change notification. There’s no audit trail by default. You have to build one yourself, or use something that does it for you.
Why doesn’t uptime monitoring catch DNS changes?
Uptime monitoring watches whether a URL returns a 200 response. It’s useful, but it has a narrow view.
A site can be fully up while its MX records point at the wrong mail server. Email fails silently. The uptime dashboard stays green. The same is true for a CNAME pointing at a deprovisioned service, a TXT record that’s been corrupted, or an NS change that’s handed control of the zone to an unintended party. None of these trigger a downtime alert. They persist until someone notices a symptom and works backwards.
Uptime monitoring answers “is the site responding?” DNS change monitoring answers “is the site configured correctly?” Both questions matter. They’re not the same question.
What a useful DNS audit trail looks like
Three things make a DNS change record actually useful.
Specificity. Not “something changed” but exactly what changed, old value and new value. An MX record change from 10 mail.example.com to 10 mail.newhost.com tells you something concrete. “MX record updated” tells you almost nothing.
**Timing.** To the hour, not the week. DNS changes propagate based on TTL values, which can be as short as a few minutes or as long as 48 hours. If you know a change was detected at 14:00 on a Tuesday, you can cross-reference it with a deployment, a handoff, or a support ticket. If you know it happened “sometime last week,” you can’t.
Record type visibility. An NS change and a new TXT verification string have very different implications. Your alerting should reflect that. An NS change should be flagged immediately. A TXT record added by a new marketing tool can wait until morning.
The other thing a good audit trail does: it answers future questions. “Why did email stop working in March?” “When did that CNAME get added?” “Who changed the nameservers before we took over the account?” These questions come up. Without a trail, the answer is archaeology. With one, it’s a two-second lookup.
What to check across the domains you manage
Before a client asks, you should be able to answer:
- When did the A record last change, and what did it change to?
- Have the MX records changed in the last 90 days?
- Are there TXT records you don’t recognise or can’t account for?
- Has the NS record changed since the domain was registered?
- Do you have a timestamped record of every DNS change in the last 12 months?
If DNS change monitoring isn’t part of how you manage domains, any of those questions will send you digging through emails or running manual lookups and hoping your memory is right. You don’t have an audit trail. You have a gap.
If you want to know the answer to all of the above before a client has to ask, kant.au tracks every record type across every domain you add, with full before/after history on every change. Start a free 14-day trial and find out what’s changed.