DNS Spoofing Explained: Cache Poisoning & the DNSSEC Defense

Before a browser connects to a website, before an app reaches its API, before mail finds its server, the same quiet step happens: a name gets turned into an IP address. The Domain Name System does that translation billions of times a day, and almost nothing else works without it. Corrupt the answer to that lookup and you control where the connection goes, no matter what the user typed.

DNS spoofing does exactly that. The attacker supplies a false answer to a name query, and the victim connects to a server of the attacker's choosing while believing they reached the real one. Because DNS sits underneath everything, a successful spoof is a foothold for interception, phishing, and malware delivery all at once.

How DNS resolution works

When you look up a hostname, your device asks a resolver, usually one run by your network or your ISP. If the resolver already has a fresh answer cached, it returns it. If not, it walks the DNS hierarchy, querying authoritative servers until it learns the address, then caches that answer for a period set by the record's time-to-live.

The classic protocol carries no proof of authenticity. A resolver accepts a response if it arrives on the right transport and matches a few fields from the outstanding query, chiefly the query name, the source and destination, and a transaction ID. Historically the transaction ID and source port were the main unpredictable elements. If an attacker can guess or match them, the resolver has no way to tell a forged answer from a real one.

That gap is the whole attack surface.

The forms of DNS spoofing

DNS spoofing shows up in a few shapes, tracked by MITRE ATT&CK as DNS Spoofing (T1557.003).

• On-path forgery. An attacker already positioned between the victim and the resolver, for example through ARP spoofing on a LAN or a rogue access point, simply reads the outgoing query and races a forged answer back. Because they can see the query fields, matching them is trivial.
• Cache poisoning. The attacker tricks a resolver into caching a false record. Once poisoned, the resolver serves that bad answer to everyone who asks, until the TTL expires. This is the high-leverage version, since one success scales to every user of that resolver.
• Compromised or malicious resolver. If the attacker controls the resolver a victim uses, whether through a rogue DHCP-assigned DNS server or a malicious network, every answer can be forged at will.

The end effect is the same across all three. The victim's traffic is steered to an attacker-chosen destination while the name they requested looks perfectly correct.

Why blind poisoning got harder, then why it still matters

Older attacks against caches were blind. The attacker could not see the resolver's outgoing query, so they flooded forged answers trying to match the transaction ID before the real answer arrived. When the transaction ID was the only unpredictable field, the odds were uncomfortably good.

The response was source port randomization, which added a second unpredictable value the attacker also has to match. Combined with a random transaction ID, this widened the space enough to make blind poisoning far harder in practice. It raised the bar considerably.

It did not remove the problem. Randomization increases the work for a blind attacker but adds nothing against an on-path attacker who can read the query fields directly. And it provides no authentication of the answer itself. The record is still just data that the resolver trusts because it looks right.

What the attacker does with it

Redirection is the point, and where it leads depends on the target.

Spoofing target	Attacker outcome	What the victim sees
A bank or login page	Credential phishing on a lookalike host	Correct name, attacker's server
A software update host	Malware delivered as an update	A normal update flow
An email server record	Mail rerouted or intercepted	Delivery appears normal
An internal service name	Interception of internal traffic	A working internal connection
Any HTTPS host	A TLS certificate mismatch, if validation holds	A browser warning or a blocked connection

The last row is the important one. If the destination uses HTTPS with proper certificate validation, the attacker's server cannot present a valid certificate for the real name, so the connection fails or warns the user. DNS spoofing redirects the connection, but TLS still authenticates the endpoint. The two defenses cover different layers and reinforce each other.

How DNSSEC changes the picture

The DNS Security Extensions, introduced in RFC 4033, add cryptographic signatures to DNS records. Zone owners sign their records, and a validating resolver checks those signatures against a chain of trust anchored at the root. If a record's signature does not verify, the resolver treats the answer as bogus and refuses it.

This attacks the problem at its root cause. A forged record, whether injected on-path or flooded into a cache, will not carry a valid signature for the zone, so a validating resolver rejects it. DNSSEC provides data-origin authentication and integrity for the answer itself, which randomization never did.

DNSSEC has limits worth stating plainly. It authenticates records but does not encrypt them, so it does not hide your lookups from an observer. It protects only zones that are actually signed and only for resolvers that actually validate. Deployment across the internet is partial. Within those bounds, though, it is the direct answer to forgery.

How to defend against DNS spoofing

Layer authentication of the data with protection of the transport, and harden the resolvers in between.

1. Validate DNSSEC. Use resolvers that perform DNSSEC validation, and sign the zones you are authoritative for. This is the control that actually rejects forged records. Follow deployment guidance such as NIST SP 800-81-2.
2. Use encrypted DNS. DNS over HTTPS (DoH) or DNS over TLS (DoT) encrypts the query and answer between client and resolver, stopping an on-path attacker from reading or rewriting them in transit. It complements DNSSEC rather than replacing it.
3. Run trusted resolvers. Point clients at resolvers you control or explicitly trust, and protect DHCP so an attacker cannot hand out a rogue DNS server. Keep resolver software patched.
4. Keep query randomization on. Modern resolvers randomize source ports and transaction IDs by default. Ensure nothing in your stack undermines it. It is a useful floor even though it is not sufficient alone.
5. Serve everything over authenticated TLS. When DNS is spoofed, strict certificate validation is the backstop that stops the redirected connection from succeeding against a lookalike server.
6. Harden the local network. Because on-path DNS forgery often rides on ARP spoofing or rogue access points, the LAN defenses that stop those attacks also cut off the easiest route to DNS interception.

