DNS - the Domain Name System - is the phone book of the internet. When you type a URL into a browser, DNS resolves that name to an IP address. The system was designed in 1983, before security was a design consideration, and is fundamentally based on trust: DNS resolvers believe the responses they receive unless they have been specifically configured not to. This design assumption has been exploited in attacks ranging from simple cache poisoning to nation-state operations hijacking government domains.
Cache Poisoning: The Kaminsky Attack
In 2008, security researcher Dan Kaminsky discovered a fundamental flaw in DNS that allowed cache poisoning attacks at scale. DNS resolvers cache responses to avoid making repeated lookups for the same domain. If an attacker can inject a false response into a resolver's cache, every user of that resolver who queries the poisoned domain will be sent to the attacker's IP address rather than the legitimate server.
Cache poisoning requires guessing the correct transaction ID (a 16-bit number) to match an outstanding DNS query. Kaminsky's insight was a way to dramatically increase the rate at which an attacker could attempt poisoning by exploiting the structure of DNS queries: by querying for many unique subdomains of a target domain simultaneously, an attacker could keep many queries outstanding at once, effectively racing to answer before the legitimate nameserver while generating many guesses per second.
Kaminsky coordinated disclosure with DNS software vendors globally - a massive, secret, multi-vendor coordinated patch effort. The patch was a behavioral change: DNS resolvers would randomize the source port of queries in addition to the transaction ID, adding approximately 16 additional bits of entropy to the guessing problem. Kaminsky kept the technical details secret until after most resolvers had been patched.
DNS Hijacking by Nation-States
DNS's trust model makes it an attractive target for intelligence operations. If you can modify DNS records for a target domain - either by compromising the domain registrar, the DNS hosting provider, or through BGP hijacking to redirect queries - you can transparently intercept all traffic to that domain.
In 2019, CISA issued Emergency Directive 19-01 after multiple US government domains were found to have had their DNS records modified. The "DNSpionage" campaign - attributed to Iranian-affiliated actors - had compromised registrars and DNS providers for government domains in Lebanon, the UAE, and the US, redirecting traffic through attacker-controlled servers that used Let's Encrypt certificates (making the interception appear HTTPS-legitimate) before forwarding to the real destination. The attack was transparent to users who saw no certificate errors and had no indication traffic was being intercepted.
The Sea Turtle campaign (also 2019) used similar techniques to target governments, intelligence agencies, and energy companies in the Middle East and North Africa. The attackers registered their own TLS certificates for victim domains - possible because they controlled the DNS records needed to complete ACME domain validation challenges - allowing perfect TLS man-in-the-middle interception.
DNS over HTTPS and the Privacy Debate
Traditional DNS queries are sent in plaintext over UDP port 53. This means your ISP, and any network observer, can see every domain name you resolve - a comprehensive record of your online activity even if the content of your web traffic is HTTPS-encrypted. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries, hiding them from network observers.
Firefox's decision to enable DoH by default in the US in 2019, routing queries through Cloudflare's 1.1.1.1 resolver, triggered a sharp industry debate. UK ISPs complained that DoH bypassed their mandatory malware-filtering and parental-control DNS systems. Enterprise security teams complained that DoH made DNS monitoring for malware C2 communication impossible. Child safety advocates complained about the parental control implications.
The debate crystallized the core tension: DNS encryption protects user privacy from ISP surveillance and network-level monitoring, but also prevents network-level security controls that depend on visibility into DNS queries. There is no technical solution that preserves both simultaneously. The policy choice about which to prioritize is a values question, not a technical one.
The Registrar Attack Surface
Domain registrars control DNS delegation. An attacker who compromises a registrar account - through credential theft, SIM swapping, social engineering, or direct registrar compromise - can modify the nameservers for any domain in that account, effectively taking over all DNS for that domain regardless of what the domain owner's DNSSEC or hosting provider configuration says.
This attack surface is significant because registrar account security is typically much weaker than the infrastructure being protected. A corporation that runs DNSSEC on its domain, has dedicated DDoS protection, uses a CDN, and employs a full security team may have its registrar account protected only by a password and an email address. The security chain is only as strong as its weakest link - and for many organizations, that link is the registrar account they haven't thought about since they registered the domain years ago.
Registry Lock (also called Domain Lock or Registrar Lock) is a protection available from major registrars and TLD registries that requires out-of-band authorization (a phone call, a physical token, or other offline verification) before nameserver changes can be made. It adds meaningful friction to registrar-based attacks. Its deployment is limited by awareness and the additional operational overhead it imposes.