You type blog.acy-partner.com into your browser, press Enter, and a page appears a heartbeat later. It feels like one smooth action, but underneath, your computer just asked a question and waited for an answer: “What is the actual address of this name?” That question-and-answer dance is DNS, and the trip it takes is more interesting than you might expect.
This article follows a single DNS lookup from start to finish. We will walk through every place your computer checks, every server it might talk to, and how caching quietly makes the whole thing fast. By the end, you will be able to picture exactly what happens between pressing Enter and seeing a page.
Why DNS exists in the first place
Computers on the internet don’t actually find each other by name. They find each other by IP address — a numeric label like 203.0.113.42 (for IPv4) or a longer string of hex like 2001:db8::1 (for IPv6). That’s the address a browser truly needs in order to open a connection.
Humans, though, are terrible at remembering numbers and great at remembering names. So we use friendly names like acy-partner.com, and we need a system that translates those names into the numeric addresses machines use. That system is DNS, the Domain Name System. Think of it as the phone book of the internet: you know the name, DNS gives you the number.
The catch is that there is no single giant phone book. With hundreds of millions of domains, no one machine could hold or serve all of it. Instead, DNS is a distributed, layered system — the work is split across many servers, each responsible for one slice. The lookup journey is really a tour through those layers.
Name vs. address
A domain name (like acy-partner.com) is what you read and type. An IP address (like 203.0.113.42) is what the network actually routes to. DNS is the translator that turns the first into the second.
The big picture: the lookup chain
Before we go step by step, here’s the whole journey in one diagram. We’ll unpack each box below.
YOU type blog.acy-partner.com
│
▼
┌──────────────────┐ hit? → done
│ Browser cache │ ─────────────►
└──────────────────┘
│ miss
▼
┌──────────────────┐ hit? → done
│ OS cache │ ─────────────►
└──────────────────┘
│ miss
▼
┌──────────────────┐
│ Recursive │ does the legwork for you
│ resolver (ISP) │
└──────────────────┘
│
▼
┌──────────────────┐ "ask the .com servers"
│ Root server │
└──────────────────┘
│
▼
┌──────────────────┐ "ask acy-partner.com's
│ TLD server (.com)│ nameserver"
└──────────────────┘
│
▼
┌──────────────────┐ "here is the IP:
│ Authoritative │ 203.0.113.42"
│ nameserver │
└──────────────────┘
│
▼
IP flows back up the chain → browser connectsThe important idea: each step is a chance to stop early. If any cache already knows the answer, the journey ends right there. The full trip to the root and back only happens when nobody nearby remembers the answer yet.
Step 1: The browser cache
The very first place your browser looks is inside itself. Modern browsers keep a small, short-lived list of names they recently resolved. If you visited blog.acy-partner.com a minute ago, the browser probably still remembers its IP, and it skips every other step entirely.
This is the fastest possible outcome: zero network requests. It’s also why the second visit to a site often feels snappier than the first.
Step 2: The operating system cache
If the browser doesn’t have the answer, it asks the operating system. Your OS keeps its own DNS cache, shared by every program on the machine — not just your browser. So if your email client looked up a name earlier, your browser can benefit from that cached result.
The OS also checks a special local file (the hosts file) that can hard-code certain names to certain addresses. That’s mostly a developer tool, but it’s part of the lookup order: the hosts file wins over everything else if it has an entry.
If the OS cache has a fresh answer, again — done. No traffic leaves your computer.
You can watch the cache
On most systems you can inspect or clear the local DNS cache. On Windows, ipconfig /displaydns shows cached entries and ipconfig /flushdns clears them. Clearing the cache is a common fix when a site’s address has changed but your machine is still using the old one.
Step 3: The recursive resolver
When neither local cache knows the answer, your computer hands the question to a recursive resolver. This is usually run by your internet provider, though you can choose a public one instead. The resolver’s job is to do all the remaining legwork on your behalf and hand back a single, final answer.
Why “recursive”? Because it’s willing to chase the question through as many servers as it takes. Your computer asks one question — “what’s the IP for blog.acy-partner.com?” — and the resolver promises to come back with the answer, no matter how many other servers it has to consult to get it.
The resolver also keeps a large cache of its own. Because it serves many users, it has very likely resolved popular names recently. If blog.acy-partner.com is already in its cache and still fresh, the resolver answers immediately, and the journey ends here — the root, TLD, and authoritative servers below never get involved at all.
But let’s assume the resolver’s cache is empty for this name. Now the real tour begins.
Step 4: The root server
The resolver starts at the top of the hierarchy: a root server. The root doesn’t know the IP of blog.acy-partner.com — that’s not its job. What the root knows is who handles each top-level domain (TLD): .com, .org, .net, .id, and so on.
The resolver reads the name from right to left. The rightmost part of blog.acy-partner.com is .com, so the resolver effectively asks the root: “Who is responsible for .com?” The root replies with a referral: “I don’t have the final answer, but here are the servers that handle .com — go ask them.”
Notice the root didn’t resolve anything. It just pointed one level down. That’s the pattern for the next few steps too: each server narrows the search and forwards you closer.
Resolvers rarely visit the root
In practice, resolvers almost never have to ask a root server, because the list of TLD servers changes slowly and gets cached for a long time. The root is the starting point in theory; in daily reality it’s usually skipped thanks to caching.
Step 5: The TLD server (.com)
Armed with the referral from the root, the resolver now asks a .com TLD server. This server is responsible for the entire .com zone, and it knows one crucial fact about our domain: which authoritative nameserver is in charge of acy-partner.com.
So the resolver asks: “Who is the nameserver for acy-partner.com?” The TLD server replies with another referral: “Here are the nameservers for acy-partner.com — go ask them for the details.” When someone registers a domain, this is the link that gets recorded: the registrar tells the TLD which nameservers own that domain.
Still no final IP. The TLD server, like the root, only narrows the search by one level. We’re getting close.
Step 6: The authoritative nameserver
Finally, the resolver reaches the authoritative nameserver for acy-partner.com. “Authoritative” means this is the source of truth — it holds the actual DNS records for the domain, configured by whoever manages it. This is where the real answer lives.
The resolver asks for the record it needs. For a website’s address, that’s usually an A record (which maps a name to an IPv4 address) or an AAAA record (for IPv6). The authoritative server looks up blog.acy-partner.com and replies: “The A record points to 203.0.113.42.”
That’s it. The question finally has an answer.
Here are the record types you’ll meet most often:
| Record | What it maps a name to | Typical use |
|---|---|---|
| A | An IPv4 address | Point a domain at a server |
| AAAA | An IPv6 address | Same, for IPv6 |
| CNAME | Another name (an alias) | Point one name at another name |
| MX | A mail server | Where email for the domain goes |
| TXT | Free-form text | Verification, policies, notes |
| NS | A nameserver | Who is authoritative for a zone |
The answer flows back up
The IP doesn’t teleport straight to your browser. It travels back along the path it came:
Authoritative → Recursive resolver → Operating system → Browser
(203.0.113.42 is carried back at each hop)The recursive resolver receives 203.0.113.42 and passes it to your operating system, which passes it to your browser. Now the browser finally has the numeric address and can open a real connection to the server — and the page starts loading.
But the resolver does one more important thing on the way back: it caches the answer so the next person who asks for blog.acy-partner.com gets it instantly, without the whole tour.
Caching and TTL: why this is fast
If every visit triggered the full root-to-authoritative journey, the web would feel slow and the upstream servers would be crushed. Caching prevents that. Almost every step we covered can store the answer and reuse it.
How long is an answer allowed to live in a cache? That’s controlled by a value called the TTL, short for time to live. Every DNS record carries a TTL — a number of seconds — set by whoever runs the authoritative nameserver. It’s a freshness timer: “you may reuse this answer for this many seconds, then throw it away and ask again.”
A record: blog.acy-partner.com → 203.0.113.42 TTL 3600
│
cache may reuse for ─┘ 3600s (1 hour)TTL is a trade-off:
| Short TTL (e.g. 300s) | Long TTL (e.g. 86400s) |
|---|---|
| Changes spread quickly | Changes spread slowly |
| More lookups, more load | Fewer lookups, faster |
| Good before a planned move | Good for stable records |
A common pattern: lower the TTL a day before you migrate a site to a new server, so the change propagates quickly, then raise it again once everything is stable.
DNS changes are not instant
Because old answers live in caches until their TTL expires, an update can take a while to be seen everywhere — sometimes hours. If you change a record and “it still points to the old place,” the cause is usually a cache that hasn’t expired yet, not a mistake on your end.
A quick recap of the journey
Let’s retrace the whole thing in one breath. You ask for a name. Your browser cache is checked, then your OS cache. If neither has it, a recursive resolver takes over and does the legwork: it asks a root server (which points it to the .com servers), then a .com TLD server (which points it to the domain’s nameservers), then the authoritative nameserver (which finally returns the IP). The answer flows back up the chain, gets cached at each layer according to its TTL, and your browser connects.
The elegant part is that most lookups never make the full trip. Caching means the common case is fast, and the long journey only happens when an answer is genuinely new or expired.
If you want to go deeper into what happens on the server side — the resolver software, zone files, and operational details behind these servers — a good next read is DNS Deep Dive (server-side). With the lookup journey clear in your head, those details will slot right into place.
