How DNS Cache Poisoning Works
The Domain Name System (DNS) acts like the internet’s address book. When someone enters a domain name, DNS translates it into an IP address so a browser can connect to the correct server. This process is usually fast and invisible, relying heavily on cached responses held by devices, routers, internet service providers, and recursive DNS resolvers. Learn more about Health.
DNS cache poisoning occurs when an attacker causes a resolver to store a false DNS record. Future users may then be directed to a malicious server instead of the legitimate destination. The forged response can support phishing, malware distribution, credential theft, surveillance, or service disruption.
Understanding the attack requires looking at how DNS requests travel, why caching exists, and where trust assumptions can be abused. The same principles apply whether the target is a major website, a company network, or a home router.
What DNS Caching Does
When a user requests a domain, a recursive resolver searches for the authoritative answer. Once it finds the domain’s IP address, it temporarily stores that result. The storage period is controlled by the record’s time to live, or TTL. During that period, later requests can be answered from the cache without repeating the full lookup process.
Caching reduces latency and lowers the volume of DNS traffic. However, a cached answer is useful only if it is authentic. Traditional DNS was designed around speed and cooperation rather than strong identity verification, which created opportunities for forged replies under certain conditions.
A resolver normally expects a response to match details from its outstanding query, including the queried domain, record type, transaction identifier, and source information. If an attacker can predict or manipulate enough of these values, a counterfeit response may be accepted before the genuine answer arrives.
How A Poisoned Record Enters
A common attack begins with a resolver asking an authoritative name server for a domain record. The attacker sends many fake responses containing a malicious IP address, hoping one matches the resolver’s pending request. If the forged packet arrives first and passes the resolver’s checks, the false result is cached.
The attacker may target a popular domain or a subdomain used for login, email, software downloads, or payment services. A user can type the correct web address and still be sent somewhere dangerous because the resolver has supplied the wrong destination.
Older DNS implementations were especially exposed because transaction identifiers offered limited randomness. Predictable source ports and weak resolver configuration made the guessing process easier. Modern systems add randomization and validation, but outdated equipment and poorly managed private resolvers can still create weak points.
Why The Attack Can Spread
Poisoning a single endpoint is relatively limited. Poisoning a shared recursive resolver can affect thousands of users, offices, schools, or customers. Every device relying on that resolver may receive the fraudulent answer until the bad record expires or administrators clear the cache.
Attackers can also manipulate records that direct users to supporting infrastructure. A fake mail exchange record could reroute email, while a modified name server record could influence future lookups for an entire domain. These attacks can remain difficult to detect because the visible domain name in the browser may look correct.
DNS manipulation is also relevant to software and internal business systems. A developer researching custom Jira plugins, for example, may download code from a lookalike host if local DNS resolution has been compromised. The technology itself may be legitimate, while the destination silently changes underneath it.
Attack Paths And Warning Signs
The table below contrasts several ways DNS trust can be abused. The exact technique varies with the attacker’s access, the resolver’s defenses, and the target’s infrastructure.
| Attack path | What the attacker changes | Potential result | Useful defense |
|---|---|---|---|
| Resolver cache poisoning | A cached domain-to-IP response | Users visit a malicious website | DNSSEC validation and patched resolvers |
| Router or gateway compromise | DNS settings supplied to local devices | All connected devices use an attacker-controlled resolver | Secure router administration and firmware updates |
| Local network spoofing | DNS replies on a shared network | Nearby users are redirected | Encrypted DNS and network monitoring |
| Registrar or authoritative server compromise | Actual DNS records for a domain | Broad, persistent redirection | Registrar lock, MFA, and DNS change alerts |
| Malware-based configuration change | Device DNS settings or hosts file | One endpoint receives false destinations | Endpoint protection and configuration checks |
Warning signs include repeated certificate errors, unexpected login pages, redirects to unfamiliar domains, and different IP results from trusted networks. A sudden change in DNS records, especially for mail or authentication services, deserves immediate review.
Users can compare responses through independent resolvers and inspect certificate details, although these checks are not perfect. Administrators should examine resolver logs, TTL changes, query patterns, and authoritative records rather than relying on browser behavior alone.
DNSSEC And Modern Protection
DNS Security Extensions, commonly called DNSSEC, add digital signatures to DNS data. A validating resolver checks those signatures and rejects records that cannot be traced through a trusted chain to the domain’s signing key. This helps confirm that the answer came from the correct authority and was not altered in transit.
DNSSEC does not encrypt DNS queries, and it does not protect a compromised registrar account by itself. It also requires correct key management and validation throughout the lookup path. A domain may publish signatures while a resolver fails to validate them, reducing the practical benefit.
Encrypted DNS protocols such as DNS over HTTPS and DNS over TLS protect queries between a client and its chosen resolver. They can reduce local network observation and some forms of reply tampering, but they do not automatically prove that every returned record is authentic. Encryption and DNSSEC address different parts of the problem.
Practical Steps For Safer Resolution
Organizations should combine technical controls with account security and routine monitoring. Useful measures include:
- Enable DNSSEC signing for domains and validation on recursive resolvers.
- Keep operating systems, routers, firewalls, and DNS software fully patched.
- Use strong random transaction values, source-port randomization, and reputable resolvers.
- Protect registrar and DNS provider accounts with multifactor authentication and restricted access.
- Monitor certificate changes, DNS records, mail routes, and unusual TTL or query patterns.
Network teams should document authoritative name servers and approved resolver addresses. Any unexpected change to those assets should generate an alert, especially when it affects authentication, email, payment, or software distribution systems.
Home users can update router firmware, change default administrator credentials, and avoid unknown public Wi-Fi for sensitive activity. Encrypted DNS may improve privacy on untrusted networks, while browser certificate warnings should be treated as security signals rather than inconveniences.
Detecting And Recovering From Poisoning
When poisoning is suspected, administrators should identify whether the problem affects one device, a local router, a recursive resolver, or the authoritative domain. Comparing results from multiple trusted networks can reveal whether the false record is broadly distributed or limited to a particular cache.
The response may include flushing affected caches, correcting DNS records, rotating compromised credentials, removing malicious router settings, and contacting the DNS provider or registrar. If certificates, email records, or application credentials were exposed, those assets may require replacement even after DNS appears normal.
Teams should also review logs for the time window in which the false record was active. A short TTL does not eliminate risk; it simply limits how long a cached answer should remain. Build DNS checks into security monitoring, verify critical records regularly, and use trusted lookup tools to investigate unexpected results before users are redirected again.
Make DNS validation, registrar protection, and record monitoring part of routine security operations. Testing your own domains and resolvers regularly can expose configuration weaknesses before an attacker turns them into a larger incident.