The threat is real and personal — not just theoretical
Around 2010, a routine network security experiment at work turned uncomfortable fast. Using ARP poisoning to redirect traffic from other machines on the office network, the intercepted data stream opened up immediately — and sitting inside it were fragments of colleagues’ private MSN Messenger conversations with their families. Nobody set out to eavesdrop. The goal was understanding the network’s vulnerabilities, not reading someone’s messages home. The experience landed like a gut punch anyway.
That discomfort is the point. Man-in-the-middle attacks don’t produce abstract security violations. They expose real conversations between real people — a parent checking on a sick child, a partner making plans for the weekend. The harm is human and immediate, even when the person intercepting the traffic has no malicious intent. A genuine attacker would have captured, stored, and exploited every word.
The attack surface in that era was vast. Hubs, which broadcast all network traffic to every connected device, were still common in many offices. Open Wi-Fi networks required no ARP poisoning at all — passive listening alone captured everything flowing across the connection. An attacker needed no special position on the network, just proximity and a packet sniffer.
Open Wi-Fi hasn’t gone away. Coffee shops, airports, hotels, and transit hubs still run unencrypted networks used by millions of people daily. DNS traffic — the queries your device sends every time it loads a website — crosses those networks in plaintext by default. Without DNSSEC validation and encrypted DNS protocols, an attacker on the same network can intercept and manipulate DNS responses, redirecting users to fraudulent servers that impersonate legitimate sites. DNS cache poisoning, a close cousin of ARP poisoning, achieves the same result at scale without requiring physical proximity at all.
The vulnerability isn’t theoretical. It is the same class of attack demonstrated in that office in 2010, updated for the infrastructure of 2024. The only difference is the target has shifted from unencrypted application traffic to the domain name resolution layer that underpins every connection a user makes.
What DNS actually does — and why it is the perfect attack target
Every time you type a web address into a browser, your device fires off a DNS query — a request to the internet’s global directory service that translates a human-readable domain name like “yourbank.com” into a numerical IP address your computer can actually route to. This lookup happens in milliseconds, invisibly, dozens of times per browsing session. That invisibility is exactly what makes DNS a prime target for attackers.
The fundamental problem is baked into DNS’s original design. Queries travel over UDP in plain text, carrying no authentication and no verification mechanism. A resolver has no way to confirm that the answer it receives actually came from an authoritative nameserver rather than a malicious third party. An attacker who can inject a forged response into that exchange — a technique called DNS cache poisoning — can redirect a user to a counterfeit server without triggering any browser warning. The address bar still shows the domain the user typed. Nothing looks wrong.
What separates DNS cache poisoning from older network interception methods is its reach. ARP poisoning, the technique used to intercept traffic on local networks, requires the attacker to already be on the same network segment as the victim. DNS cache poisoning carries no such constraint. An attacker can target a recursive resolver from anywhere on the internet, and a single poisoned resolver can misdirect thousands of users simultaneously. The 2008 Kaminsky vulnerability — a flaw discovered by security researcher Dan Kaminski that allowed rapid-fire forged DNS responses — demonstrated just how catastrophically wide that attack surface is. Patches went out in an emergency coordinated disclosure involving every major DNS software vendor, but the structural weakness the attack exploited remains: DNS responses, without cryptographic validation, are fundamentally a matter of trust.
That trust is not abstract. It governs where your banking credentials actually go, which login page your email client reaches, and whether the software update your server just fetched came from the legitimate vendor. Domain name resolution sits underneath every one of those transactions, unencrypted and, on most of the internet today, still unverified.
What DNSSEC actually does — and what most explainers get wrong
DNS has a trust problem that most people misdiagnose — and the misdiagnosis starts with how DNSSEC gets explained.
DNSSEC, the Domain Name System Security Extensions, does one specific thing: it attaches cryptographic signatures to DNS records, allowing resolvers to verify that a response is genuine and has not been altered between the authoritative nameserver and the end user. When a resolver validates a DNSSEC-signed response, it is confirming authenticity and integrity — that the answer came from the legitimate zone owner and arrived intact. That is the entire job. DNSSEC does not encrypt DNS queries or responses. Anyone positioned to observe traffic on the wire can still read exactly which domains you are looking up.
That distinction matters enormously, because a significant share of mainstream coverage lumps DNSSEC together with DNS-over-HTTPS and DNS-over-TLS as if they are interchangeable privacy tools. They are not. DoH and DoT wrap DNS traffic inside encrypted tunnels — solving the confidentiality problem by preventing eavesdroppers from reading your queries in transit. DNSSEC solves a completely different problem: it stops a forged or poisoned DNS response from being accepted as legitimate.
The classic attack DNSSEC defends against is DNS cache poisoning, demonstrated at scale by researcher Dan Kaminsky in 2008, when he disclosed a fundamental flaw in DNS that allowed attackers to inject fraudulent records into resolver caches and silently redirect users to malicious servers. A validating DNSSEC resolver rejects a spoofed response because the cryptographic signature will not match the public key published in the zone. No signature match, no acceptance.
Conflating these tools creates a specific and dangerous failure mode: a network administrator deploys DoH, concludes that DNS security is handled, and skips DNSSEC validation entirely. The queries are now private from eavesdroppers, but the responses are still vulnerable to tampering. Conversely, a domain signed with DNSSEC but queried over plain UDP offers integrity without confidentiality. Full DNS security requires both layers — authenticated responses through DNSSEC and encrypted transport through DoH or DoT. Treating them as synonyms leaves real gaps that attackers exploit.
The adoption gap: why so many domains still skip DNSSEC
Three obstacles explain why DNSSEC signing rates remain stuck in the low-to-mid single digits for generic top-level domains despite the protocol turning 25 this year.
The first is operational risk. Enabling DNSSEC requires generating cryptographic key pairs, publishing DS records at the parent zone, and maintaining strict key-rollover schedules. A misconfigured or expired DNSSEC signature doesn’t degrade gracefully — validating resolvers return SERVFAIL, making the domain completely unreachable for users whose ISPs enforce DNSSEC validation. That failure mode, where a signing error wipes out a site more thoroughly than a DDoS attack, is enough to make cautious administrators walk away from the whole idea.
The second obstacle is infrastructure fragmentation. Registrars and DNS hosting providers implement DNSSEC support inconsistently. Some automate the entire process, including key rotation. Others expose raw DS record fields and leave the rest to the domain owner. Many cheap shared-hosting providers offer no DNSSEC tooling at all. A small business using one of those providers has no practical path to domain name system security extensions regardless of how motivated the owner is, because the option simply doesn’t exist in the control panel.
The third and most corrosive factor is complacency. The attitude — “we haven’t been hit by a DNS spoofing or cache poisoning attack yet, so why bother” — is a near-perfect replay of the reasoning that kept HTTP dominant for years after HTTPS was available and cost-free through Let’s Encrypt. Operators underestimated the threat of in-transit traffic interception until browsers started marking HTTP sites as “Not Secure” and Google began penalising them in search rankings. No equivalent forcing function exists for DNSSEC today. There is no browser padlock for a correctly signed DNS response, no search-ranking penalty for an unsigned domain, and no automatic warning that tells a user their DNS lookup just traveled without cryptographic integrity protection.
Until registrar support becomes universal and tooling eliminates the manual key-management burden, these three barriers will keep the majority of domains — and the users who depend on them — exposed to DNS hijacking, BGP-based redirection, and resolver-level manipulation that DNSSEC was designed to prevent.
The missing context: HTTPS alone does not save you from DNS hijacking
Most people assume the padlock icon in their browser keeps them safe. It does not — not completely, and not when an attacker has already tampered with DNS before your browser even attempts a connection.
Here is the sequence that matters: when you type your bank’s URL, your device asks DNS to translate that name into an IP address. Only after it receives an answer does your browser reach out to make a connection. TLS certificate validation happens at that second step. Poison the first step — redirect the DNS response to a malicious server — and TLS checks the certificate on that server, not the legitimate one. The padlock can still appear. The warning may never come.
Attackers who control DNS responses have a straightforward path to a convincing fake. Certificate authorities have issued fraudulent certificates before, and self-signed certificates fool a significant share of users who either click through browser warnings or do not recognize what those warnings mean. On networks where users have low security awareness — public Wi-Fi, ISPs with lax resolver security — DNS cache poisoning turns a theoretical risk into a practical one.
Real incidents confirm this. In April 2018, attackers hijacked BGP routes and DNS records for MyEtherWallet, redirecting users to a phishing server that held a valid HTTPS certificate issued through a Russian certificate authority. Users who ignored or missed the browser warning handed over their cryptocurrency wallet credentials. The attack lasted roughly two hours and drained multiple accounts. In 2019, a sustained DNS hijacking campaign tracked by Cisco Talos and later attributed by the US Cybersecurity and Infrastructure Security Agency targeted telecommunications companies, internet service providers, and government domains across the Middle East, Europe, and North Africa — pulling credentials from mail servers and VPN infrastructure.
DNS cache poisoning exploits, BGP route hijacking, and rogue resolver attacks are not edge cases. They are documented, repeating threats that target exactly the gap DNSSEC is designed to close. Encrypted DNS protocols like DNS-over-HTTPS and DNS-over-TLS protect the query in transit but do not authenticate the answer. Only DNSSEC cryptographically signs the DNS record itself, giving resolvers a way to verify that the answer came from the authoritative source and was not modified in transit. Without it, domain name system security remains incomplete regardless of what the browser’s address bar shows.
What needs to change — and who has the power to change it
Three actors hold the power to break DNSSEC’s adoption deadlock: registrars, browser vendors, and regulators. Each has precedent to follow and no credible excuse left for inaction.
The registrar problem is fundamentally one of defaults. GoDaddy, Namecheap, and similar platforms bury DNSSEC configuration inside advanced DNS settings that most domain owners never open. Let’s Encrypt demonstrated what happens when you flip that logic — by making TLS certificates free and automatic by default, it drove HTTPS adoption from roughly 40% of web traffic in 2016 to over 95% today. Registrars could replicate that model for DNSSEC signing tomorrow. Hosting providers controlling authoritative nameservers face the same choice. Cloudflare already enables one-click DNSSEC for domains using its nameservers. That should be the floor, not a differentiating feature.
Browser vendors and operating systems own the user-facing layer. Chrome, Firefox, Safari, and Windows collectively reach billions of people who have no idea whether their DNS responses are cryptographically validated or not. The padlock icon taught an entire generation to notice whether a connection was encrypted. A comparable signal for DNSSEC validation status — or a warning when a signed domain fails validation — would make DNS security legible to ordinary users for the first time. The technical hooks exist. What’s missing is the will to implement them.
Regulators carry the bluntest instrument. PCI-DSS forced the payments industry to take baseline security controls seriously by making compliance a commercial requirement. The same mechanism applies directly to DNSSEC. Financial institutions routing transactions through unsigned DNS zones, healthcare providers whose patient portals lack domain validation, and government agencies still running unsigned .gov subdomains are all accepting risks they would never tolerate in adjacent systems. The FDA, CISA, and financial regulators in the EU operating under DORA already have the authority to mandate DNS security controls. CISA issued binding operational directive BOD 18-01 requiring DNSSEC on federal .gov domains in 2018, yet compliance remains incomplete six years later — which tells you exactly how much voluntary guidance alone achieves.
Default-on deployment, visible validation status, and regulatory mandates with teeth: none of these require new technology. They require decisions.
