Every web request begins with a DNS lookup. Your browser asks: "What IP address is bank.com?" A DNS server answers, and the browser connects to whatever IP it receives. If an attacker can tamper with that answer, your users connect to the attacker's server instead — and they have no way to know the difference. This is DNS poisoning, and it's one of the most insidious attacks on the internet.
How DNS Poisoning Works
DNS was designed in the 1980s without authentication. When a resolver queries an authoritative DNS server, it accepts the first response that matches the query's transaction ID — a 16-bit number. An attacker who can predict or brute-force this ID can inject a forged response before the legitimate answer arrives.
The Kaminsky attack, disclosed in 2008, demonstrated that this could be done reliably. Despite patches and mitigations, the fundamental issue remains: standard DNS responses are unauthenticated. The resolver has no cryptographic proof that the answer came from the legitimate authority.
Attack Vectors for DNS Poisoning
- Resolver cache poisoning: The attacker targets the DNS resolver used by many users (e.g., an ISP's resolver). One poisoned cache entry redirects every user of that resolver.
- Local network attacks: On a shared network, an attacker intercepts DNS queries via ARP spoofing or rogue DHCP and returns forged responses. Every device on the network is affected.
- Compromised routers: Home and small-office routers with default credentials or known vulnerabilities are routinely compromised. Attackers change the DNS settings to point to their own resolvers, redirecting all traffic from every device on the network.
- BGP hijacking: At the network routing level, an attacker can announce ownership of IP space belonging to DNS servers, intercepting queries destined for legitimate resolvers.
What the Attacker Controls After Poisoning
Once DNS is poisoned, the attacker controls the destination of the connection. They can:
- Serve a perfect clone of the target website, capturing credentials in real time
- Intercept API traffic between services that use DNS for discovery
- Issue valid TLS certificates for the domain (using DNS-based domain validation, which they now control)
- Redirect email by returning forged MX records, silently intercepting incoming mail
The most dangerous aspect is that the user sees the correct domain name in their browser. The URL looks right. If the attacker has obtained a certificate (which is straightforward when you control DNS), even the padlock icon appears.
The DNSSEC Solution and Its Adoption Problem
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses. A resolver can verify that the response was signed by the domain's legitimate authority and hasn't been tampered with. It's the definitive solution to DNS poisoning.
The problem is adoption. As of 2025, fewer than 30% of domains have DNSSEC enabled, and many resolvers don't validate signatures even when they're present. The deployment complexity and risk of breaking DNS resolution have slowed adoption for over a decade.
The Practical Reality
For most organisations, DNS security means: using trusted resolvers that validate DNSSEC, enabling DNSSEC on their own domains, monitoring for unauthorised DNS changes, and ensuring their domain registrar accounts have strong authentication to prevent DNS hijacking through the registrar's control panel.
DNS hijacking through registrar compromise is perhaps the most common real-world attack. Attackers compromise the domain owner's registrar account and change nameservers to their own, gaining complete control over all DNS records for the domain.
ShieldReport evaluates your domain's DNS configuration, checking for DNSSEC validation, proper record hygiene, and the authentication infrastructure that protects your users from redirection attacks.