DNS cache poisoning is a sophisticated attack that corrupts a DNS resolver’s cache with fraudulent information, causing users to be misdirected to malicious websites instead of legitimate ones.
Let’s see this in action. Imagine a user types www.example.com into their browser. Their computer asks a DNS resolver (often provided by their ISP or a public service like Google’s 8.8.8.8) for the IP address associated with that domain.
sequenceDiagram
User->>DNS Resolver: What's the IP for www.example.com?
DNS Resolver->>Root DNS Server: Where can I find .com?
Root DNS Server->>DNS Resolver: Here's the .com TLD server.
DNS Resolver->>TLD DNS Server: Where can I find example.com?
TLD DNS Server->>DNS Resolver: Here's the authoritative DNS server for example.com.
DNS Resolver->>Authoritative DNS Server: What's the IP for www.example.com?
Authoritative DNS Server->>DNS Resolver: The IP is 93.184.216.34.
DNS Resolver->>User: www.example.com is at 93.184.216.34.
The DNS resolver then caches this IP address for a period (its TTL - Time To Live) so it doesn’t have to go through this whole process every time.
Now, an attacker can try to poison this cache. They intercept the DNS query from the user or the resolver’s request to an authoritative server. The attacker then sends back a fake response, claiming to be the authoritative server, with a malicious IP address for www.example.com.
If the DNS resolver accepts this fake response (because it looks legitimate, or the attacker guesses the correct transaction ID and source port), it will store the incorrect IP address in its cache.
sequenceDiagram
User->>DNS Resolver: What's the IP for www.example.com?
DNS Resolver->>Root DNS Server: Where can I find .com?
Root DNS Server->>DNS Resolver: Here's the .com TLD server.
DNS Resolver->>TLD DNS Server: Where can I find example.com?
TLD DNS Server->>DNS Resolver: Here's the authoritative DNS server for example.com.
DNS Resolver->>Authoritative DNS Server: What's the IP for www.example.com?
Note over DNS Resolver,Attacker: Attacker intercepts or preempts the response.
Attacker->>DNS Resolver: The IP for www.example.com is 192.0.2.1 (malicious IP).
DNS Resolver->>User: www.example.com is at 192.0.2.1.
When the user’s browser tries to connect to www.example.com using the IP address from the poisoned cache, they’ll actually be sent to the attacker’s server, which might be a phishing site designed to steal credentials or a site distributing malware.
The core problem this solves is efficiency. DNS is designed to be hierarchical and distributed, but repeatedly querying the entire chain for every request would be incredibly slow. Caching is the mechanism that makes the internet usable at scale. DNS cache poisoning exploits this necessary optimization.
The attacker’s job is to guess or brute-force the correct transaction ID and source port used by the DNS resolver for a specific query. They also need to race against the legitimate response from the authoritative DNS server. The attacker usually spoofs the IP address of the authoritative DNS server to make their fake response appear legitimate.
You control the security of your DNS resolution primarily through the configuration and security practices of your DNS resolvers. For instance, if you’re running your own DNS server (like BIND or Unbound), you’d configure it with features like DNSSEC validation.
# Example BIND configuration snippet for enabling DNSSEC validation
options {
directory "/var/cache/bind";
dnssec-validation auto; # or "yes"
listen-on { 192.168.1.10; };
allow-query { 192.168.1.0/24; localhost; };
// ... other options
};
Enabling dnssec-validation auto; tells BIND to check the digital signatures provided by DNSSEC-signed zones. If a response is received that is not cryptographically verifiable, BIND will reject it, preventing the cache from being poisoned with invalid data. For public resolvers like Google DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1), they typically have robust DNSSEC validation enabled by default.
The most surprising thing about DNS cache poisoning is how often it relies on simple, predictable transaction IDs and source ports, especially in older or misconfigured resolvers. Attackers don’t always need advanced network intrusion tools; sometimes, they just need to be faster and more persistent than the legitimate DNS infrastructure. The randomness of transaction IDs (using values from 1 to 65535) and source ports (also a range) is crucial, and if these aren’t truly random or are predictable, the attack surface expands dramatically.
The next concept to understand is how DNSSEC, when properly implemented and validated, cryptographically secures DNS responses.