Bishwas Adhikari

Lesson 07 — Routing

Sun, 09 Aug 2026 00:00:00 GMT

Track: DevOps Networking — 1 Month Deep Dive Part: 1 — Networking Foundations Status: Understood and closed Concepts covered: 4 — the local-or-gateway decision, routing tables, the default route ladder, how tables write themselves Builds on: Lesson 05 (the gateway from the DHCP bundle), Lesson 06 (MAC envelopes rewritten at every hop)

The last "somehow"
Junction = router
The router's one question
The decision starts at your laptop
Inside the router — the table
The default route, and the ladder of defaults
The top of the ladder — where routers must know
Who writes a million lines?
Where this appears in real work
Easy to get wrong
Old way vs improved understanding
Terms locked in
Deliberately not covered yet
Sources

The last "somehow"

Since Lesson 01, one phrase has carried the whole story: junctions read the address and "pick a direction." The MAC lesson sharpened it — the IP envelope crosses the world untouched while each hop reads 140.82.121.4 and decides which way to pass it. This lesson explains the deciding.

Junction = router

A small unification first. These lessons said "junction" for the boxes along the path and "router" for the box in the house. Truth: they are the same thing. Every junction on Earth is a router. The home router is simply the first one on the path.

The router's one question

A router's whole job is one repeated question:

An envelope for address X just arrived. Which of my exits does it leave through?

Note the shape: a router has a handful of exits — the home router has two (the house side and the internet side); a big city router has dozens — and it must map any of 4.3 billion possible addresses onto one of them. In a fraction of a millisecond, millions of times per second.

The decision starts at your laptop

Before any router touches the envelope, the laptop makes the first routing decision. It has exactly two options:

Option A — the destination is inside the house. The laptop 192.168.1.47 sends to the TV 192.168.1.53. Same network. No router needed at all: ARP-shout for the TV's MAC, wrap the Layer 2 envelope directly to the TV's chip, done. The message never visits the router.

Option B — the destination is outside. Sending to 140.82.121.4. Not one of the house numbers. The laptop cannot deliver this itself — so it does the only thing it can: wrap the Layer 2 envelope to the way out — 192.168.1.1, the gateway from the DHCP bundle. "Not mine to solve. Router's problem now."

How does the laptop know inside from outside? The DHCP bundle told it — alongside the number came a description of which addresses count as the house (roughly: "anything starting 192.168.1 is local"). The exact notation for writing such ranges is its own small language — next lesson. For now: the laptop knows the house's range, and everything else goes to the gateway.

This two-way choice — deliver directly, or hand to the gateway — is routing at its smallest. Every computer on Earth makes it for every single message.

Inside the router — the table

The envelope is now at the home router. The router keeps the core data structure of this entire lesson: a routing table — a short list of rules, each one saying "addresses like this → leave through that exit."

The home router's entire table, essentially:

destinations in 192.168.1.x        →  exit: the house side
everything else                    →  exit: the internet side (toward the ISP)

Two lines. 140.82.121.4 doesn't match line one, so line two catches it: out toward the internet provider.

The default route, and the ladder of defaults

That second line is the most important idea of the lesson. Its official name is the default route — the rule that catches everything not matched by anything more specific. It is the router's version of "not mine to solve, pass it up." The laptop had a way out; the router has one too — its own gateway, pointing at the ISP.

A message leaving the house climbs a ladder of defaults. Laptop → home router → ISP's neighbourhood router → ISP's city router... each device knowing almost nothing, each one having a "somebody bigger will know" rule.

Ignorance, organised well, gets you remarkably far.

The top of the ladder — where routers must know

Follow the ladder up and an obvious problem appears: at the top — the big routers where continents' traffic meets — there is no "somebody bigger." A default route pointing up works until the top; up there, the routers must actually know.

And they do. A core internet router's table is not two lines — it is roughly a million lines, looking like:

