The scenario
The Client (10.0.1.10) is set to use the Resolver (10.0.1.2) as its DNS server, the way an office laptop uses the company resolver. The Resolver holds no address records at all. It has one forwarding rule: questions for names in example.lab go to 10.0.2.2, the Auth-DNS server on the server subnet. Auth-DNS is authoritative for example.lab and holds the record www.example.lab -> 10.0.2.20, the Web server. When the Client looks up www.example.lab, two DNS conversations happen: Client to Resolver, then Resolver to Auth-DNS through the Router, with each answer travelling back the same way. Real resolvers do more than this. A recursive resolver starts at the root servers, is referred to the servers for the top-level domain and then to the zone's authoritative servers, and caches every answer for its TTL. This lab models neither the root and top-level steps nor caching; the forwarding rule stands in for the last step of that walk.
What you will work out
Understand the difference between a resolver that asks on your behalf and an authoritative server that owns the answers, and why the resolver needs its own path to that server.
Why this matters
When a name fails to resolve, the question is where along the chain it broke: the client's DNS setting, the resolver, the resolver's path to the authoritative server, or the record itself. Asking each server directly with dig name @server walks that chain one link at a time. The same split between resolvers and authoritative servers sits behind office resolvers that forward internal zones and cloud resolvers that answer for private zones.
Running it
DNS Hierarchy: Resolver and Authoritative Server opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.
Open DNS Hierarchy: Resolver and Authoritative Server
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →