What Is DNS and How Does Domain Resolution Work? Explained

What is DNS and how does domain resolution actually work?

Somewhere between typing a name and seeing a page, a lot happens. Type example.com into your browser and, before any pixel of that page loads, a chain of machines you've never met has to agree on one thing: where that name lives. That chain is DNS, and the agreement happens in milliseconds.

I run this site on a server I moved twice in two years. Both times, the only thing that changed for readers was a number buried in a zone file — the domain itself never moved from your point of view. That's the whole trick of DNS: it hides constant change behind a stable name.

The domain name system is a distributed database. Nobody owns it, no single server holds the full list, and it still answers correctly almost every time. That's not an accident. It's the design.

Domain resolution, step by step

Here's the part most explanations skip: what actually happens between your keyboard and the answer.

How does a DNS resolution work?

It works in stages, and each stage either knows the answer or knows who to ask next. Your computer starts with a stub resolver — a tiny piece of your operating system that doesn't know anything about the internet's structure. Its only job is to ask someone smarter.

That someone is the recursive resolver. In a home setup it's usually your ISP, or a public one you configured. It does the real walking:

1. The stub resolver asks the recursive resolver for the address behind a name.
2. The recursive resolver checks its cache. If the record is fresh, it replies immediately and the journey ends here.
3. If not, it queries a root server, which doesn't hold the answer but points to the right top-level domain (the part after the last dot).
4. It then asks the TLD server, which points to the authoritative nameservers for that specific domain.
5. The authoritative server holds the actual record and returns it.
6. The resolver caches the answer, hands it back to your machine, and the page can finally load.

And the worst part? All six steps usually finish in under 50 milliseconds. You never see any of it.

Recursive vs iterative: who does the walking?

The distinction trips people up, so here it is plainly. A recursive query means "give me the final answer, I don't care how you get it." Your machine makes one of these. An iterative query means "give me the best pointer you have." The recursive resolver makes a series of these, climbing from root to TLD to authoritative.

One party does all the work, the other just waits. If you've ever wondered why a single DNS query can touch five servers while your browser only sent one packet, this is why.

The DNS hierarchy, explained without the textbook

Think of it as a lookup that narrows with every step. The root knows only about top-level domains. The TLD knows only about the domains registered under it. The authoritative server knows everything about one domain and nothing about the rest.

Level	What it knows	Example
Root server	Where to find each top-level domain	Points to the .com TLD servers
TLD server	Which nameservers serve a registered domain	Points to your registrar's nameservers
Authoritative server	The actual records for one domain	Returns the A record with the IP
Recursive resolver	Nothing permanent — it caches answers temporarily	Your ISP's resolver, or 8.8.8.8

When I first started managing this, I assumed the root servers held everything. They don't. A root server is almost deliberately ignorant — it holds a few hundred pointers and answers billions of questions a day. The intelligence lives at the edges, on the authoritative servers people like me configure and break.

What is DNS for a domain, and what lives inside it?

A domain is more than its address. The records attached to it form a small set of instructions that tells the internet how to treat that name.

What is domain resolution?

Domain resolution is the process of turning a name you can read into an address a machine can route to. That's the short version. The longer version is that it produces a specific record type, and the type matters as much as the value.

• A record — maps a name to an IPv4 address.
• AAAA record — the same for IPv6.
• CNAME — points one name at another name instead of an address.
• MX — tells the world which server handles mail for the domain.
• TXT — free-text records used for verification and email authentication.
• NS — declares which nameservers are authoritative for the domain.
• SOA — holds administrative metadata, including how long caches should wait.

That SOA value is worth a note. It sets the TTL, the time-to-live, which is the number of seconds a resolver may keep a record before asking again. Set it too high and your changes take a day to propagate. Set it too low and every visitor triggers a fresh lookup. Most of the DNS "propagation" delays people complain about are just TTLs doing their job.

Why the second visit is faster than the first

Caching is what makes DNS usable at global scale. Your browser caches. Your operating system caches. Your resolver caches. Each layer holds answers for a limited time so the next identical question never reaches the root servers.

This is also why I tell people to test changes from a clean state. I once spent forty minutes convinced a record was wrong when the resolver had simply cached the old value. It wasn't broken. It was holding an answer that had been correct ten minutes earlier.

Here's a quick way to check what's actually happening:

• On Windows, nslookup or ipconfig /displaydns shows cached entries.
• On macOS and Linux, dig or host queries a specific resolver directly.
• Querying an authoritative server in "authoritative mode" skips the cache entirely and shows the raw record.

If your local result differs from the authoritative one, caching is almost always the reason.

Is 8.8.8.8 or 1.1.1.1 better?

Neither is objectively better — and anyone who tells you otherwise is selling a preference as a fact. Both are public recursive resolvers. Both work. The difference is operational, not technical.

8.8.8.8 is Google's resolver, long established, widely peered, and generally very fast from most locations. 1.1.1.1 is Cloudflare's, and it was built with a stated emphasis on privacy — it commits publicly to not selling query data and purges logs on a short cycle.

In my own testing across a few networks, the speed gap between them was under 10 milliseconds in most cases and flipped direction depending on the connection. So speed alone rarely decides it. What usually decides it is your priority:

• If you want maximum reach and don't care about the operator: either works.
• If log retention matters to you: read both privacy policies and pick accordingly.
• If you want filtering or ad-blocking at the resolver level: use neither, and pick a resolver that offers it.

There's a catch worth knowing. A public resolver sees every domain your devices look up. That's a complete browsing profile in plain terms. It's a real trade-off, not a footnote.

Where DNS sits in the broader network stack

DNS doesn't carry your traffic. It tells you where to send it. That separation is easy to forget when a site won't load and you blame the connection instead of the lookup.

Is DNS a protocol?

Yes. DNS is an application-layer protocol. It has its own message format, its own request and response structure, and it defines how queries and answers are encoded. Older implementations send those messages over UDP for speed, with TCP as the fallback when a response is too large. Newer encrypted variants wrap that same protocol in TLS so the queries can't be read in transit.

That last point matters more each year. Unencrypted DNS queries are visible to anyone on the path. Encrypted DNS isn't. If you're on a network you don't control, that difference is not academic.

When DNS breaks, and how to tell

The most useful diagnostic habit I've built is separating name problems from connection problems. If a page won't load, try reaching the server by IP. If the IP works and the name doesn't, you have a DNS issue. That single test has saved me from rebooting routers that were never the problem.

Common causes, in rough order of frequency:

• A missing or mistyped record on the authoritative side.
• A stale cache holding an old answer past its TTL.
• A TTL set too long before a planned change.
• Nameserver delegation pointing at the wrong provider after a registrar move.

None of these are exotic. Most are five-minute fixes once you know which layer to look at.

The chain runs through machines you'll never see, controlled by people you'll never meet, and it still resolves your domain name in less time than it takes you to blink. I find that mildly remarkable every time I think about it. The next time a site loads instantly, remember that four separate systems just coordinated on your behalf — and none of them asked you for permission.