addresses 140.82.112.x – 140.82.127.x   →  exit 7  (toward GitHub's provider)
addresses 8.8.8.x                        →  exit 3  (toward Google)
addresses 185.199.108.x – ...            →  exit 7
... about a million more ...

The lines describe ranges, not individual addresses — nobody lists 4.3 billion entries. This is where Lesson 01's block system pays off: IP addresses are handed out in blocks (IANA → regional registries → providers), so whole blocks live in one place, and one table line covers thousands of computers. GitHub's block, Google's block — one rule each.

The full picture of a journey: a ladder of defaults going up, until the envelope reaches routers specific enough to know the destination's block — then increasingly specific hops going down into GitHub's provider, GitHub's building, GitHub's computer. Up the ignorance ladder, down the knowledge ladder.

Who writes a million lines?

The home router's two-line table was written by nobody — it is automatic from the DHCP setup. But a million-line core table? No human types that.

The routers tell each other. GitHub's provider announces to its neighbouring routers: "blocks 140.82.112–127 live behind me." Those neighbours pass the announcement to their neighbours, noting "...reachable through them." Announcements ripple outward across the planet, each router assembling its own table from everything it has heard — and when a link dies somewhere, withdrawal announcements ripple the same way and tables update themselves within seconds to minutes.

The agreed script for these announcements is called BGP — file the name away; the idea is what matters:

The internet's map is not designed or stored anywhere central. It is continuously gossiped into existence by the routers themselves.

This is also the honest reason the internet survives cut cables and dead datacenters: routes are not fixed paths. Every router re-derives "best exit" from current announcements. Today's envelope for 140.82.121.4 might cross a different ocean cable than yesterday's identical envelope, and nobody planned that — the tables just said so today.

(One consequence filed for later: big internet outages sometimes contain the phrase "BGP announcement" — a bad announcement ripples exactly as efficiently as a good one. Noted; not this lesson's depth.)

Where this appears in real work

Soon, and concretely: in the AWS part of this track, routing tables get written by hand. A cloud network is a private little internet, and AWS hands over the table editor: lines saying "this range → stay internal" and "everything else → the internet door." A wrong line makes half the project unreachable in exactly the ways Lesson 01 promised. Everything in this lesson — table, ranges, default route, gateway — reappears there as things that get typed.

Easy to get wrong

Local delivery never touches the router. Laptop-to-TV goes chip-to-chip. If two devices in one house can't reach each other, the router's internet side is irrelevant to the problem.

A router only ever picks the next exit. No router knows the full path. The "route" a message takes is the accumulated result of independent per-hop decisions, not a plan anyone holds.

The default route is a rule, not a failure. Matching "everything else" is how almost all traffic almost everywhere is handled. Small routers are supposed to know nothing.

More specific wins. When both a specific line and the default could match, the specific line is used. The default only catches what nothing else claimed. (This becomes a daily fact of life in cloud routing tables.)

Paths are not stable. Two identical messages may travel different physical routes minutes apart. Debugging with the assumption "it goes the same way every time" fails.

Old way vs improved understanding

Topic	Old way of thinking	Improved understanding
"Junctions pick a direction"	Vague magic in the middle of the internet	A table lookup: match the address against range rules, take the exit
The home router	The internet box	A two-line routing table plus a gateway of its own — bottom rung of a ladder of defaults
How the internet knows where things are	Some central map	No map exists; routers gossip announcements and each assembles its own table
Resilience	The internet mostly works, somehow	Routes re-derive continuously from live announcements; broken links get gossiped away
The laptop's role	Sends messages, that's all	Makes the first routing decision on every single message: local chip-to-chip, or gateway
Ranges in tables	—	The block system from Lesson 01 is what makes million-line tables possible at all

Terms locked in

router — the official name for every junction; the home "internet box" is one
exit (interface) — one of a router's connections; the table maps addresses to exits
routing table — the list of "addresses like this → that exit" rules inside every computer and router
default route — the catch-everything-else rule; the ladder upward
gateway — where a device's default route points; the way out (from the DHCP bundle, now fully explained)
announcement — a router telling neighbours which blocks live behind it
BGP — the agreed script routers use to gossip announcements; name filed, depth deferred

Deliberately not covered yet

The range notation — how "192.168.1.x" and block ranges are properly written: subnets and CIDR, next lesson
NAT — still owed; the reply's journey back into the house, lesson 09
BGP mechanics and BGP-caused outages — the name is enough for now
Writing routing tables in AWS — Part 2, where this lesson becomes hands-on

Sources

Topic	Source	Link
IP routing fundamentals	RFC 1122, section 3.3.1 (routing outbound datagrams)	https://www.rfc-editor.org/rfc/rfc1122.html
BGP, the announcement protocol	RFC 4271	https://www.rfc-editor.org/rfc/rfc4271.html
Live global routing table size (~1M lines)	CIDR Report (updated continuously)	https://www.cidr-report.org/as2.0/
Readable overview	Cloudflare Learning — What is routing?	https://www.cloudflare.com/learning/network-layer/what-is-routing/

Source note: the CIDR Report link shows the actual current size of the global routing table — the "million lines" figure can be checked live there.

End of Lesson 07. Next: subnets and CIDR — the little language ranges are written in.

Lesson 05 — DHCP

Sat, 08 Aug 2026 00:00:00 GMT

Track: DevOps Networking — 1 Month Deep Dive Part: 1 — Networking Foundations Status: Understood and closed Concepts covered: 1 — DHCP (plus two vocabulary words: host, protocol) Builds on: Lesson 01 (the router "handing out numbers"), Lesson 04 (the router handing over "who to ask" for DNS)

The mystery this lesson solves
The full name, word by word
The problem DHCP solves
How it works — the four-line conversation
The bundle
The number is borrowed, not given — leases
The one place DHCP is the wrong tool
Easy to get wrong
Old way vs improved understanding
Terms locked in
Deliberately not covered yet
Sources

The mystery this lesson solves

Twice now, a mysterious event has appeared in these lessons — "when your laptop joins the WiFi, the router hands it a number, and also who to ask for DNS." Lesson 01 used it. The DNS lesson used it. This lesson gives it its name.

That handing-over is called DHCP. One job:

When a computer joins a network, DHCP automatically gives it everything it needs to participate.

The full name, word by word

DHCP = Dynamic Host Configuration Protocol.

Every word maps to something in this lesson:

Word	Meaning in plain terms
Dynamic	Assigned on the fly, from a pool, with leases — the opposite of typed-in-by-hand and permanent
Host	The official word for a computer on a network. A laptop, a TV, the project machine — each is a host
Configuration	The bundle it hands over: your number, the DNS runner, the way out
Protocol	An agreed format for a conversation. The four-line exchange below is the same everywhere, because both sides follow the same script

The full name is literally the lesson in four words: dynamically configuring hosts, by protocol.

Two of those words matter far beyond DHCP:

Host — from here on, when documentation says "host," read "a computer on the network." The word has been hiding in plain sight since the ports lesson: localhost — local host — means "this computer right here."
Protocol — an agreed conversation script between computers. DNS is a protocol. The web's HTTP is a protocol — that is what the P stands for, sitting unexplained inside https:// since the ports lesson. It gets its own lesson later.

The problem DHCP solves

Imagine DHCP didn't exist. You buy a new laptop, connect to your home WiFi, and — nothing works. The laptop has no number, and nothing gives it one. You would have to open settings and type, by hand:

an IP address for the laptop — one that no other device in the house is using, so first go check what the phone and the TV took,
and the address of a DNS runner, or no name will ever resolve.

Get the number wrong — pick one the TV already holds — and both devices break in confusing ways. Now scale that to an office with five hundred laptops and visitors arriving daily: a person whose entire job is typing numbers into settings and untangling collisions.

That was actually reality in the early days. DHCP was invented so that joining a network requires zero typing.

How it works — the four-line conversation

When a laptop connects to the WiFi, before anything else, it has a conversation with the router. Four lines long — and the first line contains a puzzle:

Laptop: "Anyone out there? I'm new, I need a number."

The puzzle: how does the laptop send any message yet? A message needs a destination address and a source address, and the laptop has neither. It doesn't even know the router's number.

The answer: this one message is special. It is a shout. Instead of a destination, it is marked "to absolutely everyone on this local network." Every device in the house receives it. The TV ignores it. The phone ignores it. One device is listening for exactly this shout: the router, which runs a small DHCP answering program.

Router: "Welcome. I offer you 192.168.1.47."

The router keeps a list of which numbers in the house are already handed out, picks a free one, and offers it.

Laptop: "I'll take 192.168.1.47."

Router: "Confirmed. It's yours. Also, here's everything else you need."

Four lines, a fraction of a second, zero typing. That is the entire "handing over" from Lesson 01.

The bundle

The final confirmation carries a small bundle, not just the number — and this is where the DNS lesson connects:

your number:            192.168.1.47
the DNS runner to ask:  8.8.8.8        ← the "who to ask" from the DNS lesson
the way out:            192.168.1.1    ← the router itself, for leaving the house

The third line is new, held loosely for now: it is the address of the door — where the laptop should push any message destined beyond the house. It becomes the star of the routing lesson. What matters here: DHCP is where a computer learns it.

The number is borrowed, not given — leases

The router doesn't give the number — it lends it, with a time limit. The loan is called a lease:

"192.168.1.47 is yours for 24 hours."

Before the lease runs out, the laptop quietly asks to extend it, and normally gets it — which is why a laptop keeps the same number for months. But if the laptop leaves and never comes back, the lease expires and the number returns to the free pool, ready for the next device.

Why lend instead of give? Because the pool is small. A home router typically has a couple hundred numbers to hand out. If numbers were given forever, every phone that ever visited the house would keep one eternally, and the pool would slowly empty — the IPv4 exhaustion story from Lesson 01, in miniature, inside the house. Leases mean departed devices automatically return what they borrowed.

The pattern has appeared before: a granted thing with an expiry that makes the system self-cleaning. DNS answers have TTL; DHCP numbers have leases. Same idea, same reason — nothing stale survives forever.

The one place DHCP is the wrong tool

Connect this to the project, because a trap hides here.

The project machine is 10.0.1.10, and the React frontend has 10.0.1.10:8080 written in its settings to reach the Java backend. Suppose that machine got its number by DHCP lease. One day the machine reboots, the lease has lapsed, the router hands it a different free number — and the frontend's setting now points at nothing. Everything breaks, and nothing looks wrong anywhere.

So a rule of thumb the whole industry follows:

Devices that come and go — laptops, phones — take whatever DHCP offers. Nobody contacts them, so their number can change freely.
Computers that others depend on — the project machine, anything running a waiter from the ports lesson — get a fixed number that never changes, set deliberately.

The deeper fix is already known from the DNS lesson: depend on names, not numbers, and the number underneath can change freely. Real systems use both — fixed numbers for the machines, names on top. The project will do exactly this when it gets deployed properly.

Easy to get wrong

DHCP assigns; it does not connect. The WiFi connection happens first; DHCP is the conversation that runs immediately after, over that connection. "Connected to WiFi but no internet" is often exactly this split: the connection succeeded, the DHCP conversation failed, and the laptop sits numberless.

The first message is a shout, not a normal message. It has no destination — it goes to everyone on the local network at once. This is the only way a device with no number and no knowledge of the network can speak at all.

A lease renewal is invisible; a lease change is not. Devices normally renew and keep their number for months, so DHCP feels permanent. It isn't — and the day a dependent-upon machine's number silently changes is the day this lesson pays for itself.

DHCP hands out more than the number. The DNS runner and the way out arrive in the same bundle. When a machine has "wrong DNS" fresh out of joining a network, the DHCP answering program is where that setting came from.

Fixed numbers are a decision, not a default. Machines that others depend on don't get stable numbers by luck — someone deliberately configured them outside the lease pool.

Old way vs improved understanding

Topic	Old way of thinking	Improved understanding
Joining WiFi	It just works	A four-line shout/offer/take/confirm conversation runs instantly, following a fixed script
Your IP at home	Your number, permanently	A lease from the router's pool, silently renewed, recyclable the moment you leave for good
Where DNS settings come from	Somewhere in the operating system	The DHCP bundle, handed over at join time
"Host"	Vague tech word	Precisely: a computer on a network — as in `localhost`, this computer
"Protocol"	Vague tech word	Precisely: an agreed conversation script both sides follow — DHCP's four lines, DNS's question/answer
Servers and DHCP	Same as any device	Deliberately excluded — machines others depend on need numbers that never change

Terms locked in

DHCP (Dynamic Host Configuration Protocol) — the system that automatically hands a joining computer its number, DNS runner, and way out
host — a computer on a network; localhost = this computer
protocol — an agreed conversation script between computers
shout (broadcast) — a message to everyone on the local network at once; the official word is broadcast
lease — the time-limited loan of an IP number from the pool
pool — the set of numbers a DHCP answering program has available to lend
the way out (gateway) — the address a computer sends beyond-the-network messages to; officially the gateway; star of the next lesson

Deliberately not covered yet

Routing and "the way out" — what the router actually does with a message that leaves the house; next lesson
How the shout physically reaches everyone — needs Layer 2 / MAC addresses, lesson 06... which comes before routing in our file order, so it arrives first
HTTP — the P in https — its own lesson, number 11
How fixed numbers are configured in practice — appears naturally in the AWS part, where every project machine will get one

Sources

Topic	Source	Link
DHCP specification	RFC 2131	https://www.rfc-editor.org/rfc/rfc2131.html
The bundle's contents (DNS runner, gateway, and more)	RFC 2132 — DHCP Options	https://www.rfc-editor.org/rfc/rfc2132.html
Readable overview	Cloudflare Learning — What is DHCP?	https://www.cloudflare.com/learning/network-layer/what-is-dhcp/

Source note: RFC 2131 names the four messages DISCOVER, OFFER, REQUEST, ACK — the official versions of shout / offer / take / confirm. Same conversation, formal names.

End of Lesson 05. Next: MAC addresses and ARP — how the shout physically reaches everyone, and the last envelope we haven't opened.

Lesson 04 — DNS

Sat, 08 Aug 2026 00:00:00 GMT

Track: DevOps Networking — 1 Month Deep Dive Part: 1 — Networking Foundations Status: Understood and closed Concepts covered: 4 — the name-to-number problem, the runner and the chain, caching, TTL Builds on: Lesson 01 (IP addresses), Lesson 02 (ports), Lesson 03 (the message and its envelopes)

The cheat we finally remove
The problem DNS solves
Why not just use numbers directly?
Who answers the question?
Which computer does the laptop ask?
How the answering computer finds out — the chain
Why a chain instead of one big list?
Why 8.8.8.8, and who else does this job
Remembering answers — caching
The problem remembering creates
The fix — TTL
The complete picture
Questions raised in this lesson
Easy to get wrong
Old way vs improved understanding
Terms locked in
Deliberately not covered yet
Sources

The cheat we finally remove

Every walkthrough so far started with the same cheat: "the laptop gets GitHub's address — take it as given." This lesson removes it.

You typed github.com into Chrome.

Look at what you typed. It's a name. Words, letters, dots. But the outer envelope needs 140.82.121.4 — a number. Junctions navigate by numbers only. A junction handed an envelope saying "github.com" would have no idea which direction to pass it. Names mean nothing to the network.

So before Chrome can build the envelope, it has one problem to solve.

The problem DNS solves

Turn the name into the number.

That is the entire job of DNS. Nothing else. Name goes in, number comes out.

Why not just use numbers directly?

You could. Typing 140.82.121.4 into Chrome works right now. So why does the whole world use names instead?

Two reasons, both practical:

Reason 1 — people can't remember numbers. You know github.com, google.com, youtube.com by heart. You don't know a single one of their numbers. Names are for people; numbers are for junctions. DNS is the translator between the two.

Reason 2 — the number changes; the name doesn't. This is the deeper one. GitHub moves its computers sometimes — new building, new machines, new numbers. If the whole world had memorised 140.82.121.4, every move would break everything for everyone. Instead, the world memorises the name, and GitHub just updates what the name points to. The name is a permanent label; the number behind it can quietly change.

This problem already exists in our own project: the React frontend has 10.0.1.10:8080 written in its settings to reach the Java backend. If that computer's number ever changes, the frontend breaks. A name would fix that. This thought returns when the project gets deployed for real.

Who answers the question?

Chrome has a name and needs a number. Where does the answer come from?

Not from Chrome — it doesn't know. Not from the laptop — it doesn't know either.

The answer comes from asking another computer. There are computers on the internet whose entire job is answering exactly one kind of question: "what number is this name?" Chrome sends one of them a tiny message — a real message, with envelopes, just like everything else:

To computer: (the answering computer's number)
To program: the one on port 53
Text: what number is github.com?

And a tiny message comes back:

Text: github.com is 140.82.121.4

Now — and only now — Chrome can build the real envelope and ask for the page.

So every visit to a website is actually two conversations, back to back:

Conversation 1:  "what number is github.com?"  →  "140.82.121.4"
Conversation 2:  "please send me the homepage" →  (the page)

The first one is DNS. It happens before every site you visit, in a few milliseconds, invisibly.

Port 53: in the ports lesson, the well-known ports list had 53 DNS sitting in it, unexplained. Now it's explained. Port 53 is where the answering programs listen, on every DNS computer in the world.

Which computer does the laptop ask?

The laptop already knows who to ask — it has known since the moment it joined the WiFi.

From Lesson 01: when a laptop connects to WiFi, the router hands it a number automatically. What wasn't said then: the router hands over two things at that moment. The laptop's number, and one more line:

"...and if you ever need a name turned into a number, ask this computer: 8.8.8.8."

That second thing is the address of an answering computer. The laptop writes it down and keeps it. From then on, every DNS question the laptop ever asks goes to that one address, on port 53.

So there is no mystery and no searching. The laptop was handed the answer-computer's address on day one, the same way it was handed its own number.

How the answering computer finds out — the chain

The answering computer receives:

Text: what number is github.com?

Here's the thing — it doesn't know either. There are hundreds of millions of names in the world. No single computer holds them all. That would be impossible to keep updated.

Instead, the answering computer finds out, by following a chain:

Step 1 — ask the top. There's a small set of computers at the very top of the naming world, called the root. Their addresses are famous and never change — every answering computer on Earth has them built in. The root doesn't know where github.com is. But it knows something smaller:

"I don't know github.com. But everything ending in .com — ask this computer over there."

It answers with a referral: not the number, but who to ask next.

Step 2 — ask the .com computer. The answering computer follows the referral and asks again. The .com computer holds the list of every name ending in .com — but only one fact about each:

"I don't know github.com's number. But GitHub runs its own answering computer, here's its address — ask them."

Another referral. One step closer.

Step 3 — ask GitHub's own computer. This one does know. GitHub runs it, GitHub keeps it updated, and it holds the actual numbers for GitHub's names:

"github.com is 140.82.121.4."

Done. The chain is three questions long:

8.8.8.8 asks the root        →  "ask the .com computer"
8.8.8.8 asks .com            →  "ask GitHub's own computer"
8.8.8.8 asks GitHub's        →  "140.82.121.4"          ← the answer

Then 8.8.8.8 sends that number back to the laptop, and Chrome builds the envelope.

Why a chain instead of one big list?

Because of who gets to update things.

Look at where the real answer lived: on GitHub's own computer. When GitHub moves buildings and the number changes, GitHub edits its own computer, and the change is instantly live for the whole world. No permission needed, no central authority to notify.

The root only knows who handles .com. The .com computer only knows who speaks for each name. Each level knows one small thing and delegates the rest.

Same shape as the IANA → regional registries → providers chain from Lesson 01 — nobody holds everything; everybody holds one piece and points downward.

Why 8.8.8.8, and who else does this job

8.8.8.8 does NOT have all the info

8.8.8.8 knows almost nothing.

It's not a library. It's a runner. When the laptop asks it "what number is github.com?", it doesn't look the answer up in some giant list it owns — it goes and fetches the answer by walking the chain:

you ask 8.8.8.8  →  8.8.8.8 asks the root
                 →  8.8.8.8 asks the .com computer
                 →  8.8.8.8 asks GitHub's computer
                 →  8.8.8.8 brings the answer back to you

The info lives at the end of the chain — on GitHub's own computer, updated by GitHub. 8.8.8.8 just does the legwork of asking around, so the laptop doesn't have to.

It has exactly one skill — knowing how to walk the chain — plus the built-in addresses of the root computers, which is where every walk starts.

Why those digits?

Nothing special. It's an ordinary IP address, exactly like 140.82.121.4 — four numbers, same format from Lesson 01. Google owned that particular address and put their runner service on it.

They chose it for one human reason: it's easy to remember and easy to type. That matters for a service people configure by hand into routers and laptops. Same reason phone companies like numbers ending in 0000. There is no rule that runners live on repeating digits. It's marketing, not networking.

Who else does this job?

Many, many computers. 8.8.8.8 is not the runner. It's a runner — one of thousands. Three kinds exist:

Your internet company's runner. Every internet provider operates one for its customers. This is the default — when the router handed the laptop "who to ask" on day one, it most likely pointed at the provider's runner, not Google's. Most people use this their whole lives without knowing.

Big public runners. A few companies run free ones open to everyone, on deliberately memorable addresses:

8.8.8.8   Google
1.1.1.1   Cloudflare
9.9.9.9   Quad9

Anyone can point their laptop at any of these instead of their provider's.

Private ones. Companies run runners inside their own networks too — that becomes relevant in AWS and Kubernetes, where we will meet runners we control ourselves.

And the crucial thing: every one of them walks the same chain and gets the same answer. Ask Google's runner, Cloudflare's, or your provider's what number github.com is — all three walk root → .com → GitHub's computer, and all three come back with whatever GitHub's computer says. The runners are interchangeable. The answers have a single source: the computer at the end of the chain, run by the name's owner.

8.8.8.8 holds nothing; it fetches. The answer lives with the name's owner, and any runner in the world can go get it.

Remembering answers — caching

You visit github.com. Chrome asks the runner, the runner walks the chain, the answer comes back. Fine.

Thirty seconds later you click a link on GitHub. Another page from github.com. Does the whole chain get walked again? And again for the next click? One person alone would trigger dozens of walks per hour. Multiply by two billion people.

The root computers would be answering the same question — "who handles .com?" — trillions of times a day. Almost every answer identical to the last one. Pure waste.

So everything in this system does the obvious thing: it remembers answers it already got.

The laptop remembers. The runner remembers. Once either of them has learned github.com is 140.82.121.4, the next question gets answered instantly from memory — no chain, no waiting:

First visit:    laptop → runner → root → .com → GitHub's computer   (full walk)
Next visits:    laptop → its own memory                              (instant)

This remembering is called caching, and the stored answer is a cache. These words appear constantly in this field — they just mean "kept a copy to avoid asking again."

The problem remembering creates

Reason 2 from the start of this lesson: the number changes; the name doesn't. GitHub moves computers, updates its own answering computer, new number is live.

Except — the laptop still has the old number memorised. So does the runner. So do millions of laptops and runners around the world. They're not going to ask again; that was the whole point of remembering. Everyone confidently uses a stale answer, and GitHub's new number never reaches them.

Remembering solved the waste problem and created a staleness problem.

The fix — TTL

Every DNS answer carries one extra piece of information — how long it may be remembered:

github.com is 140.82.121.4 — you may remember this for 60 seconds

That number is called the TTL — time to live. When it runs out, the memorised answer is thrown away, and the next question triggers a fresh walk of the chain.

The elegant part: the name's owner sets it. The TTL comes from GitHub's own computer, along with the answer. So GitHub controls the trade-off for its own name:

Long TTL (say, a day): the world barely ever re-asks. Fast and cheap — but if the number changes, some people stay stale for up to a day.
Short TTL (say, 60 seconds): the world re-asks constantly — more chain-walking, but a change spreads to everyone within a minute.

Real teams use this actively. Planning to move an app to a new computer next Tuesday? Days before, drop the TTL to 60 seconds. The world's caches start refreshing every minute. Make the move — everyone follows within a minute. Then raise the TTL back up. This is a genuine DevOps move, and this is the machinery behind it.

Why "it works for me but not for him"

This also explains a classic confusion in real work. A number changes. One colleague sees the new site; another sees the old one. Nobody is wrong — one laptop's memorised answer hasn't expired yet, the other's had. Wait out the TTL, or force the laptop to forget early (there's a command for that — it goes in the troubleshooting tools lesson), and they match again.

The complete picture

1. Laptop joined WiFi        →  router handed it: your number + who to ask (8.8.8.8)
2. You typed github.com      →  Chrome asks 8.8.8.8: "what number is github.com?"
3. 8.8.8.8 walks the chain   →  root → .com → GitHub's computer → 140.82.121.4
4. Answer returns            →  Chrome builds the envelope and asks for the page

And in four lines:

names exist because people can't remember numbers, and numbers change
runners fetch answers by walking the chain: root → .com → the owner's computer
everyone remembers answers to avoid re-walking
every answer expires after its TTL, set by the owner

Questions raised in this lesson

How does "asking another computer" actually work?

Answered in full above — the two halves are which computer gets asked (the router hands over the runner's address on day one, alongside the laptop's own number) and how that computer finds out (it walks the chain: root → .com → the owner's computer).

Why is it 8.8.8.8? Does it have all the info? Is it the only one?

Answered in full above — Why 8.8.8.8, and who else does this job. Short version: the digits are marketing, not networking; it holds almost nothing and fetches everything; and it is one runner among thousands of interchangeable ones, all of which walk the same chain to the same single source of truth.

Follow-up questions: who owns names, endings, and the whole system

These questions came after the lesson was first closed. Recorded here in full, in the order asked.

First, the right word: extension = TLD

The ending of a name — .com, .in, .org — is officially called a TLD (top-level domain). "Top-level" because it is the top of the chain: the root's referrals point at TLD computers.

Who owns domain names and endings?

Ownership follows the exact same three levels as the resolution chain: root → .com computer → GitHub's computer.

The top: ICANN. The root is overseen by an organisation called ICANN — same species as IANA and the IETF from earlier lessons: a non-profit, owned by nobody, controlled by no government. (IANA, from Lesson 01, operates as part of ICANN — the address pool and the name system are stewarded under the same roof.) ICANN's job at this level is one thing: deciding which TLDs exist at all. A TLD exists only if ICANN has put it into the root.

The middle: one company per TLD. Each TLD's computer — the one that answered "ask GitHub's own computer" in the chain — is operated by a single organisation called the registry for that TLD. ICANN contracts each TLD out to exactly one registry. For .com, that is a company called Verisign. The registry keeps the master list: every registered .com name and who speaks for it.

The bottom: you. And a truth that surprises everyone: nobody owns a domain name. Not even github.com is owned by GitHub. Names are rented, yearly. GitHub pays every year to keep github.com on Verisign's list. Stop paying, and the name eventually goes back into the pool for anyone to take. It is a lease, permanently renewable, never a purchase.

Where does GoDaddy fit? Why can it sell domains?

GoDaddy owns nothing in this chain. It is a retailer.

The registry (Verisign) keeps the master list but does not deal with the public. Instead, ICANN accredits companies — called registrars — to sell entries in that list on the registry's behalf. GoDaddy, Namecheap, and hundreds of others are registrars.

"Buying" myapp.com on GoDaddy for $12/year actually flows like this:

you pay GoDaddy ~$12/year
   → GoDaddy pays Verisign ~$10 (the wholesale price of a .com entry)
      → Verisign pays ICANN a small fee ($0.18 per name per year)
         → Verisign adds one line to the .com master list:
           "myapp.com → speaks-for computer is at X"

GoDaddy's business is the retail margin plus the customer-facing work: the website, the payment, the support. The actual record lives with Verisign. This is why a name can be moved from GoDaddy to Namecheap without losing it — registrars are interchangeable shopfronts over the same master list. Exactly like the DNS runners: many doors, one source of truth.

The full ownership stack:

ICANN       decides which TLDs exist            (the root level)
registry    runs one TLD's master list          (Verisign for .com)
registrar   sells entries to the public         (GoDaddy, Namecheap...)
you         rent one name, per year             (myapp.com)

Can I create my own TLD?

Yes. Genuinely.

ICANN does not invent TLDs itself — it opens application rounds where anyone qualified can propose one. The last round was in 2012, and it created over 1,200 new TLDs — brand ones like .google and .bmw, city ones like .nyc and .london, industry ones like .shop and .finance. Those odd endings exist because companies applied for them.

What it takes (2026 round):

The application fee alone is USD 227,000 — a non-refundable evaluation cost, not a purchase price
Proof of technical and financial capability to run the TLD's computer (the registry role) — or hiring an approved provider to run it
Background checks, public objection periods, and if two applicants want the same string, an ICANN-run auction
Winning means signing an ongoing contract with ICANN, with yearly fees — the winner becomes the registry for that TLD

Timing at the moment this was asked: the current application window — the first since 2012 — opened on 30 April 2026 and closes on 12 August 2026, one week after this conversation. There is no announced date for the next round.

Realistically, TLD creation is for corporations and governments. But the mechanism matters more than the price tag: the system is genuinely open. The root is not a fixed list from the 1980s; it is an administered, expandable registry, and .com has no special magic over .pizza except age and habit.

Why does ICANN take the money? Why so expensive?

Why money at all: evaluating an application costs real work. When someone applies for .pizza, ICANN pays panels of people to verify the applicant's finances (can they run this for years without collapsing?), verify the technical setup (can their computer answer the world's questions reliably?), run background checks on the people behind it, handle objections ("that's our trademark!"), disputes, and auctions — all legally watertight, because rejected applicants sue. The fee pays those people. ICANN's stated rule: the fee is designed to fully cover the costs of the application round, so the program is cost-neutral — no profit, no loss.

Why THIS expensive: two reasons stacked.

The evaluation genuinely costs that much — months of specialist panels per application, multiplied by legal defensibility.
The price is also a filter, and that is deliberate. A TLD lives in the root, and the root must stay clean and stable — it is the level every DNS question in the world starts from. If applying cost $50, a million people would apply for joke TLDs, squatters would grab every word in the dictionary to resell, and the evaluation system would drown. At $227,000, only applicants who seriously intend to operate a TLD for decades show up. Expensive is part of the design.

What does "top of the chain" mean?

The chain from this lesson, drawn as levels:

LEVEL 1  the root            "for .com, ask over there"        ← the top
LEVEL 2  the .com computer   "for github.com, ask over there"
LEVEL 3  GitHub's computer   "github.com is 140.82.121.4"      ← the bottom

"Top" means level 1 — the place every fresh walk starts. Every question about any name in the world begins by asking the root. Everything else hangs below it. A TLD is called "top-level" because it is the level the root hands out referrals for.

What does the root actually look like?

The root is a text file.

Not a metaphor. An actual plain text file, called the root zone file, maintained by IANA. It is public and downloadable by anyone:

https://www.internic.net/domain/root.zone

It contains thousands of lines. Simplified, they say:

com.      →  ask the computers run by Verisign, at these addresses
in.       →  ask the computers run by India's registry, at these addresses
pizza.    →  ask the computers run by .pizza's registry, at these addresses

One line-group per TLD: the ending, and the addresses of the computers that answer for it. That is the entire top of the naming world. When ICANN "adds a TLD to the root," a person at IANA literally edits this file and publishes a new version. The file has a serial number that ticks up with each edit.

How does the root file reach the public? How do registrars "get" TLDs?

Two separate mechanisms:

The file reaches the world through the root computers. The root computers — whose addresses are built into every runner — each hold a copy of that text file and answer questions from it. When IANA publishes a new version, all the root computers pull the update, typically live worldwide within hours. That is the entire distribution: one file, copied to a set of computers that every runner on Earth knows how to ask.

Registrars don't "get" TLDs at all. A registrar never possesses a TLD — the registry does. What a registrar gets is a contract: an agreement with a registry (say, Verisign for .com) granting it permission to add, renew and delete entries in that registry's master list, on behalf of paying customers. GoDaddy holds such contracts with many registries, which is why it can sell .com, .in and .pizza names alike. The registrar is a shopfront with write-access to someone else's list. Nothing more.

How do we know if something is a TLD or not?

It is a TLD if it has a line in the root file. No line, not a TLD, and no name ending in it can exist.

For humans, IANA publishes the same information as a browsable list:

https://www.iana.org/domains/root/db

Every TLD in existence — about 1,400 today — with who runs each. .pizza is there. .google is there. .notarealtld is not, so myapp.notarealtld cannot exist anywhere: the root would answer "no such ending" and every chain-walk would die at step 1.

What does Verisign's master list look like?

The same thing, one level down: another text file, just enormously bigger.

The root file has ~1,400 entries — one per TLD. Verisign's .com file has about 160 million entries — one per registered .com name. Same shape of line:

github.com.    →  ask GitHub's computers, at these addresses
myapp.com.     →  ask (wherever myapp's owner pointed it)
...160 million more...

Each line: a name, and who speaks for it. Renting myapp.com through GoDaddy means GoDaddy's system telling Verisign's system to append that line. Stop paying, and the line is eventually removed. The "master list" is that literal.

The whole naming system, top to bottom, is text files pointing at other text files, copied onto computers that answer questions from them.

How does the availability check work?

Typing myapp.com into GoDaddy's search box and seeing "available!" or "taken" is exactly what you would now guess:

you type myapp.com into GoDaddy
   → GoDaddy asks Verisign's system: "is there a line for myapp.com?"
      → Verisign checks the list
   ← "no line exists"
← GoDaddy shows you: "available!"

One question, one lookup, one answer. Registrars have a direct connection to each registry's system for exactly this — the same connection used to write the line in when someone pays. (The question-and-answer format between them has a name, EPP — file it away; it never needs touching directly.)

The part worth keeping is the authority: GoDaddy does not decide availability, and neither does any registrar. They all ask the same list. That is why the answer is identical on GoDaddy, Namecheap, or anywhere else — one file, many shopfronts.

When payment happens, the line gets written into the list at that moment, and every later availability check by anyone on Earth finds it. First to write the line wins the name.

What happens if I miss my renewal date?

The key is a mechanism nobody tells domain owners about:

On the expiry date, Verisign automatically renews the line anyway — and charges the registrar the wholesale fee. The registrar then has a window of up to 45 days to either keep the renewal (if the customer finally pays) or cancel it and take a refund from Verisign (if not).

That registry-level window creates the buffer. The lifecycle of an unpaid .com (expiry date as day 0):

day 0         expiry — Verisign auto-renews, the registrar is now deciding
days 0–~30    GRACE PERIOD: renew at the normal price
              (exact length is each registrar's policy — GoDaddy is
               currently around 30 days; the site usually stops working
               after a few days, but the name is still yours)
~day 30–60    REDEMPTION: the registrar cancelled with Verisign; the name
              enters a 30-day recovery state. Recovery is STILL possible —
              but with a hefty fee ($80+) on top of the renewal
last 5 days   PENDING DELETE: locked, nobody can touch it
after that    the line is removed — the name is publicly available again

How does the registrar "decide" to remove the line? It does nothing active — it just stops paying. Cancelling the auto-renewal within Verisign's 45-day window is what starts the deletion clock. The removal is the consequence of the registrar taking its refund.

How much buffer? Roughly 30 days at normal price, then ~30 more at ransom price, then ~5 days locked — about 65–75 days total between expiry and true release. But the grace period at normal price is registrar policy, not a law; it varies and can change.

Does the registrar pay by itself if the customer doesn't renew? Technically Verisign auto-renewed on day one — but the registrar will undo that renewal and take the refund rather than absorb the cost. No registrar pays to keep a name alive out of kindness. Worse: for names with traffic, registrars may auction them to third parties during the redemption phase. Expired names with visitors are a resale market.

The habit to take from this: the buffer exists to save you from accidents, not to be a payment plan. Real teams put domain renewal on auto-pay, because the failure mode — losing a name to a squatter who wants $5,000 for it back — is not recoverable by any technical means. The name system has no "but it was mine" appeal process. The line either exists or it doesn't.

Country endings: .in, .np — and why .com.np instead of .np

Country endings are just TLDs with one special rule about who gets them.

Early in the internet's history, a decision was made: every country gets a two-letter ending, taken from an already-existing international standard list of country codes — the same list that gives IN for India, NP for Nepal, JP for Japan on currency codes and vehicle stickers. ICANN does not invent these codes; it inherits them from that list. Country on the list → entitled to a TLD.

The delegation then works like everything else: ICANN puts the line in the root, pointing at a registry — but for a country code, the registry is an organisation in or approved by that country. Each country then runs its ending by its own rules: its own prices, its own eligibility requirements, its own structure. ICANN hands over the ending and steps back.

Why .com.np and not just .np? Because that is Nepal's registry exercising exactly that freedom. Nepal organised its space with categories underneath its TLD:

.com.np   for companies
.edu.np   for schools
.gov.np   for government offices
.org.np   for organisations

Nepal's registry runs its master list one level deeper — registration happens at myshop.com.np, not myshop.np. India offers both styles: plain .in and categorised .co.in. The UK did categories for decades (.co.uk) and later opened plain .uk too. Same machinery, per-country choices — the chain from this lesson with one extra link:

root → .np computer → .com.np level → myshop's computer

Who maintains .com.np, and why was mine free?

Who: the .np registry is administered by Mercantile Communication Pvt Ltd — a private Kathmandu company that has held the delegation since .np was created in 1995. In the chain:

root  →  .np computers (Mercantile's)  →  bishwas54.com.np's line

Mercantile plays the registry role — the same role Verisign plays for .com. And register.com.np is not a separate registrar like GoDaddy — it is Mercantile's own front door. Nepal skips the registrar layer entirely: registration happens directly with the registry. No middlemen, no retail markup, one organisation doing both jobs.

Why free: a policy choice by the registry — and Nepal is genuinely unusual: almost no other country TLD is completely free with free renewal indefinitely. Mercantile runs registration as a public service to get Nepali people and businesses online, covering the cost from its other business (it is an internet provider).

Every registry sets its own rules for writing lines into its list. Verisign's rule: anyone, ~$10 wholesale. Mercantile's rule: free — but prove you belong here. That second clause is why free is sustainable. For .com, money itself is the anti-abuse filter — no human review needed. Remove the money and a different filter is needed, which is exactly the .np experience: proof of Nepali citizenship for personal domains, or company registration papers for organisations — reviewed by an actual human, which is why approval takes days, not seconds. The citizenship document does the job the $12 would have done at GoDaddy.

Two consequences of Nepal's model:

.np names are registered first-come-first-served, for lifetime — there is no expiration date. The entire expiry lifecycle above (grace periods, redemption ransoms, auction vultures) does not apply. A .com.np name has no renewal date to miss.
The eligibility check quietly protects the space: a squatter in another country cannot hoard thousands of Nepali names for resale, because each registration needs Nepali documents. The doorman is the anti-squatting mechanism.

.gov and .edu

These two feel like categories, but they are actually history. They are among the very first TLDs ever created — 1985, before the internet was global, when it was essentially an American research network. And they carry a surprise:

.gov is US-government-only. Not governments of the world — the United States government specifically. The registry is operated by a US federal agency, and eligibility is strict: only US federal, state, or local government bodies. Other countries' governments live under their country codes — India's uses .gov.in, Nepal's uses .gov.np. The bare .gov was never internationalised; it predates the idea that it would need to be.

.edu is US-accredited-institutions-only. Same story: the registry is a US nonprofit, and eligibility requires formal US higher-education accreditation. Oxford — one of the oldest universities on Earth — cannot have oxford.edu; it is ox.ac.uk, under the UK's academic category. Every country's universities live under their own code; the bare .edu is American by historical accident.

The pattern for restricted endings is nothing exotic: every registry sets rules for its own list, and the only difference is how hard the check is.

Ending	Registry's rule for writing your line
`.com`	anyone, ~$12/year
`.in`	anyone, under India's registry's terms
`.com.np`	Nepali citizens and companies, free, documents required
`.gov`	US government bodies only
`.edu`	accredited US universities only
`.google`	Google only — a brand TLD where the registry's rule is "just us"

Same files, same lines, same chain. Only the doorman changes.

New terms from this section

TLD (top-level domain) — the official word for an ending: .com, .np, .pizza
ICANN — the non-profit overseeing which TLDs exist; IANA operates as part of it
registry — the one organisation running a TLD's master list (Verisign for .com, Mercantile for .np)
registrar — a retailer with a contract to write lines into registries' lists (GoDaddy, Namecheap)
root zone file — the actual text file at the top of the naming world, one entry per TLD, publicly downloadable
renting, not owning — names are yearly leases; the "owner" is whoever keeps paying
grace period / redemption / pending delete — the three stages between missing a renewal and the name becoming public again
ccTLD (country-code TLD) — a two-letter country ending like .in or .np, delegated to a registry in that country
EPP — the wire format registrars and registries use to talk; never touched directly

Sources for this section

Claim	Source	Link
ICANN's role, TLD application rounds	ICANN New gTLD Program, 2026 round	https://newgtldprogram.icann.org/en/application-rounds/round2
$227,000 evaluation fee, cost-neutral principle	ICANN fee FAQ	https://newgtldprogram.icann.org/en/application-rounds/round2/2026-round-general/gtld-evaluation-fee/faqs
2026 window dates (30 Apr – 12 Aug 2026)	ICANN 2026 Round page	https://newgtldprogram.icann.org/en/application-rounds/round2
2012 round created 1,200+ TLDs	CentralNic Registry overview	https://centralnicregistry.com/icann-new-gtld-program/
The root zone file itself	InterNIC (IANA)	https://www.internic.net/domain/root.zone
Browsable list of all TLDs and their registries	IANA Root Zone Database	https://www.iana.org/domains/root/db
Verisign runs .com; registrar/registry model	Verisign	https://www.verisign.com/en_US/domain-names/com-domain-names/index.xhtml
ICANN fee per .com name per year	ICANN registry agreements	https://www.icann.org/resources/pages/registries/registries-agreements-en
Expired domain lifecycle (grace, redemption, pending delete)	ICANN — EPP status codes & expired domains	https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en
Registrar expiry/renewal obligations	ICANN Expired Registration Recovery Policy	https://www.icann.org/resources/pages/errp-2013-02-28-en
.np run by Mercantile, free, citizenship documents, lifetime	Wikipedia — .np (cites registry policy)	https://en.wikipedia.org/wiki/.np
.np official registration portal	register.com.np	https://register.com.np/
Country codes come from the ISO 3166 standard list	ISO 3166	https://www.iso.org/iso-3166-country-codes.html
.gov eligibility (US government only)	US government — get.gov	https://get.gov/domains/eligibility/
.edu eligibility (accredited US institutions)	EDUCAUSE .edu policy	https://net.educause.edu/eligibility.htm

Easy to get wrong

The runner is not the source of truth. The answer lives on the name owner's computer, at the end of the chain. Runners fetch and remember; they never decide.

Every website visit is two conversations, not one. The DNS question happens first, invisibly, before the page is ever requested. When "the internet is down," sometimes only conversation 1 is broken — names stop resolving while direct numbers still work. Recognising which conversation failed is a real debugging skill.

Caching means changes are not instant. Updating where a name points does not update the world. Every cache holding the old answer keeps serving it until its TTL runs out. "I changed it, why does everyone still see the old one" — TTL, almost every time.

Two people can get different answers and both be right. Different caches, different expiry moments. Not a bug — a direct consequence of the design.

The chain is for fresh questions only. Most real questions never reach the root — they're answered from a cache somewhere. The full walk happens only when nobody in the path remembers.

Old way vs improved understanding

Topic	Old way of thinking	Improved understanding
Typing a website name	The name just works, somehow	A hidden first conversation converts it to a number before anything else happens
DNS	A vague "phonebook of the internet"	A chain of delegation: root → `.com` → the owner's computer, walked by runners
8.8.8.8	A magic number that knows everything	An ordinary IP with a memorable pattern, holding nothing, fetching everything
Who controls a name's answer	Some central internet authority	The name's owner, on their own computer, editable at will
DNS changes	Instant	Spread at the speed of expiring caches, controlled by the TTL the owner set
"Works for me, not for him"	Confusing, someone must be wrong	Both right — different caches, different expiry times

Terms locked in

DNS — the system that turns names into numbers
runner (resolver) — a computer that fetches DNS answers by walking the chain on your behalf; the official word is resolver
root — the small set of computers at the top of the naming world, addresses built into every runner
referral — an answer that says "I don't know, but ask them"
the owner's computer (authoritative server) — the computer where a name's real answer lives, run by whoever owns the name; the official word is authoritative
port 53 — where DNS answering programs listen, everywhere
caching — remembering an answer to avoid asking again
cache — the remembered copy itself
TTL (time to live) — how long an answer may be remembered, set by the name's owner
stale — a cached answer that no longer matches the current truth

Deliberately not covered yet

DHCP — the router "handing things over" on day one has a name and a mechanism; next lesson
The command to force a laptop to forget a cached answer — troubleshooting tools lesson
Record types — DNS can answer more question-shapes than "what number is this name"; introduced when first needed
DNS inside Kubernetes and AWS — private runners we control; Parts 2 and 4
What the DNS message looks like on the wire, and why it behaves differently from a page request — needs TCP vs UDP first, lesson 10

Sources

Topic	Source	Link
DNS concepts, original specification	RFC 1034	https://www.rfc-editor.org/rfc/rfc1034.html
DNS implementation details, TTL	RFC 1035	https://www.rfc-editor.org/rfc/rfc1035.html
The root servers, run by twelve organisations	IANA root servers page	https://www.iana.org/domains/root/servers
Google's public runner	Google Public DNS documentation	https://developers.google.com/speed/public-dns/docs/intro
Cloudflare's public runner	Cloudflare 1.1.1.1 documentation	https://developers.cloudflare.com/1.1.1.1/
Readable overview of the full resolution chain	Cloudflare Learning — What is DNS?	https://www.cloudflare.com/learning/dns/what-is-dns/

Source note: RFC 1034 and 1035 are the original 1987 specifications and remain the authoritative base, extended by many later RFCs. The Cloudflare learning page is a readable secondary source that matches the chain as taught here.

End of Lesson 04. Next: DHCP — the router "handing things over" finally gets its real name.

Lesson 06 — MAC Addresses and ARP

Sat, 08 Aug 2026 00:00:00 GMT

Track: DevOps Networking — 1 Month Deep Dive Part: 1 — Networking Foundations Status: Understood and closed Concepts covered: 3 — MAC addresses (Layer 2), ARP, the complete journey end to end Builds on: Lesson 03 (the envelope stack, the missing Layer 2), Lesson 05 (the DHCP shout)

Two puzzles hiding in plain sight
The answer: every device has a second address
IP vs MAC — the difference is the point
The envelope we never drew — Layer 2
How the shout worked — the broadcast address
ARP — learning someone's MAC
The full journey, corrected
The complete story: from factory to pixels
Easy to get wrong
Old way vs improved understanding
Terms locked in
Deliberately not covered yet
Sources

Two puzzles hiding in plain sight

Puzzle 1. The DHCP shout worked before the laptop had any IP number. So whatever carried that shout through the house — it wasn't IP. Something underneath IP was doing the delivering.

Puzzle 2. The laptop sends the envelope for 140.82.121.4 — GitHub, far away. But the first hop of that journey is just: get the envelope from the laptop to the router, three metres away, through the air. The junctions-read-the-address story explains the world journey. It doesn't explain the three metres. WiFi is radio — when the laptop transmits, the waves hit every device in the house. The TV receives them. The phone receives them. Yet only the router acts. How does each device know "this is for me" or "ignore this"?

The IP address can't be the answer — the TV isn't reading IP envelopes addressed to other machines, and during the DHCP shout there were no IP numbers at all.

The answer: every device has a second address

Every piece of network hardware — the WiFi chip in a laptop, in a phone, in a TV, each socket on a router — left its factory with a permanent address burned in. It is called the MAC address, and it looks nothing like an IP:

a4:83:e7:2f:1b:9c

Six pairs, letters and digits (hexadecimal, like IPv6 from Lesson 01). Every network chip ever manufactured has a different one — the first three pairs identify the manufacturer, the rest are its serial numbering. A laptop's WiFi chip has exactly one, and keeps it for life, on every network it ever joins.

IP vs MAC — the difference is the point

	IP address	MAC address
Comes from	Assigned by the network (DHCP lease)	Burned in at the factory
Changes?	Different on every network you join	Never — same at home, at a café, forever
Meaningful	Across the whole world	Only inside the local network
Answers	where to deliver, globally	which physical chip, locally

The IP is your address in the world. The MAC is the serial number of your chip. Delivery across the world runs on IP; the final metres run on MAC.

The envelope we never drew — Layer 2

This pays the debt from the layers lesson. The envelope stack had the IP address on the outermost envelope. In truth, there is one more envelope outside even that one — and it carries MAC addresses:

OUTERMOST envelope:  to MAC a4:83:...    ← Layer 2 ← the missing layer
  outer envelope:    to 140.82.121.4     ← Layer 3
    inner envelope:  port 443            ← Layer 4
      the text:      please send me...   ← Layer 7

Layer 2 is the MAC envelope. Its official name is the Data Link layer. Every message travelling through the house is wrapped in one, addressed to a specific chip.

The every-device-hears-everything problem now solves cleanly: all the radio waves hit the TV, yes — but the TV's chip reads the MAC on the outermost envelope, sees it is not its own, and discards the message without opening anything. Chips do this filtering in hardware, ignoring almost everything they hear. Only the chip whose MAC matches opens the Layer 2 envelope and passes the contents upward.

How the shout worked — the broadcast address

There is one special MAC address meaning "every chip":

ff:ff:ff:ff:ff:ff

An envelope addressed to that is opened by everyone — that is what a broadcast literally is. The DHCP shout worked without any IP numbers because it never used IP delivery at all; it rode a Layer 2 envelope addressed to all chips.

ARP — learning someone's MAC

One gap remains. The laptop wants to send the GitHub envelope to the router. DHCP said the way out is 192.168.1.1 — an IP. But the Layer 2 envelope needs the router's MAC, and nobody ever told the laptop that.

The solution is charmingly simple — another shout. The protocol is called ARP (Address Resolution Protocol — a protocol, from Lesson 05, is just an agreed script):

Laptop, to all chips: "Who has 192.168.1.1? Tell me your MAC."

Every device hears it. The TV: not me, ignore. The phone: not me, ignore. The router: "Me — I'm a4:83:e7:2f:1b:9c."

Done. The laptop notes the answer in a little table it keeps — its ARP cache (caching, exactly as in DNS: remember answers, don't re-ask) — and can now wrap Layer 2 envelopes for the router all day. The entries expire after a while and get re-asked.

TTL thinking, third appearance: DNS answers, DHCP leases, ARP entries. Nothing stale survives.

The full journey, corrected

The complete, honest picture of sending to GitHub — watch what happens to each envelope:

laptop builds:   [MAC: router's chip [IP: 140.82.121.4 [port 443 [text]]]]
                        ↓
router receives it (MAC matches — opens Layer 2 envelope)
reads the IP envelope: 140.82.121.4 — not for me, pass it on
wraps it in a FRESH Layer 2 envelope, addressed to the next junction's chip
                        ↓
next junction: same again — open MAC envelope, read IP, new MAC envelope
                        ↓
        ...every hop, all the way to GitHub...

The insight worth keeping:

The IP envelope survives the whole journey untouched. The MAC envelope is torn off and rewritten at every single hop.

The IP answers "where is this ultimately going" — constant from laptop to GitHub. The MAC answers "which chip gets it next" — different at every step. The laptop never learned GitHub's MAC, and never could: MAC addresses mean nothing beyond the local network. It only ever needed the MAC of its next hop — the router. Each hop only ever needs the next chip.

The complete story: from factory to pixels

Everything from six lessons, stitched into one story: a laptop is manufactured, bought, and used to load github.com.

Act 0 — In the factory, months before you exist as a customer

A chip company manufactures a WiFi chip. Before it ships, it burns an address into it: a4:83:e7:2f:1b:9c. The first three pairs are the company's own manufacturer code; the last three are its serial numbering. No other chip on Earth gets this string.

A laptop company buys that chip, solders it into a laptop, boxes it. The laptop sits in a warehouse, then a shop. It has a MAC. It has no IP — an IP is not a property of a laptop; it is a property of joining a network. This laptop has joined nothing.

Act 1 — You buy it and open the lid at home

You type in the WiFi password. The laptop connects to the router's radio — but connecting is just Layer 1, waves established between chips. The laptop still has no number, no idea who to ask for DNS, no idea where the way out is. It can do nothing yet.

DHCP now runs, and it must start with a shout — because with no IP, normal addressing is impossible:

The laptop wraps a Layer 2 envelope addressed to ff:ff:ff:ff:ff:ff — every chip. Inside: "anyone, I need a number." The TV's chip opens it (broadcast — everyone opens it), sees a DHCP plea, has no DHCP program, ignores it. The phone likewise. The router's chip opens it, and the router does run a DHCP program:

Router:  I offer 192.168.1.47
Laptop:  I'll take it
Router:  Confirmed. Bundle attached:
           your number:  192.168.1.47
           DNS runner:   8.8.8.8
           way out:      192.168.1.1

Shout, offer, take, confirm. The laptop is now a citizen of the network. Elapsed time: under a second from password to citizenship.

Act 2 — You type github.com and press Enter

Chrome looks at github.com. It's a name; junctions need numbers. Two conversations coming — DNS first.

Chrome asks the DNS question to 8.8.8.8, port 53 (the well-known DNS port). But watch the first metres of that question. It must physically reach the router before anything else can happen, and a Layer 2 envelope needs the router's MAC. The bundle only said 192.168.1.1 — an IP. So, once only:

ARP shout: "Who has 192.168.1.1?" — TV ignores, phone ignores, router answers: "me, a4:83:e7:2f:1b:9c." Into the ARP cache it goes. Every future message to the router skips this step.

Now the DNS question travels, fully wrapped:

[MAC: router  [IP: 8.8.8.8  [port 53  ["what number is github.com?"]]]]

The router opens the MAC envelope (its chip matched), reads the IP — 8.8.8.8, not me — tears off the old Layer 2 envelope, wraps a fresh one addressed to the next junction's chip, and passes it on. Every junction between the house and Google's runner does the same: IP envelope untouched, MAC envelope rewritten.

At 8.8.8.8, the runner (which holds nothing, fetches everything) walks the chain — root: "ask .com" → the .com computer, run by the registry Verisign, checks its 160-million-line master list: "ask GitHub's own computer" → GitHub's authoritative computer: "github.com is 140.82.121.4, remember it for 60 seconds." Answer plus TTL travels all the way back into Chrome's hands. (Next visit within the TTL: no chain, no walk — cache.)

Act 3 — The real request

Conversation two. Chrome builds the envelope stack it wanted to build all along:

[MAC: router  [IP: 140.82.121.4  [port 443  ["please send me the homepage"]]]]

Port 443 because you typed https — that prefix is the port choice.
Router's MAC from the ARP cache — no shout needed this time.
Source details ride along too: source IP 192.168.1.47, and a temporary source port the operating system just invented — say 51862 — the return address for this specific conversation.

Off it goes. Router: open MAC envelope, read IP, fresh MAC envelope, forward. Junction after junction, wire after wire, possibly under an ocean — MAC envelopes born and torn at every hop, the IP envelope crossing the world unmodified.

Act 4 — Inside GitHub's building

The envelope arrives at the computer holding 140.82.121.4 — a computer like any laptop, minus the screen, because nobody sits in front of it. The layers unwrap in order, one reader each, exactly as the layers lesson promised:

Chip: MAC matches → open Layer 2, pass up
Computer: IP matches, journey over → open Layer 3, read the port
Port list: 443 → held by GitHub's web program — a waiter, which claimed 443 long ago and has been listening since → hand over Layer 4's contents
The program — the only thing that ever reads the text: "please send me the homepage"

It composes the answer and addresses the reply envelope using the request's source details — the return address the message carried, destination port 51862, the temporary one. That number is how, when the reply reaches the laptop, it lands in Chrome's hands and not some other program's — and in the right tab's conversation at that.

Act 5 — The pixels

The reply crosses the world the same way — its own IP envelope constant, MAC envelopes rewritten hop by hop — arrives at the laptop's chip, unwraps layer by layer, reaches Chrome via port 51862. Chrome reads the page content and paints it.

Total elapsed: a few hundred milliseconds. Two conversations, one ARP shout, two chain walks' worth of caching for next time, and several dozen MAC envelopes born and destroyed.

The two honest gaps in the story

Both already on the lesson list:

The reply's journey back into the house skips a step — the house shares one public number (Lesson 01's home-router trick). That mechanism is NAT, lesson 09.
"The junctions somehow know which way to pass it" is doing heavy lifting. That is routing, lesson 07 — next.

Easy to get wrong

MAC does not replace IP, and IP does not replace MAC. They answer different questions at different scales. Both are on every message, always.

The MAC envelope never crosses the world. It is local-only, rewritten at every hop. A laptop never learns, and could never use, the MAC of a faraway computer.

Broadcasts are Layer 2 events. The DHCP shout and the ARP shout work with zero IP numbers involved — they are addressed to all chips, not to all IPs.

Hardware filtering is why shared airwaves work. Every device physically receives everything; the chip discards non-matching MAC envelopes before the computer ever sees them. (One consequence for later: a chip can be told not to discard — that is how network monitoring tools see everyone's traffic. Parked until the tools lesson.)

The ARP cache is another cache. Same failure smell as DNS staleness: if a device's chip is replaced (new MAC, same IP), peers with the old cached entry keep addressing envelopes to a chip that no longer exists — until their entries expire.

Old way vs improved understanding

Topic	Old way of thinking	Improved understanding
Addresses	A computer has an IP address	A computer has two addresses: a world one (IP, leased) and a chip one (MAC, factory-permanent)
WiFi privacy of delivery	Messages go to the right device	Radio hits every device; chips filter by MAC in hardware and discard the rest
The envelope stack	IP is the outermost envelope	One more outside it — the Layer 2 MAC envelope, rewritten at every hop
Layer 2	The mysterious missing layer	The chip-to-chip delivery layer: MAC addresses, broadcasts, ARP
Reaching the router	Just happens	Requires its MAC — learned once by an ARP shout, cached, expiring
A message's journey	One address carries it end to end	Two-tier: IP constant across the world, MAC born and torn at every single hop

Terms locked in

MAC address — the permanent, factory-burned address of a network chip; six hex pairs; local-only meaning
Layer 2 / Data Link — the chip-to-chip delivery layer; the outermost envelope
broadcast address (ff:ff:ff:ff:ff:ff) — the MAC meaning "every chip opens this"
ARP (Address Resolution Protocol) — the shout that turns a local IP into a MAC
ARP cache — the remembered IP→MAC table, entries expiring like DNS answers
next hop — the only chip a sender ever needs the MAC of; the journey is a chain of next hops

Deliberately not covered yet

Routing — how each junction decides which way to pass the IP envelope; next lesson
NAT — how replies find their way back into a house that shares one public number; lesson 09
Chips told not to discard — network monitoring; troubleshooting tools lesson
Switches — the boxes that make wired Layer 2 delivery efficient in offices; introduced if and when needed (home WiFi doesn't require them to understand anything so far)

Sources

Topic	Source	Link
ARP specification	RFC 826	https://www.rfc-editor.org/rfc/rfc826.html
MAC address structure, manufacturer prefixes	IEEE — MAC address assignments	https://standards.ieee.org/products-programs/regauth/
Look up any MAC prefix's manufacturer	IEEE OUI public listing	https://standards-oui.ieee.org/
Readable overview of MAC vs IP	Cloudflare Learning — What is a MAC address?	https://www.cloudflare.com/learning/network-layer/what-is-a-mac-address/

Source note: RFC 826 is from 1982 and still governs — ARP is one of the oldest living pieces of the internet. The IEEE (a standards body like the IETF, but for hardware) hands out the manufacturer prefixes; their public list lets you identify the maker of any chip from the first three pairs of its MAC.

End of Lesson 06. Next: routing — how every junction on Earth knows which way to pass the envelope.

Lesson 03 — Network Models and Layers

Sat, 08 Aug 2026 00:00:00 GMT

Track: DevOps Networking — 1 Month Deep Dive Part: 1 — Networking Foundations Status: Understood and closed Concepts covered: 3 — what a layer is, the layer numbers and names, encapsulation Builds on: Lesson 01 (IP addresses), Lesson 02 (ports)

The message
Sending a message is separate jobs
What a layer is
The official numbers and names
The missing numbers
Why the numbers matter in real work
Encapsulation — envelopes inside envelopes
Why layer independence is automatic
Easy to get wrong
Old way vs improved understanding
Terms locked in
Deliberately not covered yet
Sources

The message

The running example: open Chrome on a laptop, type github.com, and the page appears.

For that page to appear, the laptop has to ask GitHub's computer for it. GitHub's computer is just a computer — like a laptop, but sitting in a big building full of computers, with no screen and no keyboard, because nobody sits in front of it.

The laptop cannot shout across the world. The only thing it can do is push a message out through the WiFi and have it travel, hop by hop, junction by junction, to that building.

Written out plainly, the message the laptop sends is roughly:

To computer: 140.82.121.4
To program: the one on port 443
Text: please send me the github.com homepage

Three lines. An address, a port, and what it wants. If you could freeze the message mid-flight and read it, that is what it says.

Sending a message is separate jobs

Getting that message to GitHub's building is not one job. Two very different jobs, to start with:

Job A — carry it. The message physically has to move: out of the laptop, through the air to the router, through wires under the street, maybe through a cable under the ocean, into that building. Something has to do the moving.

Job B — navigate it. At every junction along the path, something has to decide which way the message goes next. The address 140.82.121.4 is what gets read to make each decision.

A delivery truck moves a package (carrying); the GPS decides which turn to take (navigating). The truck doesn't know where it's going. The GPS doesn't move anything. Both are needed; neither can do the other's job.

Same with the message. The wires and WiFi carry it. The address navigates it.

What a layer is

Look at the message again, and ask: who reads each line?

Line 1 — the address. Read by every junction along the way. Each junction reads it, picks a direction, passes the message on. No junction ever reads line 2 or line 3. Not their job.

Line 2 — the port. Read by exactly one thing: the destination computer, after the message arrives. The journey is over, the message is inside the right building. Now the computer looks at the port and hands the message to the program holding it. (This is the port lesson — but notice when it happens: only at the very end, only at the destination.)

Line 3 — the text. Read only by the program. Not the computer, not the junctions, nobody along the way. The program holding port 443 receives it, reads "please send me the homepage," and acts on it.

To computer: 140.82.121.4      ← read by every junction along the way
To program: port 443           ← read by the destination computer, at arrival
Text: please send me the page  ← read by the program, at the very end

Three lines. Three different readers. Three different moments.

A layer is one line of the message plus the job of reading it.

That is the entire meaning of the word. When someone says "networking has layers," they mean exactly this: the message has parts, and different parts are read by different things at different points in the journey.

The carrying job — wires and WiFi — is a layer too: the bottom one. It touches no lines at all and just moves the whole message.

So the full stack, in plain words:

the text        ← read by the program           (top layer)
the port        ← read by the computer
the address     ← read by the junctions
the carrying    ← wires and WiFi, reads nothing (bottom layer)

One message, four layers, top to bottom.

The official numbers and names

Engineers worldwide need to talk about these layers and mean the same thing, so the layers have official names and numbers. The numbers count from the bottom up — carrying is 1:

Layer 7   the text        ← official name: Application
Layer 4   the port        ← official name: Transport
Layer 3   the address     ← official name: Network
Layer 1   the carrying    ← official name: Physical

The names, taken slowly:

Physical — the physically-carrying-it job. Wires, WiFi.
Network — the navigating job. The address, the junctions.
Transport — the port job. Named because it delivers to the right program.
Application — the text job. Named because the text is read by an application (Chrome, the Java backend).

The missing numbers

Where are 2, 5, and 6?

They exist. The numbering comes from an old master plan called the OSI model, drawn up in the late 1970s, which defined seven layers. But the internet as actually built doesn't use all seven as separate things — some collapsed into their neighbours in practice.

Layer 2 is real and gets its own later lesson (MAC addresses — it already has a file waiting).
Layers 5 and 6 can be ignored for an entire career. Their jobs got absorbed into layer 7.

Every DevOps engineer talks as if the stack is 1, 2, 3, 4, 7. People say "that's a Layer 7 problem" and skip from 4 to 7 without blinking.

Why the numbers matter in real work

The numbers are working vocabulary. In job posts, incident chats, and cloud settings, people say:

Phrase heard in real work	What it actually means
"That's a Layer 4 issue"	A port/delivery problem, not a content problem
"This load balancer works at Layer 7"	It reads the text, not just the address
"Layer 3 is fine"	The address and navigation work; look elsewhere

Each sentence instantly locates the problem in one line of the message. That is the entire power of the numbering — one number tells you which layer of the stack to look at.

Encapsulation — envelopes inside envelopes

The message has been drawn as three lines. The real arrangement is slightly different: the message is built like envelopes inside envelopes.

Watch it get built, from the inside out:

Step 1. Chrome writes the text: please send me the homepage. That is the innermost thing.

Step 2. The text goes in an envelope. On that envelope is written: port 443.

Step 3. That envelope goes inside a bigger envelope. On the bigger one is written: 140.82.121.4.

Step 4. The whole thing goes onto the wire and gets carried.

outer envelope:  140.82.121.4
   inner envelope:  port 443
      the text:  please send me the homepage

Now follow the journey, and watch each stage open exactly one envelope:

At every junction — the junction sees only the outer envelope: an address. It reads it, picks a direction, passes it on. It never opens anything. It cannot see the port or the text — not hidden by rules, but genuinely not visible, because they are inside.

At GitHub's computer — the address on the outer envelope matches. Journey over. The computer opens the outer envelope and finds the inner one: port 443. It hands that inner envelope to the program holding 443.

At the program — the program opens the inner envelope and finds the text. Reads it. Acts on it.

junction:  reads outer envelope   →  never opens anything
computer:  opens outer envelope   →  finds the port
program:   opens inner envelope   →  finds the text

The official word for this is encapsulation — each layer's information wraps around the layer above it. Building the message (on the laptop) adds envelopes from the inside out. Receiving it (at GitHub) opens them from the outside in.

Why layer independence is automatic

The claim at the start of the lesson: each layer does only its own job and ignores the rest, so any layer can be changed without touching the others. Swap WiFi for a cable — layer 1 changed completely, and layers 3, 4, 7 never notice.

Encapsulation is why this is true. A junction cannot misdeliver based on the text, and the carrying layer cannot care what the message says, because each stage literally cannot see beyond its own envelope.

The independence of the layers is not a rule that someone enforces. It falls straight out of how the envelopes nest.

Easy to get wrong

The numbers count from the bottom. Layer 1 is the wire, not the application. Getting this backwards makes every "Layer X" sentence mean its opposite.

The gap from 4 to 7 is normal. Hearing people skip layers 5 and 6 is not a mistake or missing knowledge — it is how the field actually talks. The internet in practice collapsed those layers into 7.

Junctions never read the port. The port is only read at the destination, after the journey is over. Everything along the way navigates by address alone. (One refinement to this arrives in a later lesson — some in-between machines can open more envelopes than a plain junction. Noted here so the future lesson does not feel like a contradiction.)

"Machine," "computer," "server" — same thing in this track. A server is just a computer in a building with no screen attached, because nobody sits in front of it.

The OSI model is a vocabulary, not a machine. Nothing in a real network "runs" the OSI model. It is a shared way of naming the jobs so engineers can point at the right one.

Old way vs improved understanding

Topic	Old way of thinking	Improved understanding
"Layers"	An abstract diagram memorised for exams, seven boxes with strange names	One message, several lines, each line read by a different thing at a different moment
The OSI model	Something a network is built out of	A naming scheme — vocabulary for pointing at the right job
Layer numbers	Trivia	A precise way of locating a problem: "Layer 4 issue" = look at the port line
Layers 5 and 6	Presumably important, must learn eventually	Absorbed into 7 in the real internet; safely ignored
Why layers are independent	A design rule someone follows	Automatic — each stage physically cannot see inside the envelopes beyond its own
A message	An abstract "chunk of data"	Envelopes inside envelopes: address outside, port inside that, text innermost

Terms locked in

layer — one line of the message plus the job of reading it
Layer 1 / Physical — the carrying: wires, WiFi
Layer 3 / Network — the address, read by junctions to navigate
Layer 4 / Transport — the port, read by the destination computer
Layer 7 / Application — the text, read by the program
OSI model — the 1970s seven-layer plan the numbering comes from
encapsulation — each layer's information wrapping around the layer above; envelopes inside envelopes
server — a computer in a building with no screen, because nobody sits in front of it

Deliberately not covered yet

Layer 2 / MAC addresses — real, has its own lesson file waiting
What the text actually looks like — the exact format of "please send me the homepage" is HTTP, lesson 11
The machines that open more envelopes than a junction — load balancers and proxies, Part 5
How the laptop learned GitHub's address in the first place — DNS, next lesson
TCP/IP model vs OSI model naming differences — deferred until TCP itself is covered, where it makes sense

Sources

Topic	Source	Link
The OSI seven-layer model, original standard	ISO/IEC 7498-1	https://www.iso.org/standard/20269.html
The internet's own layer model (four layers, not seven)	RFC 1122	https://www.rfc-editor.org/rfc/rfc1122.html
Beginner-friendly layer overview	Cloudflare Learning — What is the OSI model?	https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/

Source note: the ISO standard is paywalled (standards bodies charge for documents — unlike RFCs, which are free). RFC 1122 is the free, authoritative description of how the internet actually layers things. The Cloudflare page is a readable secondary source.

End of Lesson 03. Next: DNS — how the laptop learned GitHub's address in the first place.

Lesson 01 — What Networking Means in DevOps, and IP Addresses

Sat, 08 Aug 2026 00:00:00 GMT

Track: DevOps Networking — 1 Month Deep Dive Part: 1 — Networking Foundations Status: Understood and closed Concepts covered: 2 — networking in DevOps, IP address

Concept 1 — What networking means in DevOps
Concept 2 — IP address
Questions raised in this lesson
Easy to get wrong
Old way vs improved understanding
Terms locked in
Deliberately not covered yet
Sources

Concept 1 — What networking means in DevOps

The starting point

Take one computer running one program. Inside that program, when part A needs something from part B, it just calls it. Instantly. Nothing to configure. Nothing to break.

Now take that same program and split it into pieces, each running on a different machine:

web piece    →    backend piece    →    database piece
(machine 1)       (machine 2)           (machine 3)

Nothing about the code changed. But now, when the web piece wants something from the backend piece, it can no longer just "call" it. It has to send that request out of machine 1, across a wire, and into machine 2.

That sending is networking.

Definition

Networking is how one machine reaches another machine and gets an answer back.

Why this becomes a DevOps concern

The arrow between machine 1 and machine 2 does not exist by default. Somebody has to make it exist. Somebody has to decide:

which machine is allowed to talk to which,
at what address,
through which door.

When that arrow is missing or pointed at the wrong place, the application looks perfectly healthy — the process is running, the logs are clean — and users still get an error.

What problem it solves

Modern applications are spread across many machines. Most production failures in that world are not broken code. They are broken arrows. Networking knowledge is what turns "it's broken" into "the traffic dies between point X and point Y."

Where it sits

Everything in this track lives on one line:

user → DNS → load balancer → proxy/ingress → service → container → app

Every future topic is one hop on this line. Learn the hops one at a time, and eventually you can trace a request end to end.

Concept 2 — IP address

The problem it solves

Machine 1 needs to send a request to machine 2. But a network has many machines on it — ten, a thousand, a million. So the network needs a way to tell them apart.

The solution

Give every machine a number.

That number is the IP address. It looks like this:

10.0.1.57

Four numbers separated by dots. Every machine on the network has one, and no two machines on the same network share the same one.

How it is used

When machine 1 sends its request, it writes the destination number on it before sending:

machine 1  ──[ deliver this to 10.0.1.57 ]──►  machine 2

The network reads that number and carries the request to the machine holding it.

Definition

An IP address identifies one machine on a network.

Example from everyday experience

Connect a laptop to home WiFi and it gets one of these numbers automatically. The phone gets a different one. The TV gets another. Same network, three machines, three different numbers — so the router can tell them apart when data comes in.

What breaks without it

Machine 1 has a request ready and no way to say where it should go. Nothing can be delivered.

Questions raised in this lesson

Who decides this number?

Two different answers, depending on which network is meant.

Inside a private network (home WiFi, an office): the router hands out the numbers automatically. It keeps a small list and assigns one to each device that connects. Nobody outside is involved.

On the internet: the numbers cannot be handed out casually, because if two machines anywhere in the world had the same number, delivery would break. So there is one global organisation that holds the whole pool of numbers — IANA (Internet Assigned Numbers Authority). IANA does not give numbers to individuals. It gives large blocks to five regional organisations, called Regional Internet Registries (RIRs), and those give smaller blocks to the companies that provide internet connections, who then give one to each customer connection.

The chain looks like this:

IANA (global pool)
   ↓
5 Regional Internet Registries
   ↓
internet service providers
   ↓
you

The five RIRs cover Asia-Pacific (APNIC), Europe and the Middle East (RIPE NCC), North America (ARIN), Latin America and the Caribbean (LACNIC), and Africa (AFRINIC).

Who sets the ranges?

The ranges come from published technical standards, not from a company decision.

The reserved private ranges — the ones a home router or an internal company network uses — are defined in a standards document called RFC 1918, published in 1996. It reserves exactly three blocks:

10.0.0.0     – 10.255.255.255
172.16.0.0   – 172.31.255.255
192.168.0.0  – 192.168.255.255

Two important details from the standard itself:

An organisation can use these addresses without asking IANA or any registry for permission. They are free for anyone to use internally.
Addresses in these ranges are only unique inside one organisation. They are not routable on the public internet, and internet providers' routers are expected to filter them out.

How many IP addresses exist in the world?

This is calculable. Four slots, each holding a value from 0 to 255. That is 256 possibilities per slot:

256 × 256 × 256 × 256 = 4,294,967,296

Roughly 4.3 billion addresses. That is the entire supply of this address format.

In the standards this is described as a 32-bit address — 32 binary digits, producing 2³² combinations, the same number.

Can it finish? What happens if it finishes?

It already finished.

4.3 billion sounded infinite when the format was designed in the early 1980s, when only universities, research organisations and government agencies were connected. Then came home computers, then phones, then every laptop, tablet, camera, TV and machine in every data centre on Earth — most people now consume several addresses at once.

The global pool was emptied on 3 February 2011. IANA handed its final five blocks to the five regional registries in one ceremony, triggered by an agreed global policy, and after that there were no fresh addresses left at the top level.

The regional pools then drained over the following years, each at its own pace:

Region	Registry	Pool exhausted
Asia-Pacific	APNIC	15 April 2011
Latin America / Caribbean	LACNIC	10 June 2014
North America	ARIN	24 September 2015
Africa	AFRINIC	21 April 2017
Europe / Middle East	RIPE NCC	25 November 2019

What happened when it ran out: nothing dramatic. The internet did not stop, for one reason — most machines do not need a globally unique number.

Go back to the home WiFi example. Laptop, phone and TV each had their own number, but those numbers are only meaningful inside the house. The whole home shares one internet-facing number, and the router translates in both directions. So one global address can cover a household, an office, or thousands of machines.

That trick bought the internet an extra fifteen-plus years. It is a workaround, not a fix — and it is the reason the real solution exists.

What exists today instead of fresh addresses: a resale market. Organisations buy unused blocks from each other through the registries' transfer process. Roughly 29.7 million addresses changed hands in the first half of 2026 alone, at a published-price average of about $20 per address. Prices peaked far higher around 2021–22 and have fallen since.

What is the difference between IPv4 and IPv6?

Everything above describes IPv4 — version 4, the four-numbers-with-dots format, 32 bits, ~4.3 billion addresses.

IPv6 is version 6, designed specifically to end the shortage. Instead of 32 bits it uses 128 bits, written like this:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

Eight groups separated by colons, using hexadecimal (digits 0–9 plus letters a–f). The supply it produces is around 340 undecillion — a number with 39 digits. It will not run out.

	IPv4	IPv6
Address size	32 bits	128 bits
Written as	`10.0.1.57`	`2001:db8::7334`
Separator	dots	colons
Total supply	~4.3 billion	~340 undecillion
Supply status	exhausted since 2011	effectively unlimited
Current spec	RFC 791	RFC 8200

The detail that matters most: the two are not compatible. An IPv6-only machine cannot talk to an IPv4-only machine directly. That means the world cannot simply switch over — every network has to support both during the transition. This is exactly why IPv6 has been "coming" since its first specification in December 1998 and is only now reaching majority use.

Current adoption: IPv6 crossed 50% of Google's measured traffic for the first time on 28 March 2026 (50.10%), up from 46.33% a year earlier. So in practice: expect IPv4 daily, but IPv6 is no longer a minority protocol.

Who decided the IPv6 pattern, and what kind of people are involved?

IPv6 was designed by the IETF — the Internet Engineering Task Force.

It is not a company. It is not owned by anyone. There is no CEO, no shareholders, and no government controls it.

Who participates: it is an open group of engineers, and anyone can join. There is no membership fee and no application process. The IETF's own documents state plainly that it is not a membership organisation — there are no "members," only "participants," and this is precisely why they cannot hold votes: it would be impossible to determine who was entitled to vote. Most participants work at companies that depend on the internet functioning (network equipment vendors, internet providers, large software companies, universities), but they participate as individual engineers.

How a decision is actually made:

Someone writes a proposal and publishes it for anyone to read and attack. Others tear it apart, argue, and propose alternatives. This happens on public mailing lists and at meetings held three times a year. Every discussion is public and archived — the arguments people had about IPv6 in the 1990s are still readable today.

Two things make this group unusual:

There is no vote. Decisions are made by rough consensus — not everyone agreeing, but no one holding an objection serious enough to stand. Their founding principle, stated in a 1992 talk and quoted in their own standards documents, is: reject kings, presidents and voting; believe in rough consensus and running code. Critically, the documented rule is that an objection has to be genuinely considered and technically answered — a group cannot simply dismiss it because more people disagree. A single engineer with a valid technical objection can hold up a proposal backed by a large company.
Running code beats theory. A design is not accepted because it looks good on paper. Practical implementation experience outweighs theoretical elegance.

If a proposal survives all of that, it is published as an RFC — a numbered public document that becomes the official specification. These are free, public and permanent. Anyone can read them.

Why IPv6 looks the way it does:

The specific decisions came out of arguments over trade-offs. The address length is the clearest example. Once the group accepted IPv4 was running out, the obvious question was how much bigger to go. Some argued for a modest increase — easier to transition, less data attached to every request. Others argued that if you are going to force the entire world through a painful upgrade, you do it once and never again.

The second group won. The address was made deliberately, almost absurdly larger than needed, so the question would never return. The colon-separated hexadecimal format exists because writing an address that long in the old four-number decimal style would be unreadable.

The competing proposals and the reasons they lost are all in the public archives.

Easy to get wrong

Traps in this topic worth remembering.

The private range in the middle is not all of 172. It is 172.16 through 172.31 only. 172.32.x.x is a public address. Filtering or firewalling 172.x.x.x as a whole is a real and common mistake.

"Exhausted" does not mean "unavailable." IPv4 addresses still get allocated every day — through resale and recovery, not from a fresh pool. The distinction matters when reading announcements: "IANA's pool is empty" and "you cannot get an IPv4 address" are different statements.

Private addresses are not a security feature by themselves. They are unreachable from the internet because no router will carry them, not because something is actively blocking traffic. That distinction matters later when access control comes up.

A machine can hold more than one address. Nothing in the definition says one machine has exactly one IP. This becomes important with containers and cloud instances.

Old way vs improved understanding

Topic	Old way of thinking	Improved understanding
What networking is	Cables, WiFi, "the internet" — infrastructure someone else handles	The deliberate creation and control of paths between machines; a core part of the DevOps job
Why apps break	The code must be wrong	Most failures are reachability failures; the app can be perfectly healthy and still unreachable
IP address	A technical string that appears in configs	A machine's identity on a network; the answer to "which machine?"
Who runs it	Some company or government owns the internet's addressing	A layered chain of non-profit registries (IANA → 5 RIRs → providers), with the technical rules set by an open engineering group with no owner
Address supply	Unlimited, like a serial number	A finite, exhausted resource with a resale market attached
IPv6	A newer version, nice-to-have, always "coming soon"	The actual fix for exhaustion, incompatible with IPv4 by design, and as of March 2026 carrying the majority of Google's traffic
How standards are decided	A committee votes, or a big company decides	Public argument, rough consensus, no voting, and objections must be technically answered rather than outnumbered

Terms locked in

Terms now known and usable freely going forward:

network — the set of paths that let machines reach each other
IP address — the number identifying one machine on a network
IPv4 — the 32-bit, four-numbers-with-dots format
IPv6 — the 128-bit, colon-separated hexadecimal format
private address range — the RFC 1918 blocks, usable internally by anyone, not routable on the internet
IANA — the global holder of the address pool
RIR — one of the five regional registries that distribute addresses
IETF — the open engineering group that writes internet standards
RFC — a numbered, public, permanent standards document

Deliberately not covered yet

Recorded so future lessons do not silently assume them:

ports
DNS
routing
TCP / UDP
HTTP / HTTPS / TLS
subnets and CIDR notation (/8, /24)
NAT — the translation mechanism referenced above, not yet explained
firewalls
AWS, Docker, Kubernetes, proxies, load balancers, ingress

Sources

Every factual claim above can be verified here.

Primary standards documents

Topic	Document	Link
IPv4 specification	RFC 791	https://www.rfc-editor.org/rfc/rfc791.html
Private address ranges	RFC 1918 (1996)	https://www.rfc-editor.org/rfc/rfc1918.html
IPv6, current specification	RFC 8200 (2017)	https://www.rfc-editor.org/rfc/rfc8200.html
IPv6, original specification	RFC 2460 (Dec 1998)	https://datatracker.ietf.org/doc/html/rfc2460
How the IETF decides — rough consensus, no voting	RFC 7282	https://www.rfc-editor.org/rfc/rfc7282
Internet standards process	RFC 2026	https://www.rfc-editor.org/rfc/rfc2026.html

Address exhaustion

Claim	Source	Link
Global IPv4 pool depleted 3 Feb 2011	Number Resource Organization announcement	https://www.nro.net/ipv4-free-pool-depleted/
Same event, registry record	ARIN announcement archive	https://www.arin.net/vault/announcements/20110203/
Per-region exhaustion dates	Wikipedia — secondary, cites the registry announcements	https://en.wikipedia.org/wiki/IPv4_address_exhaustion
Private ranges are not publicly routable	ARIN reference page	https://www.arin.net/reference/research/statistics/address_filters/

IPv6 adoption

Claim	Source	Link
Live adoption measurement	Google IPv6 Statistics	https://www.google.com/intl/en/ipv6/statistics.html
Crossed 50% on 28 March 2026	Internet Society Pulse	https://pulse.internetsociety.org/en/blog/2026/04/18-years-later-ipv6-reaches-majority/
Independent confirmation and regional context	APNIC Blog	https://blog.apnic.net/2026/04/28/google-hits-50-ipv6/

IPv4 resale market — indicative only

Claim	Source	Link
29.7M addresses transferred H1 2026, ~$20/address average	IPregistry market analysis	https://ipregistry.co/blog/ipv4-market-mid-2026/
Price history and 2021–22 peak	Market commentary	https://ipbnb.com/blog/ipv4-address-price-2026

Source note: the RFC and registry links are authoritative primary sources. The resale-market links are commercial brokers and analysts — useful for order of magnitude, not precise figures.

End of Lesson 01. Next: ports.

Lesson 02 — Ports

Sat, 08 Aug 2026 00:00:00 GMT

Track: DevOps Networking — 1 Month Deep Dive Part: 1 — Networking Foundations Status: Understood and closed Concepts covered: 1 — ports Builds on: Lesson 01 (networking, IP addresses)

The problem ports solve
What a port is
Claiming a port
One program per port
The port range and the permission rule
Which programs have ports
Who sets a program's port
Open and closed
The source port
Walkthrough: what happens when you visit a website
Questions raised in this lesson
The running project
Easy to get wrong
Old way vs improved understanding
Terms locked in
Deliberately not covered yet
Sources

The problem ports solve

From Lesson 01: an IP address identifies one machine on a network.

But a machine is not running one thing. A single machine might be running a React frontend, a Java backend, and a PostgreSQL database all at the same time.

So a request arrives at the machine — and then what? Which of those three programs is it for?

The IP address cannot answer that. It only answers "which machine."

What a port is

The machine needs a second number. Not to identify itself, but to identify which program on it the request is meant for.

That second number is the port.

It is written after the address, separated by a colon:

10.0.1.10:8080

Read it as two separate pieces of information:

10.0.1.10      →  which machine
     8080      →  which program on that machine

The IP finds the machine. The port finds the program on it.

Claiming a port

When a program starts up, it picks a port number and tells the machine: anything that arrives for this number, give it to me.

That is what the word listening means. It appears constantly in startup logs:

Tomcat started on port 8080
Local: http://localhost:3000

Those lines mean the program has claimed that port. From then on, any request arriving at that machine carrying that number gets handed to that program, and nothing else.

That output is also how you find out what port a program took — the program tells you when it starts.

One program per port

Only one program can hold a given port on a machine at a time.

If a program is already listening on 8080 and a second program tries to claim it, the second one fails to start:

Error: listen EADDRINUSE: address already in use :::8080

That message means exactly one thing: something else already holds that port. Not a code problem. Not a permissions problem. Another program got there first.

Who gets the port? Whoever claimed it first. There is no queue and no priority — first come, first served.

The port range and the permission rule

Ports run from 0 to 65535. They split into two groups that behave differently:

Range	Name	Behaviour
0 – 1023	well-known ports	Protected. Admin permission required to claim one.
1024 – 65535	everything else	Free. Any program can claim any of these.

The rule is simply: low numbers are protected, high numbers are free.

Some well-known ports worth recognising:

22    SSH
53    DNS
80    HTTP
443   HTTPS
5432  PostgreSQL

These are agreed globally, which is why every piece of software on Earth treats 443 as HTTPS.

Attempting to claim a protected port without permission produces a different error from the one above:

Error: listen EACCES: permission denied 0.0.0.0:443

Two distinct failures, easily confused:

Error	Meaning
`EADDRINUSE`	The port is already taken by another program
`EACCES`	You lack permission to use this port

The reason the low ports are protected involves servers and HTTPS, neither of which has been covered yet. It is deferred to a later lesson rather than half-explained here.

Which programs have ports

Not every installed program has a port. Only programs that wait to be contacted do.

There are two kinds of program:

Waiters — they sit there doing nothing until something contacts them. They need a port, because that is how anything reaches them.

Askers — they go out and request things from elsewhere. They are not waiting for anyone, so they need no port to be reached at.

Program	Claims a port?	Why
PostgreSQL	Yes	Waits for programs to connect to it
A running Spring Boot app	Yes	Waits for requests
React dev server	Yes	Waits for the browser
Chrome	No	Sends requests, does not wait for them
VS Code, Photoshop	No	Same — they ask, they do not wait

Chrome is the clarifying case. It sends requests constantly but never sits waiting to receive one, so it claims no port to listen on. Most applications on a laptop are like this.

Who sets a program's port

The software ships with a default. Install PostgreSQL, start it, and it takes 5432. Create a React app, run it, and it takes 3000. Nothing was configured — that number came with the software, chosen by whoever built it.

You can override it. For a Spring Boot app that is a line in its config file:

server.port=9000

Now it claims 9000 instead of 8080.

So: the default comes with the software, and it is overridable but rarely needs overriding.

Who decided these defaults? Two different situations:

Low ports are officially registered. 443 for HTTPS, 22 for SSH, 5432 for PostgreSQL. These are recorded in a registry maintained by IANA — the same organisation from Lesson 01 that holds the global IP address pool. That registration is why the meaning is universal.
High ports are just convention. 3000 for React, 8080 for Spring Boot, 5173 for Vite. Nobody registered these. A tool's authors picked a free number above 1023 and other people copied it.

Why development tools all use odd high numbers: because of the permission rule. A tool that defaulted to port 80 would require admin permission every single time it started. Defaulting to 3000 or 8080 means it just runs.

Open and closed

A port is open when a program has claimed it and is listening. It is closed when nothing has claimed it.

10.0.1.10  port 3000   open     ← React frontend is listening
10.0.1.10  port 8080   open     ← Java backend is listening
10.0.1.10  port 5432   open     ← PostgreSQL is listening
10.0.1.10  port 9999   closed   ← nothing has claimed it

Port 9999 is not blocked or protected. It is simply empty. A request arriving there has no recipient and is refused immediately.

Why this matters in practice: "closed port" and "the app is down" produce the same symptom. If the Java backend crashes, it stops listening, port 8080 becomes closed, and requests start failing — even though the machine itself is perfectly healthy and still answering on 3000 and 5432.

There is a second reason a port can appear closed, where something actively blocks traffic even though a program is listening. That belongs to a later topic. For now, closed means nothing is listening.

The source port

Everything above concerns the destination port. But every request carries two ports.

When the Java backend opens a connection to PostgreSQL, the operating system also assigns the backend a temporary port of its own, picked automatically from the high range:

from  10.0.1.10:51847   ←  temporary, assigned automatically
to    10.0.1.10:5432    ←  PostgreSQL, chosen deliberately

First reason it exists: PostgreSQL has to send an answer back. It cannot reply to port 5432 — that is its own port. It needs a return address, and 51847 is it.

Second reason, and the more important one: suppose the Java backend opens three database connections at once. All three go to the same destination. When three answers come back, what distinguishes them?

from 10.0.1.10:51847  →  to 10.0.1.10:5432
from 10.0.1.10:51848  →  to 10.0.1.10:5432
from 10.0.1.10:51849  →  to 10.0.1.10:5432

The source ports. Each connection gets a different one, so each reply lands in the right place. Without them, simultaneous requests to the same destination would be indistinguishable.

	Destination port	Source port
Chosen by	You / the software's default	The operating system
Value	Fixed and known in advance	Different for every connection
Lifetime	Held as long as the program runs	Discarded when the connection ends

Walkthrough: what happens when you visit a website

Typing this into a browser:

https://github.com

1. Chrome needs GitHub's IP address. It gets one — say 140.82.121.4. (How it gets that number is the next topic.)

2. Chrome needs a port. None was typed. But https at the front tells Chrome which to use: 443. That is what https means to Chrome — use port 443.

3. Chrome now has a complete destination and builds the thing it is sending — a chunk of data with the destination on the front of it:

destination IP:    140.82.121.4
destination port:  443
content:           give me the homepage

That whole chunk is "the request." The first two lines are the label on it.

4. It travels across the network and arrives at machine 140.82.121.4.

5. The machine reads the label, sees 443, and checks its own list of which programs hold which ports:

port 22    → held by nothing
port 443   → held by GitHub's web program
port 5432  → held by nothing

443 is held by the web program, so the machine hands the chunk to it.

So "a request arrives marked :443" means: a chunk of data showed up, and the number written on its label was 443.

Questions raised in this lesson

If all three programs run on one machine, do they share an IP but have different ports?

Yes. One machine has one address. All three programs share that single address, and each claims its own port:

10.0.1.10:3000   →  React frontend
10.0.1.10:8080   →  Java backend
10.0.1.10:5432   →  PostgreSQL

Same machine number every time. Only the port changes.

This is different from running the three programs on three separate machines, where each would have its own IP and its own port:

10.0.1.10:3000   →  React frontend      (machine 1)
10.0.1.20:8080   →  Java backend        (machine 2)
10.0.1.30:5432   →  PostgreSQL          (machine 3)

Both arrangements are real and both work. The rule does not change between them: the port always answers "which program," never "which machine."

With `https://api.github.com`, does the request still reach the homepage?

No.

The port does not change. https still means 443, regardless of what name follows it.

The machine changes. github.com and api.github.com are different names, so they resolve to different IP addresses:

github.com       →  140.82.121.4:443
api.github.com   →  140.82.121.6:443

Same port, different machine. The request never arrives at the machine serving the homepage — it goes elsewhere entirely. That other machine has its own program holding its own port 443, serving API responses instead of web pages.

Two different buildings, both with a room numbered 443, doing different work inside.

(How the request specifies "the homepage" versus a particular piece of data lives inside the content portion of the chunk. That is HTTP, a later topic. At the port level: https fixes the port, the name determines the machine.)

What happens if a React app is overridden from port 3000 to 443 locally?

It fails to start:

Error: listen EACCES: permission denied 0.0.0.0:443

443 is below 1024, and npm start runs as a normal user, not an admin. The system refuses before anything else happens.

Could it be forced? Yes, by running it as an administrator. That is a bad idea — it grants a development server administrator rights over the whole machine to gain nothing, since the browser reaches localhost:3000 perfectly well.

The practical answer: leave it on 3000. The port 443 problem only appears on a real deployment, and by then something else is handling 443 in front of the app. That something else is the reverse proxy from the traffic line in Lesson 01 — a later topic.

The running project

From this lesson onward, one example app is carried through the whole track:

Tier	What it is	Port
Frontend	React app	3000
Backend	Java Spring Boot API	8080
Database	PostgreSQL	5432

Current state — one machine, three programs, three ports:

Machine 10.0.1.10
  ├── port 3000  →  React frontend
  ├── port 8080  →  Java backend
  └── port 5432  →  PostgreSQL

This shape gets rebuilt at every level of the track — as containers, then as pods, then on cloud infrastructure — so the same app can be compared across all of them.

Easy to get wrong

EADDRINUSE and EACCES are different problems. The first means the port is taken; something else must be stopped or a different port chosen. The second means the port is protected; permission is the issue, not availability. Fixing one when you have the other wastes a lot of time.

A closed port and a crashed app look identical from outside. Both produce a refused connection. The port being closed is the symptom; the program having stopped is usually the cause.

"Port" does not mean "machine." A port number alone is meaningless — port 8080 exists on every machine in the world simultaneously. Only IP:port identifies something specific.

Not everything has a port. Only programs that wait to be contacted. This is the fastest way to reason about whether something needs one.

The port number carries no authority. A machine hands data to whichever program holds the number, without checking whether it is the correct program.

Old way vs improved understanding

Topic	Old way of thinking	Improved understanding
`localhost:3000`	A magic string that makes the app appear	Two facts joined by a colon — this machine, and the program holding port 3000 on it
Ports	Something to do with security or firewalls	An addressing mechanism: which program on this machine
Why React uses 3000	An arbitrary choice, or something React requires	A free number above 1023, chosen so the tool starts without admin permission
Port already in use	A confusing error	Precise information: another program claimed it first
A program having a port	Something all software has	Only programs that wait to be contacted
Where ports come from	You configure them	The software ships with a default; overriding is possible but rarely needed
A request	An abstract event	A chunk of data with a destination IP and port written on the front of it

Terms locked in

port — the number identifying which program on a machine a request is for
listening — a program holding a port and waiting for requests on it
open port — a port a program has claimed
closed port — a port nothing has claimed
well-known ports — 0 to 1023, protected, admin permission required
default port — the port a piece of software claims unless told otherwise
source port — the temporary port the operating system assigns to the sender, used as a return address
destination port — the port being sent to, chosen deliberately
EADDRINUSE — the port is already taken
EACCES — permission denied for this port

Deliberately not covered yet

Why low ports are protected — needs servers and HTTPS first
DNS — how a name becomes an IP address (next lesson)
HTTP — what is inside the content portion of a request
TCP / UDP — how a connection is actually established and maintained
firewalls — the other reason a port can appear closed
reverse proxies — what handles port 443 in a real deployment
routing, TLS, subnets, NAT
AWS, Docker, Kubernetes, load balancers, ingress

Sources

Topic	Source	Link
Official port number registry	IANA Service Name and Transport Protocol Port Number Registry	https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
Port ranges and their categories	RFC 6335	https://www.rfc-editor.org/rfc/rfc6335.html
TCP, where port numbers are defined	RFC 9293	https://www.rfc-editor.org/rfc/rfc9293.html

Note on the permission rule: the 0–1023 restriction is an operating system convention on Unix-like systems, not something defined in an internet standard. It is documented in system manuals rather than an RFC.

End of Lesson 02. Next: DNS.

Bishwas Adhikari

Lesson 07 — Routing

Table of contents

The last "somehow"

Junction = router

The router's one question

The decision starts at your laptop

Inside the router — the table

The default route, and the ladder of defaults

The top of the ladder — where routers must know

Who writes a million lines?

Where this appears in real work

Easy to get wrong

Old way vs improved understanding

Terms locked in

Deliberately not covered yet

Sources

Lesson 05 — DHCP

Table of contents

The mystery this lesson solves

The full name, word by word

The problem DHCP solves

How it works — the four-line conversation

The bundle

The number is borrowed, not given — leases

The one place DHCP is the wrong tool

Easy to get wrong

Old way vs improved understanding

Terms locked in

Deliberately not covered yet

Sources

Lesson 04 — DNS

Table of contents

The cheat we finally remove

The problem DNS solves

Why not just use numbers directly?

Who answers the question?

Which computer does the laptop ask?

How the answering computer finds out — the chain

Why a chain instead of one big list?

Why 8.8.8.8, and who else does this job

8.8.8.8 does NOT have all the info

Why those digits?

Who else does this job?

Remembering answers — caching

The problem remembering creates

The fix — TTL

Why "it works for me but not for him"

The complete picture

Questions raised in this lesson

How does "asking another computer" actually work?

Why is it 8.8.8.8? Does it have all the info? Is it the only one?

Follow-up questions: who owns names, endings, and the whole system

First, the right word: extension = TLD

Who owns domain names and endings?

Where does GoDaddy fit? Why can it sell domains?

Can I create my own TLD?

Why does ICANN take the money? Why so expensive?

What does "top of the chain" mean?

What does the root actually look like?

How does the root file reach the public? How do registrars "get" TLDs?

How do we know if something is a TLD or not?

What does Verisign's master list look like?

How does the availability check work?

What happens if I miss my renewal date?

Country endings: .in, .np — and why .com.np instead of .np

Who maintains .com.np, and why was mine free?

.gov and .edu

New terms from this section

Sources for this section

Easy to get wrong

Old way vs improved understanding

Terms locked in

Deliberately not covered yet

Sources

Lesson 06 — MAC Addresses and ARP

Table of contents

Two puzzles hiding in plain sight

The answer: every device has a second address

IP vs MAC — the difference is the point