DNS cache poisoning happens when a DNS resolver, router, or local device stores a forged DNS answer and keeps sending users to the wrong IP address. A person can type the correct domain, but the poisoned cache returns an attacker-controlled destination instead. The practical risk is phishing, malware delivery, traffic interception, or failed access to legitimate services until the bad cached record expires or is removed.
The important distinction is where the change sits. DNS spoofing is the broader act of forging DNS answers, while DNS cache poisoning is the narrower case where the forged answer is saved and reused from cache. DNS hijacking usually changes DNS settings, router configuration, registrar access, or name-server control instead of poisoning a resolver cache.
What DNS Cache Poisoning Changes
DNS turns a readable name such as example.com into an IP address. To make browsing faster, recursive resolvers, routers, operating systems, and browsers cache DNS answers for the time allowed by the record’s TTL. If a forged answer lands in that cache, later requests may reuse the attacker-chosen IP address without asking the authoritative DNS server again.
A poisoned entry does not usually change the real domain or take the legitimate website offline. It changes the answer returned to users who rely on the poisoned cache. That is why one network, ISP resolver, office, router, or device may see the wrong destination while another network still reaches the real site.
How a Poisoning Attack Works
- An attacker tries to make a recursive resolver ask for a record that is not already cached.
- Before the real authoritative answer arrives, the attacker floods or races forged DNS responses.
- If a forged response matches the expected query details closely enough, the resolver accepts it.
- The resolver stores the false record until TTL expiry or manual cache clearing.
- Users who query that resolver are sent to the wrong IP address for the affected domain.
Modern resolvers make this harder by randomizing transaction IDs, source ports, query case, and other values. DNSSEC adds a stronger layer by letting validating resolvers reject unsigned or incorrectly signed DNS data. Still, misconfigured resolvers, vulnerable DNS software, compromised routers, malware, or unsafe local networks can keep DNS poisoning and DNS redirection relevant in real incidents.
Signs of DNS Cache Poisoning
DNS cache poisoning is hard to spot because the browser address bar can still show the domain the user typed. Treat these signs as suspicious, especially when several appear at the same time:
- A familiar domain opens a login page that looks slightly wrong, asks for unusual verification, or loses expected account state.
- The browser shows a certificate warning, mixed-content warning, or a certificate issued to a name you did not expect.
- The same domain resolves to different IP addresses on the affected network than it does on a trusted mobile hotspot or public resolver.
- Security updates, banking pages, webmail, or admin portals fail only on one network or one device.
- Router DNS settings, Windows adapter DNS, proxy settings, Secure DNS, or the hosts file changed without approval.
- A redirect disappears after switching DNS resolvers or after flushing local DNS cache, then returns after reconnecting to the same router.
How to Check a Suspicious Redirect
Do not enter passwords on a page that feels off. Compare DNS answers from the affected network against at least one trusted resolver and, when possible, another network.
nslookup example.com
nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8
ipconfig /displaydns
Different answers are not always malicious because large websites use CDNs, geo-routing, and load balancing. The warning sign is a mismatch that points to an unrelated hosting provider, a new login page, a certificate warning, or a redirect that only appears behind one router, VPN, ISP resolver, or office network.
On Windows, also check C:\Windows\System32\drivers\etc\hosts, adapter DNS servers, browser Secure DNS settings, proxy settings, and scheduled startup items. If the redirect began after installing an unknown program, browser extension, cracked app, fake update, or remote-access tool, scan the system before assuming this is only a resolver problem.
What to Do If You Suspect Poisoning
- Stop submitting credentials. Close the suspicious page and change passwords from a clean network if you already signed in.
- Flush local cache. On Windows, run
ipconfig /flushdns, restart the browser, and clear browser DNS cache if it has one. - Check DNS settings. Review adapter DNS, router DNS, VPN DNS, proxy settings, Secure DNS, and the hosts file.
- Restart or reset the router when needed. Update router firmware and change the admin password if DNS settings were modified.
- Compare from another network. Use a mobile hotspot or a trusted resolver to confirm whether the wrong answer is local, router-level, ISP-level, or broader.
- Scan for malware. If DNS settings keep reverting or redirects return, use Gridinsoft Anti-Malware to check for persistence that changes network settings, proxy rules, browser policy, or startup entries.
If Windows reports that the DNS server is not responding after malware, follow the cleanup order there before changing random DNS settings repeatedly. When a redirect leads to a suspicious download or fake login, you can also check the destination with the Gridinsoft URL Scanner before opening it again.
Prevention for Users and Network Owners
| Situation | Safer action |
|---|---|
| Home user | Keep router firmware updated, change default admin credentials, use trusted DNS resolvers, and avoid entering credentials after certificate warnings. |
| Windows device | Watch adapter DNS, proxy, hosts file, browser Secure DNS, and startup persistence after malware or fake update incidents. |
| Domain owner | Enable DNSSEC signing where supported, lock registrar access with MFA, monitor DNS records, and keep authoritative DNS accounts separate from everyday credentials. |
| Network or ISP resolver | Use patched resolver software, source-port and query randomization, DNSSEC validation, logging, alerting, and restricted resolver access. |
Encrypted DNS transports such as DoH and DoT can help prevent local network observers from reading or modifying DNS traffic in transit, but they do not replace DNSSEC. DNSSEC is the control that lets a validating resolver detect whether DNS data was forged or altered before accepting it.
Real-World Impact
The classic worst case is a banking, webmail, ecommerce, or software-update domain resolving to an attacker-controlled IP address. A convincing fake site can collect credentials, push malware, or act as a traffic relay. In an organization, a poisoned resolver can affect many users at once because all of them trust the same cached answer.
Cache poisoning can also look like censorship or ISP-level interference when DNS answers are intentionally changed to block a website, redirect users to a notice page, or force a captive portal. That is why diagnosis should separate malicious poisoning from DNS hijacking, captive portals, router changes, and ordinary CDN routing.
FAQ
Is DNS cache poisoning the same as DNS spoofing?
DNS cache poisoning is a specific form of DNS spoofing. Spoofing means forging DNS answers; cache poisoning means the forged answer is stored in cache and reused for later users.
Can flushing DNS fix cache poisoning?
Flushing DNS can remove a poisoned local cache entry from one device. It will not fix a poisoned router, recursive resolver, ISP resolver, compromised DNS server, or malware that keeps changing DNS settings.
Does HTTPS stop DNS cache poisoning?
HTTPS helps because a fake server should not have a valid certificate for the real domain. However, users can still be tricked by certificate warnings, lookalike domains, malicious downloads, or compromised endpoints, so DNS and browser warnings both matter.
Does DNSSEC prevent DNS cache poisoning?
DNSSEC helps validating resolvers reject forged DNS data when the domain is properly signed and validation is enabled. It does not fix malware on a device, router DNS hijacking, registrar compromise, or phishing pages on lookalike domains.
References
- ICANN. “DNSSEC – What Is It and Why Is It Important?” Internet Corporation for Assigned Names and Numbers, updated March 5, 2019, accessed June 7, 2026. https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en/
- A. Hubert and R. van Mook. “Measures for Making DNS More Resilient against Forged Answers.” RFC 5452, RFC Editor, January 2009, accessed June 7, 2026. https://www.rfc-editor.org/info/rfc5452
