Names and numbers
Two services do most of the invisible work of the internet: one turns names into addresses, the other hands out addresses in the first place. Most "the internet is down" tickets are one of them.
- You can describe what happens between typing a domain and getting an address, including where the caching happens.
- You can explain why one person sees a new website and another sees the old one, and why a device with a 169.254 address is a DHCP failure.
You type example.com and press enter. Your machine cannot route to a name; it needs a number. Everything that happens in the next few milliseconds is a distributed lookup with several layers of memory, and every layer sets how long a change takes to reach the world.
6.1DNS is a hierarchy with caches
Nobody holds the whole list. The system is a tree, and a resolver walks it.
| Step | Who answers | What they say |
|---|---|---|
| 1. Cache | Your browser, then your OS | "I already know this, here it is" — or nothing |
| 2. Resolver | Your provider, or 1.1.1.1 / 8.8.8.8 | "Let me find out" — and caches the result |
| 3. Root | The root servers | "Ask the servers for .com" |
| 4. TLD | The .com servers | "Ask the authoritative server for example.com" |
| 5. Authoritative | Whoever runs the domain | The actual record, with a TTL |
The TTL is the number that decides how quickly a change propagates. A 300-second TTL means stale answers live for at most five minutes. A 24-hour TTL means a mistake this morning follows you into tomorrow.
Nothing known. The resolver walks root → TLD → authoritative, then returns the record. That is four network round trips instead of none, and the first visitor after a cache expiry pays for all of them.
What this explains: why the very first request to a new service is slow, and why DNS is a latency source you can remove with caching rather than bandwidth.
The resolver already has the record and returns it immediately. The TTL decides how long "already" lasts. Every cache between you and the authoritative server is its own copy, with its own countdown.
What this explains: why a change is visible to one person and not another. It is not a bug; it is a cache with time left on it. dig shows the remaining TTL, which is the number to quote when someone asks "when will it be live?".
6.2The records that matter
| Record | Means | Common mistake |
|---|---|---|
| A | This name has this IPv4 address | Pointing at a load balancer's old IP |
| AAAA | The IPv6 equivalent | Missing, so IPv6 clients fall back slowly |
| CNAME | This name is an alias for another name | Using one at the apex of a zone, where the standard forbids it |
| MX | Where mail for this domain goes, by priority | Pointing at a hostname without an A record |
| TXT | Arbitrary text: SPF, DKIM, verification | Two SPF records, which invalidate both |
| NS | Which servers are authoritative for the zone | Changing these without changing the zone at the same time |
| PTR | Reverse: address to name | Expecting it to match the forward record automatically |
dig example.com +short # the address
dig example.com A +noall +answer # the record, with its TTL
dig +trace example.com # walk the hierarchy yourself
dig @1.1.1.1 example.com # ask a specific resolverTwo resolvers disagreeing is normal and diagnostic: it tells you which cache is stale. Two authoritative servers disagreeing is a misconfiguration, and it produces intermittent failures that move as caches expire at different times.
6.3DHCP: joining a network
Before a device can use DNS it needs an address. DHCP provides one, along with the gateway and the resolver list, in four messages.
When a DHCP pool runs out, new devices get no address and self-assign one starting with 169.254. Existing devices keep working, so half the office is fine and the other half "cannot connect". Nothing in the network is broken; the pool is empty. Check the lease count before you check a single cable — and remember that a 24-hour lease on a 100-address pool breaks on the day 120 people bring laptops.
6.4One more number: the port
An address gets you to the machine. A port gets you to the service. The destination port names what you want (443 for HTTPS, 53 for DNS, 5432 for PostgreSQL); the source port names your side of the conversation.
This is why a server can run a web app, an API and an admin console on one address: three ports, three listeners. It is also why "the server is up but the site is down" is a coherent statement — the machine answered, the port did not.
You moved a site to a new server an hour ago. Some people see the new site, others see the old one. Why?
60-second recap
- DNS is a tree with caches. TTL decides how long a mistake lives.
- 169.254 means no DHCP. The address is a diagnosis, not a configuration.
- Ports name services. Address reaches the machine; port reaches the thing on it.