DNS201
Understand DNS Cache Poisoning with Diagrams and Exercises
After you have grasped the basics of name resolution in DNS101, this DNS security follow-up course is a natural next step. The axis here is "what happens when a forged answer is left in a shared resolver's cache" — and we walk through transaction ID, source port, bailiwick, TTL, and DNSSEC in order.
Defense and observation perspective
42 questions in total
Graded in-browser
Saved to localStorage
Time
3–4 hours
Question count
42 questions
Format
7 chapters + short exercises + case studies
Cost
Free
Important note: This is a knowledge course for defense and diagnosis. We do not cover attack steps or tool-building against real environments.
First diagram to have in mind
| Actor | Role |
|---|---|
| User / browser | The side that looks up names. It trusts the resolver's answer. |
| shared recursive resolver | This is where the cache lives. It is shared across many users. |
| authoritative servers | Hold the canonical data for each zone. |
If a bad RRset ends up in the cache of the shared recursive resolver, the same bad answer gets served to every user of that resolver.
What makes this course different
1. High-level understanding of the mechanism
Instead of attack steps against real environments, we focus on why a shared cache is dangerous and what defenders should watch.
2. Feel bailiwick and the race through models
Touch small models that illustrate in-bailiwick glue, out-of-bailiwick additional data, and the relationship between entropy and attempts.
3. Avoid misreading what DNSSEC covers
You get origin authentication and integrity, but confidentiality is a separate matter — and the last-hop trust problem still remains.
4. End with case studies
Wrap up with 8 case questions covering split-horizon, negative caching, NAT, the AD bit, and other topics that are easy to confuse in the field.
Five viewpoints we keep reusing
1. Which layer's cache?
Do not confuse browser / OS / recursive resolver / authoritative caches.
2. Under what conditions will a response be accepted?
Only when question, ID, address, and port all match is it considered the same transaction.
3. How far can you trust that additional data?
Keep glue, referral, and final answer separate, and stay conscious of bailiwick.
4. What drives success probability?
Think of the width of entropy and the number of attempts as separate levers.
5. The boundary between DNSSEC and operations
Separate what signatures can protect from the trust problems at the stub / recursive / channel layers.
Chapter overview
1 Introduction — What is DNS cache poisoning
5 questions. Grasp the picture that when a shared resolver memorizes a forged RRset, every user sees the same bad answer.
2 Cache and bailiwick — What can you trust
5 questions. Separate referral / glue / bailiwick, and sort out what is safe to put in the cache.
3 Acceptance conditions and race — ID / port / TTL / time window
6 questions. Capture the response acceptance conditions and the race window in concrete numbers for ID / source port / TTL.
4 Lessons from 2008 — Parallel queries and short-term mitigations
5 questions. Understand the widely-known 2008 issue as a high-level attack concept together with its short-term mitigations.
5 DNSSEC and defense in depth — What it protects and what remains
6 questions. Pin down DNSSEC's scope and the last-hop limits, and assemble defense in depth.
6 Observation and triage — dig / logs / common misdiagnoses
7 questions. Use dig, logs, and negative caching to tell suspicious behavior apart from common misdiagnoses. Also covers patterns for spotting poisoning indicators in logs.
7 Final review and case studies
8 questions. Tie everything together with case questions covering split-horizon / NAT / AD bit and other topics that are easy to confuse.
Tips for studying
- Fix "which layer's cache" first, then read the question.
- Do not skim the numeric questions in your head — write TTL and elapsed time out in seconds.
- Confirm the bailiwick discussion in Chapter 2, the entropy discussion in Chapter 3, and the DNSSEC discussion in Chapter 5 with formulas and numbers.
- After the final review, doing one more pass on only the questions you have not yet solved helps them stick.
Prerequisites before you start
- Having the DNS101-level basics (recursive lookup, authoritative servers, TTL) helps you get started.
- You do not need deep cryptography theory. We cover DNSSEC only as far as needed.
References
- RFC 5452: Measures for Making DNS More Resilient against Forged Answers
- RFC 4033: DNS Security Introduction and Requirements
- RFC 2308: Negative Caching of DNS Queries
- RFC 4035: Protocol Modifications for the DNS Security Extensions
- Unbound documentation (implementation examples for glue / DNSSEC hardening)
- JVNVU#800113: Cache poisoning vulnerability in multiple DNS implementations