What Is DNS Spoofing? How It Works and How to Stop It

DNS Spoofing in Brief: DNS spoofing injects forged records into a DNS resolver's cache, substituting legitimate IP addresses with attacker-controlled ones. It exploits the DNS protocol's lack of native authentication. Targeted users are redirected to malicious sites without any visible browser warning. DNSSEC (DNS Security Extensions) is the primary technical defense: it adds cryptographic signatures to DNS records that resolvers verify before accepting a response.

DNS spoofing is a cyberattack in which an attacker inserts forged records into a DNS resolver's cache, redirecting users from a legitimate website to an attacker-controlled server. The user sees no warning. Their browser loads the wrong site, and every credential they enter goes directly to the attacker.

The attack works because DNS was not built with authentication in mind. The original DNS protocol operates over UDP with no built-in mechanism to verify whether a response came from a legitimate authoritative server. Attackers exploit that gap by racing a forged response to the resolver before the legitimate one arrives.

What Is DNS Spoofing?

DNS spoofing, also called DNS cache poisoning, is an attack that corrupts the DNS resolution process by substituting legitimate IP address mappings with malicious ones. When users query a poisoned resolver, their browsers connect to the attacker's server rather than the intended destination.

The terms DNS spoofing and DNS cache poisoning are often used interchangeably, but they are not identical. DNS cache poisoning is a specific technique: it injects forged records directly into a resolver's cache. DNS spoofing is the broader category, which includes cache poisoning as well as interception attacks on DNS traffic in transit and direct compromise of authoritative DNS servers. Every cache poisoning attack is a form of DNS spoofing. The reverse is not always true.

DNS records are not authenticated by default. The original DNS protocol, defined in RFC 1035, was built for reliability. Security was not part of the original specification. Because resolvers have no native way to verify that a response came from the legitimate authoritative server, an attacker who can get their forged response to the resolver first wins the exchange.

Also see: Combining WHOIS Data with DNS and SSL for Deeper Analysis Insights

How DNS Spoofing Works

Understanding DNS spoofing requires understanding the normal resolution process it disrupts. When a user types a domain into their browser, the following happens:

• The client sends a query to a recursive resolver, typically operated by the ISP or a public DNS provider.
• If the resolver has a cached answer, it returns that IP address immediately and the browser connects.
• If not, the resolver queries a root nameserver, which points it to the correct TLD server (.com, .org, .net, etc.).
• The TLD server directs the resolver to the domain's authoritative nameserver.
• The authoritative nameserver returns the correct IP address. The resolver caches this response and returns it to the client.

DNS spoofing attacks step 2. The attacker's goal is to insert a forged record into the resolver's cache before the legitimate response arrives. A classic method exploits the limited transaction ID space in DNS queries: attackers flood a resolver with forged responses for a targeted domain, hoping one matches the outgoing query ID. Once accepted, the poisoned record persists in the cache until its TTL expires. The 2008 Kaminsky vulnerability showed that resolvers lacking source-port randomization could be poisoned rapidly under favorable network conditions.

Attackers can also use ARP spoofing to position themselves on the local network between a client and its resolver, intercepting DNS queries before they reach the legitimate server and returning forged responses directly. This is the MitM variant of DNS spoofing and does not require touching the resolver's cache at all.

DNS Spoofing vs DNS Cache Poisoning

These two terms appear interchangeably in most documentation, but they describe different scopes. The distinction matters when selecting defenses.

Every cache poisoning attack is a form of DNS spoofing. Not every DNS spoofing attack involves the cache. An attacker using ARP spoofing to intercept DNS traffic in transit, for example, bypasses the resolver's cache entirely.

Types of DNS Spoofing Attacks

1. DNS Cache Poisoning

DNS cache poisoning targets a recursive resolver's stored records. Attackers send forged DNS responses that match the transaction ID of an outgoing query. If accepted, the resolver stores the attacker's IP address under the legitimate domain name. Every user of that resolver is then redirected to the malicious server until the cache entry expires.

DNS caching exists to improve performance: resolvers store answers to reduce round-trip queries to authoritative servers. Attackers exploit this performance optimization by poisoning those stored answers. The cache becomes the delivery mechanism for the attack.

The 2008 Kaminsky vulnerability demonstrated the scale of the problem. Resolvers that lacked source-port randomization could be poisoned rapidly for a targeted domain under favorable network conditions. The fix was patched into BIND and other major resolvers within 30 days. Unpatched resolvers remain vulnerable to variants of this technique.

