You type an address into the bar, hit enter, and a page shows up. It feels instant and it feels simple. Underneath, your computer just asked a question that traveled through a hierarchy of servers spanning the entire planet, governed by an organization most people have never heard of. I find the whole thing genuinely beautiful, so let me walk the whole path.
The problem DNS solves is small to state. Computers talk to each other using numbers, IP addresses. Humans are bad at remembering numbers and good at remembering names. DNS is the phone book that turns a name you can remember into the number a machine needs. The interesting part is that no single phone book could possibly hold every name on the internet, so instead of one book there is a tree, and no one server knows the whole thing.
Who is actually in charge
At the very top sits a nonprofit called ICANN. It does not run your website or answer your queries. What it does is govern the root of the naming system and decide which top level domains exist at all. Dot com, dot org, dot io, every country code, all of them exist because this coordination layer says they do. ICANN does not sell you a name directly. It delegates.
Below ICANN are the registries, the organizations that operate a given top level domain. One organization runs the authoritative list of everything ending in dot com. Another runs dot org. They hold the master record of who owns what within their slice. And below the registries are the registrars, the companies you actually buy a name from. When you register a domain, you are dealing with a registrar, who tells the registry, who is trusted because of the delegation that traces back up to ICANN. It is turtles, but the turtles are organized and each one only has to know about the layer directly beneath it.
The servers that answer the question
That governance mirrors a matching set of servers. At the top are the root name servers. There are thirteen root server identities, served from hundreds of physical machines scattered around the world using some clever routing so that the nearest one answers. The root servers do not know where your website is. They know something smaller and more useful. They know who is responsible for each top level domain.
Under the root are the top level domain servers, the ones that know about all the dot coms or all the dot orgs. They also do not know where your specific site lives. They know who is authoritative for your particular domain. And finally there are the authoritative name servers for the domain itself, usually run by whoever you bought the name from or whoever hosts your site. These are the servers that actually hold the answer, the record that says this name points to this address. Each level knows only enough to point you one step closer.
The resolver that does the legwork
Your browser does not walk this tree itself. It hands the whole job to something called a recursive resolver, usually run by your internet provider or a public service. Recursive is the key word. It means this server takes on the entire task of chasing the answer down and comes back to you only when it has it.
Here is the walk it does, assuming nothing is cached yet. It asks a root server, where do I find out about dot com. The root says, talk to the dot com servers, here is how to reach them. It asks a dot com server, where do I find out about this specific name. That server says, talk to these authoritative servers, here they are. It asks an authoritative server, what is the address for this name. That server, finally, gives the real answer. Four conversations, each one narrowing the search, and your browser saw none of it. It just got a number back.
Why it is not slow every time
If that dance happened on every single visit, the web would feel sluggish. It does not, because of caching at every layer. Every answer comes with a time to live, a number of seconds it is allowed to be remembered. Your resolver caches it. Your operating system caches it. Your browser caches it. So the first person to look up a name that day pays the full cost of the walk, and everyone after them, for as long as the time to live lasts, gets the answer instantly from a cache much closer to home.
This is also why changing where a domain points is not immediate. The old answer is sitting in caches all over the world, each counting down its own timer. Until those expire, some people still get the old address. That lag is not a bug. It is the same caching that makes the system fast, seen from the other side.
Then the real work starts
Notice that after all of this, no web page has loaded yet. All DNS did was turn a name into an address. Only now does your browser open a connection to that address, negotiate a secure channel, ask for the page, and start rendering. DNS is the part that runs before the part everyone thinks of as loading a website, which is exactly why it is invisible. It finishes its job before the visible work begins.
What I like about it is the restraint. No single machine in this system knows very much. The root only knows the top level domains. Each level only knows the level below it. The whole thing holds together not because anyone is in charge of all of it, but because everyone is in charge of a small piece and trusts the delegation above them. It is one of the largest distributed systems humans have ever built, and it works because nobody tried to make one part understand the whole.