DNS works like the internet's phonebook. It takes a domain name that people can easily remember and connects it to the IP address of the server where the website is hosted. Without DNS, we would have to remember long strings of numbers every time we wanted to visit a website.
But what happens when someone manages to interfere with this process?
That is where DNS cache poisoning becomes a serious security problem. An attacker can trick a DNS resolver into storing a fake IP address and sending users to the wrong destination. In some cases, users may not even realize that anything has gone wrong.
In this guide, we explain what DNS cache poisoning is, how the attack works, and why it can put users and organizations at risk. We also look at practical ways to prevent it, including DNSSEC, secure DNS resolvers, regular updates, and DNS monitoring. By the end, you should have a clear idea of why protecting DNS is an important part of protecting the internet itself.
What is DNS Cache Poisoning?
DNS cache poisoning happens when an attacker tricks a DNS resolver into saving incorrect information in its cache. Instead of storing the real IP address linked to a domain, the resolver stores a malicious one controlled by the attacker.
Normally, when a DNS resolver receives a request for a domain, it finds the correct IP address and keeps that information in its cache for a certain period. This helps it answer future requests faster. But if an attacker manages to send a fake DNS response that the resolver accepts, the wrong IP address can be saved.
From there, anyone using that resolver could be sent to the attacker's server when they try to visit the affected website.
For example, imagine you type your bank's real website address into your browser. You entered the correct URL, but the DNS resolver has a poisoned cache. Instead of sending you to the bank's real server, it returns the attacker's IP address. You could then land on a fake website designed to look like the real one. If you enter your username, password, or payment details, the attacker could steal them.
DNS Cache Poisoning vs. DNS Spoofing
DNS cache poisoning and DNS spoofing are related, but they describe slightly different things. DNS spoofing is the broader practice of creating or sending fake DNS responses that make a domain appear to point somewhere it does not.
DNS cache poisoning is more specific. Here, the false DNS information is successfully stored in a resolver's cache. This means the malicious result can continue affecting users until the cached information expires or is removed.
This is what makes DNS cache poisoning especially dangerous. An attacker does not necessarily need to target every user individually. Poisoning a shared DNS resolver can potentially redirect many users at once. This is why DNS cache poisoning prevention should be treated as part of an organization's overall security strategy, not just a DNS administration task.
How Does DNS Cache Poisoning Work?
DNS cache poisoning may sound complicated, but the basic idea is easier to understand when you follow the attack from start to finish. The attacker is trying to interfere with a DNS lookup and get the resolver to accept a false answer as if it came from a legitimate DNS server.
The attack can happen in different ways, but the goal is usually the same: make a DNS resolver temporarily trust the wrong information. Here are the usual steps.
Step 1: A User Requests a Domain
Suppose a user wants to visit example.com. Their device needs the domain's IP address, so it sends a DNS query to a DNS resolver. The resolver first checks its cache. If it already has a valid, unexpired answer for example.com, it can return that answer immediately. If there is no cached answer, the resolver needs to find the correct information by making a DNS query.
This second situation can create an opportunity for an attacker.
Step 2: The Resolver Sends a DNS Query
When the requested information is not already in the cache, the resolver sends a query to the appropriate DNS infrastructure to find the domain's authoritative answer. At this point, the resolver is waiting for a DNS response containing the requested information. The response should come from the expected source and match the query that was sent. An attacker may try to interfere before the legitimate response arrives.
Step 3: The Attacker Sends a Fake DNS Response
The attacker attempts to send a forged DNS response that claims to answer the resolver's query. Instead of giving the legitimate IP address, the fake response contains an IP address controlled by the attacker.
The difficult part for the attacker is getting the resolver to accept this response. DNS resolvers do not simply accept every response they receive. They use information from the original query to determine whether a response belongs to that request. One important piece of this process is the DNS transaction ID.
Step 4: The Attacker Tries to Guess the Transaction ID
A DNS query includes a transaction ID, which helps the resolver match a response with the query that caused it. An attacker attempting a traditional cache poisoning attack may send many forged responses with different transaction IDs. The attacker is essentially trying to get the right combination before the legitimate response arrives.
If the forged response closely matches the expected details and reaches the resolver first, the resolver may accept it as the answer to the original query.
Modern DNS software uses additional protections that make this much harder than it was in the past. For example, resolvers can randomize source ports and transaction IDs, reducing an attacker's chances of correctly predicting the values.
Step 5: The False Record Gets Cached
If the resolver accepts the forged response, it may store the malicious DNS information in its cache. This is the point where DNS cache poisoning becomes particularly serious. The attacker does not have to keep sending a fake response to every individual user. The poisoned resolver can now return the malicious IP address to other users requesting the same domain.
How long this false information remains available depends on the record's TTL, or Time to Live. The TTL tells a resolver how long it can keep a DNS record in its cache before it needs to request fresh information.
How Can One Poisoned Record Affect Multiple Users?
The real danger of DNS cache poisoning is that the attacker may only need to corrupt the cache once to affect many users. This is because a DNS resolver does not keep separate answers for every person who asks about the same domain. It stores the DNS response and can reuse it for other users until the record's TTL expires.
For example, imagine a company has 500 employees, and all of their devices use the same internal DNS resolver. An employee searches for onlinebank.com for the first time that morning. The resolver does not have the domain in its cache, so it performs a DNS lookup.
If an attacker successfully poisons that lookup and the resolver saves a malicious IP address, the problem is no longer limited to that first employee.
A few minutes later, another employee enters the same domain. Their computer asks the same resolver for the IP address. The resolver sees that it already has a cached answer and returns it without performing another lookup. If the cached answer is malicious, the second employee can also be sent to the attacker's server.
The same thing can happen to hundreds of other employees until the poisoned record expires or someone removes it from the cache.
The scale can be even larger when the affected resolver is operated by an internet service provider or another large network. A single poisoned response could potentially be reused across a much larger group of users who depend on that resolver.
This is also why the TTL of a DNS record matters. A longer cache lifetime can mean that incorrect information remains available for longer. However, TTL alone does not determine whether an attack succeeds. The more important issue is whether the resolver accepted the forged response in the first place.
Common DNS Cache Poisoning Attack Scenarios
The attacker's next step depends on what they want to accomplish after redirecting users. The malicious IP address in the poisoned record can point to a server that hosts almost anything the attacker chooses.
Phishing and Credential Theft
One common goal is to send users to a fake website that looks like a legitimate service. For example, an attacker could attempt to redirect users looking for a company's login portal to a server hosting a convincing copy of that portal. The user may enter their email address and password because they believe they are on the correct website.
The attacker can capture those credentials and use them in later attacks. The important detail is that the user did not necessarily make a mistake. They may have typed the correct domain instead of clicking a suspicious link. The redirection happened before the browser could connect to the intended server.
Malware Delivery
A poisoned DNS record can also send users to a server controlled by an attacker that hosts malicious files or exploits vulnerable software.
For instance, an attacker could target a domain commonly used by employees to download software or access business resources. Users who visit that domain could instead receive content from the attacker's server. This can turn a DNS attack into the first step of a larger compromise.
Financial Fraud
Attackers may also target websites where users enter payment or financial information. Imagine a user tries to access an online payment service using its normal domain. If DNS resolution has been compromised, the browser could connect to a fake destination. The page may closely mimic the original site's design, so the user does not immediately notice anything wrong. The attacker can then attempt to collect card details, banking credentials, or other sensitive information.
Traffic Redirection and Interception
DNS cache poisoning can also be used to redirect traffic toward infrastructure controlled by an attacker. What happens next depends heavily on the security of the connection and the protections used by the legitimate service.
For example, HTTPS provides an important layer of protection because a valid TLS certificate is required for a secure connection to the legitimate domain. A DNS redirect alone does not automatically enable an attacker to successfully impersonate an HTTPS website. However, DNS poisoning can still create serious risks, particularly when users encounter insecure services, certificate warnings, poorly configured applications, or other weaknesses.
Why the User May Not Notice the Attack
One of the most concerning parts of DNS cache poisoning is that the attack can happen without changing what the user types. The user enters the correct domain. The browser sends the request. The page may even look normal.
The problem is that the DNS resolver has supplied the wrong destination. Think of it like asking a receptionist for the address of a particular office. You give the correct company name, but someone has secretly changed the address in the receptionist's directory. Every person who asks for that company may then be given the same wrong address.
That is the basic reason DNS cache poisoning can have an impact beyond a single device. The attacker is not necessarily attacking every user individually. They are trying to corrupt a source of information that many users trust.
DNS Cache Poisoning Prevention: How to Protect Your DNS
Preventing DNS cache poisoning requires several layers of protection. No single setting can secure the entire DNS resolution process, so organizations should combine authentication, secure configuration, monitoring, and access controls.
Use DNSSEC to Authenticate DNS Responses
DNSSEC adds digital signatures to DNS records so a resolver can check whether a DNS response is authentic and whether anyone has changed it. This is important for DNS cache poisoning prevention because the attack depends on getting a resolver to trust a fake DNS answer.
Unlike protections that only make it harder for an attacker to guess the right query details, DNSSEC gives the resolver a way to verify the response. If the digital signature is missing, invalid, or does not match the expected information, the resolver can reject the response instead of storing it in its cache. This makes DNSSEC one of the strongest defenses against forged DNS responses.
Keep DNS Resolver Software and Infrastructure Updated
DNS resolvers, operating systems, and other parts of the DNS infrastructure should be updated regularly. Software updates often include fixes for security problems that attackers could use to interfere with DNS queries, responses, or the way a resolver works.
It is also important not to focus only on the DNS resolver itself. Organizations should keep the servers, network devices, and systems used to manage DNS updated as well. When this infrastructure is kept current, there are fewer security weaknesses that an attacker can use to support a DNS cache poisoning attack.
Use Trusted, Secure DNS Resolvers
Organizations should be careful when choosing the DNS resolvers their employees and systems use. A resolver that is poorly configured, outdated, or already compromised could return incorrect DNS information and create other security risks.
Internal networks should use DNS resolvers that are properly configured and managed by trusted teams or reliable providers. IT teams should also keep track of which DNS resolvers are being used across the organization. This makes it easier to spot devices using unknown or unauthorized DNS services and helps keep DNS traffic under control.
Randomize DNS Query Parameters Where Supported
DNS resolvers can make cache poisoning attacks more difficult by making certain parts of their DNS queries harder for attackers to predict. For example, source port randomization and unpredictable transaction IDs make it harder for an attacker to create a fake response that matches an active DNS request.
This does not completely stop a cache poisoning attack on its own. However, it makes the attack much harder because the attacker has a smaller chance of guessing the information needed to fool the resolver. It is an important part of DNS cache poisoning prevention, especially when used together with DNSSEC and other secure DNS settings.
Configure Appropriate TTLs and Cache Controls
TTL, or Time to Live, tells a DNS resolver how long it can keep DNS information in its cache before it needs to look for a fresh answer. Organizations should choose TTL values carefully based on how often their DNS records change and how quickly those changes need to reach users.
A shorter TTL can limit how long an incorrect DNS record stays in a cache. However, simply making TTLs very short is not enough to prevent an attack. It can also cause more DNS queries and increase network traffic. Cache settings should therefore be used as one part of a larger security plan, rather than as the main defense against DNS cache poisoning.
Monitor DNS Activity for Unusual Changes
DNS monitoring can help security teams notice strange activity before it turns into a bigger problem. Teams can watch for unexpected DNS responses, unusual changes to records, sudden changes in traffic, or DNS requests that do not match the organization's normal activity.
It is even more useful when teams compare current DNS activity with older data. For example, if a domain normally points to one set of IP addresses but suddenly starts pointing somewhere completely different, that change should be checked. Regular monitoring can help organizations find signs of a poisoned cache or another DNS security problem sooner.
Restrict Access to DNS Infrastructure
DNS servers and the systems used to manage them should not be open to everyone in an organization. Access should be limited to the people and systems that actually need it. Strong passwords, multi-factor authentication, role-based permissions, and network restrictions can all help protect DNS infrastructure.
Organizations should also keep records of important DNS changes. If someone makes an unexpected change, these logs can help security teams understand what happened and who made the change. Protecting the DNS infrastructure itself is an important part of DNS cache poisoning prevention because attackers may try to gain access to DNS systems directly.
The Bigger Problem: DNS Attacks Don't Always Look Like Attacks
DNS cache poisoning can be hard to notice because everything may look normal. A user can type the correct website address, and the browser can open a page without showing any obvious warning. But behind the scenes, DNS may have sent the user to the wrong server.
That is why organizations should treat DNS as an important part of their security, not just a system that helps websites load. DNSSEC, HTTPS, regular monitoring, and secure DNS settings can all help protect against different DNS threats.
A good first step is to check your DNS records and look for anything unusual. You can also run NsLookup.io's DNS Health Check to find possible DNS configuration and security issues.
In the end, DNS cache poisoning prevention is not only about protecting the DNS server. It is about ensuring users can trust that DNS is directing them to the right place.
Frequently Asked Questions
Can DNS cache poisoning affect mobile devices?
Yes. Mobile devices can also be affected if they use a DNS resolver that has been compromised. The device itself does not have to be hacked for the attack to work.
Can clearing the DNS cache fix DNS cache poisoning?
Clearing the cache can remove a poisoned DNS entry from a specific resolver or device. However, it does not fix the reason the false record was accepted. The source of the attack should still be investigated.
Is DNS cache poisoning the same as a DNS hijacking attack?
No. They are related but different attacks. Cache poisoning involves putting false DNS information into a resolver's cache, while DNS hijacking usually involves taking control of DNS settings or infrastructure and changing where DNS requests are sent.
Can HTTPS stop DNS cache poisoning?
HTTPS can provide an important layer of protection if a user is redirected to the wrong server. A fake server normally cannot use a valid certificate for the real domain. However, HTTPS does not stop the DNS attack itself, so DNS security is still important.