DNS Cache Poisoning and Domain Hijacking, Explained

DNS cache poisoning (also called DNS spoofing) is an attack that inserts forged records into a Domain Name System (DNS) resolver’s cache, so that lookups for a legitimate domain return an attacker-controlled IP address. Domain hijacking is a different attack with a similar payoff: instead of corrupting a resolver, the attacker takes over the domain’s registration itself — usually by compromising the registrar account — and changes the authoritative records at the source. Both send victims to servers the attacker controls, but they strike at different layers of the DNS trust chain.

Why DNS is worth attacking

Almost every connection starts with a name lookup. When your browser asks for bank.example.com, a recursive resolver (typically run by your ISP or company) walks the DNS hierarchy, gets an answer from the domain’s authoritative name servers, and caches it for the record’s time-to-live (TTL). Every device that trusts that resolver now gets the cached answer without any further checking.

That caching is the attack surface. If an attacker can get a bad answer into the cache — or change the authoritative source that answers in the first place — every downstream user is silently redirected. No malware on the victim’s machine, no phishing link to click. The victim types the correct address and still lands on the attacker’s server, which typically hosts a convincing clone of the real site to harvest credentials or payment data.

How DNS cache poisoning works

Classic cache poisoning is a race. When a resolver sends a query to an authoritative server, it will accept the first response that matches the query’s source port and 16-bit transaction ID. An attacker who can predict or brute-force those values floods the resolver with forged responses, hoping one lands before the legitimate answer. If a forgery wins, the resolver caches the attacker’s IP address for the domain and serves it to every client until the TTL expires — attackers set long TTLs to make the poisoning persist.

The 2008 Kaminsky technique made this dramatically more practical: instead of racing to poison one record, the attacker triggers thousands of lookups for random nonexistent subdomains (a1x9.bank.example.com, and so on), getting unlimited fresh races and injecting a forged delegation that hijacks the entire zone in the cache.

Two other paths get the same result without the race:

• On-path spoofing. An attacker already positioned on the local network (for example via ARP poisoning or a rogue access point) simply answers DNS queries directly, faster than the real resolver ever could.
• Hosts-file or resolver tampering. Malware edits the local hosts file or changes the device’s configured DNS server, so lookups never reach a trustworthy resolver at all. Exam questions sometimes lump this in as “local” DNS poisoning, and it’s exactly the kind of local tampering host-based intrusion prevention is built to block.

The main defense is DNS Security Extensions (DNSSEC), which adds digital signatures to DNS records so a validating resolver can detect forged answers regardless of who responded first — signatures whose strength rests on collision-resistant hashes, the property the birthday attack targets. Randomized source ports, 0x20 case randomization, and encrypted transports like DNS over HTTPS (DoH) and DNS over TLS (DoT) also shrink the spoofing window.

How domain hijacking works

Domain hijacking skips the resolver entirely and steals control of the domain’s registration. The typical path: the attacker phishes or credential-stuffs their way into the domain owner’s registrar account, then changes the authoritative name server (NS) records — or transfers the domain to another registrar altogether. From that moment, the legitimate DNS hierarchy hands out the attacker’s answers. Resolvers everywhere cache them honestly, because as far as DNS is concerned, the records are genuine.

That’s the telltale sign in an investigation: the company’s public website suddenly resolves to an unfamiliar server, and the registrar account shows a login followed by NS record changes. Nothing was “poisoned” — the domain itself was taken over. DNSSEC does not help here, because the attacker controls the zone and can re-sign it or strip the signatures.

Defenses are administrative, not cryptographic: strong unique registrar passwords with multi-factor authentication (MFA), registrar lock (which blocks transfers and record changes until the lock is removed through an out-of-band process), monitoring for unexpected changes to NS and registration records, and keeping registration contact emails on a domain the attacker can’t also seize.

A related nuisance is domain squatting (registering a lookalike or expired domain, e.g. typosquatting) — the attacker never touches your domain, they just register a deceptive one of their own. The exam treats that as a distinct concept.

Cache poisoning vs domain hijacking

	DNS cache poisoning	Domain hijacking
What’s compromised	A resolver’s cached answers	The domain registration itself
How	Forged responses win a race into the cache	Registrar account takeover; NS records changed
Scope of victims	Clients of the poisoned resolver	Everyone on the internet
Duration	Until the cached TTL expires or cache is flushed	Until the owner recovers the registrar account
Are the DNS records “authentic”?	No — forged	Yes — issued by the (stolen) authoritative source
Key defense	DNSSEC validation, port/ID randomization	Registrar MFA, registrar lock, change monitoring

How the SY0-701 exam tests this

• Name the attack from the mechanism. A scenario describes a resolver’s cache being corrupted so a legitimate domain resolves to a malicious IP, and asks what the attack is called. Mechanism at the resolver = DNS cache poisoning/spoofing.
• Hijacking hidden in the forensics. You’re told a website now resolves to a phishing server, and the investigation trail shows stolen credentials used at the registrar to change name server records. The registrar detail is the discriminator — the answer is domain hijacking, not poisoning.
• Pick the mitigation for the layer. Given a poisoning scenario, the best answer is DNSSEC (validating signed responses); given a hijacking scenario, it’s registrar MFA/registrar lock. Crossing these up is the trap.
• Distinguish from lookalikes. Options often include typosquatting, on-path (man-in-the-middle) attack, and URL redirection. If the real domain’s resolution changed, it’s poisoning or hijacking; if the attacker registered a similar domain, it’s squatting.

Poisoning vs hijacking is a one-detail discrimination, and the exam knows it — work through SY0-701 practice questions until the registrar clue stands out immediately.

Quick reference

• DNS cache poisoning = forged records injected into a resolver’s cache; victims are that resolver’s clients, until the TTL expires.
• Poisoning exploits the race to answer a query with a matching transaction ID and source port; Kaminsky-style attacks retry endlessly via random subdomains.
• Domain hijacking = takeover of the domain registration (registrar account compromise, NS record changes); affects everyone, and DNSSEC won’t save you.
• Registrar clue in a scenario → hijacking. Resolver/cache clue → poisoning.
• DNSSEC adds signatures so resolvers can validate answers — the canonical anti-poisoning control.
• Registrar lock + MFA on the registrar account are the canonical anti-hijacking controls.
• Typosquatting is neither: the attacker registers a different, lookalike domain.