How DNS Works — domain names to IP addresses
How DNS works, shown on an interactive canvas: your device, the recursive resolver, and the root, TLD and authoritative servers that together turn a domain name into an IP address.
DNS is the phone book of the internet: it maps the human-readable names you type into the IP addresses routers actually use, through a chain of servers that each know one smaller piece of the answer.
How DNS Works — domain names to IP addresses
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Start in the "Your device" cluster with "You type a domain", and follow the two-row sequence across: the device asks the resolver, the resolver decides whether it already knows the answer.
- When the resolver does not know, the arrow moves into the "Resolution" column and down the chain — root to TLD to authoritative server — before returning to the resolver and back to your device.
- The "Yes" branch on the cache decision jumps straight to the end, showing the fast path everyone experiences on a repeated visit.
The lookup chain
"Browser sends the query to a recursive resolver" hands the question to a server that is allowed to ask others on your behalf — typically your ISP's or a public service like your network's DNS. From there the "No" branch of the cache decision walks the chain: "Resolver asks the root server", "Root server points to the .io TLD server", "TLD server points to the authoritative server", and finally "Authoritative server returns the IP address". Each hop narrows the question by one level of the name.
The resolver's role
The resolver sits between your device and the three server clusters for a reason: it is the part that remembers. "Resolver caches the answer and returns it" is why a second visit to the same site skips the whole chain, and the "Yes" branch on the cache decision is that fast path drawn explicitly. The resolver also handles retries and security extensions, all invisible to the browser.
Where the chain ends
"Browser connects to the IP address" closes the loop back in the "Your device" cluster — the lookup exists only to produce a destination for the actual request. That destination is what the internet visual's "Browser asks DNS where the domain lives" step uses, and what the API request lifecycle visual assumes is already resolved.
Key relationships and takeaways
- DNS is a delegated chain: root points to TLD, TLD points to authoritative, and only the authoritative server holds the final record.
- The recursive resolver does the work once and caches the answer, which is why repeated lookups are near-instant.
- The domain holder controls only the authoritative server — not the root or TLD servers.
- A lookup failure anywhere in the chain means the browser has no destination and no request is sent.
- DNS resolution precedes every connection, which is why it is the first hop in the API request lifecycle.
When to use this visual
- Explaining to a new team member why a domain is slow to resolve the first time and instant afterwards.
- Debugging a "site not found" report by walking the chain — cache, authoritative records, TTL — instead of guessing.
- Teaching the ownership model: which DNS records your team controls versus the registrar or hosting provider.
How it works
Trace your own domain through the chain
Replace "querychart.io" with a domain you control, and on the authoritative server step note which provider hosts its records — your registrar, a DNS service, or your hosting company.
Add the security extensions you use
Insert a DNSSEC validation step between the resolver and the answer, or a stub-resolver step on the device, to show the parts your setup actually runs.
Annotate the cache with real TTLs
Put the time-to-live of your records on the cache decision so the diagram says how long a change takes to propagate — the number that makes the whole picture practical.
Add the failure branches
Include what happens when a server in the chain is unreachable or returns no record (a SERVFAIL), each ending in an explicit outcome, so the canvas covers real incidents.
Frequently asked questions
What is DNS in simple terms?
DNS, the Domain Name System, is the directory that turns a domain name like querychart.io into the IP address a computer can connect to. It works by delegation: a chain of servers, each responsible for one part of the name, that together produce the final address. Without it you would have to remember and type IP addresses.
What is the difference between a recursive resolver and an authoritative server?
The recursive resolver is the server your device asks; it does the searching, follows the chain on your behalf and caches the result. The authoritative server is the domain owner's own server and the source of truth for that domain — it holds the final records and is the only server that can answer authoritatively. The visual places them at opposite ends of the chain for exactly this reason.
Why is DNS cached and what is a TTL?
Caching is what keeps DNS fast: without it every page load would trigger a full chain of lookups. Every DNS record carries a time-to-live (TTL) saying how long a resolver may remember it. The cache decision in the visual is that mechanism — when a record's TTL expires, the resolver must walk the chain again.
What happens when DNS fails?
If no server in the chain can produce an answer, the resolver returns an error and the browser shows the domain cannot be reached. The usual causes are a missing or mistyped record on the authoritative server, an expired domain, or a resolver that cannot reach the chain. Walking the lookup order in this visual is a practical way to find which of those it is.
Edit this visual in QueryChart (FlowJam)
Open this exact DNS lookup canvas as your own chart, rename the servers to your providers, and trace your own domains.