DNS Monitoring: What to Watch, and Why Hijacking Is the Scary Part

DNS monitoring is unglamorous and arguably the most consequential kind of monitoring. Every other layer (TLS, servers, application) sits downstream of DNS: if the wrong records are being served, your visitors are on someone else's server, your email is being delivered somewhere else, and your uptime monitor may be cheerfully green because something is answering. Unlike a crashed server, a bad DNS change doesn't announce itself. This guide covers which records to watch, how to detect hijacking and unauthorized changes, what a sane TTL strategy looks like, and why domain expiry is the DNS failure that ends everything at once.

The records worth monitoring

You don't need to watch every record in the zone, just the ones whose silent change would hurt:

• A / AAAA: the address records for your apex and critical subdomains (www, api, app). A changed A record means traffic is going to a different machine. If you didn't change it, that's the single most alarming event in this post.
• MX: where your email is delivered. A modified MX record silently reroutes your inbound mail (password resets, invoices, support tickets) to a server you don't control. Users notice a downed website in minutes; rerouted email can run for weeks.
• NS: the delegation itself. Changed nameservers mean someone else now answers every query for your domain: the A, MX and TXT records you see at your provider are no longer the ones the world sees. NS changes you didn't make are an emergency.
• CNAME: aliases pointing at third-party services (status.example.com → a hosted status page, shop. → a commerce platform). Two failure modes: the target changes, or the third-party endpoint behind it is decommissioned, leaving a dangling CNAME that a subdomain-takeover attacker can claim.
• TXT: where SPF, DKIM and DMARC live. A tweaked SPF record can authorize an attacker's mail server to send as your domain, or break your own deliverability. These records deserve dedicated email-authentication monitoring as well.

Baseline everything with a quick audit: the free DNS lookup tool shows the records for any domain as the world currently resolves them.

Detecting hijacking and unauthorized changes

DNS hijacking is rarely dramatic. In practice it's a compromised registrar account, a phished DNS-provider login, or a malicious insider making one quiet record edit. The defense is the same for all of them: know what your records should be, and alert the moment reality differs.

That's what DNS monitoring is: recorded expected values, regular re-resolution, and an alert on any difference:

• Any change you didn't initiate is an incident until proven otherwise. Most alerts will be your own teammates' legitimate edits; the confirmation costs a Slack message. The one alert that isn't legitimate pays for years of the habit.
• Watch NS and MX with the most paranoia. A-record hijacks are visible (wrong site); NS and MX hijacks can be engineered to be invisible to you while intercepting traffic and mail.
• Check from external resolvers, not from inside your own infrastructure. You care about what the world sees, and some attacks (and some mistakes) only show up in public resolution.

Harden the account layer too, because the monitoring is your tripwire, not your lock: strong unique passwords and mandatory 2FA on registrar and DNS-provider accounts, an owner-of-record email that isn't on the domain itself (or you can't recover a hijacked domain via email on that domain), and registrar lock (clientTransferProhibited) so the domain can't be transferred away without an explicit unlock.

TTL strategy: the dial everyone forgets

TTL (how long resolvers cache each record) is a trade-off between agility and resilience:

• Steady state: 1 hour (3600s) is a sensible default for most records. Low enough that a fix propagates within lunch, high enough that resolver caches shield you from transient DNS-provider blips.
• Before a planned change: drop the TTL first. Lower it to 300s at least one old TTL period before the migration. If the record was at 3600, do it an hour or more ahead, because resolvers holding the old record won't see the new TTL until their cache expires. After the change settles, raise it back.
• Don't run 60-second TTLs permanently out of vague flexibility instinct. You multiply query load, add resolution latency for users, and lose the caching that keeps you partially reachable during a DNS-provider outage.

"Waiting for propagation" is mostly a myth

DNS changes don't "push" across the internet over 24–48 hours. There is no propagation wave, only caches expiring. When you change a record, every resolver that has never cached it sees the new value immediately; resolvers holding the old value serve it until its TTL runs out, then fetch fresh.

So the honest version of "how long until it's live everywhere" is: the old record's TTL (as it was before your change), plus a little slack for the minority of resolvers that ignore TTLs. If the old TTL was 3600, you're looking at about an hour, not two days. When a change seems "stuck" beyond that, stop waiting and start diagnosing: query the authoritative server directly (dig @your-nameserver example.com) to confirm the zone is actually right, then compare public resolvers (dig @1.1.1.1 vs dig @8.8.8.8), the same isolation step from our website-down checklist. Usually the "propagation problem" is an edit made at the wrong provider, a typo'd record, or your own OS cache.

Domain expiry: the ultimate DNS failure

Every failure above breaks part of your DNS. An expired domain breaks all of it simultaneously: website, API, email, every subdomain, every service authenticated by a TXT record, all in one event. It's also more common than people admit: the renewal card expired, the renewal notices went to a former employee's inbox, auto-renew was on at a registrar you migrated away from. Major companies with entire IT departments have made the news this way.

Worse, the failure has a tail: after expiry, domains pass through grace and redemption periods where recovery gets progressively more expensive, and eventually the domain can be re-registered, often by squatters who monitor expiry lists specifically to ransom or monetize lapsed domains with existing traffic.

Treat expiry like certificate expiry, but with higher stakes: monitor the date independently of your registrar's emails, alert at 60/30/14 days, keep auto-renew on and verified (auto-renew silently fails when the card on file dies), and keep the registrar account's contact email current and off-domain. (The full timeline is in domain expiry: the outage nobody monitors.)

Watch the layer everything sits on

DNS fails quietly: a changed record, a cache misunderstanding, a renewal notice in a dead mailbox. Monitoring means you hear about it before your customers do. CompleteStatus monitors your DNS records (A, AAAA, MX, NS, TXT and CNAME) for unexpected changes, alerts at 60, 30, 14 and 7 days before domain expiry, and puts both alongside your uptime, SSL, cron-heartbeat and email-authentication monitoring in one dashboard, so the whole stack from delegation to application is watched by one tool instead of five.

Baseline your domain now with the free DNS lookup tool, then start monitoring free (10 monitors, commercial use allowed) and hear about the next unexpected DNS change on the next check, not from a customer.