TL;DR: A stub resolver asks a recursive resolver, which walks the root, the top-level domain and the domain's authoritative servers and caches answers for their TTL. Attackers forge answers to poison a resolver's cache (made much harder by randomising query IDs and source ports after the 2008 Kaminsky attack), run a malicious resolver on a network they control, or take over the domain itself through the registrar or DNS provider. DNSSEC lets a validating resolver verify that records were signed by the zone's key, defeating forgery and poisoning, but it does not encrypt anything. DNS over HTTPS or TLS encrypts and authenticates the hop from client to resolver, providing privacy and integrity on that link, but trusts the resolver. Neither replaces TLS certificate validation, which still catches a wrong IP for an HTTPS site.
How to approach it
Explain resolution and caching first, because poisoning only makes sense with the cache in mind. Then group attacks by where they happen (on the path, at the resolver, at the authoritative side, at the registrar), and map DNSSEC and encrypted DNS onto those positions precisely.
A strong answer
Random query IDs and source ports make the race hard; DNSSEC makes a forged answer fail validation.
Client
stub resolver
Recursive
caches answers
Authoritative
root → TLD → zone
Attacker
off path
- Lookup
Client to Recursive
1bank.example A?
1. bank.example A?
Often over plain UDP; DoH or DoT would protect this hop.
Resolution. The client's stub resolver sends a query (UDP, port 53 by default) to a recursive resolver. If the answer is not cached, the resolver asks a root server for the TLD's servers, then the TLD's servers for the domain's authoritative servers, then those for the record. It caches each answer for its TTL and returns it to the client. A query is matched to a response by the 16-bit transaction ID and the source port.
Attacks by position.
- Off-path cache poisoning. The attacker races the real authoritative answer with forged responses, guessing the transaction ID (and, before 2008, the fixed source port). Dan Kaminsky's 2008 technique made this practical by querying random subdomains so the race could be repeated many times, and by injecting authority records that redirected the whole domain. The response was source port randomisation across resolvers, multiplying the guess space, plus later hardening (0x20 case randomisation, stricter response validation).
- On-path or local network. On hostile Wi-Fi, a rogue DHCP server or the access point itself supplies a malicious resolver, or the attacker answers queries directly.
- Resolver compromise. A compromised or malicious resolver answers whatever it likes for its users.
- Authoritative and registrar side. An attacker who takes over the domain's registrar account or DNS provider changes the records at the source, which no cache defence can detect; several notable incidents redirected organisations' mail and login domains this way.
- Dangling records. A CNAME pointing to a decommissioned cloud resource lets someone claim that resource and serve content on your subdomain (subdomain takeover).
DNSSEC: authenticity of the data. Each zone signs its records; the parent zone vouches for the child's key with a DS record, forming a chain up to the root's trust anchor. A validating resolver rejects records that do not verify, which defeats forgery and cache poisoning. Limits: it does not encrypt, many domains do not sign, validation usually happens at the resolver (so the last hop to the client is unprotected unless that is also secured), and it does not help if the attacker controls the signing zone through the registrar.
Encrypted DNS: privacy and integrity of the hop. DNS over TLS (port 853) and DNS over HTTPS (port 443) encrypt and authenticate the connection between client and resolver, so a network observer cannot read or tamper with queries on that link. Limits: the resolver sees everything and could lie; it does not prove records came from the zone owner.
| Stops forged records in a cache | Hides queries from the network | Trusts the resolver | |
|---|---|---|---|
| DNSSEC (validating resolver) | Yes | No | For validation, yes |
| DoT / DoH | Only on the client-resolver hop | Yes | Yes |
| TLS certificate validation | Stops connection to an impostor for HTTPS | No | No |
Defences for your own domains. Registrar lock and MFA on registrar and DNS provider accounts, DNSSEC signing, monitoring of record changes and Certificate Transparency for unexpected certificates, cleaning up dangling CNAMEs, and email records (SPF, DKIM, DMARC) to protect the domain's mail identity.
What interviewers probe next
- "If DNS is poisoned for a bank's domain, are users compromised?" For HTTPS with valid certificate checking and HSTS, the attacker cannot present a trusted certificate, so connections fail. Users of plain HTTP or apps without proper validation are exposed.
- "Why do enterprises sometimes dislike DoH?" It can bypass the organisation's resolver and its filtering and logging; they configure endpoints to use the corporate resolver.
- "What is a subdomain takeover?" A DNS record still points to a cloud resource you deleted; someone else creates a resource with that name and serves content on your subdomain.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A company's recursive resolver serves 5,000 employees, and someone asks how an attacker could make it return a false address for the company's SSO domain.
Start here
How does recursive resolution work?
Who does the resolver ask, in what order?
A stub resolver asks the recursive resolver, which walks the root, the top-level domain and the domain's authoritative servers, then caches answers for their TTL.
Carry it forwardRecursive resolvers walk the hierarchy and cache.
Weak answerThinking clients query authoritative servers directly.
Constraint changes
How does cache poisoning work?
What must a forged answer match?
An attacker forges answers that the resolver accepts and caches, so every employee gets the false address until the TTL expires. Randomising query IDs and source ports after the 2008 Kaminsky attack made forging much harder.
Carry it forwardPoisoning plants false answers in caches.
Weak answerAssuming poisoning is solved forever.
Constraint changes
What other routes lead to false answers?
What if the attacker controls the domain's records?
Running a malicious resolver on a network the attacker controls, or taking over the domain itself through a compromised registrar account or DNS provider. Registrar takeover affects everyone, not just one resolver.
Carry it forwardRegistrar and DNS provider accounts are critical.
Weak answerSecuring the resolver but not the registrar.
Constraint changes
What does DNSSEC add?
Which hop does DNSSEC protect?
Signed records let validating resolvers reject forged answers. It protects integrity between authoritative servers and the resolver, not the last hop to the client, unless the client also validates or uses encrypted DNS to the resolver.
Carry it forwardDNSSEC validates records at the resolver.
Weak answerAssuming DNSSEC encrypts queries.
Constraint changes
What protects the SSO login even if DNS is poisoned?
What stops a fake SSO server?
TLS certificate validation: the attacker cannot present a valid certificate for the SSO domain. Phishing-resistant MFA bound to the origin adds another layer.
Carry it forwardTLS and origin-bound MFA defeat DNS attacks.
Weak answerRelying on DNS alone for trust.
Now defend it
How would you protect the SSO domain?
Harden the resolver with randomisation, DNSSEC validation and patching; use encrypted DNS from clients to the resolver; lock the registrar and DNS provider accounts with MFA and registry lock; sign the zone with DNSSEC; and rely on TLS and origin-bound MFA as the decisive defences.
How it's scored
Weak: "DNSSEC encrypts DNS."
Hire: Explains recursive resolution and caching, cache poisoning and the randomisation fix, and distinguishes DNSSEC (authenticity) from DoH/DoT (privacy).
Strong Hire: Groups attacks by position including registrar takeover and dangling records, explains the Kaminsky technique and its mitigations, states DNSSEC's chain of trust and deployment limits, tabulates what each control protects, and connects back to TLS validation and domain hygiene.
Common mistakes
- Saying DNSSEC provides confidentiality.
- Believing encrypted DNS proves record authenticity.
- Ignoring registrar and DNS-provider account takeover.
- Forgetting dangling DNS records.