DNS resolution walk

When an application asks for api.example.com, it doesn't contact DNS servers itself. Its operating system's stub resolver sends one question to a recursive resolver, usually the ISP's, a corporate server, or a public service like 1.1.1.1. That resolver does the real work: it walks the hierarchy, caches each answer, and returns the final result.

Knowing the order of these steps tells you which cache answered, and why a change took as long as it did.

Walking through it

Suppose the resolver has nothing cached for api.example.com:

1. Ask a root server: "Who handles .com?" The root replies with the .com name servers. Roots answer with referrals, not final answers.
2. Ask a TLD server: "Who handles example.com?" The .com server replies with the authoritative name servers for example.com.
3. Ask an authoritative server: "What is the A record for api.example.com?" This server owns the zone, so it answers with the record and its TTL.
4. Cache and return: the resolver stores the answer for the TTL and returns it to the stub resolver. The stub may cache it too.

The next lookup for the same name, within the TTL, skips steps 1 to 3 entirely. That is why most lookups never touch the root.

Caches along the path

Four places can hold an answer:

• The application, through a language runtime cache or a long-lived connection pool. Some clients resolve once and never again.
• The OS stub resolver, such as systemd-resolved or the macOS daemon.
• The recursive resolver, which holds the answer for the full TTL. This is the cache most people mean.
• Negative caches. A name that doesn't exist (NXDOMAIN) is cached too, for the zone's SOA minimum. So a typo or a record you're about to create can stay missing for a while.

Each layer can ignore or extend the TTL in its own way. Some caches enforce a minimum TTL. That is why a 30-second TTL doesn't always mean 30 seconds.

Recursive versus iterative

The stub asks recursively: "give me the final answer, and do the work." The recursive resolver asks each server iteratively: "tell me where to go next." Authoritative servers answer only for their own zones, and they never recurse. This split keeps authoritative servers simple and fast, and it puts the caching work in the resolver.

Common mistakes

• Debugging an application by looking only at the authoritative server, when a stale cache is answering.
• Forgetting negative caching. A record created just after a failed lookup can take the negative TTL to appear.
• Assuming every resolver honors your TTL.

Check yourself

• Why does a second lookup within the TTL skip the root servers? Answer: the recursive resolver cached the full answer, so it doesn't need to walk the hierarchy again.
• Why can a new record take longer to appear after a failed lookup? Answer: the NXDOMAIN answer is cached for the negative TTL, so the resolver keeps reporting the name as missing.

Key takeaways

• The stub resolver asks one recursive resolver, which walks root, TLD and authoritative servers.
• Caches sit at the application, the OS, the recursive resolver and the negative cache.
• Authoritative servers answer only for their zones and never recurse.

Further learning

Next, see TTLs and caching for how these caches set the speed of a DNS change.