Skip to content

Iterative DNS lookup

Go back to the +trace output the DNS resolution process article opened with. Every one of the four answers in that output came from a different server, and none of those servers went and asked anyone else before replying. The root server didn't contact the .com servers on the resolver's behalf. The .com servers didn't contact example.com's authoritative servers either. Each one simply answered with whatever it actually had — a real record, or a pointer to somewhere better positioned to know — and stopped. That's an iterative lookup: not a lesser version of recursion, but the other half of the same exchange, running underneath it.

"Best answer available" is a real, bounded promise

A server responding iteratively makes one of exactly two moves, never a third:

  • If it's authoritative for the exact name being asked about, it returns the real record.
  • If it isn't, but it knows who is (or who's closer), it returns a referral — the NS records for whichever zone comes next in the hierarchy — without attempting to resolve anything further itself.

Root and TLD servers essentially never do the first thing; by design, they hold delegation information, not the records themselves. A server that only supports iterative queries — and most authoritative servers, root servers included, are configured this way deliberately — will never say "let me go check and get back to you." It answers from what it already has, immediately, and the burden of chasing the next hop falls entirely on whoever asked.

sequenceDiagram
    participant Client as Stub resolver
    participant Rec as Recursive resolver
    participant Root as Root server
    participant TLD as .com TLD server
    participant Auth as example.com authoritative

    Client->>Rec: Query: www.example.com A (rd=1)
    Rec->>Root: Query: www.example.com A
    Root-->>Rec: Referral: ask .com servers
    Rec->>TLD: Query: www.example.com A
    TLD-->>Rec: Referral: ask example.com servers
    Rec->>Auth: Query: www.example.com A
    Auth-->>Rec: Answer: A record
    Rec-->>Client: Answer: A record (ra=1)

Notice which arrows are labeled "Query" versus "Answer" or "Referral," and who initiates each one. The recursive resolver is the only participant that sends more than one query — it's the single actor doing recursion, chaining three separate iterative exchanges together into the one recursive answer the stub resolver eventually receives. Root, TLD, and the authoritative server each took part in exactly one request-response pair and never initiated anything themselves.

Diagnosing exactly where a delegation breaks

The NS record article already worked through one delegation failure — a registrar's delegation listing a decommissioned name server while the zone's own records had moved on. This is a different kind of break, and the iterative nature of +trace is precisely what makes it diagnosable.

A subdomain, api.example.com, was just handed off to a separate DNS provider with its own dedicated name servers — a common setup when a specific subdomain is managed by a different team or a different platform than the rest of the domain. Right after the change, some requests to api.example.com succeed and others time out. Running +trace shows exactly where the chain currently stands:

dig api.example.com A +trace

;; global options: +cmd
.                       518400  IN      NS      a.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53(192.168.1.1) in 10 ms

com.                    172800  IN      NS      a.gtld-servers.net.
;; Received 833 bytes from 198.41.0.4#53(a.root-servers.net) in 29 ms

example.com.            172800  IN      NS      a.iana-servers.net.
;; Received 168 bytes from 192.5.6.30#53(a.gtld-servers.net) in 26 ms

api.example.com.        300     IN      NS      ns1.api-provider.net.
;; Received 96 bytes from 199.43.135.53#53(a.iana-servers.net) in 38 ms

;; connection timed out; no servers could be reached

Every hop up through example.com's own authoritative server succeeded — root referred to .com, .com referred to example.com, and example.com's own zone correctly delegates api.example.com onward to ns1.api-provider.net. The chain only breaks at the very last hop: the new provider's name server itself isn't answering, whether because it isn't fully provisioned yet, a firewall on their end is blocking port 53, or the delegation was published before that server was actually ready to serve the zone. Because each server in an iterative chain only speaks for its own link, +trace isolates the problem to that exact link — root, .com, and example.com's own zone are all confirmed working, and effort goes straight to ns1.api-provider.net rather than being spent re-checking layers that were never broken.

Practice exercises

  1. Run dig <a-domain-you-control-or-know-well> +trace and identify, hop by hop, which response is a referral and which is the final answer.
  2. Using the sequence diagram above, explain in one sentence why the root server never appears more than once in a +trace for a single query, no matter how deep the domain's subdomain nesting goes.

The chain this article and the last one both walked assumes every host involved already has an IP address to route packets toward in the first place. Nothing about DNS explains how a laptop joining a new Wi-Fi network gets its own address, a default gateway, and a DNS resolver to query — that's a separate protocol, and the next group of articles in this module takes apart exactly how it negotiates a lease.

Sources