How Does DNS Work? – Resolution Step by Step
Follow a DNS lookup from the stub resolver through root, TLD, and authoritative servers, and see where caching changes what you observe.
Resolution looks instantaneous and involves several parties. Knowing which one answered explains most confusing DNS behaviour.
1. The Participants
| Party | Role |
|---|---|
| Stub resolver | The client library that asks on the application's behalf |
| Recursive resolver | Does the walking and caches the answers |
| Root servers | Know which servers handle each top-level domain |
| TLD servers | Know which nameservers are authoritative for a domain |
| Authoritative servers | Hold the actual records |
2. The Walk
- The application asks the stub resolver for
www.example.com. - The stub asks its configured recursive resolver.
- If not cached, the resolver asks a root server, which points to the servers for
.com. - Those point to the nameservers authoritative for
example.com. - Those return the record.
- The resolver caches it for the record's TTL and answers the stub.
Only step six is visible to the application. Everything before it happens once and is then reused.
3. Caching Is Layered
The operating system caches, the browser caches, the recursive resolver caches, and each honours the TTL independently.
That is why a change appears immediately in one place and not another: the layers expire at different moments, and clearing one does not clear the others.
4. Delegation Is Where Migrations Break
The chain works only if each level points correctly at the next. The registrar publishes which nameservers are authoritative, and if that delegation still points at a previous provider, the records you edited are never consulted.
Symptom: the new records are visibly correct at the new provider, and the world still sees the old ones.
5. Observing Each Stage
dig +trace www.example.com # walk the chain from the root
dig @1.1.1.1 www.example.com # ask one public resolver
dig @ns1.example.com www.example.com # ask the authoritative server directly
The trace shows where the walk stops. Comparing a public resolver against the authoritative answer separates a caching problem from a record problem, and both from a local one.
6. Where Local Overrides Interfere
The hosts file bypasses DNS entirely, and a stale entry silently overrides everything above. VPN clients and containers also install their own resolvers, which can answer for internal names and fail for public ones.
Checking these before investigating anything upstream saves a great deal of time.
7. Why Answers Differ by Location
Authoritative servers can return different records depending on where the query came from, which is how content delivery networks steer users to nearby edges and how geographic failover works.
Two resolvers in different regions therefore receive genuinely different, equally correct answers.
8. Summary
A lookup walks from root to TLD to authoritative servers, with a recursive resolver doing the work and caching the result for its TTL, and further caches at the operating system and browser.
Diagnose by asking each level directly: the trace shows where the walk stops, the authoritative server shows the truth, and a public resolver shows what the world currently believes.