What is DNS?

The internet's phone book

Every device on the internet has an IP address: a number like 198.51.100.34. But humans don't think in numbers. We think in names: google.com, github.com, myapp.com.

The Domain Name System (DNS) is the service that translates human-readable domain names into machine-readable IP addresses. Without DNS, you'd have to memorize IP addresses for every website you visit.

You type:     google.com
DNS returns:  142.250.80.46
Browser uses: 142.250.80.46 to make a TCP connection

DNS is one of the most critical pieces of internet infrastructure. If DNS goes down, the internet effectively stops working: even though every server is still running. People can't find them.

Why not use IP addresses directly?

You could use IP addresses directly. Try http://142.250.80.46 in your browser: Google answers (over HTTPS you'd get a certificate warning, since the certificate names google.com, not the IP). But there are critical problems:

The analogy: phone books and contacts

DNS works like the contacts app on your phone:

Contacts App                DNS
─────────────               ───
"Mom" → +1-555-0123         "google.com" → 142.250.80.46
"Work" → +1-555-0456        "github.com" → 140.82.121.4
"Pizza" → +1-555-0789       "myapp.com"  → 203.0.113.42

You don't memorize phone numbers: you look up names. DNS does the same for the internet.

But unlike your contacts app (which stores everything locally), DNS is a distributed system: no single server has all the answers. Instead, different servers are responsible for different parts of the naming hierarchy.

How DNS fits in the request lifecycle

DNS is the first step before any HTTP request can be made:

1. User types: https://myapp.com/courses
2. Browser asks DNS: "What's the IP of myapp.com?"
3. DNS responds: "203.0.113.42"
4. Browser connects to 203.0.113.42:443 (TCP handshake)
5. Browser sends HTTP request: GET /courses
6. Server responds with HTML
7. Browser renders the page

Without step 2-3, steps 4-7 can't happen. DNS is the bridge between human-readable URLs and machine-readable addresses.

DNS is a distributed database

The DNS system handles trillions of queries per day. No single server could handle that load. Instead, DNS uses a hierarchical, distributed architecture:

flowchart TB
  R["Root servers (.)<br>13 root server identities, anycast worldwide"]
  COM[".com TLD"]
  ORG[".org TLD"]
  BR[".br ccTLD"]
  R --> COM & ORG & BR
  COM --> G["google.com<br>nameserver"]
  COM --> H["github.com<br>nameserver"]
  ORG --> W["wikipedia.org<br>nameserver"]
  BR --> GB["google.com.br<br>nameserver"]

Each level is responsible for a portion of the namespace:

We'll explore this hierarchy in detail in lesson 3.

DNS uses UDP (mostly)

As you learned in the TCP/IP course, DNS primarily uses UDP on port 53:

Browser → DNS Resolver (UDP port 53)
  Query: "What's the IP of myapp.com?"

DNS Resolver → Browser (UDP port 53)
  Response: "203.0.113.42"

Total: 2 packets, ~5ms

Why UDP?

• DNS queries are small (fits in one packet)
• Speed matters: DNS happens before every new connection
• If the response is lost, the client asks again

DNS switches to TCP when:

• The response is too big for UDP (over 512 bytes classically; EDNS0 raises that, often to 1232)
• Zone transfers between DNS servers (AXFR)
• DNSSEC validation requires larger payloads

DNS in your daily Rails work

You interact with DNS constantly as a Rails developer:

Common DNS-related errors

# DNS resolution failed
SocketError: getaddrinfo: nodename nor servname provided, or not known
# → The domain name couldn't be resolved to an IP

# DNS timeout
Resolv::ResolvTimeout: DNS resolv timeout
# → DNS server didn't respond in time

Key DNS terminology

Summary