The recursive resolver is where the actual work of DNS resolution happens — following a specific, structured process to turn a domain name into an answer, whether or not that answer was already sitting in cache.
The referral chain
When a recursive resolver has no cached answer, it starts at a root server, which doesn't know the specific answer but knows which top-level domain (TLD) servers to ask next. The TLD server, in turn, doesn't have the final answer either, but knows which authoritative server holds the actual records for that specific domain. The resolver follows this chain of referrals until it reaches an authoritative answer.
Caching at every step
Each answer along the way — including intermediate referrals — gets cached according to its TTL (time to live), which is why repeated lookups for popular domains rarely require walking the full chain again. This caching is what makes DNS fast in practice despite its distributed, multi-step design.
Negative answers
When a lookup genuinely has no answer (a domain that doesn't exist), the resolver caches that negative result too, for a period defined by the domain's own configuration — preventing repeated wasted lookups for names that consistently don't resolve.
Why not every request reaches every layer
Because of caching, the vast majority of everyday DNS lookups are answered from a resolver's cache without touching the root or TLD layers at all — the full referral chain only runs when genuinely nothing along the path has a fresh cached answer, which is relatively rare for common domains but routine for the freshly-generated hostnames a DNS leak test deliberately uses.
FAQ
How long does a full recursive lookup take?
Typically a fraction of a second when needed, though it varies with network conditions and how many referral hops are required — cached answers are essentially instant by comparison.