Earlier on this trail, DNS was the internet's phone book — the service that turns names into addresses before anything else happens. Here's the detail that post politely deferred: DNS was designed in the 1980s with essentially no security whatsoever. Answers weren't authenticated, queries weren't encrypted, and everyone trusted everyone. Attackers noticed. What follows is the three main ways the phone book gets abused, and what each one teaches.
1. Cache poisoning: writing lies into the phone book
Recall that resolvers cache answers for speed. Cache poisoning is tricking a resolver into caching a false answer — so that everyone who asks it "where is mybank.com?" gets the attacker's server instead, and every one of those users' padlock-less traffic flows somewhere hostile. Classic DNS made this alarmingly feasible: answers were accepted if a simple transaction ID matched, and IDs could be guessed at speed. The landmark 2008 Kaminsky research showed poisoning could be industrialised, and it forced emergency changes across the entire internet. The deeper defence is DNSSEC — digital signatures on DNS records, so resolvers can verify an answer came from the domain's true owner rather than merely arriving first. (Same signature logic as the encryption post; adoption, honestly, remains patchy.)
2. Tunnelling: smuggling contraband inside queries
The cleverest abuse inverts the threat: DNS not as target but as getaway vehicle. Firewalls almost never block DNS — everything breaks without it — so it's often the one protocol guaranteed to pass. Attackers exploit this by encoding stolen data into the names being looked up: a compromised machine "resolves" x7f3a9c...chunk-of-your-database.evil-domain.com, the attacker's name server for evil-domain.com receives the query, decodes the payload, and can even reply with encoded commands. Data walks out of the building disguised as phone-book lookups. The defence is behavioural: absurd query volumes, very long random-looking subdomains, and DNS analytics — one reason mature security teams log and inspect DNS specifically.
3. Hijacking: stealing the domain itself
Why forge answers when you can change the phone book's master entry? Compromise the account at the domain registrar — often via simple phishing — and you can repoint a company's real DNS records at servers you control. Every visitor, every email, delivered to the attacker, with valid-looking everything. Real campaigns have done this to governments and enterprises at scale. The defence is unglamorous and effective: registrar accounts with strong MFA, registry locks, and monitoring for record changes — the domain account is crown-jewels infrastructure that many organisations forget they own.
Pattern worth carrying up the trail: all three attacks exploit trust that was never verified — trust in answers (poisoning), trust in a protocol's innocence (tunnelling), trust in an account (hijacking). Modern fixes — DNSSEC, encrypted DNS, DNS filtering, registrar hardening — are all the same move: replacing assumed trust with checked trust. You've seen that move before on this trail, and you'll see it again. It's most of what security progress is.