DNS Monitoring 101: How to Catch Unauthorized Record Changes Before They Cost You
16 min read
Loading...
You'd typically only find out about unauthorised DNS changes when something breaks: email stops arriving, your site redirects somewhere odd, or a client calls asking why your domain looks "off." By then, the damage is often already done. DNS monitoring closes that gap. It checks your records on a schedule, say every few minutes, and alerts you the moment an A, MX, NS, or TXT record changes without your approval.
Paired with the SSL certificate monitoring and domain expiration monitoring you're likely already running, DNS monitoring gives you a much fuller picture of your domain's health: who controls it, where traffic goes, and whether the connection is secure.
Let's get into why DNS security matters, how DNS hijacking actually happens, and how to set up DNS record change alerts that catch trouble before your customers do.
Here's something I've noticed working with IT teams across the UK and beyond: everyone's got uptime monitoring dialled in. Most have SSL certificate monitoring covered too, because nobody wants that dreaded "Not Secure" warning showing up in a client's browser. But DNS monitoring? It's often the forgotten middle child of domain security.
That's a problem, because DNS was designed in an era when the internet ran on trust rather than verification. The protocol itself has no built-in mechanism to confirm that a record change actually came from you. If someone gets into your registrar or DNS provider account, they can point your domain wherever they want, and nothing about the DNS protocol will stop them or flag it as suspicious.
It's worth being precise here: this isn't a flaw in DNS as a technology so much as a gap in how account access is protected. The UK's National Cyber Security Centre (NCSC) has repeatedly flagged registrar and DNS account security as a basic hygiene issue that's easy to overlook, particularly for smaller organisations and charities managing their own .co.uk or .org.uk domains without dedicated security staff.
Think about it this way: your registrar login is essentially a master key. Compromise that one password, and you control where all traffic for that domain goes: your website, your email, your APIs, your identity systems, all of it. NIST's guidance on DNS security puts it plainly: an unauthorised change to a single record can redirect traffic, intercept email, or break authentication without touching your actual application code. Your servers stay healthy. Your uptime monitor shows green. Meanwhile, visitors are being quietly funnelled somewhere else entirely.
That quietness is exactly what makes DNS attacks so dangerous. A changed A record doesn't throw a 500 error or trip a firewall alert. It just works. For the attacker. Cisco Talos documented this in their research on the Sea Turtle campaign, where attackers compromised DNS-related accounts across telecom and government targets, then redirected victims to convincing fake login pages using stolen credentials and fraudulent certificates. The organisations affected had legitimate domains and often legitimate-looking certificates. Nothing about the URL bar screamed "danger."
The scale of this risk is bigger than most teams assume. A 2024 EfficientIP and IDC survey found that 87% of organisations had experienced at least one DNS attack in the preceding year, with an average cost of roughly $1.1 million and about nine hours of downtime per incident. Those are survey figures rather than a full census, so treat them as a strong signal rather than gospel, but they make clear this isn't a fringe concern reserved for large enterprises.
DNS-level attacks bypass almost everything your endpoint security and network monitoring are built to catch. You can have solid server hardening, tight patch management, and strict firewall rules, and none of it matters if someone simply logs into your DNS provider's dashboard and edits a record.
Not all DNS tampering looks the same, and the mechanism behind each type affects what you should actually be watching for. Here's what to keep on your radar:
It's worth separating out the different mechanisms here, because how an attack happens shapes exactly what controls, and what DNS monitoring, will actually catch.
The most common entry point is straightforward: weak or reused passwords, no two-factor authentication, and you've got a door practically left open. CISA's Emergency Directive 19-01, issued after widespread DNS infrastructure tampering was discovered affecting government domains, specifically called out registrar credential security as a gap agencies needed to close immediately. The NCSC has issued similar guidance for UK public sector and critical national infrastructure organisations, and the underlying advice is the same regardless of jurisdiction: treat your registrar account like the master key it is.
Attackers also go after the humans, not just the systems. Convincing a registrar or DNS provider support representative that you're the account owner is a well-documented tactic. Done successfully, it bypasses the need to guess a password at all.
This is a different category altogether from account compromise. Man-in-the-middle interception of unencrypted DNS queries, or cache poisoning at a resolver, can redirect users without ever touching your actual DNS records. This is exactly what DNSSEC is designed to help prevent, by cryptographically signing DNS responses so a resolver can verify they haven't been tampered with in transit.
It's an important distinction, though: DNSSEC protects the integrity of DNS responses on the wire. It does nothing to stop someone who's legitimately logged into your registrar account from changing a record. That's a separate problem, and DNS monitoring is what catches it.
Finally, there's the dangling CNAME scenario mentioned above. Attackers scan the internet for exactly this kind of abandoned reference and claim the resource, instantly gaining a foothold on a subdomain that still resolves under your trusted domain name, again without needing your registrar credentials at all.
The real-world examples here are sobering. In 2018, attackers redirected MyEtherWallet users to a cloned site by exploiting weaknesses in the DNS delivery path, not by hacking MyEtherWallet's actual servers, and made off with roughly $150,000 in stolen cryptocurrency, according to KrebsOnSecurity's reporting. The Sea Turtle campaign that Cisco Talos tracked affected at least 40 organisations across 13 countries, again by targeting DNS-related accounts rather than application vulnerabilities.
The common thread running through these incidents is that none of them required breaching the victim's actual servers. Traditional server monitoring and uptime checks were never built to catch this category of attack. Your infrastructure can be completely untouched while your domain's trust is thoroughly compromised.
Okay, so how do you actually build a defence against this? The good news is that DNS monitoring is one of the more straightforward pieces of infrastructure monitoring to set up. Here's how I'd walk through it:
This is the kind of setup Moonitor was built to make easy. DNS monitoring sits alongside SSL certificate monitoring, domain expiration monitoring, HTTP/S checks, and the rest, all on one dashboard, with checks run from multiple locations, and a setup process that usually takes a few minutes rather than an afternoon.
Let's say your DNS monitoring alert fires. Records have changed, and it wasn't you. Speed matters, but so does not destroying evidence you'll need later. Here's a practical sequence to work through:
DNS monitoring catches problems fast, but a bit of upfront hardening means fewer problems to catch in the first place. Worth building these into your standard domain security hygiene:
I get asked sometimes whether DNS monitoring is really necessary if you're already tracking SSL certificates and domain expiration. Short answer: yes, each one protects a different piece of the puzzle.
| Monitor Type | What It Detects | What It Protects Against |
|---|---|---|
| DNS monitoring | Unauthorised changes to A, MX, NS, and TXT records | Hijacking, traffic redirection, and email interception |
| SSL certificate monitoring | Expiring or misconfigured certificates, and (where supported) unexpected new certificates via certificate transparency logs | Browser security warnings, broken HTTPS, and fraudulent certificates issued in your name |
| Domain expiration monitoring | Domains approaching their renewal date | Accidental lapses and domain squatting |
Together, these three cover the full trust chain of your domain: who controls it, how traffic reaches it, and whether the connection along the way is secure. Skip any one of them, and you've got a blind spot. A domain with a valid SSL certificate and years left before renewal can still be silently hijacked at the DNS layer, and nobody notices until email starts bouncing.
This is exactly why Moonitor runs all three from a single dashboard, alongside HTTP/S monitoring, keyword monitoring, port and ping checks, cron/heartbeat monitoring, and branded status pages. One place to configure alerts, one place to check when something looks off, with checks run from multiple regions to reduce false alarms from local blips.
Without DNS monitoring, you'd usually find out the hard way: a client reports your site looks wrong, email bounces, or your status page starts throwing incidents. With DNS monitoring in place, a scheduled check compares your live records against your baseline and alerts you via email, Slack, or whichever channel you've configured, typically within minutes of a deviation, well before customers notice anything.
Just bear in mind this is check-interval detection, not instant detection. A very brief change made and reverted between checks could theoretically be missed.
DNS hijacking is when an attacker changes your DNS records, often by compromising your registrar or DNS provider account, to redirect traffic, intercept email, or serve phishing pages under your own domain name. It's more common than most IT teams assume, partly because it doesn't require breaching your servers at all, just your domain management account, which for many organisations is protected by nothing more than a single password.
DNS monitoring itself doesn't stop an attacker from making a change. It can't block a login or reject an unauthorised edit at the registrar level. What it does is dramatically shrink the window between the moment a malicious change happens and the moment you know about it, turning what might otherwise be days of silent damage into a much shorter incident.
Combined with preventative measures like two-factor authentication, registrar locks, and DNSSEC, DNS monitoring becomes the safety net that catches whatever slips past your other defences.