For a sense of which adversaries lean on DNS redirection and interception in their operations, our Threat Group Directory connects groups to the network techniques they use.

A cache poisoning attempt, walked through

It helps to trace the sequence a blind poisoning attempt follows, because seeing the timing makes clear why each defense lands where it does. Assume the attacker wants a recursive resolver to cache a false address for a target hostname, and assume they cannot see the resolver's outbound queries.

First, the attacker triggers a lookup. They ask the resolver to resolve the target name, or a name in the same zone, so the resolver has an outstanding query on the wire to an authoritative server. The resolver picks a source port and a transaction ID for that query, waits for the authoritative server to answer, and will accept the first response that matches those values along with the question section.

Second, the attacker floods. Before the genuine answer returns, they send a burst of forged responses, each guessing a transaction ID and aimed at the port they hope the resolver used. Every forged packet claims to come from the authoritative server and carries the attacker's chosen address in the answer. If one forged packet matches the resolver's port and transaction ID while the query is still open, the resolver accepts it, caches the false record for the record's time-to-live, and discards the real answer as a late duplicate.

Third, the attacker widens the odds. A single name has one query in flight at a time, and once the real answer lands the window closes until the TTL expires. Techniques that provoke many simultaneous outstanding queries, for example by asking for many distinct non-existent names in the target zone, give the attacker many parallel races instead of one, and a way to keep racing without waiting for a cached record to age out. This is the shape that made classic blind poisoning practical enough to worry about.

The defenses map straight onto this sequence. Source port randomization multiplies the values the flood has to match, so the guessing gets far more expensive. Encrypted DNS between client and resolver removes the on-path shortcut where an attacker just reads the query fields instead of guessing them. DNSSEC ends the race outright, because a forged answer carries no valid signature and a validating resolver drops it no matter how well the port and transaction ID were guessed.

Detection signals

DNS forgery is quiet, but it leaves observable traces when you are watching the resolver and the answers it returns. Concrete indicators worth alerting on:

• A spike in inbound DNS responses that do not match any outstanding query. A flood of forged answers produces many responses the resolver had no pending question for. Servers that count and log these unsolicited or mismatched responses give you a direct signal of a poisoning attempt in progress.
• Answers that disagree with a second, trusted resolver. Resolving the same name through an independent path and comparing the result catches a poisoned cache. A record that differs only from one resolver, and reverts when that cache is cleared, is a strong lead.
• A cached address that does not belong to the domain owner. An answer pointing at an IP range with no relationship to the organisation that owns the name, especially for a high-value host like a login or update server, deserves immediate review.
• DNSSEC validation failures clustering in time. For signed zones, a validating resolver logs bogus answers when signatures do not verify. A sudden cluster of validation failures for a specific zone can mean someone is injecting forgeries that DNSSEC is catching.
• Unexpected TTL patterns. A poisoned record is often injected with an unusually long TTL so it survives in the cache as long as possible. A record whose TTL looks nothing like the zone's normal values is worth a second look.
• Rogue DNS server assignments. On the endpoint side, clients configured with a DNS server nobody recognises, often handed out by a rogue DHCP responder, point at the compromised-resolver form of the attack rather than a poisoned cache.

How DNS spoofing compares to related attacks

DNS spoofing is often confused with neighbouring techniques that also redirect or hijack a name. The distinctions matter because the defenses differ.

Technique	What it corrupts	Where it operates	Primary defense
DNS spoofing / cache poisoning	The answer to a name lookup	Resolver cache or the query path	DNSSEC validation, encrypted DNS
Domain hijacking	The registration of the domain itself	The registrar or registry account	Registrar lock, strong registrar auth
BGP hijacking	The route packets take to an IP	Internet routing between networks	RPKI, route monitoring
ARP spoofing	The MAC-to-IP mapping on a LAN	The local network segment	Dynamic ARP inspection, static entries
Rogue DHCP	The DNS server a client is told to use	Client network configuration	DHCP snooping, trusted DHCP only

DNS spoofing sits at the naming layer. Domain hijacking changes the authoritative data at the source, so DNSSEC signed by the hijacker would still validate, which is why account security at the registrar is the control there. BGP hijacking leaves the name correct but sends the traffic for its IP down the wrong path. ARP spoofing and rogue DHCP are the LAN-level footholds that often put an attacker on-path in the first place, from which DNS forgery becomes trivial. Treating these as one problem leads to the wrong fix. Treating them as a chain, where a LAN foothold enables on-path forgery, is closer to how real intrusions unfold.

