DNS Deep Dive: How a Domain Name Becomes an IP Address

You type acypartner.example into your browser, hit Enter, and a page shows up. Behind that ordinary moment is one of the busiest, most elegant systems on the internet: the Domain Name System, or DNS. Its whole job is to answer one deceptively simple question — what number do I actually connect to? — because computers don’t route traffic to names, they route it to IP addresses.

Most people meet DNS through the “phone book of the internet” line, and that’s a fine starting point. But the phone book comparison hides almost everything interesting: DNS isn’t one big book, it’s a worldwide, distributed lookup that hops across several servers, leans heavily on caching, and updates in a way that can feel maddeningly slow. Once you really see how a lookup flows, a lot of mysterious networking behavior — slow propagation, stale records, that one device that “still sees the old site” — suddenly makes sense.

The problem DNS solves

Every machine on the internet is reachable by an IP address — a number like 203.0.113.42 (or a longer IPv6 string). Routers and switches only understand those numbers. Humans, on the other hand, are terrible at remembering numbers and great at remembering names. DNS is the translation layer that lets us live in a world of friendly names while the network keeps running on numbers underneath.

If you’ve already met the idea of names versus numbers in domains and DNS, this article is the layer underneath it: not what a domain is, but how the lookup actually happens, server by server.

Here’s the core trade DNS makes. Instead of one giant central directory that every lookup in the world has to hit, DNS spreads the work across millions of servers, each responsible for only a small slice of the name space. No single machine knows every name on the internet. Instead, the system is built so that any resolver can find its way to the one server that does know the answer for a given name.

The cast of characters

A single DNS lookup involves several different roles. They’re easy to mix up, so let’s name them clearly:

• Stub resolver — the tiny DNS client built into your operating system. When an app asks for a name, this is who it talks to. It does very little thinking on its own; it just forwards the question.
• Recursive resolver (or just resolver) — the workhorse. This is usually run by your internet provider, or a public service. It takes your question and does whatever legwork is needed to get a final answer, then hands it back. It also caches answers heavily.
• Root servers — the starting point of the hierarchy. They don’t know the IP of your domain, but they know who to ask next for any top-level domain.
• TLD servers — responsible for a top-level domain like .com, .org, or .id. They don’t know your final answer either, but they know which servers are authoritative for your specific domain.
• Authoritative name servers — the servers that actually hold the real records for a domain. This is where the truth lives. Whoever controls these controls what a domain points to.

The clever part is how a resolver walks down this chain — from root, to TLD, to authoritative — narrowing the search at each step until it lands on the one server that truly knows the answer.

Walking through a real lookup

Let’s trace a fresh lookup for shop.acypartner.example, assuming nothing is cached anywhere yet (the worst case, which almost never actually happens — but it shows the full machinery).

  YOUR DEVICE                 RECURSIVE RESOLVER              THE HIERARCHY
 (stub resolver)              (your ISP / public)
      │                              │
      │ "where is                    │
      │  shop.acypartner.example?"   │
      │ ───────────────────────────► │
      │                              │  1. ask a ROOT server
      │                              │ ─────────────────────► [ ROOT ]
      │                              │ ◄── "ask the .example TLD servers"
      │                              │
      │                              │  2. ask the .example TLD server
      │                              │ ─────────────────────► [ .example TLD ]
      │                              │ ◄── "ask acypartner.example's
      │                              │      authoritative servers"
      │                              │
      │                              │  3. ask the authoritative server
      │                              │ ─────────────────────► [ AUTHORITATIVE ]
      │                              │ ◄── "shop = 203.0.113.42"
      │                              │
      │ ◄── "it's 203.0.113.42"      │
      │                              │
   connect to 203.0.113.42

Read top to bottom, here’s what happened:

1. Your device asks its configured recursive resolver: what’s the IP for shop.acypartner.example?
2. The resolver, knowing nothing yet, starts at the top. It asks a root server. The root doesn’t know the final answer, but it replies, in effect, “I don’t handle that, but here are the servers for the .example top-level domain — ask them.”
3. The resolver asks a .example TLD server. That server also doesn’t know the final IP, but it knows who’s authoritative for acypartner.example, so it replies, “ask these name servers.”
4. The resolver asks the authoritative name server for acypartner.example. This server has the real records. It answers: “shop points to 203.0.113.42.”
5. The resolver returns that final answer to your device, and your browser opens a connection to 203.0.113.42.

This is called recursive resolution from your device’s point of view (you asked one question and got one final answer) and iterative resolution from the resolver’s point of view (it asked a series of questions, narrowing down at each hop). Both terms describe the same lookup from different angles.

Caching: why it isn’t always this slow

If every lookup did all that work, the internet would crawl. It doesn’t, because of caching. At nearly every layer, answers get remembered for a while so the next lookup can skip steps.

• Your operating system caches recent answers, so opening the same site twice in a row usually skips DNS entirely.
• Your recursive resolver caches aggressively. Once it learns that .example is handled by certain TLD servers, it won’t re-ask the root for hours. Once it learns where shop.acypartner.example points, it serves that answer straight from memory to everyone who asks.
• Even your browser keeps a short-lived cache of its own.

