DEV Community: Tech In Public

Why DNS Had to Exist: The Directory Problem Explained From First Principles

Tech In Public — Sun, 13 Sep 2026 18:19:16 +0000

The Directory Problem: Why DNS Was Inevitable

Software Laws from First Principles — Investigation 009. This picks up directly from Identity ≠ Location — read that first if you haven't.

A person moves to a new home while a neighborhood directory keeps track of their current location.
A person moves to a new home while a neighborhood directory keeps track of their current location.

The moment identities stay stable but locations keep changing, some kind of directory becomes unavoidable — a thing whose only job is to keep the mapping between the two up to date. That's why DNS exists. Not because engineers liked adding components, but because the problem forces it. Here's why DNS had to exist, built from first principles instead of memorized.

Start with a city, not a computer

You're running a city. People move houses every month. Businesses relocate. Hospitals expand into new buildings. Schools change campuses. Nothing about who these people and places are has changed — only where they are.

Now try to run that city with only one kind of information.

If everyone only knew street addresses, what happens the moment someone moves? Every person who wanted to reach them is now holding a dead address. You'd have to personally notify the entire city every time you changed apartments. Absurd.

Flip it. If everyone only knew names — no addresses at all — how do you deliver a package? You know exactly who it's for and have no idea where to take it.

Neither extreme works. Identity alone can't route anything. Location alone breaks the instant something moves. The city is stuck.

The thing that has to exist in the middle

There's only one way out, and you can derive it without ever hearing the word "DNS." You need a third thing: a system whose entire job is to answer one question — "this identity, where is it right now?" — and to stay current as locations change.

That's a directory.

Diagram showing a stable identity connected through a directory to a changing current location.
Diagram showing a stable identity connected through a directory to a changing current location.

It sits between the stable identity and the shifting location and keeps the mapping fresh:

Identity  →  [ Directory ]  →  Location
  (stable)     (keeps it       (changes)
                current)

The people holding identities never have to know about moves. They ask the directory. The directory is the only thing that has to be updated when something relocates — and updating one directory is infinitely cheaper than notifying everyone.

You've met this directory a hundred times

Once you see the shape, it's everywhere:

A phone book maps names to numbers. When someone changes their number, the book updates — not every person who ever knew them.

Your phone's contacts are a personal directory. "Mom" stays "Mom"; the number behind her can change and you only fix it in one place.

A company directory maps employee names to desks, offices, extensions. People move desks constantly; the directory absorbs the churn.

Every one of these exists for the same reason: identities are stable, locations aren't, and something has to hold the mapping.

Why DNS is exactly this — for the internet

You type "google.com". That's an identity — it doesn't change. But the machine you actually need to reach lives at an IP address like 142.250.x.x , and that can change: servers move, scale, get replaced.

If your browser had to memorize the IP, every server change on earth would break every user pointing at it. So the internet does the city's only sane move — it puts a directory in the middle. DNS takes the stable identity (google.com) and returns its current location (the IP), and stays updated when that location changes. You never touch the IP. You ask the directory.

DNS isn't a clever add-on. It's the inevitable consequence of identity ≠ location at internet scale.

The same pattern, one layer down and one layer up

The directory pattern isn't unique to DNS — it reappears wherever identity and location split:

ARP maps a device's stable network identity to its current hardware address on the local network.
Service discovery in distributed systems maps a service's name to wherever its instances currently live.
Kubernetes Services and load balancers hold a stable front while the actual pods and servers behind them churn.
Different names, different layers, identical job: keep the mapping current so identities never have to care where anything moved.

The takeaway

You don't memorize DNS. You realize it had no choice but to exist. The instant a system has stable identities and changing locations — which is nearly every real system — a directory becomes inevitable, because the only alternatives are "notify everyone on every move" or "know who but never where." Both collapse.

That's the whole trick to understanding infrastructure: don't ask what a component does, ask what problem made it unavoidable.

Next in the series: the four responses every overloaded system has — and why there is no fifth. [Coming soon.]

FAQ

Why does DNS exist? Because website identities (like google.com) stay stable while their locations (IP addresses) change. DNS is the directory that maps the stable identity to the current location, so users never have to track the moving IP.

What problem does DNS actually solve? The directory problem: when identities stay put but locations change, something must hold and update the mapping between them. Without it, every location change would break everyone trying to reach that identity.

What's the difference between DNS and ARP? Both are directories, at different layers. DNS maps a domain name to an IP address. ARP maps an IP address to a device's physical hardware address on the local network. Same pattern — identity to current location — different scope.

Is service discovery the same idea as DNS? Conceptually, yes. Service discovery maps a service's stable name to wherever its running instances currently are, exactly as DNS maps a domain to a current IP. Both are directories solving identity vs location.

Part of the series Previous: Identity ≠ Location.

Identity vs Location in Networking (Explained From First Principles)

Tech In Public — Mon, 07 Sep 2026 08:39:52 +0000

Identity ≠ Location: The Software Idea That Explains DNS, Kubernetes, and Your Phone Contacts

Software Laws from First Principles — Law 13. New here? Start with the series intro: I Tried to Invent the Internet From Scratch Before Learning How It Works.

Identity answers “who are you?” Location answers “where can I reach you right now?” These are two different pieces of information, and almost every hard problem in networking, databases, and distributed systems comes from accidentally treating them as one. Here’s the distinction between identity vs location, discovered from first principles — including where I got it wrong.

The mistake I made (and you probably will too)

I was working through this with a set of examples: passport, GPS coordinate, house address, SIM card, email address. The task: sort each into identity or location.

I confidently put SIM card → both and email → both.

That felt right. It was wrong — and being wrong is the whole lesson. Let me walk it the way it actually unfolded.

Start with a person who moves

A person moves from Mumbai to Delhi. Does their identity change, or only their location?

Only location. The identity defines them — it’s unique and it stays. The location is temporary and can even be shared. That’s the first principle, and everything else is just testing it.

Testing the examples: which are identity, which are location

Passport → identity. Fly from India to Japan. Does your passport change? No. It says who you are, not where you are.

GPS coordinate → location. Can two people stand at the exact same coordinate? Yes. If two things can share it, it can’t identify one of them. Location.

House address → location. Feels like identity, but: move house, and the address changes while you didn’t. And five people in one house share it. Shared + changeable = location.

SIM card → here’s where I was wrong. I said “both.” Test it: take the SIM out and put it in another phone — did the SIM’s identity change? No. Travel Pune to Delhi — did it change? No. The SIM keeps one stable identity; only its relationship to a phone and its location move around it. The SIM is identity. What I’d mistaken for “location” was the mapping sitting next to it.

That mistake — seeing a stable identity tangled up with a changing mapping and calling the whole thing “both” — is exactly the mistake the software industry made for decades.

The hotel analogy that makes identity vs location click

You walk into a hotel and say: “I’d like to meet Rocky.”

Reception doesn’t ask “what’s his GPS coordinate?” They ask “which room is he in?”

Rocky stayed Rocky. Only the room changed. The hotel keeps a mapping:

Rocky  →  Room 402

That mapping can change all day. Rocky doesn’t.

The pattern: identity, mapping, location

Whenever identity and location are different, you need a third thing between them:

Identity
   ↓
Mapping
   ↓
Location

You see it everywhere once you have the lens:

Phone contacts: “Mom” is identity. Mom → +91… is the mapping. Her number changes; you update the mapping. You don’t rename her to “New Number.”

Google Maps: it says “drive to Pune Railway Station,” not “drive to latitude 18.52…”. Name (identity) → coordinates (location), via a mapping.

A company: Employee ID is identity. Desk number is location. The desk changes; the ID shouldn’t.

Why DNS exists: identity vs location on the internet

