How a DNS query works

The last time I changed a domain's A record, the new site showed up for me instantly and stayed on the old server for half the team for almost a full day. The usual suspect surfaced in the group chat: "must be DNS propagation." Except there's no propagation in the magical sense people picture. What actually happened was cache expiring at different paces in different resolvers, each one honoring the TTL the record had when it was queried.

This article breaks down the path a DNS query travels, from your browser to the authoritative server that holds the answer, and why caching at each layer explains nearly everything that looks mysterious.

The problem: a name is useless to the network

When you type example.com, your browser has no idea where to send the packets. The TCP/IP network routes by IP, not by name. So before any HTTP request can happen, someone has to translate the name into an IP address. That someone is the DNS resolution chain, and it's busier than it looks.

The translation always ends in the same thing: an IP (or several). That's all DNS hands back in the end. Everything in the middle exists to find that IP reliably without forcing the whole world to ask the same central server.

The resolution chain, step by step

The path has five main actors. It's worth knowing each one, because when something breaks, the problem lives in one of them.

Stub resolver is the minimal client inside your operating system. It can't resolve anything on its own; it only knows how to ask a bigger resolver and accept the answer. It's what sits behind functions like getaddrinfo.

Recursive resolver is the workhorse. Usually it's your ISP's, or a public one like 8.8.8.8 / 1.1.1.1. It takes on the job of chasing down the entire answer for you, hitting the right servers one by one. That's why the query you send it is called a recursive query: you ask for the final, complete answer and let it figure out the rest.

Root servers sit at the top of the hierarchy. They don't know the IP of example.com, but they know who handles .com. There are 13 root addresses (A through M), spread across hundreds of instances via anycast.

TLD servers handle each top-level domain: .com, .org, .br, and so on. The .com server doesn't know the IP of example.com either, but it knows which authoritative servers run that domain.

Authoritative server is the one holding the truth. It's the server hosting the zone for example.com and it finally returns the A record with the IP.

Recursive vs iterative: who does the heavy lifting

Here's the part that trips people up. The query between the stub and the recursive resolver is recursive: "hand me the finished answer." But the queries the recursive resolver makes to root, TLD, and authoritative are iterative: each one replies "I don't know, but ask this guy."

In practice the flow looks roughly like this:

1. Stub asks the recursive resolver: what's the A record for example.com?
2. Resolver asks root: where's .com? Root replies with the .com servers.
3. Resolver asks the .com TLD: where's example.com? TLD replies with the domain's authoritative servers.
4. Resolver asks the authoritative: what's the A record for example.com? Authoritative replies with the IP.
5. Resolver caches the answer and hands it back to the stub.

You can watch the whole chain with a single command:

dig example.com +trace

+trace makes dig mimic the recursive resolver's job, showing each hop: root, then TLD, then authoritative. It's the most hands-on way to see the hierarchy work live.

For a normal lookup without the whole show, just run:

dig example.com A

And on Windows, or when you just want a quick answer:

nslookup example.com

Caching at every layer: where "propagation" lives

This is the point that dismantles the myth. Each actor in the chain caches answers for the time set by the record's TTL (time to live). If example.com has a TTL of 3600, the recursive resolver holds that IP for an hour and won't even consider asking again during that window.

When you change a record, the authoritative server has the new value instantly. But resolvers around the world keep serving the old value until their TTL expires. Since each resolver queried the record at a different moment, they expire at different moments. The result: some people see the new value, some see the old one, and it lasts roughly the length of the TTL.

That isn't propagation. Nothing is actively spreading across the network. It's cache expiring. The distinction matters because it completely changes what you can do about it.

The caching layer doesn't stop at the resolver. Your own operating system caches, the browser caches, and even the stub resolver can hold answers. That's why you, having flushed your local cache, see the new site while the colleague who didn't is still on the old one.

The opinion: lower the TTL before you migrate

If "propagation" is really cache expiring, the fix is obvious and almost nobody does it: lower the TTL ahead of time. A couple of days before a planned migration, drop the record's TTL to something short, like 300 seconds. Wait for the old TTL to expire (if it was 86400, wait a day). From then on, every resolver will be holding the record for just 5 minutes.

When you make the actual switch, the inconsistency window drops from hours to minutes. Once everything settles, bump the TTL back up to a healthy value to ease the load on resolvers. "Propagation" delays are almost always a high TTL nobody remembered to lower beforehand. It's not magic, it's planning.

What the resolver returns, and how to confirm the destination

At the end of the chain, what comes back to you is an IP. It's worth looking at that IP closely, because it confirms where the domain actually points, regardless of what the registrar panel says. A DNS query ends in an address, and inspecting the resulting IP helps confirm the destination: you can drop that address into an IP address info tool to see who owns it and where it's hosted.

If you want a better grip on what each record type does (A, AAAA, CNAME, MX, and friends), the way to go is the sibling article on DNS record types, which digs into the detail left out here.

UDP, TCP, and the modern transports

By default, DNS runs over UDP on port 53. UDP is fast and ceremony-free: send the question, get the answer, done. It works well because most answers fit in a single packet. When the answer is too big (DNSSEC, lots of records), the resolver falls back to TCP, which handles larger responses at the cost of a handshake.

More recently, DoH (DNS over HTTPS) and DoT (DNS over TLS) showed up. Both solve the same problem: a traditional DNS query travels in plain text, so anyone on the path sees which domains you're visiting. DoH wraps the query inside HTTPS (port 443, indistinguishable from normal web traffic) and DoT uses a dedicated TLS connection on port 853. For resolution itself, nothing changes: the root, TLD, authoritative chain stays the same. Only the leg between you and the recursive resolver gets encrypted.

Frequently asked questions

How long does DNS "propagation" take?

The time equals the largest TTL that was active at the moment of the change. If the record had a TTL of 86400 (a day), some resolvers may serve the old value for up to 24 hours. You can't force the world to forget faster; that's why the move is to lower the TTL before you touch anything.

Why does the new site open for me but not for my colleague?

Local cache. Your system, browser, or resolver has already expired and fetched the new value, while your colleague's is still inside the TTL window. Flushing the machine's DNS cache (or temporarily using a different resolver) usually fixes it for whoever's testing.

What's the difference between a recursive resolver and an authoritative server?

The recursive resolver chases the answer for you, asking the right servers and caching the result. The authoritative server owns the truth for that zone: it asks no one, it just answers with the data you configured. One fetches, the other answers definitively.

Does changing my PC's DNS server speed up browsing?

Sometimes. A faster or closer recursive resolver answers sooner on lookups that aren't cached yet. But once a record is cached, the gain disappears. The effect is more noticeable for someone visiting many different domains than for someone parked on the same sites all day.

Takeaway

A DNS query is a chain: the stub resolver asks the recursive resolver, which iterates through root, TLD, and authoritative until it finds the IP, caching everything along the way and honoring the TTL. What people call "propagation" is just that cache expiring at different paces. Knowing this, the only preparation that matters before a migration is lowering the TTL ahead of time. Do that and the mysterious delays turn into a predictable window of minutes, not a full-day lottery.