DNS spoofing — also called DNS cache poisoning — is one of the most insidious network attacks in existence because it hijacks the very system your browser trusts to find websites. A victim can type a perfectly correct URL, see a perfectly convincing webpage, and hand over credentials or payment details to an attacker without a single warning. Understanding exactly how this attack works, why DNS is vulnerable to it, and what you can do right now to close the gap is essential knowledge for anyone running a network, a website, or even just a home router.
What Is DNS Spoofing
DNS spoofing is the act of injecting forged DNS records into a resolver's cache so that queries for a legitimate domain return an attacker-controlled IP address instead of the real one. Every DNS resolver — whether it lives on your ISP's infrastructure, your company's on-premises server, or your home router — maintains a cache of recent answers to speed up lookups. If an attacker can get a fraudulent record into that cache before the legitimate answer arrives, every device that trusts that resolver will be silently redirected for as long as the record's TTL keeps it alive.
The result is a transparent man-in-the-middle scenario. The victim's traffic flows to a rogue server. The attacker can serve a cloned login page, intercept unencrypted communications, deliver malware, or simply observe what the victim does. Because the URL bar still shows the correct domain name, most users never suspect anything.
Why DNS Is Vulnerable
The original DNS protocol, defined in RFC 1034 and RFC 1035, was designed in the early 1980s for a small, trusted academic network. It uses UDP by default, which means there is no connection handshake and no built-in authentication. A resolver sends a query with a 16-bit transaction ID and accepts the first response that matches that ID and the source port. Early implementations used predictable transaction IDs (0, 1, 2 ...) and a fixed source port of 53, which made forgery trivially easy.
Modern resolvers randomize both the transaction ID and the source port, increasing the search space to roughly 32 bits. That sounds large, but an attacker on a fast connection can flood a resolver with forged responses, and given enough tries — or a lucky race condition — a poisoned record lands in cache. This is the classic birthday attack variant applied to DNS, and it is exactly the technique Dan Kaminsky publicized in 2008, which forced an emergency coordinated patch across the entire DNS industry.
The Mechanics of a Cache Poisoning Attack Step by Step
- Trigger a query. The attacker causes the target resolver to send a query it does not already have cached. This can be as simple as embedding an image tag pointing to victim.com on a page the attacker controls, causing a visitor's browser to ask the resolver for victim.com.
- Race the legitimate answer. The moment the resolver's UDP query leaves its socket, the attacker begins flooding the resolver with forged UDP responses, each guessing a different transaction ID and source port combination.
- Win the race. If a forged packet matches the transaction ID, source port, and question section before the real authoritative answer arrives, the resolver accepts it and stores the fake record in its cache.
- Wait for victims. Every device that queries that resolver for victim.com during the TTL window now receives the attacker's IP address. The attacker's rogue server handles the connection while optionally proxying the real site to avoid suspicion.
A variant called on-path DNS spoofing skips the race entirely. If the attacker already sits between the resolver and the authoritative server — on a compromised router, a hostile Wi-Fi access point, or a BGP-hijacked transit path — forging responses is trivial because the attacker controls the wire.
Real-World Attack Scenarios
DNS spoofing is not purely theoretical. In 2018, attackers poisoned DNS records for Brazilian banks by compromising the registrar accounts, redirecting customers to credential-harvesting clones for hours. In 2019, a campaign dubbed Sea Turtle targeted registrars and DNS providers across the Middle East and North Africa, redirecting government and military domains. In both cases, attackers combined DNS manipulation with valid TLS certificates obtained through the ACME protocol against the spoofed domains — proving that HTTPS alone does not protect you if DNS is already compromised.
How to Detect DNS Spoofing
Detection is possible at several layers. The fastest manual check is to compare the IP address your resolver returns against what authoritative servers report. Use the DNS Lookup tool to query a domain directly against multiple public resolvers and compare results. If your local resolver returns a different IP than 8.8.8.8, 1.1.1.1, and 9.9.9.9 all agree on, treat it as a red flag.
On Linux and macOS, you can do this from the command line:
On Windows:
If the local answer differs, flush your DNS cache immediately and switch to a trusted resolver temporarily:
For continuous monitoring on a network, tools like PassiveDNS and dnstop record historical DNS traffic so anomalous changes in A or AAAA records are visible over time. Enterprise solutions such as Cisco Umbrella and Infoblox include real-time anomaly detection specifically for this threat.
How to Prevent DNS Spoofing
Enable DNSSEC on Your Zones
DNSSEC (DNS Security Extensions) cryptographically signs every DNS record. A validating resolver verifies the signature chain from the root all the way down to the answer. A forged record cannot carry a valid signature, so the resolver rejects it. If you host a domain, enabling DNSSEC is the single highest-impact action you can take. Most major registrars support it with a few clicks.
Check whether a domain has DNSSEC enabled:
On the resolver side, configure your recursive resolver to validate DNSSEC. In BIND:
In Unbound:
Use DNS over HTTPS or DNS over TLS
Even with DNSSEC, the DNS query itself travels in plaintext, allowing on-path attackers to see what you are looking up and to drop or delay responses. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the entire DNS conversation, removing the opportunity for interception or injection at the transport layer. Configure your operating system or browser to use a trusted encrypted resolver:
On Windows 11, go to Settings > Network and Internet > Wi-Fi (or Ethernet) > Hardware Properties > DNS server assignment > Edit, enter a DoH-capable resolver such as 1.1.1.1 or 8.8.8.8, and set the DNS over HTTPS dropdown to On (automatic template).
Harden Your Router's DNS Configuration
Home and small-office routers are frequent targets because they serve as the resolver for every device on the network. A compromised router DNS setting redirects the entire LAN silently.
Netgear routers (routerlogin.net or 192.168.1.1): Navigate to Advanced > Setup > Internet Setup and hard-code the DNS servers to 1.1.1.1 and 1.0.0.1 rather than leaving them as ISP-assigned. Disable remote management under Advanced > Remote Management.
TP-Link routers (tplinkwifi.net or 192.168.0.1): Go to Advanced > Network > Internet > DNS, set primary to 9.9.9.9 (Quad9 with DNSSEC validation) and secondary to 149.112.112.112. Update firmware under Advanced > System Tools > Firmware Upgrade.
ASUS routers (asusrouter.com or 192.168.1.1): Navigate to WAN > Internet Connection > WAN DNS Setting, disable Connect to DNS Server automatically, and enter your chosen resolvers. Enable DoT under WAN > DNS Privacy Protocol if your firmware version supports it (Merlin builds or firmware 386+).
Linksys routers (192.168.1.1): Go to Connectivity > Internet Settings > DNS 1 / DNS 2 and manually enter trusted resolver IPs. Change the default admin password immediately under Connectivity > Administration to prevent attackers from changing DNS settings via the router's web UI.
Deploy Source Port Randomization and Response Rate Limiting
If you run your own recursive resolver, verify that source port randomization is active. Modern BIND and Unbound do this by default, but some embedded or legacy resolvers do not. Also enable Response Rate Limiting (RRL) on authoritative servers to prevent your infrastructure from being used as an amplification vector:
Monitor TTLs for Anomalies
Attackers who successfully inject a record often set a very high TTL to keep their poisoned entry alive as long as possible. Conversely, a real domain owner preparing for a migration might legitimately lower TTLs. Any TTL on a critical domain that suddenly jumps from 300 seconds to 86400 seconds (24 hours) without a corresponding change at the registrar warrants investigation.
What to Do If You Suspect Active Spoofing
- Immediately stop submitting any credentials or sensitive data on the affected connection.
- Switch to a cellular data connection and compare DNS answers for the affected domain using multiple public resolvers.
- Flush the DNS cache on all affected devices and routers (commands above).
- Check your router's DNS settings for unauthorized changes at the admin panel — attackers who compromise routers change the DNS settings there.
- Check for unauthorized DNS server entries in your network adapter settings: on Windows, Control Panel > Network Connections > right-click adapter > Properties > IPv4 > Properties.
- If router credentials were likely compromised, factory-reset the device, update firmware, and set a strong unique admin password before reconfiguring.
- File a report with your ISP if their resolver is returning incorrect answers — this may indicate infrastructure-level compromise that affects many customers.
The Bigger Picture: Why HTTPS Is Not Enough
A common misconception is that HTTPS eliminates the DNS spoofing threat. It reduces it significantly but does not eliminate it. HTTPS verifies that you are talking to a server that holds the private key for a certificate issued to the domain name — but Certificate Authorities will issue certificates to whoever can prove control of the domain, and if DNS is spoofed, an attacker can redirect the ACME HTTP-01 challenge to their own server and obtain a legitimate certificate for a domain they do not own. This is exactly what happened in the Sea Turtle campaign.
Mitigations at the certificate layer include CAA records (which restrict which CAs can issue for your domain) and Certificate Transparency logs combined with monitoring services that alert you when a new certificate is issued for your domain. Neither of these stops the attack in real time, but CT log monitoring gives you rapid detection so you can respond before the spoofed records expire.
The only complete defense is a combination of DNSSEC to authenticate records, DoH or DoT to protect the transport, strong router and resolver hardening to prevent unauthorized configuration changes, and ongoing monitoring. Any single layer in isolation leaves gaps an attacker can exploit.
Key Takeaways
- DNS spoofing injects forged records into resolver caches, silently redirecting users to attacker-controlled servers.
- The attack works because the original DNS protocol has no built-in authentication and relies on easily-forgeable UDP.
- DNSSEC cryptographically signs records and is the strongest protocol-level defense; enable it on every zone you control.
- DNS over HTTPS or DNS over TLS encrypts queries end-to-end, blocking on-path injection.
- Harden your router by hard-coding trusted DNS servers, keeping firmware updated, and disabling remote management.
- HTTPS alone is not a complete defense — combine it with CAA records and Certificate Transparency monitoring.
- Detection is straightforward: compare your local resolver's answers against multiple independent public resolvers and investigate any discrepancy immediately.