Glossary · simply explained

DNS spoofing & cache poisoning

DNS spoofing means forging DNS answers: the attacker makes a name resolve to the wrong address — users land on their servers while the browser shows the correct address. Cache poisoning is the most effective variant: the forged answer is planted into a resolver and distributed from its cache to all users.

The root of the problem: classic DNS has no authenticity check — whoever delivers a formally matching answer first wins. This credulity stems from the early internet and has not been fixed comprehensively to this day.

How the forgery succeeds — and what prevents it

In cache poisoning the attacker floods a resolver with forged answers to a query they triggered themselves; if one matches the transaction data of the real query, the cache adopts the forgery — and distributes it to all clients for the lifetime of the entry. Locally, simpler means suffice: manipulated routers or ARP spoofing redirect DNS traffic directly.

The structural answer is DNSSEC: signed zones make every forgery cryptographically detectable — a validating resolver discards it. Encrypted DNS (DoH/DoT) additionally protects the path between client and resolver. Together they take away both the ground and the transport of the attack.

Why this is business-critical

  • Redirected users enter credentials on look-alike portals.
  • Systems are hit too: API calls and update servers follow the same resolution.
  • Email delivery can be diverted via forged MX answers.
  • The damage hits your brand — on servers that never belonged to you.

Frequently asked questions about DNS spoofing & cache poisoning

What is the difference between DNS spoofing and cache poisoning?

Spoofing is the umbrella term for forging DNS answers. Cache poisoning is the variant with leverage: the forgery lands in a resolver’s cache and is automatically distributed to all users behind it — one hit, many victims.

Does HTTPS not protect against the consequences anyway?

It helps considerably: the attacker cannot present a valid certificate for the real domain, browsers warn. Risks remain with dismissed warnings, non-browser clients without strict validation and services without TLS. DNSSEC prevents the redirection itself rather than just its consequences.

How does DNSSEC prevent the forgery?

Signed zones provide a cryptographic proof of authenticity with every answer along a chain of trust from the root zone to the domain. A validating resolver recognises forged answers and discards them — cache poisoning comes to nothing.

What does encrypted DNS (DoH/DoT) contribute?

It protects the stretch between client and resolver from eavesdropping and manipulation — in open Wi-Fi, say. It does not replace DNSSEC: encrypted transport does not guarantee the answer itself is genuine. Only together do both provide full protection.

What should companies do concretely?

Sign their own zones with DNSSEC (one click on modern platforms), use validating resolvers, run DNS infrastructure DDoS-resistant and monitor anomalies in resolution. DNS belongs under the same protective umbrella as web and APIs.

Wondering how this looks in your own network? Talk to KAEMI: we plan, build and manage the right solution with you.