PlantUML DiagramDNS Hierarchy
A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
DNS is the most-used protocol you never think about. Every web request, every API call, every email begins with a name-to-IP lookup. When DNS fails, half the internet feels broken even though packets still route fine. Understanding DNS isn't optional — it's table stakes.
The hierarchy has three levels. Root servers know where TLD servers are (.com, .org, .net, etc.). TLD servers know where authoritative servers for specific domains live. Authoritative servers hold the actual records for a domain — they're the source of truth. A recursive resolver walks this hierarchy on your behalf.
| Type | Who does it | Behavior |
|---|---|---|
| Recursive | Client → Resolver | Client asks once; resolver does all the work |
| Iterative | Resolver → Root/TLD/Auth | Each server returns a referral; resolver follows it |
Most client queries are recursive — the client asks its resolver and waits for a final answer. The resolver does iterative queries against the DNS hierarchy. This split is why your ISP's resolver matters for performance — a slow resolver makes everything feel slow.
CNAME records can chain (a CNAME pointing to another CNAME) but this is bad practice and can cause resolution loops. Best practice: CNAME should point directly to an A or AAAA record. If you're resolving a chain and hit a loop, the resolver gives up — and your users see a failure.
Users intermittently can't resolve intranet hostnames while external names work fine. The failures happen for a few minutes, then recover. What's the likely cause?
Select the safest next action.
Finish the lesson once you have worked through the material. This awards ★ 50 XP.