You type “google.com” — that’s an identity. The network resolves it to something like 142.250.x.x — that’s a location. The thing doing the resolving (DNS) is the mapping. It exists only because identity and location are different.

And Kubernetes: Pods come and go, their IPs change constantly. If clients depended on those changing IPs, everything would break every minute. So Kubernetes adds a stable thing in front — a Service — that holds a steady identity while the Pod locations churn behind it. Same hotel. Same mapping. You just discovered a core Kubernetes idea without touching Kubernetes

The takeaway: why separating identity and location matters

When identities stay stable but locations change, a directory becomes inevitable — something whose entire job is to keep the mapping current. That’s DNS, ARP, service discovery, load balancers, and your phone’s contact list, all at once.

Confuse identity with location and you get systems that break the moment something moves. Separate them, put a mapping in the middle, and things are free to move without anything breaking.

FAQ

What’s the difference between identity and location in networking?
Identity is who/what something is and stays stable (a domain name, a username, an employee ID). Location is where to reach it right now and can change (an IP address, a desk, a GPS coordinate). A mapping or directory connects the two.

Is an IP address identity or location?
Location. An IP tells you where to reach a machine on the network right now; it can change when the machine moves or restarts. The stable identity is usually a name (like a domain) that resolves to an IP.

Why does Kubernetes need Services?
Because Pod IPs (locations) change constantly, but clients need a stable identity to talk to. A Service is the stable identity in front of the shifting Pod locations — the mapping in the middle.

Is a domain name identity or location?
Identity. “google.com” stays the same while the IP address it points to can change. DNS is the mapping that turns the identity into a current location.

I Tried to Invent the Internet From Scratch Before Learning How It Works

Tech In Public — Thu, 03 Sep 2026 12:59:38 +0000

Software Laws from First Principles — the story behind the series

The thought experiment: rebuilding communication from first principles, one constraint at a time.

I did something backwards. Instead of opening a networking course and memorizing what TCP and IP and DNS are.
I started my thought experiment in the year 1800 — before any of it existed — and tried to invent the internet myself, one forced decision at a time. Every time I proposed a solution, it broke under the next problem. And every time it broke, I was accidentally rediscovering an idea that real engineers spent decades arriving at.

This post is the map of that journey. It's also the premise of everything else I'm writing: I don't want to learn what humanity invented. I want to put myself in the position where the invention becomes inevitable — and then compare my version to the real one. That's the whole series.

Here's how it went, mistakes included.

It didn't start with computers. It started with distance.

Strip away all the technology and communication is just this: someone has information, someone else needs it, and something in between has to carry it. Smoke signals, letters, telephones, WhatsApp — same system, different transport. The enemy was never "not having a phone." The enemy was distance, and everything after is a fight against the delay distance creates.

Communication begins with a simple problem: getting information across distance.

So I started with nothing. A messenger on a horse. Information moves only as fast as a physical object. Then the telegraph arrives and, for the first time in history, humans separate the message from the messenger — the information moves without a physical thing carrying it the whole way. That separation turns out to be one of the biggest moves in the entire story, and it keeps coming back.

Then I had to connect more than two computers — and it fell apart fast

Two computers, one wire. Fine. Then a third, a fourth, a thousand. I got asked a deceptively simple question: to connect 1,000 computers so each can reach every other, how many wires do you need? I didn't calculate it — I just felt it. It explodes. It doesn't scale.

Connecting more machines makes the network harder to scale—and exposes the limits of direct connections.

So I proposed a central hub. Everything routes through one machine. Clean. And immediately I'd walked into my first trap: the single point of failure. Destroy the hub and the entire network dies. A king, a CEO, a database, a data center — great architects fear the thing that takes everything down when it falls.

A centralized network is simple to build, but one failed hub can bring everything down.

That fear is exactly what drove the real design. The Cold War military didn't ask "how do we connect computers?" They asked "if a city is destroyed, should the network survive?" The old telephone system said no. The answer had to be yes. That single requirement bent the entire architecture.

