How it works
Resolver state, registrar accounts, authoritative records or local settings are altered so a name resolves incorrectly; or a network originates or propagates routes for address space it does not hold, diverting traffic at the internet layer.
Attacking the map, not the territory
Both attacks here leave the target untouched. The servers are healthy, the application is fine, the certificates are valid. What changes is the directions everyone else is given.
That property makes them unusually hard to notice from the inside. Your monitoring, running from your network, resolves and routes correctly and reports everything green while users in another region reach an impostor. Detection has to come from outside your own perspective, which is why external monitoring is not optional for either of these.
It also makes them unusually damaging, because the victim inherits the attacker's infrastructure with the victim's own name attached — including, if certificate issuance can be completed, a valid certificate for it.
The registrar is the weakest link
Sophisticated DNS attacks get the attention, and the common case is far more mundane: someone signs into the registrar account and changes the nameservers.
From there the attacker controls every record for the domain. They can point traffic wherever they choose and, because certificate authorities frequently validate domain control through DNS or HTTP, they can obtain a legitimate certificate for the name. At that point the impersonation is complete and produces no browser warning at all.
Registrar accounts are therefore tier-zero assets and are routinely protected worse than a staging server: shared credentials, no MFA, an address belonging to someone who left. Registry lock, strong MFA, and delegation monitoring that alerts on nameserver change are the whole defence, and they are cheap.
Resolver poisoning and local tampering
Cache poisoning targets resolvers rather than records — persuading a resolver to store an answer the authoritative server never gave, which is then served to everyone using it until it expires.
Protocol hardening has made blind poisoning substantially harder, and DNSSEC removes the class entirely for signed zones by letting a validating resolver verify the answer's origin. Adoption remains partial, which is why the technique is diminished rather than gone.
The more common variant now is local: malware or a compromised router changing a device's configured resolver. Every subsequent lookup is answered by the attacker, and nothing at the network or registrar level is involved. The signal is answers differing between the device and a known-good resolver, which is straightforward to check and rarely checked.
Routing hijacks and route leaks
Internet routing operates largely on trust between networks. A network announces which address space it can reach, and its peers generally believe it. A network that announces address space it does not hold can attract that traffic — and a more specific announcement wins regardless of who is legitimate.
Many incidents are accidental. A misconfigured filter propagates routes learned from one peer to another, and traffic that should have taken a direct path detours through a network with no capacity for it. The result is an outage rather than an interception, and it is indistinguishable from an attack at the moment it starts.
Deliberate hijacks are used to intercept traffic, to obtain certificates by controlling validation traffic, or to send traffic nowhere at all. Duration is usually short, because the routing community notices — but short is sufficient for certificate issuance.
RPKI is the meaningful control: publishing route origin authorisations lets other networks reject announcements from an origin you have not authorised, and validating received routes means you do not propagate someone else's hijack. Neither is complete while adoption is partial, and both raise the cost considerably.
Also known as
What defenders may observe
- DNS answers differing between trusted resolvers
- Unexpected nameserver or registrar changes
- Valid names resolving to unfamiliar infrastructure
- An unexpected origin autonomous system for your prefix
- Reachability changing by region rather than globally
- Route monitoring reporting a new path or a more specific announcement
Prevention and mitigation
- Lock registrar accounts and protect them with strong MFA
- Monitor authoritative records and nameserver delegation continuously
- Validate DNSSEC where supported, and sign your own zones
- Publish RPKI route origin authorisations and validate received routes
- Apply prefix and peer filters; do not accept what a peer should not announce
- Subscribe to route monitoring with an agreed provider escalation path
Initial response priorities
- Segment or isolate the affected network path.
- Validate routing, certificates, DNS and device identities.
- Preserve packet, resolver and infrastructure control-plane logs.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.