From an address to a page

Before you read another line, do this. It takes two minutes and it won't work afterwards.

Four researchers, in work published in 2015, asked twenty-eight people to do exactly that, with paper and a pen, and then talk through what they had drawn.¹ Seventeen were ordinary users and eleven had technical training.

Fourteen of the twenty-eight drew a single box. You send a request in, an answer comes back, and there is nothing in between. Thirteen of those fourteen were the ordinary users.

That picture isn't stupid. It's a perfectly reasonable summary of what you can see. The trouble is what it can't hold: the people with layered pictures named about four parties who could see their data, and the single-box people named about two and a half, and the authors' explanation is the sentence this lesson exists for.

You can't worry about something your picture doesn't contain.

So this lesson is about putting the parties into your picture. Not because worry is good, but because in lesson 1 you wrote a security plan, and a plan can only defend against threats you can name.

The ladder, top down

Start where you already are. This lesson works downwards, from the thing you did to the machinery underneath, rather than upwards from cables and signals, because the top of that ladder is the only end you've ever touched. So: you type wikipedia.org and press return.

One. The name has to become an address. wikipedia.org is a name for humans. The machinery underneath works on numeric addresses, so something has to translate, and that something is the Domain Name System, DNS. Your machine asks a name server, and the answer comes back as an address. That is a round trip of its own, and it is finished before step two starts. Nothing below is guided by the name server on the way; it hands over an address and drops out.

Two. A connection is opened to that address. Your request leaves your machine, goes to your router, goes to your internet provider, and from there crosses some number of other networks until it reaches a machine that answers to that address. You did not choose the route in between, and for most of its length neither did the far end, although a large service does choose which networks it buys from and where it puts its copies.

Three. A request is sent and a response comes back. Your browser asks for a particular page. The far end replies with the page, or with an error code saying why not.

Four. And then it happens again, dozens of times. The page you asked for is a skeleton. It names images, fonts, scripts, advertising, analytics, and each of those is a fresh trip, often to a different company. A single ordinary page can touch a dozen organisations, most of which you've never heard of and none of which you asked for.

Notice how little of that is what you think of as "the website".

Who is actually in the path

The same journey, drawn as a list of parties, because the parties are the part that matters for the rest of the course.

Seven parties, and you have a relationship with exactly one of them.

Lesson 8 takes this same picture and marks which parts are hidden from whom, which is a different question and is the one people usually mean when they ask whether something is private.

Why a failure looks like something else

The mechanism worth carrying away is not a diagram of seven boxes. It's a division of labour.

Each step knows only its own job and trusts the one below it to deliver. The name lookup doesn't know what a page is. The connection doesn't know what a name is. The browser doesn't know which cables the response came over.

That's why the system works at scale: nobody has to understand the whole of it, and any part can be replaced without telling the others. And it is why a failure at one step produces a symptom at another that looks unrelated. A name that will not resolve and a server that is down both show you a browser page saying it could not reach the site. The browser is reporting the only thing it can see, which is that nothing came back.

So the way to diagnose anything on a network is to walk the ladder and ask, at each rung, did this step work? That is what the next two commands are for.

Two commands, on your own machine

You have a terminal now, and you know how to read what comes back from a command. Here are the two worth knowing.

Name to address

dig asks the name system a question and shows you the answer.

$ dig +short wikipedia.org
208.80.153.224

That's the short form. The long form, dig wikipedia.org, prints considerably more, and three parts of it are worth finding:

;; ANSWER SECTION:
wikipedia.org.		145	IN	A	208.80.153.224

;; Query time: 27 msec
;; SERVER: 192.168.4.1#53

The answer section has the address. The number beside it, 145 here, is a time to live: how many seconds this answer may be kept before it has to be asked for again.

That number is the one worth watching, because it's the only place in the output where you can see a cache with your own eyes. Run the same lookup again half a minute later and it will have gone down rather than started over. Run it seven times in ten seconds and you can watch it count. On the machine this lesson was written on it read 107, 99, 97, 95, 93, 90.² Nothing about the name changed in those ten seconds. What you are watching is one kept copy of the answer ageing somewhere between you and the place that is authoritative for the name, and when the count reaches zero the next asker pays for a fresh lookup. It's also why a change to a site's address takes a while to reach everybody.

The query time is how long this particular answer took to come back, and it is worth being exact about what it does and does not show. dig does not read your own system's cache. It sends a real query to the machine on the SERVER line every time, so you pay that round trip on every run and the number stays roughly level: those same seven runs took 26, 29, 32, 30, 25, 25 and 29 milliseconds.² If you ever do see 0 msec, it means the machine answering is your own, which is a different arrangement from the one described here. The cache is real, and the time to live is where you see it. The query time is not.

The server line is the machine that answered this query, and on most home connections it is your own router, which then asked somebody else. Unless that was changed, the chain ends at your internet provider. That is the party drawn off to the side in the figure above, and it is the one most people have never thought about.

