DNS resolution
The end-to-end process of turning a domain name into an IP, including caching and the chain from recursive resolver to authoritative server.
DNS resolution is the bigger picture of which DNS lookup is the user-facing step. Resolution covers everything from the moment a hostname is queried until a final answer arrives, including all the intermediate hops, caching layers, and fallback paths.
The roles involved
- Stub resolver. The tiny resolver in your OS or browser that hands queries off to a real resolver. Doesn't do recursion itself.
- Recursive resolver. The workhorse. Walks the DNS tree, caches results, returns the final answer. Usually run by your ISP or a public service (1.1.1.1, 8.8.8.8).
- Authoritative server. Holds the canonical records for a zone. Returns the answer when asked.
A complete resolution
When your laptop wants example.com:
laptop stub → recursive resolver → root server → TLD server → authoritative server
← ← ← ←
Each ← is a cache opportunity. The recursive resolver typically caches all four downward steps so the next query for example.com skips everything except its own cache.
What can go wrong
- Slow authoritative server. Resolution waits for it. User sees latency.
- NXDOMAIN cached too long. A record that doesn't exist gets cached as "doesn't exist" for the SOA minimum TTL. After you create it, some resolvers won't see it for a while.
- Resolver outage. Some resolvers (your ISP, your office network) are flakier than others. Public resolvers (1.1.1.1, 8.8.8.8) are much more reliable.
- DNS hijacking. A bad actor returns wrong answers. Mitigations: DNSSEC, DoH, DoT.
Why this matters for SaaS
Faster resolution = faster initial page load. Use anycast authoritative DNS so global users hit a nearby server. Keep TTLs reasonable so changes propagate without sacrificing cache hit rate.