Why DNS is attractive to attackers
DNS is the layer that turns a name you can read (your-bank.com) into the IP address your computer actually connects to. If an attacker controls that translation, they control where your traffic goes — before TLS, before any application-layer security check. The browser will happily handshake with whatever IP DNS handed it.
Three properties make DNS unusually attractive as a target. It runs over UDP by default, which is connectionless and trivial to spoof. The original protocol has no authentication — any answer that arrives with the right transaction ID is believed. And it's heavily cached at every layer (browser, OS, router, resolver), so a single poisoned answer can affect thousands of users for hours. For background on how the system normally works, see What is DNS?.
Cache poisoning (Kaminsky attack, randomization mitigations)
Cache poisoning is the classic DNS attack. The goal is to get a resolver to store a forged answer in its cache so that every subsequent user who asks for that domain gets the attacker's IP. Because resolvers cache aggressively, one successful injection can redirect traffic for the duration of the record's TTL.
In 2008, Dan Kaminsky demonstrated that the standard implementation was far weaker than anyone realized. A DNS query carries a 16-bit transaction ID — only 65,536 possibilities. An attacker who can race the legitimate authoritative server can flood the resolver with forged responses guessing the ID. Worse, Kaminsky showed you could repeatedly trigger fresh queries (for random1.bank.com, random2.bank.com, etc.) and inject a poisoned glue record that redirected the entire bank.com zone.
The mitigation everyone adopted was source port randomization. Instead of always sending queries from UDP port 53, resolvers now use a random ephemeral port for each query. That adds roughly 16 more bits of entropy an attacker has to guess alongside the transaction ID, turning a feasible attack into one that requires sending billions of forged packets. Modern resolvers also implement 0x20 encoding (randomizing the case of the queried name, since DNS responses must echo it back) for additional entropy. None of this authenticates the answer — it just makes blind guessing impractical. DNSSEC is the real authentication fix, covered below.
DNS hijacking (router-level, ISP-level, malware)
Hijacking is more direct than poisoning: instead of tricking a resolver, the attacker simply changes which resolver you use. There are several common vectors.
- Router-level hijacking. Home routers with default credentials or unpatched firmware get their DNS settings changed remotely. Every device on the LAN inherits the malicious resolver via DHCP. This was the basis of the long-running DNSChanger malware campaign and dozens of router botnets since.
- ISP-level interception. Some ISPs transparently redirect all outbound UDP traffic on port 53 to their own resolver — even if you've configured 1.1.1.1 or 8.8.8.8. This is sometimes done for "safety" (blocking malware domains) and sometimes for monetization (rewriting NXDOMAIN responses to point at ad-laden search pages).
- Malware on the endpoint. A trojan can edit the system's resolver list, add entries to /etc/hosts, or install a rogue root certificate so that hijacked HTTPS connections don't even produce a browser warning.
The defenses are layered: change the default router password, keep firmware patched, use encrypted DNS so the ISP can't transparently intercept (more on this below), and audit /etc/hosts and configured resolvers periodically.
DNS spoofing on the local network (ARP + DNS combo)
On a shared LAN — coffee shop Wi-Fi, hotel networks, conference floors — an attacker doesn't need to poison a resolver or compromise your router. They can sit between you and the gateway with an ARP spoofing attack, then answer DNS queries themselves.
The technique chains two protocols. ARP spoofing convinces your laptop that the attacker's MAC address belongs to the gateway IP. Now all your outbound traffic goes through them. When your laptop sends a plaintext DNS query, they reply faster than the real resolver with a forged answer. Tools like ettercap and bettercap automate this end-to-end.
Encrypted DNS (DoH/DoT) defeats this specific attack because the attacker can't read or forge a TLS-protected query. A trustworthy VPN also helps because the DNS query is tunneled inside the VPN connection before the local network ever sees it — see VPN vs Proxy vs Tor for the privacy trade-offs of each approach.
DNS over HTTPS (DoH) and DNS over TLS (DoT) — what they protect, what they don't
DoH and DoT are two ways of wrapping DNS queries in TLS so they're encrypted and authenticated in transit. DoT (RFC 7858) runs over a dedicated TCP port, 853, which makes it easy to identify and easy for networks to block. DoH (RFC 8484) tunnels DNS queries inside ordinary HTTPS requests on port 443, making them indistinguishable from regular web traffic.
Both achieve the same security goal: an observer on the network path between you and your resolver cannot see what you're looking up, and cannot inject forged responses. This kills passive ISP surveillance of your browsing, defeats LAN-level spoofing, and prevents the transparent-redirect-on-port-53 trick.
DNSSEC — authentication, not encryption
DNSSEC solves a different problem than DoH/DoT. Where DoH/DoT encrypts the channel between you and the resolver, DNSSEC cryptographically signs the records themselves. The signatures are produced by the domain's authoritative name servers and can be verified all the way back to the root zone via a chain of trust.
In practice that means: when DNSSEC is correctly deployed, a validating resolver can detect a forged answer no matter where in the path it was injected — even by another resolver. Cache poisoning attacks fail because the forged record won't carry a valid signature. The trade-off is operational: zones must be signed and key-rolled properly, and broken signatures cause hard failures (the domain becomes unresolvable). It also does not hide what you're looking up — the queries and answers are still in plaintext on the wire unless you also use DoH/DoT.
DoH/DoT and DNSSEC are complementary, not alternatives. Encrypted transport hides the query; signatures prove the answer is real. Major public resolvers validate DNSSEC by default; you inherit the benefit by using them.
Choosing a trustworthy resolver
Whoever resolves your DNS sees a log of every domain you visit. That makes resolver choice a privacy decision as much as a security one. A few options worth knowing:
- 1.1.1.1 — Cloudflare. Fast globally, supports DoH and DoT, validates DNSSEC, audited "no logs beyond 24 hours" policy. 1.1.1.2 adds malware filtering; 1.1.1.3 adds malware + adult content filtering.
- 9.9.9.9 — Quad9, run by a Swiss-based non-profit. Blocks known-malicious domains by default using threat-intelligence feeds. DoH and DoT supported, DNSSEC validated.
- NextDNS — customizable per-account filtering (ads, trackers, malware, categories), with detailed logs you control. Free tier covers personal use.
- AdGuard DNS — opinionated ad and tracker blocking at the DNS layer. Useful if you don't want to run blockers on every device.
- 8.8.8.8 — Google. Reliable and fast, but you're handing Google an additional view of your browsing on top of everything else they already see. Acceptable as a fallback, not ideal as a primary.
Whatever you pick, configure it on your router so every device on the network inherits it via DHCP, and enable DoH or DoT in your browser and OS so the queries are encrypted in transit.
Checking your own setup
The fastest way to confirm which resolver is actually answering your queries is the DNS lookup tool here, plus a couple of local commands:
- dig +short whoami.cloudflare CH TXT @1.1.1.1 — returns the IP Cloudflare sees you connecting from, confirming you're really talking to 1.1.1.1 and not a transparent intercept.
- dig example.com +dnssec — shows the AD ("authenticated data") flag if DNSSEC validation succeeded.
- nslookup -type=ns example.com — lists authoritative name servers for a domain. Useful for sanity-checking that records are coming from where you expect.
- Visit 1.1.1.1/help or on.quad9.net in a browser — both tell you whether your current setup is using their encrypted endpoints.
Quick word on enterprise DNS hygiene
In a corporate environment the picture changes. You want split-horizon DNS so internal hostnames resolve to internal IPs without ever leaking to public resolvers. You want all client devices forced through internal resolvers (block outbound port 53, 853, and known DoH endpoints at the firewall) so that visibility is preserved and DNS-based exfiltration is harder. You want resolver query logs shipped to your SIEM — DNS logs are one of the highest-signal data sources for detecting compromise, since most malware eventually has to look up a C2 domain. And if you publish DNS yourself, sign your zones with DNSSEC so downstream validators can detect tampering.
The themes are the same as on a home network — control the resolver, encrypt the path, authenticate the records — but the stakes and the tooling are different.
Related: DNS lookup tool · What is DNS? · IP address privacy protection