A company's website is up, its servers are untouched, and its logs look clean. Yet customers in one city keep landing on a convincing copy of the login page and handing their passwords to someone else. Nothing was hacked in the usual sense. The attacker changed the answer to a single question every device asks hundreds of times a day: what address goes with this name?
That question is answered by the Domain Name System, and because almost every connection starts with a DNS lookup, DNS is a high-value target. On the CompTIA Security+ SY0-801 exam, DNS attacks and cache poisoning sit under objective 2.5, which expects you to read a scenario's indicators and name the attack. This lesson covers how DNS resolution works, how cache poisoning and hijacking redirect users, how DNS tunneling smuggles data in and out, and how DNSSEC, DoH and DoT defend the system.
DNS turns names into addresses through a chain of resolvers
Before you can attack DNS, you need the normal flow. When a device looks up a name, it asks a recursive resolver, usually run by the company or the ISP. If the resolver doesn't already know the answer, it walks the hierarchy: it asks a root server, which points to the server for the top-level domain such as .com, which points to the authoritative name server for the domain, which gives the final answer. The resolver hands that answer back to the device and keeps it in its cache for as long as the record's time-to-live (TTL) allows, so the next lookup is instant.
Classic DNS runs over UDP on port 53, with no authentication and no encryption. A response is accepted if it arrives on the right port and matches the query's transaction ID and question. That design is fast and was built for a smaller, more trusting internet, and nearly every DNS attack abuses one of its weaknesses: answers aren't verified, queries aren't private, and the whole system is trusted implicitly.
Two layers can be attacked. The data can be falsified, so the right question gets a wrong answer, which covers cache poisoning and hijacking. Or DNS itself can be used as a carrier for something it was never meant to move, which is tunneling.
Cache poisoning plants a false answer in a resolver's memory
A resolver caches answers to avoid repeating work. Cache poisoning, also called DNS spoofing, tricks a resolver into caching an answer the attacker chose. Every device that uses that resolver is then sent to the attacker's address until the bogus record's TTL expires, and the attacker sets a long TTL to make it last.
The original attack raced the real answer. When a resolver asked an authoritative server for a name, an attacker who could guess or see the query's 16-bit transaction ID could send a forged reply from the authoritative server's address before the real one arrived. If the forged reply matched, the resolver cached it. Dan Kaminsky showed in 2008 how to make this reliable, and the mitigation was to add source port randomization: the resolver now also picks a random source port the attacker must guess, turning 16 bits of entropy into about 32 and making blind guessing impractical. An on-path attacker who can see the query still defeats this, because they don't have to guess.
The indicator is a mismatch between what a resolver returns and the real, authoritative record. A technician comparing the two sees it directly:
$ dig +short payroll.example.com @10.10.1.5
203.0.113.200
$ dig +short payroll.example.com @1.1.1.1
198.51.100.42
The company's own resolver at 10.10.1.5 is returning an attacker's address, while a public resolver returns the correct one. The scope is the tell: cache poisoning affects only the users of the poisoned resolver, so if one office is misdirected while everyone else is fine, suspect that office's resolver. Users may also report a certificate warning on the fake site, because the attacker rarely has a valid certificate for the real name. DNSSEC, covered later in this lesson, is the direct defense, along with the port randomization already built into modern resolvers.