2. DNS Hijacking

DNS hijacking changes the query destination rather than poisoning a cache. Attackers compromise the resolver itself, either by exploiting router vulnerabilities, installing malware on endpoints that redirect DNS queries, or making unauthorized changes to ISP-level DNS configurations. A compromised resolver answers all queries through the attacker's server, not just queries for a targeted domain.

NS record and A record tampering are the primary mechanisms. An attacker who controls the resolver can return a malicious A record for any domain at will, with no need to win a timing race against a legitimate response.

Continuous domain monitoring can alert security teams when DNS records for watched domains change unexpectedly, which is a reliable early indicator of DNS hijacking at the infrastructure level.

3. DNS Response Modification

Response modification intercepts a legitimate DNS response in transit and alters the IP address before it reaches the client. The resolver sends a valid query to the authoritative server; the attacker captures the response mid-flight and substitutes a different IP address.

Executing this attack requires a network-level position between the resolver and the authoritative server, which makes it harder to carry out than cache poisoning. However, in environments with weak network segmentation or on shared infrastructure, the attacker's vantage point is achievable. NS record tampering enables the substitution. The client and resolver see a structurally valid DNS response; only the IP address has changed.

4. Pharming

Pharming redirects users at scale by corrupting DNS resolution at the infrastructure level. Rather than targeting a single session, pharming attacks modify the resolution layer that all users of a given resolver or network share.

Tactics include compromising the hosts file on individual machines (host-based pharming), altering DNS settings on a router (network-level pharming), or combining DNS cache poisoning with automated phishing landing pages that activate when users reach the spoofed site. A record, NS record, and CNAME record manipulation are all used depending on which layer the attacker controls.

Pharming is particularly effective in environments where many users share a single resolver and where those users have limited ability to inspect or question the DNS responses they receive.

5. Man-in-the-Middle (MitM) DNS Attack

In a MitM DNS attack, the attacker positions themselves between the client and the resolver, intercepting queries and returning fabricated responses. ARP spoofing is the standard entry point: the attacker broadcasts forged ARP messages associating their MAC address with the router's IP. DNS queries the client intends for the legitimate resolver are routed through the attacker's machine instead.

Unlike cache poisoning, MitM DNS attacks affect only clients on the compromised network segment. The resolver's cache is untouched. A records, NS records, and PTR records are all at risk. PTR record tampering is particularly relevant because some security monitoring tools use reverse DNS to identify hosts; a compromised PTR record can cause a malicious server to appear legitimate in those logs.

What Are the Risks of DNS Spoofing?

DNS spoofing's most direct consequence is traffic interception. Once an attacker controls where a domain resolves, they can harvest credentials, serve malware, manipulate ad traffic, or deny access entirely. The risks fall into three categories covering the majority of real-world damage.

1. Credential Theft and Financial Fraud

A spoofed login page for a bank, SaaS platform, or corporate VPN is visually indistinguishable from the legitimate site. Users enter their credentials without knowing they are on a fraudulent server. The attacker captures usernames, passwords, and in some configurations multi-factor authentication codes. Those credentials can be used immediately for account takeover, sold on underground markets, or held for targeted fraud.

The attack is particularly effective because users trust the visual appearance of a familiar site more than they trust technical indicators. Most users do not check the TLS certificate before logging in.

2. Malware Distribution and Ransomware Delivery

Spoofed sites serve malicious payloads disguised as legitimate software updates, browser plugins, or document downloads. The user never navigated to a suspicious site. The DNS layer sent them there before the browser had any opportunity to evaluate the destination.

A single endpoint infected through a DNS spoofing redirect can escalate. Ransomware planted on one device often moves laterally across a corporate network, encrypting shared drives and backup infrastructure. The initial infection point, a redirected download, is easy to overlook in a post-incident investigation.

3. Legal and Regulatory Exposure

Organizations that fail to protect DNS infrastructure face regulatory consequences alongside the operational damage. GDPR requires organizations to implement appropriate technical measures to protect personal data; a DNS spoofing attack that exposes customer credentials triggers mandatory breach notification obligations in most EU member states. HIPAA holds US healthcare organizations to comparable standards.

Reputational damage compounds the legal exposure. A widely publicized DNS hijacking incident affecting customer accounts typically outlasts the technical incident itself in terms of customer trust and media coverage.

