Every time you visit a site, something invisible has to happen first: the human-friendly name (vibeengines.com) must become a machine address (an IP). There is no single directory of the whole internet — that wouldn’t scale — so DNS is a distributed, hierarchical tree, and looking up a name is a small journey through it. Your device asks a recursive resolver (often your ISP’s or a public one like 1.1.1.1), and that resolver does the legwork: it asks a root server, which doesn’t know the answer but points it to the right top-level-domain (TLD) server; the TLD server points it to the domain’s authoritative server; and the authoritative server finally returns the address. Each step is a referral down the tree. Then — crucially — the resolver caches the answer for its time-to-live, so the millions of later lookups are instant. Resolve a name step by step, then look it up again and watch the cache short-circuit the whole journey.
recursive walk · root → TLD → authoritative · referrals down the tree · then cache (TTL)
recursive resolver
The server (your ISP’s or a public one) that does the full lookup on your behalf and returns the final answer.
root server
Top of the tree. Knows nothing about domains directly — refers you to the correct TLD server.
authoritative server
Holds the actual records for a domain and returns the real address.
TTL
Time-to-live: how long an answer may be cached before it must be looked up again.
resolve.js — walk the tree, then cache
Ready
Your resolver must turn www.vibeengines.com into an IP. It has no idea where to look, so it walks the tree from the top. Press Ask ▸ to send the next query, or Resolve to run the whole journey. Then look it up again and watch the cache.
0
network hops
empty
cache
—
answer
How it works
DNS is a lookup system that had to work for the entire internet without any single machine holding the whole map, so it is built as a hierarchy of delegation. The name www.vibeengines.com reads right-to-left as a path down a tree: the root (the implied trailing dot), then the com TLD, then vibeengines, then the www host. No server knows the whole tree — each level only knows how to refer you one step down. A recursive resolver chains those referrals: it asks a root server (“who handles com?”), gets a referral to the TLD servers, asks them (“who handles vibeengines.com?”), gets a referral to the domain’s authoritative servers, and asks them for the actual record. This delegation is also how ownership works — buying a domain means the TLD registry points its referral at your authoritative servers. The final piece is caching: every answer carries a TTL, and resolvers cache aggressively, so although the first lookup of a name takes several round-trips across the world, virtually every subsequent lookup is served from a nearby cache in well under a millisecond.
1
Ask the root
The resolver asks a root server for the name. The root doesn’t know the domain, but it knows who runs the .com TLD — it returns a referral to the TLD servers.
2
Ask the TLD server
The resolver asks the .com TLD server. It doesn’t hold the record either, but it knows which authoritative servers were delegated the domain — another referral, one step deeper.
3
Ask the authoritative server
The resolver asks the domain’s authoritative server, which actually holds the records and returns the real IP address. The journey is complete.
✓
Cache, then instant repeats
The resolver caches the answer for its TTL and hands the IP back to your device. Look the name up again and the cache answers immediately — no journey needed until the TTL expires.
Tree levels
root · TLD · authoritative
Each step
a referral down
First lookup
several round-trips
Cached lookup
< 1 ms
The code
# Recursive resolution (what your resolver does for you)defresolve(name):
if name in cache and not expired(name):
return cache[name] # instant: served from cache
server = a_root_server # start at the top of the treewhile True:
reply = ask(server, name)
if reply.is_answer:
cache.put(name, reply.ip, ttl=reply.ttl)
return reply.ip # authoritative server answered
server = reply.referral # root → TLD → authoritative
Quick check
1. What does a root server return when asked to resolve www.vibeengines.com?
Root servers don’t hold domain records. They know which servers run each top-level domain, so they return a referral pointing the resolver to the .com TLD servers — the first step down the tree.
2. Who actually holds the real DNS records for a domain?
The authoritative name servers for a domain hold its actual records (A, AAAA, MX, etc.). Root and TLD servers only refer you down the tree; the authoritative server is where the resolution ends with a real answer.
3. Why is the second lookup of the same name almost instant?
Every DNS answer carries a TTL (time-to-live). The recursive resolver caches the answer for that duration, so subsequent lookups are served from the local cache in well under a millisecond — no walk down the tree needed until the TTL expires.
FAQ
What is DNS resolution?
Turning a human-readable domain name into the IP address a computer needs to connect. DNS is a distributed hierarchical tree, and a recursive resolver walks it: it asks a root server (which refers it to the TLD server), then the TLD server (which refers it to the authoritative server), which returns the actual address. The resolver caches the answer for its TTL.
What is the difference between a recursive resolver and an authoritative server?
A recursive resolver does the legwork: it chases the chain of referrals (root → TLD → authoritative) until it has the answer, then returns and caches it. An authoritative server is one end of that chain — it holds the real records for a specific domain and gives definitive answers, but doesn’t chase other names. Your device talks to a resolver; the resolver talks to authoritative servers.
What is a DNS TTL and why does it matter?
TTL (time-to-live) says how many seconds a DNS record may be cached before re-fetching. It’s the central DNS trade-off: a long TTL means faster lookups and less load but slow propagation of changes (old answers linger in caches); a short TTL propagates changes fast but increases traffic. Teams often lower TTLs before a planned migration, then raise them after.
What is DNS caching and where does it happen?
DNS caching stores resolved answers so repeat lookups skip the tree walk. It happens in the OS stub resolver, sometimes the browser, and most importantly the recursive resolver (which serves many users and caches popular names heavily). Because of caching, the vast majority of lookups never reach the root or TLD tiers — which would otherwise be overwhelmed. It’s what makes a global lookup feel instant.