DNS poisoning: what it is and how to actually stop it

DNS — the Domain Name System — is the internet's address book. When you type a domain name into a browser, DNS translates it into an IP address your device can connect to. It is also one of the most persistently insecure components of the average network. DNS poisoning attacks exploit this, redirecting traffic to destinations the user never intended. Understanding the attack and the defences against it is foundational to network-level privacy and security.

What DNS poisoning is

DNS poisoning (also called DNS cache poisoning or DNS spoofing) is an attack in which false DNS records are inserted into a resolver's cache. When a victim queries a poisoned resolver for a domain — say, their bank's website — instead of receiving the correct IP address, they receive an attacker-controlled IP. Their browser connects to the attacker's server, which may present a convincing copy of the legitimate site. The user's address bar shows the correct domain name. They have no indication anything is wrong.

The consequences range from credential theft to malware delivery. The attack does not require breaking TLS encryption directly — it bypasses it by redirecting the connection before it is established.

How it works technically: the Kaminsky attack

DNS uses UDP (User Datagram Protocol) as its transport by default. UDP is connectionless and unauthenticated — there is no handshake to verify that a response comes from the expected server. DNS responses are matched to queries using a 16-bit transaction ID and the source port number. An attacker who can guess or brute-force both values can inject a fake response that the resolver accepts as legitimate.

In 2008, security researcher Dan Kaminsky published a practical method for poisoning DNS caches at scale. Rather than targeting individual responses, the Kaminsky attack exploits the birthday paradox: by querying for a large number of randomly generated subdomains of the target domain simultaneously, the attacker forces the resolver to generate many outgoing queries — each with a different transaction ID. The attacker floods the resolver with fake responses to all of these queries. The probability of a collision — a fake response matching the transaction ID of a genuine query — becomes unacceptably high within seconds.

The attack was serious enough to trigger a coordinated industry response. Resolver software was updated to randomise source ports in addition to transaction IDs, making collision significantly harder. But the fundamental vulnerability — UDP, no authentication — was not resolved by these mitigations. It was reduced.

DNSSEC: cryptographic record signing

DNSSEC (DNS Security Extensions) addresses the authentication problem by applying public key cryptography to DNS records. Zone administrators sign their DNS records with a private key. Resolvers verify these signatures against a chain of trust anchored at the DNS root. A poisoned record — one that was not signed by the legitimate zone owner — will fail verification and be rejected.

DNSSEC provides genuine integrity protection. If a resolver validates DNSSEC and the zone is signed, DNS poisoning of that zone is cryptographically prevented. The limitations of DNSSEC are important to understand:

• It does not encrypt DNS queries: Queries and responses travel in plaintext. An observer positioned on the network path can still see exactly what domains you are looking up.
• Not all zones are signed: DNSSEC adoption remains partial. Many domains — including some major ones — do not have DNSSEC records. For unsigned zones, DNSSEC provides no protection.
• Zone enumeration: DNSSEC's original implementation (NSEC records) allowed attackers to walk a zone and enumerate all subdomains. NSEC3 mitigates this but does not eliminate it entirely.

DNS-over-HTTPS and DNS-over-TLS: privacy for queries

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) address the confidentiality problem that DNSSEC does not. Both protocols encrypt DNS queries between the client and the resolver, preventing observers on the network — whether that is your ISP, a rogue access point operator, or a network-level surveillance system — from seeing which domains you are looking up.

• DoH sends DNS queries over HTTPS (port 443), making them indistinguishable from regular web traffic. It is supported natively in Firefox, Chrome, and most modern operating systems.
• DoT sends DNS queries over TLS on a dedicated port (853). It provides equivalent encryption but is more easily identifiable and filterable by network operators.

Neither DoH nor DoT validates DNS record integrity — they protect the query in transit, not the response content. A resolver using DoH can still return a poisoned record if the resolver itself has been compromised.

The correct combination: DoH/DoT plus DNSSEC

Effective DNS security requires both properties: confidentiality and integrity. The correct configuration is DoH or DoT (to protect queries from interception) combined with DNSSEC validation (to verify that the records returned have not been tampered with). Most privacy-focused DNS resolvers support both.

Privacy-respecting resolvers worth considering include:

• Cloudflare 1.1.1.1: Supports DoH and DoT, DNSSEC validation enabled by default. Cloudflare publishes a privacy policy committing to not selling query data and deleting logs within 24 hours.
• Quad9 (9.9.9.9): Non-profit operated resolver based in Switzerland. No query logging, DNSSEC validation, and blocking of known malicious domains. Supports DoH and DoT.
• NextDNS: Configurable resolver with blocking lists, per-device logging controls, and support for DoH, DoT, and DoQ (DNS-over-QUIC). Suitable for families or organisations needing content filtering alongside privacy.

Router-level vs device-level DNS configuration

DNS can be configured at the individual device level — within browser settings or the operating system — or at the router level, where it applies to every device on the network. Router-level configuration is more comprehensive: it protects devices that cannot be individually configured (smart home devices, printers, IoT hardware) and ensures consistent protection regardless of which browser or app a device uses.

The practical limitation of router-level DoH is that many consumer routers do not support it. Standard consumer firmware typically allows you to change the DNS server IP but not to enforce encrypted DNS. A router running OpenWrt or equivalent can run a local DNS resolver (such as Unbound) with full DoT/DNSSEC support, forwarding all device queries through this resolver regardless of device-level configuration. For a router pre-configured with encrypted DNS and DNSSEC validation, see the Norypt encrypted router.