So in real life, most lookups are answered in milliseconds from a cache somewhere along the path. The full root-to-authoritative walk only happens occasionally — when an answer has expired or nobody nearby has asked for that name recently.

   First visitor          →  full walk: root → TLD → authoritative  (slow-ish)
   Next 10,000 visitors   →  served from the resolver's cache       (instant)

How long does a cache hold an answer? That’s controlled by a value attached to every record: the TTL.

TTL and the reason DNS changes feel slow

TTL stands for time to live. It’s a number, in seconds, attached to each DNS record that says, “you may cache this answer for this long before checking again.” A TTL of 3600 means one hour. A TTL of 300 means five minutes.

TTL is the single most important thing to understand about why DNS changes seem to take forever. When you update a record — say, you point your domain at a new server — the change is instant on your authoritative server. But every resolver on Earth that already cached the old answer will keep serving it until its copy expires. If the old record had a 24-hour TTL, some users might keep hitting the old server for nearly a full day.

This is what people loosely call DNS propagation. Nothing is really “spreading” across the world — there’s no global push. What’s actually happening is millions of independent caches quietly expiring, one TTL at a time, and only then picking up the new answer.

The record types you’ll actually meet

A domain’s authoritative server doesn’t just store one answer — it stores a small collection of records, each a different type for a different purpose. You don’t need all of them, but a handful come up constantly:

• A — maps a name to an IPv4 address (e.g. shop → 203.0.113.42). The most common record there is.
• AAAA — same idea, but for an IPv6 address. (Yes, four A’s; that’s how you say it.)
• CNAME — an alias that points one name at another name instead of an IP (e.g. www → acypartner.example). The resolver then looks up that target. Handy, but a CNAME can’t sit at the root of a domain and can’t coexist with other records on the same name.
• MX — mail exchange. Tells the world which servers handle email for the domain. Email routing depends entirely on these.
• TXT — free-form text attached to a name. Originally for notes, now heavily used for verification and email-security records (proving you own a domain, configuring anti-spam policies, and so on).
• NS — name server. Lists the authoritative name servers for a domain. This is the record that delegates control — the TLD uses your NS records to know who to point resolvers toward.

acypartner.example.   record set (simplified)
  @       A       203.0.113.42
  www     CNAME   acypartner.example.
  shop    A       203.0.113.42
  @       MX      10 mail.acypartner.example.
  @       TXT     "v=spf1 include:mailhost.example ~all"
  @       NS      ns1.dnsprovider.example.
  @       NS      ns2.dnsprovider.example.

The @ here is shorthand for the domain itself (the apex or root of the zone). Everything else is a subdomain hanging off it.

Inspecting DNS yourself

DNS isn’t a black box — you can ask it questions directly from a terminal. Standard command-line tools let you see exactly what a resolver sees. Universal examples:

# Ask for a name's address records
dig acypartner.example A

# See the full chain the resolver walks (root → TLD → authoritative)
dig acypartner.example +trace

# Look up a specific record type
dig acypartner.example MX
dig acypartner.example TXT

# Ask a specific resolver instead of your default one
dig @9.9.9.9 acypartner.example A

# The simpler, friendlier classic (available almost everywhere)
nslookup acypartner.example

The +trace option is especially good for seeing this article in action: it shows the resolver starting at the root, getting referred to the TLD, then to the authoritative server, and finally getting the answer — the whole walk, printed out step by step.

Where DNS fits in the bigger picture

DNS is the very first step of almost every connection you make online. Before your browser can speak HTTP or HTTPS to a site, before any data flows over TCP/IP, it has to know the IP address to connect to — and that’s a DNS lookup. It’s quietly the opening move of how the internet works on a practical level.

DNS also does more than point at a single server. It’s a key tool for steering traffic. A CDN, for instance, often uses DNS to send each visitor to a nearby edge location by returning different IP addresses depending on where the request came from. The same lookup you’ve been tracing can quietly hand back the answer that’s geographically best for you. That flexibility — answer depends on who’s asking — is part of why DNS, despite being decades old, is still doing serious work in modern infrastructure.

Wrapping up

Here’s the whole picture in one place:

• DNS translates human-friendly domain names into the IP addresses machines actually connect to.
• It’s not one central directory but a distributed hierarchy: root servers point to TLD servers, which point to authoritative servers that hold the real records.
• A recursive resolver does the legwork — walking root → TLD → authoritative — then hands your device a single final answer.
• Caching at every layer is why lookups are usually instant; the full walk only happens occasionally.
• TTL controls how long answers are cached, and it’s the real reason DNS changes feel slow — old answers linger until each cache expires (what people call propagation).
• Common record types — A, AAAA, CNAME, MX, TXT, NS — each serve a different job, and you can inspect any of them with dig or nslookup.

Get comfortable with the resolver chain and TTL, and DNS stops being a source of mystery delays and becomes a precise, predictable tool. Next, it’s worth turning to the practical side — what to do when a lookup fails — and building a calm, methodical approach to network troubleshooting when something between your machine and the server isn’t behaving.