How DNS Resolution Actually Works: From Browser to Authoritative Server

Every time you visit a website, a chain of DNS servers works together to turn a name like vernalweb.com into an IP address — usually in a few milliseconds. Understanding that chain is the foundation for troubleshooting almost any DNS problem. Here is the full journey. For the basics first, see what DNS is and how it works.

The players involved

• Stub resolver — the tiny DNS client in your operating system that the browser asks.
• Recursive resolver — your ISP's server (or a public one like 1.1.1.1) that does the legwork and caches results.
• Root servers — the top of the tree; they point to the right TLD servers.
• TLD servers — for .com, .org, .bd and so on; they point to a domain's authoritative servers.
• Authoritative servers — the nameservers that hold the real answer for the domain.

The step-by-step walk

1. Caches first. The browser, then the OS stub resolver, check their caches. A hit ends the journey immediately.
2. Ask the recursive resolver. On a miss, the stub asks the recursive resolver, setting the "recursion desired" flag.
3. Root referral. If the resolver has nothing cached, it asks a root server, which replies with a referral to the .com TLD servers (it does not know the answer, only who does).
4. TLD referral. The resolver asks a .com server, which refers it to the domain's authoritative nameservers.
5. Authoritative answer. The resolver asks an authoritative server, which returns the actual record.
6. Cache and return. The resolver caches the answer for its TTL and hands it back to you.

Recursive vs iterative

Your device makes a recursive query ("get me the final answer"). The resolver then makes iterative queries, following referrals down the tree itself. This division of labour is why one resolver can serve thousands of clients efficiently — repeated lookups are answered from cache.

Why caching changes everything

Because each step caches for the record's TTL, most lookups never travel the whole chain. This is also why DNS changes are not instant — resolvers keep serving cached answers until the TTL expires, which is the real mechanism behind DNS propagation. You can watch the whole chain resolve with dig +trace.

Frequently asked questions

Does my browser talk to the root servers directly?

No — your device asks a recursive resolver, and that resolver queries the root, TLD and authoritative servers on your behalf. The root servers only hand out referrals, never final website answers.

Why is the second visit to a site so much faster?

Because the answer is cached — in your browser, your OS, and the recursive resolver — for the record's TTL. Subsequent lookups are served from cache instead of walking the whole chain again.

What are the 13 root servers?

They are 13 named root server identities (A through M), but each is actually many physical servers spread worldwide using anycast, so the real count is hundreds of instances globally.