DNS Explained: What Happens Between Typing a URL and Loading a Page

Type a domain into your address bar and a page appears in under a second — but behind that second is a small relay race across several different servers, none of which you ever see.

Step one: check what's already known

Your browser first checks its own cache, then your operating system's cache. If you (or anyone on that network) visited the site recently, the answer might already be sitting there, and the whole process below gets skipped entirely.

Step two: ask a resolver

If nothing is cached, the request goes to a DNS resolver — usually run by your ISP, or a public one like 1.1.1.1 or 8.8.8.8 if you've configured it. The resolver's job is to do the legwork on your behalf and hand back a final answer.

Step three: the relay — root, TLD, authoritative

The resolver asks a root server "who handles .com?", gets pointed to the TLD server for .com, asks that server "who handles example.com?", and gets pointed to example.com's authoritative name server — the one place that actually knows the IP address. That server gives the real answer, and the resolver hands it back to your browser.

Browser → Resolver → Root server → TLD server → Authoritative server → IP address

Why it still feels instant

Each of those servers caches answers too, with an expiry time called TTL. Popular domains are cached at nearly every layer, so most real-world lookups never touch a root server at all — they're answered from cache two or three hops in.

Where it goes wrong

"DNS_PROBE_FINISHED" errors almost always mean the chain broke somewhere before reaching an authoritative answer — often a misconfigured resolver, an expired domain, or a record that was never created. Tools like dig or nslookup let you walk the same chain manually to see exactly where it stops.