DNS Spoofing

DNS spoofing makes a computer accept a fake answer to a DNS question, so a name you trust leads to a server an attacker controls. Planted in a shared resolver's cache, one fake answer misleads everyone who uses that resolver until it expires.

How a normal lookup works

Computers connect by IP address, so before your browser can load bank.example it has to ask which address that name points to. The question goes to a recursive resolver: a DNS server run by your ISP, your employer or a public service. If the resolver has the answer cached, it replies straight away. If not, it walks the hierarchy: a root server, then the server for the top-level domain, then the domain's own authoritative name server, which holds the real record.

The resolver then keeps the answer for as long as the record's TTL (time to live) allows, often minutes or hours. Caching is what keeps DNS fast, because thousands of people behind one resolver share one lookup. It's also what makes spoofing so damaging. If TTLs are new to you, DNS Propagation covers how cached records age out.

Why DNS is easy to lie to

Classic DNS was designed in the 1980s for a network where everyone was assumed to be friendly. Questions and answers travel as plain UDP packets on port 53, neither encrypted nor signed. When a resolver sends a question, it accepts the first reply that looks right:

• it comes from the address the question went to;
• it arrives on the port the question left from;
• it carries the same 16-bit transaction ID;
• it repeats the same question.

Nothing in the reply proves the name server wrote it. Anyone who can build a packet that passes those checks, and get it there before the real one, has written the answer.

Cache poisoning: one fake answer, many victims

When the fake answer lands in a resolver's cache, the attack is called DNS cache poisoning. The attacker doesn't need to be on your network. They only need the resolver to ask a question, then win a race against the real name server.

Here is that race, step by step:

A transaction ID has only 65,536 possible values. For years the main barrier was timing: if the attacker lost the race, the genuine answer was cached and they had to wait for its TTL to run out before trying again.

In 2008, the security researcher Dan Kaminsky showed a way round that. The attacker makes the resolver look up made-up names such as a1.bank.example, a2.bank.example and so on. Each one is a fresh cache miss, so a fresh race. A forged reply can also carry extra records claiming the attacker's server is the name server for the whole of bank.example. Win once, and the attacker controls every name under the domain.

Resolvers responded by sending each query from a random source port as well as a random ID, so a forged reply has to guess both. That multiplied the number of guesses needed by tens of thousands and made blind poisoning far harder. It still depends on guessing being hard: nothing in the reply proves where it came from.

Other ways to spoof DNS

Cache poisoning is the version the video shows, but a false answer to 'where is this name?' can arrive by other routes:

• On-path spoofing: on shared Wi-Fi, someone on the same network can see your DNS questions and answer them before the real resolver does. They don't need to guess, because they can read the transaction ID.
• Rogue DNS settings: a compromised home router, or a fake hotspot, hands out the attacker's resolver through DHCP. Every lookup then goes to a server that lies on purpose.
• The hosts file: malware can add a line to /etc/hosts (or its Windows equivalent), which the operating system checks before it asks DNS at all.
• Hijacking the domain: an attacker who gets into the domain's account at its registrar or DNS provider can change the real records. Every resolver then serves the attacker's address, and signature checks won't catch it, because the records really have changed.

What an attacker does with it

Picture a small office whose router has been quietly switched to an attacker's resolver. Most lookups get honest answers, so nothing seems wrong. But bank.example now resolves to a server the attacker runs, hosting a copy of the bank's login page. Staff type their usernames and passwords, the fake page records them and then redirects to the real site, and nobody notices.

The address bar shows the right name, so the usual advice to check the URL doesn't help. What should give it away is the certificate, covered below. The same position gives the attacker other options:

• Phishing: a lookalike login page on the real name.
• Malware: a download or software update fetched from the attacker's server instead of the vendor's.
• Mail interception: a forged MX record, the record that says where a domain's email goes, sends messages to the attacker's mail server.

A poisoned router misleads one office. A poisoned ISP resolver misleads every customer who uses it, for as long as the fake record's TTL lasts, and the attacker chooses that TTL.

How to defend against it

The video names three defences: DNSSEC, HTTPS and encrypted DNS. Each protects a different part of the trip, which is why you want all three.

DNSSEC

DNSSEC adds digital signatures to DNS records. The domain's owner signs its records, the parent zone vouches for the owner's key, and so on up to the root, whose key resolvers already trust. A validating resolver checks that chain for every signed answer and throws away anything that doesn't verify. A forged reply then fails, however well its ID and port were guessed.

It has limits. It only helps for domains that sign their records and resolvers that check them, and neither is universal. It encrypts nothing, so anyone watching still sees which names you look up. And most devices trust their resolver's verdict rather than checking signatures themselves, so the hop between your laptop and the resolver isn't covered.

HTTPS

HTTPS is the backstop. Even if DNS sends you to the wrong server, that server must present a certificate for bank.example from a certificate authority your browser trusts. An attacker who controls a DNS answer normally can't get one, so the browser shows a full-page warning instead of the login form.

That only works when the connection really is HTTPS and the user doesn't click past the warning. HSTS, a response header that tells the browser 'only ever use HTTPS for this site', stops an attacker quietly moving a returning visitor to plain HTTP, where no certificate is checked.

Encrypted DNS

DNS over HTTPS (DoH) and DNS over TLS (DoT) carry your device's questions to the resolver over an encrypted connection, and check that the resolver is who it claims to be. Someone on the same café Wi-Fi can no longer read or answer your lookups, which shuts down on-path spoofing. Most browsers and operating systems have a setting to turn it on.

It doesn't make the resolver's own answers trustworthy. If the resolver's cache is poisoned, encrypted DNS delivers the poisoned answer securely. That's the gap DNSSEC fills.

Checking answers yourself

The dig command (on macOS and Linux) shows what a resolver says about a name. Comparing your usual resolver with a public one is a quick check when something looks off:

dig +short example.com
dig +short example.com @1.1.1.1

If the two disagree, look closer. A mismatch alone isn't proof, though: large sites often return different addresses in different places.

To see whether an answer passed DNSSEC validation, ask for the signatures and read the header:

dig +dnssec example.com @1.1.1.1

;; flags: qr rd ra ad; QUERY: 1, ...

The ad flag ('authenticated data') means the resolver checked the signatures and they verified. The answer section also includes an RRSIG record: the signature itself.

Common mistakes

• Treating HTTPS as the whole answer: it protects a site only when the connection is HTTPS and people heed the warnings. A site without HSTS can still be reached over plain HTTP first.
• Mixing up DNSSEC and encrypted DNS: one proves an answer is genuine, the other hides it in transit. Neither does the other's job.
• Breaking your own domain with DNSSEC: a signature that expires, or a key change done in the wrong order, makes validating resolvers reject your real records, and the site disappears for their users. Let your DNS provider automate signing rather than doing it by hand.
• Ignoring the router: default admin passwords on home and office routers are a common way in for rogue DNS settings. Change them and keep the firmware updated.

Key takeaways

• DNS spoofing feeds a computer a false answer, so a trusted name leads to an attacker's server.
• Cache poisoning plants that answer in a resolver, and caching passes it to every user until the TTL runs out.
• Classic DNS accepts the first reply that matches a few guessable fields: nothing proves who sent it.
• DNSSEC proves an answer is genuine, encrypted DNS protects the hop to your resolver, and HTTPS catches a fake server at the end.
• If you run a site, serve it over HTTPS with HSTS and let your DNS provider sign the domain with DNSSEC.