Chapter 2 — DNS: Finding the Address
Before your browser can connect to Netflix, it needs to know Netflix's IP address. DNS is how it finds out.
The Simple Version (5-year-old)
Imagine you want to call your friend "Netflix" but you don't know their phone number. So you:
- Ask your mom (your computer's resolver) — she doesn't know either.
- Mom calls the big phone book office (the root name server) — they say "I don't know Netflix's number, but call the
.comdirectory." - Mom calls the
.comdirectory — they say "I don't know Netflix's exact number, but call Netflix's own office." - Mom calls Netflix's own office (their authoritative name server) — they give the real number:
52.38.36.82. - Mom writes it down so she doesn't have to ask again for a while (caching).
- Now you can call Netflix directly.
What is DNS?
DNS (Domain Name System) is the internet's phone book. It translates human-readable names like www.netflix.com into machine-readable IP addresses like 52.38.36.82.
Without DNS you would have to memorize 52.38.36.82 instead of netflix.com. DNS also lets Netflix change their IP address without you needing to update anything — the name stays the same.
The Players in DNS
| Player | Role | Example |
|---|---|---|
| Stub Resolver | Built into your OS. Takes DNS queries from apps. | systemd-resolved on Linux, mDNSResponder on macOS |
| Recursive Resolver | Does the heavy lifting — queries the chain on your behalf. | 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), your ISP's resolver |
| Root Name Servers | Top of the DNS hierarchy. 13 clusters worldwide. | a.root-servers.net through m.root-servers.net |
| TLD Name Servers | Responsible for top-level domains like .com, .org, .io |
Verisign operates .com and .net |
| Authoritative Name Server | Netflix's own DNS server. Has the final answer. | ns-1496.awsdns-59.org |
Full DNS Resolution — Step by Step
When you type www.netflix.com and no cache has the answer:
Your Browser
│
│ 1. "What is the IP of www.netflix.com?"
▼
OS Stub Resolver
│ checks /etc/hosts → not there
│ checks OS DNS cache → MISS (or expired)
│
│ 2. Sends query to configured recursive resolver
▼
Recursive Resolver (e.g., 8.8.8.8)
│ checks its own cache → MISS
│
│ 3. Queries a Root Name Server (.)
│ "Who knows about .com?"
▼
Root Name Server (e.g., a.root-servers.net)
│ "I don't know netflix.com, but for .com domains,
│ ask these TLD servers: 192.5.6.30, 192.5.6.31..."
│ (This is called a REFERRAL, not the final answer)
│
│ 4. Queries the .com TLD Name Server
│ "Who knows about netflix.com?"
▼
.com TLD Name Server (Verisign)
│ "I don't know the IP, but netflix.com's own name servers are:
│ ns-1496.awsdns-59.org, ns-1816.awsdns-35.co.uk..."
│ (Another REFERRAL)
│
│ 5. Queries netflix.com's Authoritative Name Server
│ "What is the IP of www.netflix.com?"
▼
netflix.com Authoritative Name Server (AWS Route 53)
│ "Here is the answer:"
│ A record: 52.38.36.82 TTL: 60s
│ AAAA record: 2600:1f14:fff:f802::1 TTL: 60s
│
│ 6. Recursive resolver caches this answer
│ returns it to your OS stub resolver
▼
OS stub resolver caches it, returns to browser
│
▼
Browser caches it, connects to 52.38.36.82
The whole process is typically 20–120ms for a cold lookup. With caching it's instant.
DNS Record Types
DNS stores different types of records for different purposes:
| Record | Full Name | What It Stores | Example |
|---|---|---|---|
A |
Address | IPv4 address of a hostname | www.netflix.com → 52.38.36.82 |
AAAA |
Quad-A | IPv6 address of a hostname | www.netflix.com → 2600:1f14::1 |
CNAME |
Canonical Name | Alias — points one name to another | www → netflix.com |
NS |
Name Server | Which servers are authoritative for this domain | netflix.com NS ns-1496.awsdns-59.org |
MX |
Mail Exchange | Which server handles email for this domain | netflix.com MX mail.netflix.com |
TXT |
Text | Free-form text — used for SPF, DMARC, verification | "v=spf1 include:amazonses.com ~all" |
PTR |
Pointer | Reverse DNS — IP address to hostname | 82.36.38.52.in-addr.arpa → host.netflix.com |
SOA |
Start of Authority | Metadata about the zone — serial number, TTL defaults | One per zone |
CAA |
Cert Authority Auth | Which CAs are allowed to issue TLS certs for this domain | netflix.com CAA digicert.com |
SRV |
Service | Service location (host + port) — used by some protocols | _http._tcp.netflix.com SRV 10 0 80 www.netflix.com |
CNAME Chains — How Aliases Work
www.netflix.com CNAME netflix.com.edgekey.net (Akamai edge)
netflix.com.edgekey.net CNAME e1234.dscg.akamaiedge.net
e1234.dscg.akamaiedge.net A 23.200.1.1
The resolver follows the chain until it hits an A/AAAA record. You cannot put a CNAME on the root domain (netflix.com itself) — that's called the CNAME apex restriction. Workarounds: ALIAS records or AWS Route 53 ALIAS.
TTL — Time to Live
Every DNS record has a TTL (Time to Live) in seconds. This tells caches how long they can keep the answer before they must ask again.
netflix.com A record TTL: 60 seconds
→ Your resolver can cache this for 60 seconds
→ After 60s, must ask again
google.com A record TTL: 300 seconds
→ Cached for 5 minutes
cloudflare.com A record TTL: 1800 seconds
→ Cached for 30 minutes
Low TTL = changes propagate fast (good for failovers) but more DNS queries (more load on resolvers). High TTL = fewer queries (faster for users) but changes take longer to spread.
Large traffic-heavy services often use short TTLs for some records so they can reroute users more quickly during an outage or traffic shift. The exact TTL depends on the record, CDN strategy, and resolver behavior.
DNS Caching — Layers
DNS answers are cached at multiple levels. Each layer serves from cache if the TTL hasn't expired:
[Browser DNS cache] (checked first — fastest)
│ MISS
▼
[OS DNS cache] (/etc/hosts first, then OS resolver cache)
│ MISS
▼
[Recursive Resolver cache] (8.8.8.8, 1.1.1.1, or your ISP's)
│ MISS
▼
[Full recursive resolution] (Root → TLD → Authoritative)
You can inspect your browser's DNS cache at chrome://net-internals/#dns.
IPv4 vs IPv6 — Happy Eyeballs
Modern browsers request both A (IPv4) and AAAA (IPv6) records simultaneously. Then they try both connections in parallel, preferring IPv6 (by giving it a 50ms head start). Whichever connects first wins. This algorithm is called Happy Eyeballs (RFC 8305).
Browser sends simultaneously:
DNS query for A record (IPv4)
DNS query for AAAA record (IPv6)
Both respond: IPv4=52.38.36.82, IPv6=2600:1f14::1
Browser starts:
IPv6 connection attempt (immediately)
IPv4 connection attempt (50ms later, as fallback)
IPv6 connects first → use IPv6
IPv6 fails → IPv4 takes over seamlessly
Why prefer IPv6?
- No NAT — end-to-end, lower latency
- Better routing (no NAT state machines in the path)
- Future-proof
Encrypted DNS — DoH and DoT
Standard DNS sends queries in plain text over UDP port 53. This means:
- Your ISP can see every domain you look up.
- Anyone on your network (coffee shop Wi-Fi) can snoop.
- DNS responses can be tampered with (cache poisoning).
Two solutions:
DNS over TLS (DoT) — Port 853
Wraps DNS in a TLS connection. Encrypted, but uses a different port — network admins can block or monitor port 853.
DNS over HTTPS (DoH) — Port 443
Sends DNS queries as HTTPS requests. Looks identical to regular web traffic — cannot be easily blocked without blocking all HTTPS.
Traditional DNS (plaintext):
Browser ──UDP:53──► 8.8.8.8
Anyone can read: "query for www.netflix.com"
DoH (encrypted):
Browser ──HTTPS:443──► 1.1.1.1/dns-query
Payload encrypted — ISP sees only: "you talked to 1.1.1.1"
Chrome, Firefox, and most modern browsers use DoH by default to resolvers like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google).
DNSSEC — Preventing Fake Answers
The problem: A malicious resolver could lie. "netflix.com? That's at 1.2.3.4 (attacker's server)." Your traffic goes to the attacker. This is DNS cache poisoning.
DNSSEC (DNS Security Extensions) digitally signs DNS records. Each record has a cryptographic signature. Resolvers can verify the signature against a public key — forged answers are detected and rejected.
netflix.com A 52.38.36.82
netflix.com RRSIG [signature over the A record]
netflix.com DNSKEY [public key to verify the signature]
DNSSEC doesn't encrypt DNS — it only authenticates responses. DoH/DoT encrypts; DNSSEC authenticates.
DNS and Security — What Can Go Wrong
| Attack | What Happens | Defense |
|---|---|---|
| Cache Poisoning | Attacker injects fake DNS records into resolver cache | DNSSEC, DNS randomization |
| DNS Hijacking | ISP or attacker redirects all DNS to a different resolver | DoH/DoT, check resolver IP |
| DNS Amplification DDoS | Attacker spoofs victim's IP, sends small DNS queries → massive responses flood victim | Rate limiting, BCP38 filtering |
| NXDOMAIN Hijacking | ISP intercepts "domain not found" and shows ads | DoH to a trusted resolver |
| DNS Exfiltration | Malware encodes data in DNS queries to smuggle data out | Monitor for unusually long DNS names, high query rates |
Across the series
- Build a DNS client from raw bytes in Go, including message compression and the transaction-ID check that defends against spoofing: TCP/IP guide, Chapter 18.
- Operate DNS: delegation, glue, SOA serials, negative caching, migration TTL
timelines, DNSSEC failures, and a
dnsdifftool that compares resolvers: TCP/IP guide, Chapter 55. - The HTTPS record (type 65) that advertises HTTP/3 before the first
connection is decoded by this guide's
protoprobelab in Chapter 14. - Happy Eyeballs in Go:
net.Dialeralready races IPv6 and IPv4 for you. ItsFallbackDelayfield (default 300 ms) is the head start IPv6 gets before an IPv4 attempt begins.
Key Takeaways
- DNS translates
www.netflix.com→52.38.36.82. Without it you'd memorize IPs. - Resolution is a chain: Stub Resolver → Recursive Resolver → Root NS → TLD NS → Authoritative NS.
- Results are cached at every layer based on TTL. Short TTL = fast failover, more queries.
- DoH/DoT encrypts DNS queries so ISPs can't snoop. DoH is most widely used.
- DNSSEC prevents fake answers by digitally signing records.
- Short TTLs can enable faster DNS-based traffic shifts, but exact behavior depends on resolver caching and the service's DNS/CDN architecture.
- The CAA record prevents unauthorized CAs from issuing TLS certs for a domain.