DNS Spoofing and Cache Poisoning: What They Are and How to Stop

DNS spoofing can silently send a browser to the wrong website even when the user enters the correct domain name. The Domain Name System, or DNS, translates a familiar web address into the destination a device needs to contact. During that lookup, an attacker may try to substitute a fake DNS answer, causing the browser to connect somewhere else without an obvious warning.

In a DNS spoofing attack, the attacker injects a forged response before the genuine reply arrives. The device accepts the false answer and follows the destination it contains. The browser can then open a phishing site, meaning a deceptive page designed to mislead the visitor, or a site that distributes malware, which is harmful software. From the user’s perspective, the lookup happened automatically and the requested page appeared, so the redirection may not be visible.

The timing is central to this form of DNS spoofing. The attacker is not necessarily changing the website address that the user typed. Instead, the attacker is interfering with the answer that tells the browser where that address should lead. If the forged response is accepted first, the legitimate reply arriving afterward does not undo the connection that has already started. The immediate victim is the device that accepted the false answer.

Cache poisoning places the deception at a different point. A resolver, the DNS system that receives a user’s question and obtains an answer, commonly keeps recently requested results in a cache. A cache is temporary stored information that can be reused instead of being requested again immediately. If an attacker plants a bogus DNS record in that cache, the resolver can continue returning the false destination whenever users ask for the affected domain.

That changes the scale of the problem. DNS spoofing can target a particular exchange between a device and DNS, while cache poisoning makes the resolver itself repeatedly distribute the planted answer. Every user who relies on that poisoned cache may receive the same false result until the bogus record is no longer being served. It does not poison DNS everywhere, but it can affect everyone receiving that cached answer from the compromised resolver.

Both attacks are difficult for an ordinary user to notice because DNS normally works out of sight. A person enters the expected domain, the browser requests a destination, and a page loads. Neither the browser’s routine lookup nor the presence of a familiar address necessarily tells the person that the DNS answer was forged. A convincing phishing page can therefore appear to be the expected destination, while a malware site can be reached through what looked like an ordinary browsing action.

Domain Name System Security Extensions (DNSSEC) addresses the authenticity of DNS records. It uses signature verification, a mathematical check that establishes whether a DNS record is genuine and unchanged. When DNSSEC is properly deployed and checked, a forged record fails that verification instead of being accepted as authentic. This is directly relevant to bogus answers and poisoned cache entries because the false record cannot pass the required signature check.

DNSSEC does not encrypt the DNS request or conceal it from someone observing the network. Its role is to verify records, not to protect the transport path. That distinction matters because a valid signature check and a private connection solve different parts of the problem.

Encrypted DNS protects the journey between a device and the DNS service. DNS over HTTPS (DoH) carries DNS through an encrypted HTTPS connection, DNS over TLS (DoT) uses an encrypted Transport Layer Security connection, and DNS over QUIC (DoQ) uses the encrypted QUIC transport protocol. These methods prevent a network observer from tampering with the DNS query while it is in transit.

Encryption alone does not establish that every DNS record is genuine. It protects the query’s transport from an observer on that path, but it does not replace DNSSEC’s signature verification. Likewise, DNSSEC does not replace encrypted transport. Using both addresses two separate questions: whether someone can interfere with the query on the network, and whether the returned DNS record can be verified as authentic.

For website owners, DNSSEC is relevant to the records published for their domains. For users and IT teams, DoH, DoT or DoQ is relevant to the connection used to send DNS requests. Administrators should therefore examine both record verification and transport encryption rather than treating either one as a complete answer to every form of DNS manipulation.

As a relevant service option, AEU DNS offers private, secure DNS for everyone. The practical lesson is to match each defence to its actual role: DNSSEC rejects forged records that fail verification, while encrypted DNS prevents a network observer from altering a query in transit.