How DNS works: the map of the system

A name isn't enough

You type antoniocintora.com and hit Enter. To your browser, that name means nothing yet: it cannot open a connection to a name. Routers on the internet don't route names, they route IP addresses.

So before anything can ask for the page, someone has to translate that name into an address. And until that answer comes back, the request just waits. That preliminary step — the one we almost never see — is DNS.

Names and addresses: two ways of naming the same thing

DNS stands for Domain Name System. It exists for a very simple reason: people and machines don't name things the same way. We remember names. The network finds machines by number.

DNS is the layer that keeps those two ways of naming the exact same thing tied together. It isn't a convenience bolted on top: without it the network would still work, but you'd have to memorise the numeric address of every service you use.

What DNS actually holds

The most useful comparison is a vast address book spread across the whole world: you ask for a name and it tells you where the service is.

And not just IP addresses. A domain's record set also holds the server that receives its mail, the aliases pointing at other names, and the verification records external services use to prove the domain is yours. Each one is a different record type, and that's what part two is about.

There is no such thing as "the DNS server"

Here's the first misconception, and the most common one: picturing a single enormous DNS server holding every domain on the internet. It doesn't exist. No machine holds that complete list.

What exists is a system split across thousands of servers, each responsible for its own part only. Two words describe that shape:

• Distributed means the responsibility is carved up.
• Hierarchical means those pieces are organised in levels.

No server knows everything, but every server knows who to ask.

And one detail worth clearing up, because it comes up constantly: people talk about thirteen root servers, which sounds like thirteen machines in thirteen places. They're really thirteen identities, served from hundreds of instances around the world via anycast. The same IP address is announced from many points at once, and your query lands on the nearest one. Which is why losing an instance isn't losing "one of the thirteen".

The hierarchy, top to bottom

A domain name isn't a flat string: each piece belongs to a different level of a tree.

At the very top sits the root zone, written as nothing more than a dot. And yes, there's a trailing dot after com: browsers hide it, but technically it's there.

Just below are the top-level domains, the TLDs: .com, .org, .es. Under each TLD, the domains we register, like antoniocintora.com. And inside each domain, the host names: www, mail, and whatever else is needed.

One trick for reading them: a domain name is interpreted right to left, from the most general to the most specific.

Delegation: nobody has to know everything

And now the idea that makes all of this work: no level stores what's below it — it delegates.

The root has no idea where antoniocintora.com is. It doesn't try to. What it knows is who runs .com. And the .com servers don't know that site's IP either: they know which servers are responsible for that specific domain, the ones declared when it was registered.

That delegation is what lets the system grow without limit and without anyone having to know everything. When you register a domain you aren't adding a row to some global list: you're being handed responsibility for a branch of the tree.

The four actors

A typical lookup involves four distinct roles. They're worth getting straight, because nearly all DNS vocabulary refers to one of them.

One question, several queries

You ask once. Underneath, several queries are chained together.

The resolver asks the root; the root sends it to .com; .com sends it to the authoritative server, and that one answers with the address.

Notice what the intermediate steps have in common: no intermediate answer resolves the question. What they do is move the resolver closer to whoever does have authority. That's why it's called recursive: you ask once and it keeps going until it brings the answer back.

How many milliseconds this takes, and why in practice it almost never runs end to end, is the subject of part two.

Seeing it yourself

None of this is abstract theory: you can walk the hierarchy from your own terminal. On Linux and macOS, the tool is dig.

dig antoniocintora.com A +trace

+trace is the command that matches this article: it asks level by level instead of accepting an answer someone already has stored. You'll see the root first, then the .com servers, and finally the authoritative one. It's the tree above, printed in your terminal.

dig @ns1.antoniocintora.com antoniocintora.com A

With @ you skip the intermediaries and ask the authoritative server in person. It's how you check what the official source says, with nothing in between.

Resolve-DnsName antoniocintora.com -Type A -Server 1.1.1.1

On Windows, Resolve-DnsName is considerably better than the old nslookup: it returns objects, takes record types, and lets you choose which server to ask.

Three errors you'll meet in production

Glossary

Frequently asked questions

To sum up

People use names. The network uses IP addresses. And DNS ties the two together by walking a distributed hierarchy in which every level delegates to the next.

With the map drawn, part two walks that path step by step: what happens at each hop, why caching means it almost never has to run end to end, what TTL is, and which record types live in a domain's record set.

Official resources