Common misconceptions

A few beliefs about DNS spoofing lead teams to the wrong conclusions.

• "We use HTTPS, so DNS spoofing cannot hurt us." HTTPS authenticates the endpoint once the connection reaches it, which does stop a redirected connection from succeeding against a lookalike with strict certificate validation. It does nothing to stop the redirection itself, and it does not protect protocols that lack that endpoint authentication. A spoofed answer can still break availability, feed a downgrade attempt, or hit a service that does not validate certificates.
• "Randomized ports fixed cache poisoning." Randomization raised the cost of blind guessing considerably. It provides no authentication and no protection against an on-path attacker who reads the query fields directly. The record is still trusted because it looks right.
• "DNSSEC encrypts my DNS." DNSSEC signs records for authenticity and integrity. It does not hide the query or answer from an observer. Confidentiality comes from encrypted transport such as DoH or DoT, which is a separate control.
• "Only ISPs run resolvers worth attacking." Any resolver with many users behind it is a high-value cache to poison, including the resolver inside a corporate network or a home router. Home and small-office routers running old firmware are a common soft target precisely because they are rarely patched.
• "A spoofed record lasts forever." A poisoned cache entry lives only for its TTL unless the attacker keeps re-injecting it. That is why attackers favour long injected TTLs and repeatable techniques, and why flushing a suspect cache is a valid immediate response while you investigate.

How DNS spoofing evolved

The attack is nearly as old as the protocol. Early DNS software made outbound queries easy to predict, and for a period the transaction ID was effectively the only unpredictable field an attacker had to match, which made blind poisoning uncomfortably feasible. The response arrived in stages. Implementers added source port randomization so an attacker had to match a second value drawn from a large range, which turned a plausible guess into an expensive flood. Around the same time the DNS Security Extensions matured into a deployable standard, moving the defense from making forgery hard to making forged data verifiably invalid. In parallel, encrypted transports for DNS, DoT and then DoH, addressed the on-path reading and rewriting that randomization never touched. The direction across all of it is consistent: from obscurity, to statistical difficulty, to cryptographic authentication of the data and encryption of the path. Each layer closed a door the previous one left open, and the modern posture combines all of them because each still covers a failure the others do not.

Frequently asked questions

Is DNS spoofing the same as DNS cache poisoning? Cache poisoning is one form of DNS spoofing, the one that plants a forged record in a resolver's cache so it is served to every user of that resolver. DNS spoofing is the broader term that also covers on-path forgery against a single victim and answers from a malicious or compromised resolver. All of it maps to MITRE ATT&CK T1557.003.

Does DNSSEC stop every kind of DNS spoofing? DNSSEC stops forged records from being accepted by a validating resolver for zones that are actually signed. It does not help for unsigned zones, for resolvers that do not validate, or against an attacker who has taken over the authoritative source or the domain registration, because data they publish would be signed legitimately. It also does not encrypt anything.

If a site uses HTTPS, why worry about DNS spoofing at all? Because DNS sits underneath the connection. HTTPS with strict validation will fail or warn when a spoof points the browser at a lookalike, which is a real backstop. It does not stop the redirection, it does not protect non-HTTPS services, and it does not help clients that skip certificate validation. DNS integrity and TLS authentication cover different layers and you want both.

Can I detect cache poisoning without DNSSEC? Partly. You can compare answers for high-value names against an independent resolver, watch for a surge of unsolicited DNS responses at your resolver, and flag cached addresses that do not belong to the domain owner. These catch many attempts, though they are reactive. DNSSEC validation is the control that rejects the forgery at the moment it arrives.

Why does source port randomization matter if it is not authentication? It multiplies the values a blind attacker must match, turning a feasible guess into a much larger flood and buying time for the genuine answer to arrive and close the window. It is a useful floor that raises cost. It stops nothing for an on-path attacker and proves nothing about who sent an answer, which is why it is a complement to authentication rather than a substitute.

What is the fastest response if I suspect a resolver is poisoned? Flush the resolver cache to drop the suspect record, then resolve the affected names through an independent trusted path to confirm the correct answers. Point critical clients at a known-good validating resolver while you investigate, and check whether clients were handed a rogue DNS server by DHCP, which would indicate the compromised-resolver form rather than a poisoned cache.

Does encrypted DNS such as DoH make DNSSEC unnecessary? No. Encrypted DNS protects the path between client and resolver, so an on-path attacker cannot read or rewrite queries in transit. It does nothing about a forged record injected into the resolver's cache from elsewhere, or a poisoned upstream. DNSSEC authenticates the record itself. The two solve different problems and are strongest together.

DNS spoofing is powerful because it corrupts the lookup that everything else depends on, and it works because classic DNS answers carry no proof. Sign your zones, validate DNSSEC, encrypt the transport, and keep TLS strict on top, and the forged answer stops being believed at the layer where it is injected.

Related guides

• DNS Tunneling Explained
• DNSSEC Explained
• Man-in-the-Middle Attacks Explained
• How HTTPS Works