In this chapter
We'll learn how a name like blueticket.example becomes an IP address — DNS, the internet's phone book — what domain names are, how to read every part of a URL, and how a stale DNS record broke BlueTicket for one college.
The Problem in Real Life
John asks the Northgate IT team to run one more command on campus: nslookup blueticket.example. The answer comes back: 198.51.100.7 — the old server.
Anna runs the same command on her laptop. Her answer: 203.0.113.10 — the new one. Same name, two different answers, depending on where you ask. "How can the internet give two different answers to the same question?"
The internet doesn't remember names. It remembers numbers. Somebody has to look the name up — and Northgate's somebody has an old copy of the phone book.
John
Typing a Name vs. Finding the Number Behind It
People use names, networks use numbers
Nobody types 203.0.113.10. A system has to turn names into addresses.
Answers get remembered
To be fast, the lookup answer is saved and reused — sometimes for too long.
A URL has many parts
Each part of a web address answers a different question: how, where, and what.
DNS, Domain Names and URLs
The phone contacts analogy: you don't remember your friends' phone numbers — you tap their names in your contacts, and the phone finds the number. If a friend changes their number and you never update your contacts, calling them by name rings the old number — maybe nobody answers at all. That's exactly what's happening at Northgate.
Domain name — the name in the contacts list: a domain name is a human-friendly name for an address on the internet, like blueticket.example. Domain names are read from right to left, from general to specific: .example (or .com, .org, .in) is the top-level domain; blueticket is the name BlueTicket registered; and anything in front, like www. or api., is a subdomain that the owner can create freely. Companies rent domain names yearly from companies called registrars.
DNS — the internet's phone book: the Domain Name System (DNS) is the system that turns domain names into IP addresses. When a browser needs blueticket.example, it asks DNS: "what's the number for this name?" and gets back 203.0.113.10. Only then can it connect (last chapter).
- Step 1 — ask nearby first: the browser and the computer check their own memory. Have we looked this up recently?
- Step 2 — ask the resolver: if not, the computer asks a DNS resolver — a helper server usually run by your ISP, your company or your college (or public ones like 1.1.1.1 and 8.8.8.8). Northgate's computers all ask the campus resolver.
- Step 3 — the resolver finds the answer: if the resolver doesn't know, it asks a chain of DNS servers: the root servers ("who handles .example?"), then the top-level domain servers ("who handles blueticket.example?"), and finally BlueTicket's own authoritative DNS server, which holds the official record:
blueticket.example → 203.0.113.10. - Step 4 — remember it for a while: the answer comes with a TTL (time to live) — how long it may be reused, for example one hour. The resolver and the computer save (cache) the answer for that long, so the next thousand lookups are instant.
| Part | Value | Question it answers |
|---|---|---|
| Scheme | https | How do we talk? (secure web) |
| Host | blueticket.example | Which server? (looked up by DNS) |
| Port | 443 | Which program on it? (usually left out) |
| Path | /events/festival | Which page or resource? |
| Query string | ?seat=C14 | Any extra details for the server? |
| Fragment | #map | Which spot on the page? (browser only) |
| Who asked | Resolver's cached answer | Result |
|---|---|---|
| Anna, at the office | 203.0.113.10 (refreshed after the one-hour TTL) | Site loads |
| Students on mobile data | 203.0.113.10 | Site loads |
| Students on Northgate Wi-Fi | 198.51.100.7 (kept for 7 days, ignoring the TTL) | "Took too long to respond" |
| Part | Example | Means |
|---|---|---|
| Top-level domain | .example (.com, .org, .in) | The broadest group |
| Domain | blueticket | The name the company registered |
| Subdomain | www. or api. | Names the owner creates freely |
Looking up blueticket.example
Browser and computer
"Have I looked this up recently?"
DNS resolver
ISP, company or campus — checks its cache
Root → .example → authoritative server
the official record: 203.0.113.10
Answer + TTL
cached for the TTL, e.g. one hour
Browser connects to 203.0.113.10:443
now the real request can start
These commands work in a terminal on Windows, Mac and Linux.
nslookup blueticket.example# Server: campus-dns.northgate.example# Address: 198.51.100.7 <- the OLD server: stale cachenslookup blueticket.example 1.1.1.1 # ask a public resolver instead# Address: 203.0.113.10 <- the correct, current address
Asking a second, public resolver is the quickest way to prove a DNS answer is stale.
What went wrong at Northgate: when BlueTicket moved servers last weekend, the team updated the official DNS record to the new address, with a one-hour TTL. Every resolver in the world should have picked up the new address within an hour. But the Northgate campus resolver was configured to keep cached answers for seven days, ignoring the TTL — to save bandwidth. So it kept handing every student the old number from its outdated copy of the phone book. Campus students knocked on the door of a switched-off server; everyone else got the new one.
The fix: Anna writes to the Northgate IT team: "Your DNS resolver is still returning our old address, 198.51.100.7, for blueticket.example. The correct address has been 203.0.113.10 since Saturday. Please clear your resolver's cache and respect record TTLs." Ten minutes later, the student union posts: "It works!" Anna has just solved a problem without changing a single line of BlueTicket's code.
Reading a URL — the full address of one thing on the web: a URL (Uniform Resource Locator) is a complete web address. Take https://blueticket.example:443/events/festival?seat=C14#map and read it like a sentence. https is the scheme — how to talk (the secure web protocol, chapter 6). blueticket.example is the host — which server, found through DNS. :443 is the port — usually left out, because browsers assume 443 for https and 80 for http. /events/festival is the path — which page or resource on that server. ?seat=C14 is the query string — extra details for the server, as name=value pairs. #map is the fragment — a spot inside the page, used only by the browser and never sent to the server.
Key Takeaway
DNS is the internet's phone book: it turns domain names like blueticket.example into IP addresses. Your computer asks a resolver, which finds the official answer and caches it for its TTL. If a resolver keeps an old answer too long, people get sent to an old address. A URL is a complete address read as scheme (how), host (where), port, path (what), query (details) and fragment (a spot on the page).
Why This Matters
"It's always DNS" is a running joke among engineers, because so many outages turn out to be a wrong, missing or stale DNS record. Whenever BlueTicket moves a server, adds a subdomain or changes providers — as it will in Act 19 and Act 20 — DNS is involved. And reading URLs part by part is something every web developer does dozens of times a day.
Northgate's students can reach the right server now. But Anna realises she still doesn't know what actually travels to that server once the connection is open — what a browser's "question" looks like, and what the "answer" is. That's the language of the web: HTTP.