Where I started sounding like a government (and why that was a problem)

I noticed my own instinct. Every time a problem appeared, I invented a master — a controller, a manager, a central registry that knows everything. That's how governments and corporations organize. So the guide kept attacking it: who manages the master? Who manages the backup of the master? How many updates per second can one master process before it becomes the bottleneck?

That's when the real shift happened. I stopped asking "who should be in charge of this?" and started asking "can this organize itself?" Ant colonies work and no ant knows the whole colony. Traffic, markets, languages — none has a central controller, and they all function. I moved from central control to local rules, and it turns out that's one of the biggest mindset changes in all of software architecture: local knowledge scales better than global knowledge.

Removing the single point of failure means allowing the network to route around problems.

The mistakes I made along the way (these are the good part)

I want to keep these in, because the polished version of this story would hide them and the polished version is worthless.

I assumed the bottleneck is always the medium — the wire, the road, the transport. Wrong. The sender can be the bottleneck. So can the receiver, the storage, the trust, the cost. Most technology isn't solving a transport problem at all.
I kept adding metadata to every message — address, order, status, security, retries, checks — until the guide asked: should a two-character message carry the same baggage as a 1GB file? At some point the information about the message gets bigger than the message. Every solution creates new information that itself has to be managed.
I tried to build a master that knows everything, repeatedly, before finally accepting no such machine can exist at scale.

Each wrong answer wasn't a failure. It was the exact wrong turn the industry itself took before correcting. Making the mistake is how you understand why the correction mattered.

The moment it stopped being about wires

Late in the journey the guide asked what I was really building — a network, or something else. And the answer that came out was: a set of rules that lets strangers communicate. Not wires. Rules.

That reframed everything. The real invention wasn't the internet. It was the agreement — the protocol — that lets independent systems that know nothing about each other still cooperate.

The machines can be independent; the rules are what allow them to communicate.

That's the idea behind internetworking: independent networks connected by a common set of protocols.

The rules matter more than the machines.

And rules, it turns out, are what survive. The internet isn't wires; it's protocols. React isn't components; it's principles about UI. Docker isn't containers; it's a principle about packaging environments. The implementation dies. The contract lives.

The laws I walked out with

By the end I hadn't memorized networking. I'd collected a set of engineering laws that keep reappearing far outside networking — in databases, cloud, React, Kubernetes, even in how companies are structured:

*Purpose before mechanism *— ask why it exists before how it works.
Constraints create innovation — no constraint, no invention.
Every solution is a tradeoff — there's no perfect architecture, only chosen pains.
Shared resources beat dedicated ones when demand is intermittent (this is why we share roads, CPUs, and cloud servers instead of building private ones per user).

-** Local knowledge scales better than global knowledge.**
Overload has only four responses: wait, distribute, add capacity, or reduce demand. There is no fifth.

Bottlenecks move; they don't disappear. Solve one and it reappears somewhere else.
Every responsibility has a natural home — a system should do only what only it can do.
Communication is transferring a mental model, not words — meaning comes from shared reality, not vocabulary.
Isolate what changes fast from what changes slowly — this is why layers exist.
Stable contracts enable independent evolution — protect the agreement, not the implementation.
Identity ≠ Location — who you are and where to reach you are two different things, and confusing them breaks systems the moment anything moves.
Each of those is its own post in this series. This is the map; the rest are the territory.

Why I'm doing it this way

Most people learn technology by accepting the invention. I'm questioning the necessity of the invention. When you can see the problem before the solution, the technology stops being something to memorize and becomes something you'd have built yourself.

The catch — and I'll be honest about it — is that all of this stays theoretical unless it ends in something real. So every cycle of this series ends with building, publishing, or shipping. Understanding without building is just a more sophisticated way of collecting tools.

Next in the series: Identity ≠ Location — the distinction I got wrong at first, and the reason DNS, Kubernetes Services, and your phone's contact list all quietly work the same way.