Be careful how far you carry it, though, because dig is only telling you about your operating system's resolver and your browser may not be using it. Firefox has sent its own lookups to a resolver it chose, rather than to the one your machine is configured with, by default for users in the United States since February 2020.⁴ dig cannot see that and cannot tell you about it, because it knows nothing about your browser. So the honest reading of the server line is "this is who answers when my operating system asks", which is not always who answers when you type into the address bar.

nslookup wikipedia.org

nslookup -debug wikipedia.org

The route

A route trace sends packets with a deliberately short life and collects the complaints, which gives you a list of the machines along the way. Each machine that takes your packet and passes it on is one hop, and a trace prints one line per hop.

On macOS and Linux it is traceroute. On Windows it is tracert, which does work in Git Bash, but its flags are not the same ones and copying the line below will strand you. tracert counts hops with -h rather than -m. It has no -q at all, because it always sends three probes to each hop, so its output has three time columns rather than one. And it takes -w in milliseconds rather than seconds, so -w 1 asks every machine on the path to answer inside a thousandth of a second and every one of them fails to.³ The Windows form of the command below is:

tracert -h 12 -w 1000 wikipedia.org

This one was run from the machine this lesson was written on.² Every address after hop one has been replaced with a description, because together they identify a particular home connection:

$ traceroute -m 12 -w 1 -q 1 wikipedia.org
traceroute to wikipedia.org (208.80.153.224), 12 hops max
 1  192.168.4.1  3.820 ms
 2  <the provider's first machine>  5.517 ms
 3  <inside the provider's network>  6.232 ms
 4  <inside the provider's network>  15.254 ms
 5  *
 6  *
 7  *

The asterisk rows carried on to the twelfth hop, where the limit stopped it. The sample is cut at seven so that it fits the page.

Read it from the top. Hop one is the router in the house, at a 192.168. address. Three ranges are set aside for private networks, 10., 172.16. through 172.31., and 192.168., and home routers usually sit in the last of them, so yours will probably look similar. If yours starts with 10. instead, nothing is wrong. Hops two, three and four are inside the internet provider. Then it goes quiet.

The asterisks are the most instructive part of the output, and they do not mean the path is broken. They mean those machines chose not to announce themselves, which many are configured not to do. The page loads perfectly. What you've learned is real: the first four rungs of the ladder are where you thought they were, and after that the path is somebody else's business.

Working out which rung failed

Now the diagnosis, on the case everybody meets.

"The site does not load on my laptop, but it works on my phone."

Most people conclude the laptop is broken. You can do much better, because you know what the two devices do and don't share.

The phone, on mobile data, is on a different network, with a different route, and usually a different name server. It is the same browser company, the same site, and the same person typing. So the comparison has already ruled out a great deal: the site is up, and your typing is fine.

Walk the ladder on the laptop.

Did the name resolve? Run dig on the domain. If it returns an address, that rung is fine. If it returns nothing, the fault is at the top, and the commonest causes are a name server that is unwell and an answer that was kept too long.

Did the connection open? Run the route trace. If hop one fails, the trouble is between you and your own router, and that one is solid, because hop one is a machine in your house that ought to answer.

Past hop one, be careful, because this is where the rows of asterisks from earlier in this lesson meet the diagnosis and the two can be made to disagree. Asterisks on their own are not a fault, since plenty of machines are configured not to announce themselves, and a trace to a perfectly healthy site is often full of them. What is worth something is a comparison: run the same trace to a site that does load, from the same machine, and see where each one stops. If the good trace runs past the point where the bad one stops, you have learned something about the path. If both stop in the same place, you have learned about which machines answer traces, and nothing at all about your problem.

Did the response arrive with a complaint? If the page loads and says something like 403 or 500, everything below has worked perfectly and the site is telling you about itself.

That's three questions and two commands, and it turns "the internet is broken" into a sentence with a subject in it.

What people get wrong

"The internet is a place I send things to." The single box from the study at the top. There are at least seven parties, you've a relationship with one, and the rest are in the path whether you think about them or not.

"The website is a computer somewhere and I am talking to it." Mostly you are talking to a copy held much nearer than the company itself, and your page is pulling pieces from several other companies at the same time. "Which computer am I talking to" usually has more than one answer.

"Home Wi-Fi is safe because it has a password." What the participants in the study actually said was that their home network was safer than public Wi-Fi, because of its password and its settings.¹ That's a comparison rather than a verdict, and as a comparison it's fair. The trouble starts when it's heard as one, so it's worth being exact about what the password actually does. It decides who may join the network inside your house. Everything from your router onwards, which is six of the seven parties in the figure, is entirely untouched by it. A password on your Wi-Fi is a lock on your front door, and the postal system is unaffected.

