The question leaves, and does almost nothing on the way out
A DNS query is the most passive thing on the network: it travels inert, and every decision about what happens next belongs to something else.
What the query actually contains
Strip away the transport and a DNS query is a short, fixed-format message. It carries a name, a type, and a class — almost always IN for Internet — and a handful of flags: whether recursion is desired, whether the client accepts DNSSEC authentication data, the maximum UDP payload size it can receive. That is the complete inventory of influence a stub resolver has over the resolution process. There is no route encoded in the packet, no preference for which nameserver answers, no instruction about how long the lookup should take. The query is a question in the most literal sense: it asks, and then it waits.
The stub resolver on your workstation — the thin client that hands queries off to a configured forwarder or recursive resolver — does essentially nothing beyond forming that message correctly and sending it to whatever address is in /etc/resolv.conf or its platform equivalent. It picks no path. It has no visibility into the delegation chain, no knowledge of where the authoritative servers are, and no role in finding them. Once the query leaves the stub, the machine that sent it is out of the story until an answer arrives.
The recursive resolver owns the entire walk
Everything that actually constitutes DNS resolution happens inside the recursive resolver — the server your stub delegated to. That machine is the one that knows, or learns, where to start: it carries a copy of the root hints, a small file listing the addresses of the thirteen root servers so that it always has somewhere to begin, even from a cold cache.
From there the walk is a sequence of referrals. The resolver sends the full query name to a root server. The root server does not answer it; it returns a referral to the TLD nameservers responsible for the rightmost label — .com, .org, .uk, whatever the query ends in. The resolver follows that referral, sends the query again to a TLD nameserver, and receives another referral — this time to the nameservers listed in the registry for the specific second-level domain. The resolver follows that one too, sends the query a third time, and if the zone is not further delegated, gets an answer. Three round trips is the common case for a cold resolver; a warm cache collapses that to one, or to zero if the answer is already sitting local.
The query packet itself is identical each time. The resolver does not modify it to track progress or annotate the chain it has followed. What changes between iterations is only the destination address: root, TLD, authoritative. The routing logic, the decision about which server to try next, the retry on timeout, the selection among multiple NS records — all of that lives in the resolver's own state machine, entirely invisible to the original client. What a resolver is really doing across those retries is managing state that the query never carries.
The name itself encodes the hierarchy implicitly. Reading right to left, each label is a delegation boundary: the rightmost label goes to the root, the next to the TLD, the next to the authoritative zone, and so on until there are no more labels to resolve. The resolver decodes that structure from the name alone. No signalling from the client is required, or possible.
Glue, referrals, and what the packet cannot ask for
There is one structural complication the resolver must handle silently, and the query has no mechanism for expressing it: the case where the nameserver for a zone lives inside the zone it serves. If ns1.example.com is the nameserver for example.com, a resolver asking the TLD for a referral to example.com gets back an NS record pointing at ns1.example.com — and it cannot look up ns1.example.com without first knowing where example.com is authoritative. The circularity would be fatal.
The fix is glue: the TLD nameserver includes an additional A or AAAA record for ns1.example.com in the referral response, outside the zone's own authority, so the resolver has an address to send the next query to without needing to resolve the nameserver name first. The missing glue condition — where the parent zone omits this record — breaks resolution silently and completely. The query cannot compensate; it has no mechanism for requesting glue or for signalling that the nameserver address is unresolvable. The resolver simply gets no answer, and the client waits until it times out.
This is the broader truth about the packet's passivity: the failure modes are all invisible to the client until the timer expires. A lame delegation — where the parent's NS records point at a server that holds no data for the zone — looks identical to a slow network from the client's perspective. The query goes out, reaches a server that is authoritative for nothing relevant, receives a REFUSED or a SERVFAIL, and the resolver must try the next NS record or give up. The client knows none of this. It sees only the elapsed time and, eventually, either an answer or an error.
There is one structural complication the resolver must handle silently, and the query has no mechanism for expressing it: the case where the nameserver for a zone lives inside the zone it serves.
TTL and the cache that shortens the walk
The one mechanism that does reduce what a query has to do is caching, and caching is controlled entirely by the answer side. Every DNS response carries a TTL — a time-to-live in seconds set by the zone operator, not the client. When a recursive resolver caches a referral or a final answer, it stores it for at most that long. Subsequent queries for the same name that arrive before the TTL expires are answered from cache: no walk, no referrals, no round trips to authoritative servers.
The query can influence caching only negatively: the CD (checking disabled) bit and the DO (DNSSEC OK) bit affect whether the resolver validates signatures, but neither shortens nor extends the TTL. The client cannot instruct the resolver to bypass cache, cannot set a minimum freshness requirement, cannot request that a record be fetched directly from the authoritative server. Some resolver implementations expose a local mechanism — flushing a cache entry via a control socket, for instance — but that is an operator interface, not a query feature. The IETF's specification of the DNS message format in RFC 1035 ↗ defines the query section as carrying name, type, and class, and nothing more. There is no field for routing preference, no field for cache control, no field for expressing urgency.
The consequence is that resolution speed, reliability, and correctness all depend on decisions made well before the query was sent: the TTL values the zone operator chose, the NS records the registrar published, the glue the registry carries, the anycast topology the root and TLD operators maintain. By the time a query leaves the stub, those decisions are already baked in. The packet travels inert, and everything that matters was settled elsewhere.
Subsequent queries for the same name that arrive before the TTL expires are answered from cache: no walk, no referrals, no round trips to authoritative servers.