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.