"My internet provider just carries the data." It carries the data, and on most home connections it also answers your name lookups, which means it sees the name of every site you ask for and not only the address. Those are two different kinds of knowing and the second is much the more revealing, because a name is the site and an address often is not.

Be careful about the next step, though, which is the one people take without noticing. Seeing is not the same as keeping. Whether a provider records what it saw, and for how long, varies by company, by contract and by country, and this course has not read the research that would let it tell you what yours does. What's certain is that the name is available to it. What happens to it afterwards is a question you'd have to ask.

"If the site is slow, my connection is slow." It might be. It might also be one of a dozen other companies whose script the page is waiting on, or a name lookup that is timing out, or a copy that is further away than usual. "Slow" is a symptom at the top of the ladder and its cause is usually further down.

Practice

Connections

Lesson 6 gave you the habit this lesson runs on: type a command, read what comes back, work out what it means. The two commands here are the first time you've pointed that habit at something outside your own machine.

Lesson 8 takes the figure above and marks it up. Now that you can name the parties, the question "what does encryption hide, and from whom" has somewhere to land, and so does the more interesting version: which of your worries do none of the three popular tools touch at all?

Lesson 11 needs one idea from here: a link goes somewhere, and the somewhere is a name, and a name is not the thing it looks like.

Lesson 13 needs the party count. When you ask what a service holds about you, this lesson is why the honest answer includes companies you never chose.

Lesson 1's security plan gains named parties, which is the whole of what this lesson does for it.

Go deeper

• Kang, Dabbish, Fruchter and Kiesler, "My Data Just Goes Everywhere" (2015), free from the symposium. Read it for the drawings and the quotations. The participants describe the internet in their own words and it is the best argument I know for why this lesson exists.
• MDN, "How does the Internet work?", free and under a Creative Commons licence. Mozilla's own beginner's account of the same machinery, working upwards from cables and switches to routers and providers, which is the opposite order from this lesson. Read it for the half this lesson deliberately left out, and for the distinction between the internet and the web.
• Your own browser's developer tools. Press F12, or Command, Option and I on a Mac, open the Network tab, and reload a page you use. Every row is one of the trips described in step four above. Counting the companies on a news site is a five-minute exercise that does more than another thousand words here would.

Sources

1. Ruogu Kang, Laura Dabbish, Nathaniel Fruchter and Sara Kiesler, "'My Data Just Goes Everywhere': User Mental Models of the Internet and Implications for Privacy and Security", Symposium on Usable Privacy and Security, 2015, pages 39 to 46. Read in full. Supplies the drawing method, the 28 participants split 17 lay and 11 technical, the finding that 14 drew a simple single-box internet of whom 13 were lay users, the comparison of how many parties each group named (about 4 against about 2.56), and the belief about home Wi-Fi. That belief is comparative in the paper, that a home network is safer than public Wi-Fi because of its password and its settings, and this lesson states it that way; an earlier draft inherited a trimmed absolute form. The date is the year of publication, which is the only date the citation carries; the paper's fieldwork dates are not repeated here because they were not read.
2. Checked on the machine this lesson was written on, macOS, September 2026. dig +short wikipedia.org returned 208.80.153.224. The long form reported a time to live of 145 seconds and a server on the local network. Run seven times over about ten seconds, the time to live counted down 107, 99, 97, 95, 93, 90 and the query times were 26, 29, 32, 30, 25, 25 and 29 milliseconds, never zero and never falling: dig queries the configured server on every run rather than reading the operating system's cache, which is why the countdown and not the query time is where the cache is visible. An earlier draft of this lesson claimed the second query time is "often reported as 0 msec", which is false on the setup described here and was corrected on 19 September 2026. traceroute -m 12 -w 1 -q 1 wikipedia.org answered for four hops and then returned asterisks to the twelfth, where the limit stopped it, while the site loaded normally in a browser. Every address after hop one in the sample above is replaced with a description, because together they identify a particular home connection.
3. Microsoft, "nslookup", "nslookup set debug" and "tracert", learn.microsoft.com. Read 19 September 2026. Supplies the nslookup -debug form and the sentence quoted from it about showing more information about the packet and the answer, which is verbatim; and the whole of the tracert flag warning, namely that hops are set with /h (which also works as -h), that the timeout /w is in milliseconds with a default of 4000, that there is no -q or -m, and that the documented example output carries three time columns per hop. That the default nslookup output contains neither a time to live nor a query time is from the same pages, which document no such fields. The ttl = line inside debug output is not in the documentation and is marked in the lesson as reported rather than documented.
4. Mozilla, "Firefox continues push to bring DNS over HTTPS by default for US users", blog.mozilla.org, 25 February 2020. Read 19 September 2026. Supplies the single claim it is cited for: that Firefox began sending lookups to a resolver of its own by default for users in the United States from that date, rather than to the one the operating system is configured with. It is cited because it falsifies "unless you changed a setting", which an earlier draft of this lesson said.