DNS Monitoring — What to Actually Watch (and Why Hijacking Is the Scary Part)

DNS monitoring is the least glamorous kind of monitoring and arguably the most consequential. 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 — you need to watch 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 a five-alarm fire.
• 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 monitoring — see our SPF/DKIM/DMARC explainer.)

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 rarely looks like Hollywood. 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 actually is — recorded expected values, continuous re-resolution, and an alert on any delta:

• 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 dial 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 — there are 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 — gone in one event. And it's more common than pride admits: 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: post-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.

Watch the layer everything sits on

DNS fails quietly: a changed record, a cache misunderstanding, a renewal notice in a dead mailbox. Monitoring turns each of those into an alert with your name on it instead of a surprise with your customers' names on it. CompleteStatus monitors your DNS records for unexpected changes, tracks domain expiry with tiered alerts, 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 find out about the next DNS change the minute it happens.