How to Detect a DNS Spoofing Attack

The following steps are written for DNS administrators and security engineers with access to resolver infrastructure and network monitoring tools. Detection is harder than prevention because the attack happens at the network layer before the browser loads anything. These three methods give security teams the most reliable signal of an active attack.

1. DNSSEC Validation Logs

DNSSEC-validating resolvers log signature verification failures. If a resolver receives a response that fails DNSSEC validation for a signed domain, that is a direct indicator of a spoofing attempt. Review BIND, Unbound, or your commercial resolver's logs for SERVFAIL responses on DNSSEC-signed zones. Repeated validation failures for a specific domain warrant immediate investigation.

2. DNS Cache Inspection and Authoritative Comparison

Compare the IP addresses stored in your resolver's cache against the authoritative DNS records for your critical domains. A discrepancy between what your internal resolver returns and what the authoritative server returns for the same domain is a strong indicator of cache poisoning.

WhoisFreaks DNS Lookup can query live authoritative DNS records for any domain. Run a comparison between those authoritative records and what your internal resolver returns for the same hostname. Any mismatch deserves investigation.

3. Network Traffic Monitoring

Unusual patterns in DNS traffic can indicate an active attack. Specific signals to monitor include: sudden spikes in queries for a single domain, multiple responses arriving for a single outgoing query (a sign of a response-flooding attempt), unexpected NXDOMAIN rates, or high volumes of queries for domains that should resolve consistently.

Tools useful for this detection layer:

• Zeek (formerly Bro): Network analysis framework with a dedicated DNS log. Can alert on anomalous response counts and unexpected IP changes per domain.
• Snort: Network intrusion detection system with DNS-specific rules for detecting cache poisoning patterns and response flooding.
• Commercial SIEM platforms: Most enterprise SIEMs support DNS anomaly detection rules out of the box, including sudden changes in resolved IPs for monitored domains.

How to Prevent DNS Spoofing Attacks

DNS spoofing defense requires layers. Steps 1 through 3 below are infrastructure-level controls for DNS administrators. Steps 4 and 5 apply to individual users and teams without resolver access. DNSSEC protects the resolver-to-authoritative-server path. DNS over TLS and DNS over HTTPS protect the client-to-resolver path. A secure resolver adds filtering. No single measure covers the full attack surface.

1. Deploy DNSSEC

DNSSEC adds cryptographic signatures to DNS records. Each response includes a digital signature that the resolver verifies against the zone's public key before accepting the record. Forged responses, which lack valid signatures, are discarded. DNSSEC is defined in RFC 4033 through RFC 4035 and is supported by all major TLD operators and modern resolver software.

Deployment requires action on both sides. The authoritative nameserver must sign the zone records. The resolver must be configured to validate signatures. Both must be active for DNSSEC to provide protection. Enabling DNSSEC on the authoritative side alone, without validating resolvers, provides no security benefit.

2. Use DNS over TLS or DNS over HTTPS

DNS over TLS (DoT, port 853) and DNS over HTTPS (DoH, port 443) encrypt queries between clients and resolvers. This protects against interception attacks where an attacker captures DNS traffic in transit before it reaches the resolver.

DoH is supported natively in Chrome, Firefox, Edge, and Safari, and at the operating system level in Windows 11 and Android 9 and later. DoT is more common at the network infrastructure level. Neither replaces DNSSEC: DoT and DoH protect the client-to-resolver path; DNSSEC protects what happens after the resolver queries the authoritative server.

3. Patch Resolver Software Regularly

Known cache poisoning vulnerabilities are regularly found and patched in DNS resolver software. The Kaminsky attack and subsequent variants are patched in current versions of BIND, Unbound, and commercial resolvers. Running outdated resolver software means running known, exploitable vulnerabilities. Apply patches on the same cycle as your other critical network infrastructure.

4. Use a VPN on Untrusted Networks

On public or untrusted networks, DNS queries are exposed to any attacker who can intercept traffic on that segment. A VPN routes all traffic through an encrypted tunnel to the VPN provider's resolver, preventing local network interception.

A VPN protects the client-to-resolver path in the same way DoT and DoH do, but at the transport level rather than the DNS layer. It does not protect against a compromised resolver at the VPN provider's end. VPN protection is one layer of a layered defense, not a standalone solution.

