DNS, IP addresses & URLs, or how a name becomes a number.

Section · 01

IP addresses — the numbers under the names

Every device on the internet has an IP address: a unique number that says where to send packets. There are two versions in active use.

IPv4   →  204.79.197.200            (32-bit, ~4 billion addresses, mostly exhausted)
IPv6   →  2606:4700:4700::1111      (128-bit, effectively infinite)

IPv4 ran out of free addresses around 2011. IPv6 has been the replacement “coming soon” for 25 years and is now deployed on more than half the internet. For most of what you’ll do as a web dev, you can stay with IPv4 in your head and never get confused. The protocols below them (TCP, HTTP) work the same way on either.

Local vs public IPs

The IP your home router shows under 192.168.x.x or 10.x.x.x is private — it works only inside your house. Your router translates between that and a single publicIP that the internet sees. That trick is called NAT (Network Address Translation) and it’s why your laptop, phone, and toaster all look like one device from outside.

Section · 02

Why we need DNS

If we only had IPs, every link would look like https://204.79.197.200. Nobody would remember anything. Worse: every time a company moved its servers, every link to them would break.

DNS (Domain Name System) is the layer that maps memorable names — yorksims.com— to IP addresses that can change behind the scenes. It’s a giant distributed database that no single entity owns.

Section · 03

The DNS resolution dance

When you type yorksims.com into your browser, this happens in roughly 10-50 milliseconds:

1. Browser cache?           Has yorksims.com been looked up recently?
2. OS cache?                Same question, OS level.
3. Resolver (your ISP)      A server that's seen the answer for someone else.
4. Root server              "I don't know, but ask the .com server."
5. TLD server (.com)        "Ask yorksims.com's name servers — here's where."
6. Authoritative server     "yorksims.com lives at 76.76.21.21." ← the real answer

Whichever layer answers first wins. The answer gets cached at every layer above it for a duration set by the TTL(time to live). That’s why DNS changes can take hours to propagate — old caches haven’t expired yet.

Section · 04

DNS record types you'll see

A domain’s DNS settings are a list of records. The ones you’ll touch:

A      → IPv4 address              yorksims.com → 76.76.21.21
AAAA   → IPv6 address              yorksims.com → 2606:4700::...
CNAME  → alias to another name     www.yorksims.com → yorksims.com
MX     → mail server               yorksims.com → mail.google.com (priority 10)
TXT    → arbitrary text            (used for verification, SPF, DKIM)
NS     → name servers              yorksims.com is managed by ns1.vercel.com

When you point a new domain at a hosting provider, you’re editing these records — usually an A record (for IP) or a CNAME (for a hostname). Email problems? MX or TXT. Domain ownership verification? TXT.

Section · 05

Anatomy of a URL

A URL (Uniform Resource Locator) is the address bar of your browser broken into parts. Each part has a job.

https://blog.yorksims.com:443/posts/dns?ref=newsletter#chapter-2

scheme     →  https
subdomain  →  blog
domain     →  yorksims.com
TLD        →  .com
port       →  443                 (usually implied; 80 for http, 443 for https)
path       →  /posts/dns          (which resource on the server)
query      →  ref=newsletter      (extra parameters, after the ?)
fragment   →  chapter-2           (in-page anchor, after the #; never sent to server)

One quirk worth knowing: the fragment (after the #) never gets sent to the server. It’s purely a client-side thing. Single-page apps used to abuse this to route inside one page without triggering a full reload.

URL vs URI vs URN

Pedantically: a URI is the umbrella; URL is the kind of URI that tells you where something is; URN is the kind that tells you what it is without a location. In practice everyone says URL and you can too.

Section · 06

The whole picture, one diagram

Put together, here’s the full path from typing a URL to seeing pixels:

You type:        https://yorksims.com
DNS resolves:    yorksims.com → 76.76.21.21
TCP handshake:   your laptop ↔ 76.76.21.21:443
TLS handshake:   encrypt the channel
HTTP request:    GET / HTTP/1.1, Host: yorksims.com
Server runs:     route, query DB, render HTML
HTTP response:   200 OK, Content-Type: text/html, body...
Browser parses:  HTML → DOM, CSS → styles, JS → run
More requests:   for every image, font, script, stylesheet
Render:          paint pixels

You can do all of this in less than 500ms on a good connection. When a page feels slow, one of those steps is too slow — and knowing the steps tells you where to look. Next lesson: what actually lives at the other end of that connection.