DNS threats and how they work
DNS hijacking, cache poisoning, subdomain takeover and the rest: how each attack works, and what actually detects it.
Most DNS attacks are invisible from the inside. Your dashboard looks fine while traffic or mail is quietly diverted. The defence is layered: good access hygiene up front, and continuous monitoring to catch what slips through.
DNS hijacking
An attacker who gains access to your registrar or DNS provider edits your records, repointing A/AAAA, MX or NS to infrastructure they control. Visitors and email flow to the attacker while everything looks normal.
The details
Often the entry point is a phished registrar login or a reused password, not a flaw in DNS itself. Registrar lock, MFA and least-privilege access are the front-line defences; monitoring is how you find out fast if they fail.
How to catch it Snapshot your records and compare them on a schedule, so an unexpected A, MX or NS change becomes an alert within minutes rather than a discovery weeks later.
Cache poisoning / spoofing
An attacker tricks a resolver into caching a forged answer, so users are sent to the wrong address even though your authoritative records are untouched.
The details
Modern mitigations (source-port randomisation, and DNSSEC, which signs the records so a validating resolver can reject a forged answer) make this harder. Because the poisoning lives in a resolver's cache, different resolvers can briefly return different answers.
How to catch it Query several public resolvers at once. If one disagrees with the rest, you can see it rather than guess.
Subdomain takeover
A CNAME points a subdomain at a third-party service (a cloud host, CDN, or SaaS app) that has since been de-provisioned. An attacker re-registers that target and now serves their content from your subdomain, with your name and, often, your cookies.
The details
These "dangling" records accumulate quietly as projects are retired. The fix is to remove the CNAME when you tear down the service, but first you have to know the subdomain exists.
How to catch it List every host under your domain, including the ones you forgot, from certificate transparency logs, passive DNS and your own records. Then check each CNAME still points at something you own.
Email spoofing
With no (or misconfigured) SPF/DKIM/DMARC, anyone can send mail as your domain, used for phishing your customers and staff. A p=none DMARC policy that was never tightened is a very common gap.
The details
See the email-security guide for how the three records combine. The subtle failure modes (an SPF record over the 10-lookup limit, a DKIM key that no longer matches) pass a casual eyeball but fail in practice.
How to catch it Validate SPF, DKIM and DMARC against the RFCs rather than just checking they exist, and alert when a policy weakens or disappears.
Expired or broken certificates
Not a DNS attack, but a close cousin: a TLS certificate that expires, has a broken chain, or doesn't cover the hostname breaks trust instantly: browsers throw full-page warnings and users bounce.
The details
Expiry is predictable and therefore entirely preventable, yet it's one of the most common self-inflicted outages. Pair certificate monitoring with CAA records to also control who may issue certificates for you.
How to catch it Track issuer, expiry, chain and protocol for every hostname you serve, with alerts well before anything expires.
Catch changes before your users do
Continuous monitoring turns "we found out weeks later" into an email within minutes. sec.team runs these checks and is free to start.