DNS Spoofing and DNS Hijacking: How Forged Answers Work

How DNS spoofing works on the wire

A resolver accepts a response when it matches the question, arrives from the expected address and port, and carries the right 16-bit ID field. RFC 5452 counts the odds: with only 65,536 possible IDs and a fixed source port, an attacker who floods the resolver with guesses has a realistic chance of matching one before the real answer arrives.

An attacker on the same network has it easier. On shared Wi-Fi or a compromised transit link, the query is visible in plain text, so nothing has to be guessed: the attacker reads the ID and port and replies faster than the real resolver. RFC 3833 lists this, eavesdropping combined with spoofed responses that beat the real one back.

DNS cache poisoning and the Kaminsky attack

DNS cache poisoning moves the forgery from one device to a shared resolver. If the resolver caches a fake record, every client using it receives the forged address until the record’s time to live expires. One successful guess can redirect every user of that resolver, which is why resolvers rather than single laptops were the most attractive target.

In July 2008 Dan Kaminsky published a technique that made DNS cache poisoning far more practical; RFC 7873 still cites it. The attacker no longer waits for a cached record to expire: each query for a random name under the target zone opens a fresh race, and a forged referral in any winning reply can take over the zone.

The fix came in RFC 5452 (January 2009): use an unpredictable source port for every outgoing query, so the attacker has to guess the port as well as the ID. RFC 7873 added DNS Cookies, which let a resolver reject forged replies that do not carry the expected cookie value. Neither change authenticates the data, so DNS spoofing stays possible.

DNS hijacking: when the resolver itself is the problem

DNS hijacking skips the race entirely. Instead of forging an answer to your resolver, the attacker changes which resolver you talk to. A home router with a default password can have its DNS setting rewritten, malware can replace the system resolver on a single computer, and a network operator can quietly answer queries that were addressed to someone else.

The common thread in DNS hijacking: the answers come from a server that is allowed to answer, as far as your device can tell. No packet is forged, so source-port randomisation and cookies do nothing here. Microsoft’s Windows 11 security documentation names DNS hijacking as a risk its encrypted DNS controls are meant to reduce.

Hotel and airport networks add a third variant: captive portals that answer every lookup with a login page until you accept the terms. That behaviour is usually benign, but it uses the same mechanism as a malicious hijack, and it is why encrypted DNS clients need special handling for portals. The guide to DNS on public Wi-Fi covers that case.

What DNSSEC fixes and what it leaves open

DNSSEC attacks DNS spoofing at the data level. A signed zone publishes signatures over its records, and a validating resolver checks them against a chain of keys that starts at the root. RFC 4033 describes this as data origin authentication and integrity: a forged record fails validation, so DNS cache poisoning stops working for signed zones on validating resolvers.

RFC 4033 is equally clear about the limit: DNSSEC does not provide confidentiality, by deliberate design. It also does nothing when the zone is unsigned, when the resolver does not validate, or when the last hop between your device and the resolver is hijacked. The DNSSEC page explains signatures, keys and validation in more detail.

What encrypted DNS fixes

Encrypted DNS protects the path between your device and the resolver. DNS over TLS (RFC 7858) names on-path tampering as one of the threats it addresses, and DNSCrypt signs every resolver certificate with the provider’s Ed25519 key. A network that tries to answer in the resolver’s place cannot produce a valid response, so the client rejects the forgery.

Neither layer replaces the other. Encrypted DNS proves that the answer came from your chosen resolver; DNSSEC proves that the resolver did not invent it. Running both, for example dnscrypt-proxy with require_dnssec = true pointing at a validating resolver, closes the local network attack and the upstream cache attack at once. The encrypted DNS overview compares the protocols.

Checking your own setup for DNS spoofing

Start with the resolver you actually use. The DNS leak check lists commands that reveal which server answers your queries; if it is not the one you configured, you are looking at DNS hijacking rather than spoofing. Then confirm DNSSEC: dnscrypt-proxy -resolve example.com reports whether the resolver returns signed answers.