# IP Addresses, DNS & Ports, Explained > The address book of the internet: what an IP address really is, how DNS turns names like example.com into numbers, and how ports let one machine run many services at once. --- # IP Addresses, DNS & Ports, Explained You type `example.com`, press Enter, and a page appears. Somewhere between your keypress and that page, your computer found one specific machine out of the billions online, knocked on the right door, and asked for the right thing. It feels instant and invisible, so it's easy to treat it as magic. It isn't. It's an address book, a phone directory, and a building full of numbered doors - three plain ideas working together. This guide installs those three ideas so the internet stops being a black box. By the end, "the site is down" and "it's probably DNS" will mean something specific to you, and you'll know where to look. ## How to read this - **Just want one answer?** Each phase stands on its own - jump to [Ports](03-ports.md) if that's the piece you're missing. - **Want it to finally make sense?** Read in order. IP comes first because DNS hands you an IP, and ports attach to an IP. Each phase builds on the one before. ## The phases 1. **[IP Addresses](01-ip-addresses.md)** - what an IP *actually is* (a machine's number), why there are two kinds (IPv4 and IPv6), and why all your home devices share one public address. 2. **[DNS - Names to Numbers](02-dns.md)** - the internet's phone book: how `example.com` becomes an IP, the chain of helpers that look it up, why caching makes it fast, and why so many outages are secretly DNS. 3. **[Ports - One Machine, Many Doors](03-ports.md)** - how a single machine runs the web, email, and SSH at once, each behind a numbered door, and why the real address of a service is *IP + port*. > This guide is about *finding* and *addressing* machines. How data actually travels between them - packets, routing, the journey of a request - lives in [How the Internet Works](/guides/how-the-internet-works), and what your browser says once it reaches the server lives in [HTTP, Explained](/guides/http-explained). --- # IP Addresses - A Machine's Number Every machine that talks on a network needs a way to be found. When you mail a letter, the postal system needs an address. When two computers talk, they need the same thing - a number that says "deliver this here, and nowhere else." That number is an **IP address**, and once you see it as nothing more than a mailing address, the whole topic settles down. 📝 **Terminology.** *IP* stands for *Internet Protocol* - the agreed-upon rules for addressing and delivering data between machines. An *IP address* is one machine's address under those rules. ## What an IP address actually is **What it actually is.** An IP address is a number assigned to a device on a network so other devices can send data to it specifically. That's the whole job: identify one endpoint so traffic reaches it and not the machine next to it. **Why people get this wrong.** People often think an IP address is glued to a device forever, like a serial number etched in the factory. It usually isn't. Your laptop gets an IP when it joins a network and may get a different one tomorrow. The address describes *where you are on the network right now*, not *who you are* - closer to a hotel room number than a passport. **What it looks like.** The familiar form is four numbers separated by dots, each from 0 to 255: ```text 203.0.113.42 └─┬─┘ └─┬─┘ network part host part (roughly - the split varies) ``` You read it left to right like a postal address narrowing down: the left portion points at a network, the right portion points at a specific machine within it. ## IPv4 vs IPv6 - why we made a second kind **The problem that forced a change.** The original scheme, **IPv4**, uses those four dotted numbers. Four slots of 0–255 gives about 4.3 billion possible addresses. In the 1980s that sounded endless. Then every phone, laptop, thermostat, doorbell, and server wanted one, and 4.3 billion stopped being enough. We genuinely ran out. 📝 **Terminology.** *IPv4* = Internet Protocol version 4, the original dotted-decimal addresses. *IPv6* = version 6, the newer, much larger scheme. (There was no widely deployed "version 5" - the number was already used for something else, so the next version became 6.) **The fix.** **IPv6** uses much longer addresses written in hexadecimal, separated by colons: ```text IPv4: 203.0.113.42 IPv6: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 ``` The exact count isn't worth memorizing - the point is that IPv6 has so many addresses that running out is no longer a practical worry. The two systems run side by side today; most devices speak both, and a single machine often has an IPv4 *and* an IPv6 address at the same time. ⚠️ **Gotcha.** IPv6 addresses can be shortened: long runs of zeros collapse to `::`, and leading zeros in a group are dropped. So `2001:0db8:0000:0000:0000:0000:0000:0001` may appear as `2001:db8::1`. Same address, two spellings - that surprises everyone the first time they compare two logs. ## Public vs private - your devices share one address This is the part that quietly confuses almost everyone. **Two worlds, two kinds of address.** Your home has many devices - phone, laptop, TV, console. Each gets a **private IP address**, handed out by your router, that only means something *inside your home network*. Out on the public internet, your whole home appears as a *single* **public IP address**, the one your internet provider gave your router. ```mermaid flowchart LR laptop[laptop
192.168.1.10] --> router[Router] phone[phone
192.168.1.11] --> router tv[TV
192.168.1.12] --> router router -->|one public IP for everything| net((Internet
203.0.113.42)) ``` 📝 **Terminology.** *Private IP addresses* come from reserved ranges (you'll often see `192.168.x.x` or `10.x.x.x`) that are reused in every home and office worldwide - they're meaningful only inside their own network. *Public IP addresses* are unique across the whole internet. **How one public IP serves a whole house.** Your router keeps a little ledger. When your laptop asks for a web page, the router notes "this reply belongs to the laptop," sends the request out under the *public* IP, and routes the answer back to the right device when it returns. That translation trick is called **NAT** (Network Address Translation). It's also one reason IPv4 survived running out of addresses - a thousand homes can hide behind far fewer public addresses. **Why this saves you later.** "What's my IP?" has two correct answers, and now you can tell them apart. The address a website sees is your *public* one (shared by your household). The address your laptop calls itself on the home network is a *private* one. When a tutorial says "connect to `192.168.x.x`," it means a device on your own network - not something out on the internet. ## See it for yourself First, find a public IP by asking your computer to look up a name (more on *how* that lookup works in the next phase - for now, just watch the number come back): ```console $ ping example.com PING example.com (93.184.215.14): 56 data bytes 64 bytes from 93.184.215.14: icmp_seq=0 ttl=56 time=11.3 ms 64 bytes from 93.184.215.14: icmp_seq=1 ttl=56 time=10.9 ms ^C --- example.com ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max = 10.9/11.1/11.3 ms ``` *What just happened:* You asked to "ping" a name. Your computer first turned `example.com` into an IP address (`93.184.215.14`), then sent tiny "are you there?" messages to that address. The server answered each one, and `time=11.3 ms` is how long the round trip took. The number in parentheses is the thing this phase is about - the actual address the name points to. (Press Ctrl-C to stop pinging; on Windows, `ping` sends four messages and stops on its own.) ⚠️ **Gotcha.** A failed `ping` does *not* always mean a site is down. Many servers are deliberately configured to ignore pings while happily serving web pages. `ping` is a quick liveness probe, not a verdict on whether a service works. Now look at your laptop's *private* address on the home network: ```console $ ipconfig getifaddr en0 192.168.1.10 ``` *What just happened:* You asked your machine which IP it's using on its active network connection, and it answered with a private `192.168.x.x` address - the room number inside your house, not the street address the world sees. (On Windows, run `ipconfig`; on Linux, `ip addr` - the command differs, the idea doesn't.) ## Recap 1. **An IP address is a machine's number on a network** - where it is right now, not a permanent identity. 2. **IPv4** (dotted numbers like `203.0.113.42`) ran out of addresses, so **IPv6** (long, colon-separated) was created with far more. 3. **Private IPs** are meaningful only inside your own network; **public IPs** are unique on the internet. 4. **All your home devices share one public IP**, with your router using **NAT** to route replies back to the right device. You now have the *number*. But you didn't type a number - you typed a name. Next, the system that translates one into the other. ## Try it yourself Change the address or drag the prefix - see the network, broadcast, and host range update live: ```playground-subnet 192.168.1.10/24 ``` --- # DNS - Names to Numbers In the last phase you saw that machines find each other by number. But you don't type numbers - you type `example.com`, `github.com`, the name of your bank. Names are for humans; numbers are for machines. Something has to translate between the two, every single time, before any connection can happen. That something is **DNS**, and it runs so smoothly that most people never learn it exists - until it breaks, and a perfectly healthy website appears to vanish. 📝 **Terminology.** *DNS* stands for *Domain Name System*. Think of it as the internet's phone book: you know the name, DNS gives you the number. ## What DNS actually does DNS is a lookup service: you hand it a name (`example.com`) and it hands back an IP address (`93.184.215.14`). Your browser then connects to that address - the name is a convenience for you, the address is what the network actually uses. It's tempting to imagine one giant computer somewhere holding a master list of every name on earth. There isn't one - there couldn't be. DNS is *distributed*: the answer for any name is spread across a chain of servers, each responsible for one slice of the job. No single machine knows everything, and that's the design, not a flaw. Every time you visit a site, follow a link, or load an image from another domain, a DNS lookup happens first (or a cached answer is reused - more on that shortly). It's the quiet first step of nearly every internet action. ## The lookup chain - who answers, in order When your computer needs the IP for a name it hasn't seen recently, it doesn't ask one server - it walks a short chain. You don't have to memorize the machinery, but seeing the shape of it makes the failures later make sense. ```mermaid sequenceDiagram participant You as Your computer participant Resolver as Resolver (recursive) participant Root as Root + TLD servers participant Auth as Authoritative name server You->>Resolver: What's the IP for example.com? Resolver->>Root: Who handles .com names? Root-->>Resolver: ask example.com's own name server Resolver->>Auth: What's the IP for example.com? Auth-->>Resolver: 93.184.215.14 Resolver-->>You: 93.184.215.14 ``` 📝 **Terminology.** A *resolver* (or *recursive resolver*) is the helper that does the legwork - it asks the other servers for you and returns the final answer. An *authoritative name server* is the one that actually *owns* the answer for a given domain. The intermediate steps (*root* and *TLD* servers, where *TLD* = top-level domain like `.com` or `.org`) just point the resolver toward the right authoritative server. The key idea: each server in the chain doesn't know the final answer, but it knows *who to ask next*. The resolver follows that trail of pointers until it reaches the authoritative server, then hands the IP back to you. ## Caching - why it's fast the second time If every lookup walked that whole chain, the internet would feel sluggish. It doesn't, because of **caching**: once an answer is found, it's remembered for a while at several points along the way - your computer, your resolver, even your browser. 📝 **Terminology.** *Caching* means storing an answer so the next request can reuse it instead of looking it up again. Each DNS answer carries a **TTL** (*time to live*) - a countdown in seconds saying how long it's safe to remember before checking again. **Why this matters in real life.** The first visit to a site does the full lookup; the next visits reuse the cached answer and skip straight to connecting. It's why a site you just visited loads faster than one you haven't. ⚠️ **Gotcha.** Caching is also why changes don't take effect instantly. If a site moves to a new IP address, machines that cached the old one keep using it until the TTL expires. This is the source of the classic "it works on my machine but not yours" during a migration - one of you has a stale cached answer. Clearing your DNS cache or waiting out the TTL fixes it. ## See a lookup happen You can watch the translation directly. The `dig` tool (Domain Information Groper) shows you exactly what DNS returns: ```console $ dig example.com ; <<>> DiG 9.18.18 <<>> example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35012 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 3600 IN A 93.184.215.14 ;; Query time: 12 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ``` *What just happened:* You asked DNS for the address of `example.com`. The QUESTION SECTION echoes what you asked (an `A` record - the record type that maps a name to an IPv4 address). The ANSWER SECTION is the payoff: `example.com` is `93.184.215.14`, and the `3600` is the TTL - this answer is good to cache for 3600 seconds (one hour). The `SERVER` line shows which resolver answered (`1.1.1.1`) and that DNS rode on port `53` - a detail that connects straight to the next phase. If you're on a system without `dig`, `nslookup` does a similar job: ```console $ nslookup example.com Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: example.com Address: 93.184.215.14 ``` *What just happened:* Same translation, plainer output. "Non-authoritative answer" means it came from your resolver's cache or its legwork, not directly from the domain's own authoritative server - which is completely normal and not a problem. ## "It's probably DNS" - why outages hide here There's a running joke among engineers that whenever something breaks mysteriously, "it's probably DNS." It's a joke because it's so often true. Here's why. DNS is the *first* step of almost every connection. If the lookup fails or returns a wrong/stale address, your browser never even reaches the real server - so the symptom looks identical to the site being down. The server may be perfectly healthy, serving everyone else, while *you* can't load it because your translation step failed. 🪖 **War story.** A team once spent an hour convinced their app server had crashed - it was unreachable, pages timed out, panic rising. The server was fine the whole time. A DNS change had propagated unevenly: their office resolver still cached the old IP, pointing them at a machine that no longer existed. Everyone outside the office loaded the site normally. The fix was waiting out a TTL, not restarting anything. **How to tell DNS apart from a real outage.** If `ping example.com` or `dig example.com` can't resolve the name at all, but pinging a known IP directly works, the problem is name resolution, not connectivity. That single distinction will save you from restarting things that were never broken. ## Recap 1. **DNS is the internet's phone book** - it translates names you type into the IP addresses machines use. 2. **No single server knows everything**; a **resolver** walks a chain (root → TLD → authoritative) following pointers to the final answer. 3. **Caching** (with a **TTL** countdown) makes repeat lookups fast - and makes changes take time to spread. 4. **When DNS fails, healthy sites look dead** to you, because the lookup is the first step of every connection. Check whether the *name* resolves before assuming the *server* is down. You can now turn a name into a number. But an address gets your request to the right *machine* - how does it reach the right *service* on that machine? That's ports. Follow a single lookup as it travels from your machine out to the root, TLD, and authoritative servers: ```playground-dns ``` Watch it animated: [DNS resolution](/explainers/DNS.dc.html) --- # Ports - One Machine, Many Doors You now know how to find a machine: a name turns into an IP address, and the IP gets your request to that one computer. But here's a question that idea alone can't answer. A single server often runs a website, *and* a mail system, *and* a way for admins to log in remotely - all at the same time, all at the same IP. When your request arrives at that address, how does the machine know *which* of those services you wanted? An address gets you to the building. Something has to get you to the right room. That something is a **port**. ## What a port actually is A port is a number that identifies one specific service on a machine. The IP gets you to the computer; the port gets you to the particular program listening there. Picture the IP address as a building's street address and ports as its numbered doors: ```text IP address: 203.0.113.42 ┌─────────────────────────────────────────┐ │ ▢ 22 ▢ 80 ▢ 443 ▢ 25 │ │ (SSH) (web) (web, (email) │ │ secure) │ │ │ │ one machine, many doors - each door │ │ leads to a different service inside │ └─────────────────────────────────────────┘ knock on door 443 → you reach the secure web server knock on door 22 → you reach the remote-login service ``` Beginners often picture a port as a physical thing - a socket on the back of the computer. It isn't hardware. A port is purely a number the operating system uses to sort incoming traffic and deliver it to the right program. Nothing is plugged into "port 443"; it's a label saying "traffic marked 443 goes to the web server." A program that wants to receive traffic *listens* on a port - it tells the OS "send me anything that arrives for door 80." When your request shows up tagged for port 80, the OS routes it to that program and to no other. Two services can run side by side precisely because they sit behind different door numbers. 📝 **Terminology.** A program waiting for connections is *listening* on a port. The combination of an IP address and a port - written `203.0.113.42:443` - is sometimes called a *socket*: the full address of one specific service on one specific machine. ## The real address is IP + port This is the idea to hold onto: **an IP address alone is not a complete address for talking to a service.** The complete address is *IP plus port*. ```text 203.0.113.42 : 443 └────┬─────┘ └┬─┘ which machine which service on it ``` You use this constantly without noticing, because the common ports are filled in for you. When you type `https://example.com`, your browser quietly assumes port **443** (the standard door for secure web traffic). Type plain `http://`, and it assumes port **80**. The colon-number you occasionally see in a URL - `http://localhost:3000` - is you naming the door explicitly because it isn't the default one. ```console $ curl -I https://example.com HTTP/2 200 content-type: text/html; charset=UTF-8 content-length: 1256 ``` *What just happened:* You fetched the headers of `example.com` over HTTPS. You never typed a port, but the request still went to port **443** because that's the default door for `https://`. The server's web program was listening there, answered with `200` (success), and the connection worked - IP found the machine, port 443 found the web service on it. ⚠️ **Gotcha.** "Connection refused" and "connection timed out" often mean the IP was reachable but *nothing was listening on that port* - you knocked on a door with no one behind it. That's different from the machine being unreachable. If the wrong port is the problem, the fix is finding the right door, not fixing the address. ## Common ports worth recognizing Certain port numbers are conventions everyone agrees on, so services are predictable. You don't need to memorize these, but recognizing them tells you at a glance what a connection is for. | Port | Service | What it's for | |------|---------|---------------| | 80 | HTTP | Web pages (unencrypted) | | 443 | HTTPS | Web pages (encrypted - the modern default) | | 22 | SSH | Secure remote login to a machine's command line | | 25 | SMTP | Sending email between mail servers | | 53 | DNS | The name lookups from the last phase | | 3306 | MySQL | A common database (often only inside a private network) | 📝 **Terminology.** Ports 0–1023 are the *well-known ports* - reserved by convention for standard services like the ones above. Higher numbers are used freely by other programs (which is why a local dev server happily grabs something like `3000` or `8080`). 💡 **Key point.** The conventions are just agreements, not laws. A web server *can* listen on port 8080 instead of 80 - and then you'd reach it at `http://example.com:8080`, naming the non-standard door yourself. The defaults exist so you almost never have to. ## See what's listening You can ask your own machine which programs are listening on which ports right now: ```console $ lsof -i -P -n | grep LISTEN node 4821 ada 23u IPv4 ... TCP 127.0.0.1:3000 (LISTEN) postgres 1190 ada 7u IPv4 ... TCP 127.0.0.1:5432 (LISTEN) ``` *What just happened:* You listed the programs currently holding doors open on your machine. A `node` process is listening on port `3000` (a local web app you're probably developing) and `postgres` on `5432` (a local database). `127.0.0.1` is the machine talking to itself - those services are open to *this* computer only, not the wider network. (On Windows, `netstat -ano` shows the same listening ports; the command differs, the picture doesn't.) **Why this saves you later.** "Port 3000 is already in use" - the bane of every developer's afternoon - now reads plainly: another program already grabbed that door, and two programs can't listen on the same port at once. The fix is to stop the other program or pick a different port. No mystery, just a door that's taken. ## Recap 1. **A port is a number that picks one service** on a machine - the IP finds the building, the port finds the door. 2. **A port is not hardware**; it's a label the OS uses to route incoming traffic to the right listening program. 3. **The full address of a service is IP + port** (`203.0.113.42:443`); your browser fills in `443` for HTTPS and `80` for HTTP so you rarely type it. 4. **Common ports are conventions** (80, 443, 22, 53…) - predictable by agreement, not locked by law. ## Putting all three together Trace one ordinary action - visiting `https://example.com` - and you'll see every idea in this guide do its part: ```mermaid flowchart TD type["you type https://example.com"] --> dns["DNS lookup: example.com → 93.184.215.14
(Phase 2: name → number)"] dns --> connect["connect to 93.184.215.14
(Phase 1: the machine's IP)"] connect --> port["on port 443, default for https
(Phase 3: the right door)"] port --> page["the page loads"] ``` A name became a number, the number found a machine, and a port found the right service on it. That's the address book of the internet, top to bottom - and it's running behind every link you'll ever click. > Where to go next: [How the Internet Works](/guides/how-the-internet-works) follows the data on its journey between machines, [HTTP, Explained](/guides/http-explained) covers the conversation once your request arrives, and [Your Home Network](/guides/your-home-network) digs into the router, NAT, and private addresses from Phase 1.