5. Deploy a Secure, Validating DNS Resolver

Public resolvers that perform DNSSEC validation and block known malicious domains reduce the attack surface without requiring infrastructure changes. Cloudflare's 1.1.1.1 and Google's 8.8.8.8 both validate DNSSEC and offer malware-blocking variants (1.1.1.2 and 8.8.8.8 with Safe Browsing enabled, respectively).

For enterprise environments, a dedicated internal resolver with strict zone policies, DNSSEC validation, and query logging provides visibility and control that public resolvers cannot match.

Real-World DNS Spoofing Examples

DNS spoofing attacks have affected both commercial infrastructure and government networks.

MyEtherWallet (2018): In April 2018, attackers used a BGP route hijack to reroute DNS queries for MyEtherWallet through a malicious resolver hosted on servers associated with Russian network infrastructure. Users who visited the site were redirected to a phishing replica. Blockchain analysis confirmed approximately $17 million in Ethereum was stolen before the attack was identified. The attack combined BGP manipulation with DNS spoofing, illustrating how the two techniques compound each other.

Sea Turtle Campaign (2019): Cisco Talos researchers documented a DNS hijacking campaign they tracked as Sea Turtle, active from at least 2017 through 2019. The threat actor compromised at least 40 organizations across 13 countries, including telecommunications providers, internet registrars, and government ministries in the Middle East and North Africa. The attackers modified NS records at the registrar level, giving them control over DNS resolution for targeted organizations without touching the organizations' own infrastructure.

Both cases illustrate the same underlying problem: DNS provides no native means for clients to verify the authority behind a response. DNSSEC validation and registrar-level account security controls are the primary structural defenses against both attack patterns.

Conclusion

DNS spoofing works because DNS was not built with authentication in mind. Resolvers trust responses they receive. Anything that delivers a matching, faster response than the legitimate authoritative server wins the exchange.

The defense is layered. DNSSEC validates record authenticity at the authoritative-to-resolver stage. DNS over TLS and DoH encrypt the client-to-resolver stage. A validating resolver adds filtering against known malicious domains. Each layer closes a different part of the attack surface; removing any one of them leaves a gap.

For security teams monitoring domain infrastructure, tracking DNS record changes is a core detection capability. If an A record or NS record for a domain you own or monitor changes without a corresponding change request in your DNS management console, that is a direct signal of potential hijacking. The WhoisFreaks DNS Lookup lets you query live authoritative DNS records for any domain. Teams automating this comparison can use the WhoisFreaks DNS API to track DNS record changes in real time across monitored domains.

Frequently Asked Questions

What is the difference between DNS spoofing and DNS cache poisoning?

DNS cache poisoning is a specific technique within the broader category of DNS spoofing. Cache poisoning injects forged records into a resolver's cache. DNS spoofing includes cache poisoning but also covers interception attacks on DNS traffic in transit and direct compromise of authoritative DNS servers. All cache poisoning is DNS spoofing. Not all DNS spoofing involves the cache.

How do I know if I've been a victim of DNS spoofing?

Common signs include SSL certificate warnings for sites you visit regularly, login pages that look slightly different from expected, or being redirected after entering a known URL. At the network level, comparing your resolver's cached IP for a critical domain against the authoritative DNS record confirms whether poisoning has occurred. A mismatch between the two is the clearest indicator.

Does HTTPS protect against DNS spoofing?

Partially. HTTPS encrypts the connection and TLS certificate validation will generate a warning if the certificate does not match the expected domain. However, many users dismiss SSL warnings, and some attackers obtain fraudulent certificates for spoofed domains through compromised certificate authorities or domain validation. HTTPS is not a substitute for DNSSEC; they protect against different attack vectors.

How long does DNS cache poisoning last?

A poisoned cache entry persists until its TTL (Time to Live) value expires or an administrator manually flushes the cache. Attackers who can target domains with longer TTL values maximize the duration of the attack. Most DNS records carry TTL values between 300 seconds (5 minutes) and 86,400 seconds (24 hours). Flushing the resolver cache terminates the poisoning immediately.

Can a VPN fully prevent DNS spoofing?

No. A VPN prevents local network interception by routing DNS queries through an encrypted tunnel, which eliminates MitM attacks on public networks. It does not protect against cache poisoning at a compromised resolver or DNS hijacking of the VPN provider's own resolver. A VPN is one layer of a multi-layer defense.