Recursive DNS lookup chain and the DHCP DORA lease handshake
This tool animates two of the most common name- and address-assignment protocols in any IP network. The DNS mode walks through a full recursive lookup — client, recursive resolver, root server, TLD server, and authoritative nameserver — showing exactly which hop answers which question. The DHCP mode animates the classic DORA four-way handshake (Discover, Offer, Request, Acknowledge) that assigns a client its IP address, gateway, and DNS servers.
A client's stub resolver almost never talks to root, TLD, or authoritative servers directly — it delegates the entire lookup to a recursive resolver (run by an ISP or a public service like 8.8.8.8 or 1.1.1.1). That resolver walks the DNS hierarchy on the client's behalf: it starts at a root server to find which servers handle the top-level domain (.com, .org, etc.), then queries that TLD server to find the domain's authoritative nameserver, and finally queries the authoritative server directly for the actual record. Each server below the authoritative one only ever returns a referral ("ask this other server"), not the final answer — only the authoritative nameserver knows the real A/AAAA/MX/etc. record.
DHCP (Dynamic Host Configuration Protocol, RFC 2131) automatically assigns IP configuration to new devices via a four-message exchange. DHCPDISCOVER and DHCPREQUEST are both broadcast because the client has no IP address yet and does not know in advance which server(s) will respond — multiple DHCP servers on a segment can all see and answer a DISCOVER. Broadcasting the REQUEST additionally tells any non-chosen server that its offer was declined, letting it return that address to the free pool immediately rather than waiting for a timeout.
Both protocols rely on time-bounded caching to reduce network chatter. DNS answers carry a TTL (time-to-live) set by the authoritative zone administrator; resolvers and clients may reuse the cached answer until it expires, at which point a fresh lookup is required. DHCP leases work similarly but from the opposite direction — a client proactively renews its lease via a unicast DHCPREQUEST once it reaches roughly 50% of the lease duration (the T1 timer), well before the lease actually expires, to avoid any interruption in connectivity.
It could in theory, but almost no client stack implements full iterative resolution — it is far more efficient to delegate the whole walk to a recursive resolver that already caches answers for thousands of other clients, dramatically cutting root/TLD server load and typical lookup latency.
The client accepts one offer (commonly the first one received) and broadcasts a DHCPREQUEST identifying which server's offer it is accepting. Every DHCP server on the segment sees this broadcast; any server whose offer was not chosen releases its reserved address back into its available pool.
Because DHCPDISCOVER is a Layer 2 broadcast, it cannot cross a router boundary by default. A DHCP relay agent (configured as an "ip helper-address" on Cisco routers) listens for DHCP broadcasts on a client subnet and forwards them as unicast to a DHCP server on a different subnet, then relays the reply back — this is how one central DHCP server can serve many remote VLANs.
When a name genuinely does not exist, the authoritative server returns NXDOMAIN, and resolvers cache that negative result too (per the SOA record's minimum TTL field) so repeated lookups for a nonexistent name do not repeatedly hit the authoritative infrastructure.
Try our Enterprise IT Networks Studio
More calculators, simulators, and guides for this discipline.