Before Your Browser Connects, Something Else Decides Who Answers
Every connection your device makes starts with a DNS query. The answer to that query determines where you actually end up. Here is exactly how that system gets compromised — and why the fix has existed for twenty years without being deployed.
Open a browser and type a web address. Before anything loads, before any connection is made, your device sends a question to a server you almost certainly didn't choose and have probably never thought about. That server looks up the address, returns an answer, and your device connects to whatever it was told to connect to.
The system doing this is called DNS — the Domain Name System. It translates human-readable addresses into the numerical IP addresses machines use to find each other. Every device on the internet uses it, constantly, for everything. Unlike most of the infrastructure that powers the web, DNS operates almost entirely on trust rather than verification.
That distinction is the entire problem.
How the Lookup Works
When you type an address into your browser, your operating system doesn't go looking for it directly. It asks a resolver — a dedicated server whose job is to find the answer on your behalf.
That resolver is almost certainly configured by your router. Your router got its configuration from your ISP when it first connected. Unless you've explicitly changed it, every DNS query from every device on your network flows through a server you've never interacted with and have no direct visibility into.
The resolver works down a hierarchy. It starts at the top — asking one of thirteen root nameservers which server is responsible for the relevant top-level domain (.com, .org, .net). It then asks that TLD nameserver which server is authoritative for the specific domain. It then asks that authoritative server for the actual address. The authoritative server is the final source of truth — the server the domain owner controls and has explicitly configured.
That entire chain — root, TLD, authoritative — typically completes in milliseconds. The resolver caches the answer so it doesn't have to repeat the process every time the same domain is requested. The cached answer lives for a period defined by the domain owner, called the TTL — time to live. While it's cached, every device using that resolver trusts it completely.
Three points in this chain can be compromised. Each one breaks trust differently. Each one has been actively exploited.
The Router
The most direct attack doesn't touch DNS infrastructure at all. It changes which server your device questions in the first place.
Your device receives its resolver address from your router via DHCP — the same protocol that assigns your IP address when you join a network. DHCP is the welcome packet your router hands every device that connects: here is your address, here is the gateway, here is who to ask when you need to find something. If an attacker controls the router, they control the welcome packet.
Changing one field in the DHCP configuration — the DNS server address — is enough to redirect every query from every device on the network to a server the attacker controls. That server can operate mostly honestly, returning correct answers for the vast majority of requests so nothing appears wrong. But for specific targets — a banking login, a corporate email portal, a government authentication system — it returns a different address, one pointing to infrastructure the attacker controls, running a convincing copy of the real destination.
The user arrives at a page that looks identical to the one they intended to reach. They enter their credentials. The attacker captures them. The server then forwards the connection to the real destination so the user logs in successfully and notices nothing unusual. No malware was installed. No user made a mistake. The compromise happened entirely in the infrastructure between the device and the internet.
This has been running at scale against government ministries, diplomatic organizations, and military agencies across multiple continents. It works because home and small-office routers are the least-monitored assets on most networks — configured once, forgotten, left running unpatched firmware for years. Exploiting a documented, unpatched router vulnerability requires minimal effort. The payoff is passive, persistent access to the DNS traffic of every device behind that router, with the option to selectively intercept specific connections when a high-value target appears.
The Resolver's Cache
Even if the resolver your device uses is legitimate and unmodified, its cache can be corrupted from outside.
DNS queries and responses travel over UDP — a lightweight protocol that sends packets without confirming delivery or verifying the sender's identity. When a resolver sends a query to an authoritative server, it assigns that query a transaction ID — a 16-bit number — and expects the response to carry the same ID back. An attacker who can send a forged response with the correct transaction ID, arriving before the legitimate server's real response, can insert a false record into the resolver's cache.
Once poisoned, the cache serves the forged answer to every device querying through that resolver, for as long as the record's TTL keeps it alive. The attacker doesn't need to intercept individual connections in real time. The corrupted cache does the work automatically, for every subsequent request.
In 2008, security researcher Dan Kaminsky demonstrated exactly how exploitable this was. Resolvers at the time used a fixed source port for outgoing queries, meaning the only variable an attacker had to guess was the 16-bit transaction ID — 65,536 possible values. Kaminsky found that rather than waiting for a cached record to expire and then racing a single query, he could flood the resolver with requests for non-existent subdomains of the target domain, forcing fresh queries continuously. Each fresh query was a new race — thousands of forged responses sent with different transaction IDs, trying to land the correct one before the legitimate server responded.
More critically, he found that rather than poisoning a single address record, he could target the authoritative nameserver record for an entire domain. Poisoning that record means the resolver stops asking the real authoritative server entirely — it asks the attacker's server instead. Every address under that domain, for every device using that resolver, goes wherever the attacker directs.
The immediate response to Kaminsky's disclosure was to randomize both the transaction ID and the source port, expanding the guessing space from 65,536 to over four billion combinations. This made straightforward cache poisoning significantly harder, not impossible. Researchers have since demonstrated side-channel attacks that infer the source port through network timing, substantially collapsing the effective entropy. The patch raised the bar. The underlying architecture stayed the same.
The Authoritative Record
The deepest attack in the DNS chain goes after the authoritative nameserver directly — the server every resolver in the world ultimately defers to for a given domain.
In 2019, Cisco Talos documented a campaign targeting the DNS registrars and registries managing authoritative nameserver records for national security organizations across the Middle East and North Africa. The attackers didn't compromise the target organizations' own systems. They compromised the registrar accounts — the management interfaces used to update DNS records — and changed the records themselves to point to infrastructure they controlled.
When authoritative DNS records are modified at the registrar level, no cache needs to be poisoned and no resolver needs to be compromised. The correct answer, according to the global DNS hierarchy, is now the attacker's answer. Every resolver on the internet fetches it, caches it, and serves it. Email and web traffic for the affected organizations was silently intercepted for months before anyone noticed.
A related technique exploits organizational housekeeping failures rather than active intrusion. When an organization decommissions a cloud service — a storage bucket, a CDN endpoint, a hosted application — it sometimes forgets to remove the DNS record pointing to it. That record keeps resolving, referencing an address that no longer belongs to anyone. An attacker who registers that abandoned resource inherits the DNS entry. Subdomains of major institutions — government health agencies, large professional services firms — have been successfully hijacked this way, not through any breach of the institution's own systems, but through stale records pointing to infrastructure anyone could claim.
The common thread is that DNS trust flows downward through the hierarchy without expiration. Once a record says something, the whole system believes it until someone authoritative changes it. The assumption built into this design — that authoritative records are controlled by the people who own the domain — holds until it doesn't.
Why HTTPS Only Partially Helps
The standard assumption is that HTTPS handles this. The padlock means the connection is encrypted and the server's identity has been verified — so even if DNS sends you to the wrong address, the certificate check catches it and the browser warns you.
This is true for many DNS attacks. An attacker redirecting your traffic to a server they control generally cannot present a valid certificate for the real domain, because certificate authorities verify domain ownership before issuing one. The browser's certificate check fails. A warning appears.
But the check only works if the user stops.
Years of certificate errors on internal corporate systems, self-signed certificates on network equipment, and misconfigured HTTPS on minor sites have trained many users to treat these warnings as friction. Clicking through on a compromised network triggers no further protection. The connection proceeds. The session is intercepted.
HTTPS protects the channel. DNS hijacking attacks the addressing layer underneath it. The protection holds only where users treat certificate warnings as the hard stop they are designed to be — which means the security model depends less on cryptography than on behavior.
The Fix That Has Existed Since 2005
DNSSEC — DNS Security Extensions — adds cryptographic signatures to DNS responses. An authoritative server with DNSSEC enabled signs its records with a private key. The corresponding public key is published up the DNS hierarchy, creating a verifiable chain of trust from the root nameservers down to the specific domain. A validating resolver checks those signatures before accepting a response. A forged or tampered record fails validation and gets rejected.
DNSSEC would stop cache poisoning. It would have caught the registrar-level modifications in the 2019 campaign. It is a direct technical answer to the core problem.
It was standardized in 2005. As of February 2026, 4.27% of domains have it enabled.
That figure comes from an analysis of 240 million domains using actual TLD zone files — not a survey or an estimate. Just over 10 million domains carried valid DNSSEC signatures. Among resolvers, the global validation rate sits at approximately 35%, meaning that even for signed domains, roughly two thirds of DNS queries worldwide are processed by resolvers that don't check signatures at all.
The reasons are structural. DNSSEC requires coordinated action from two parties with no contractual relationship: the operator of the authoritative nameserver, and the operator of the recursive resolver used by end users. Neither is required to act. There is no padlock for DNSSEC, no visible signal to users that a domain is protected or unprotected, no consequence that makes the absence immediately apparent to anyone.
There is also a failure mode that actively discourages adoption. A misconfigured DNSSEC setup — an expired signature, a botched key rollover, a mismatched record — causes validating resolvers to return an error rather than fall back to an insecure response. The domain goes completely unreachable for everyone using a validating resolver. Misconfiguration is not rare, and the consequences are severe enough that organizations where uptime matters have consistently chosen not to deploy a security extension that could take them offline if anything goes wrong.
The comparison to HTTPS is instructive and slightly depressing. HTTPS went from under 40% adoption to over 90% in a few years — not because of a technical breakthrough, but because Let's Encrypt made certificates free and automated, and browsers started showing visible warnings on unencrypted pages. The incentive structure changed, and adoption followed. DNSSEC has neither a free automated deployment path for most registrars nor a user-visible signal when validation fails. Twenty years after standardization, the incentive structure hasn't changed, and the numbers reflect it.
What You're Left With
DNS is not a legacy system waiting to be replaced. It is the active infrastructure through which every internet connection begins — no parallel systems, no fallbacks, no opt-outs. When you connect to anything, your device asks a resolver where to go. The answer determines the destination.
Three points in the resolution chain are actively exploited: the resolver your device uses, the cache that resolver maintains, and the authoritative records at the top of the hierarchy. The methods differ. The outcome is the same — your device connects somewhere it didn't intend to, with no indication anything is wrong.
The cryptographic fix exists. It covers four percent of domains. The resolver configuration that would protect your device is sitting in a router you've probably never logged into since the day it was installed.
Certificate warnings are not browser bugs or security theater. They are the last signal the system is capable of producing when something in the addressing layer has gone wrong. A certificate mismatch on a login page — on any network you don't fully control, a hotel, an office, a shared connection — is not friction to click through. It is the only moment in the entire DNS resolution process where the system can tell you that the answer it received might not have been the right one.
Most people never think about DNS. It's designed to be invisible. The attacks that exploit it are designed to stay that way. The certificate warning is the one moment that design breaks down — and it only works if you treat it as the warning it is.