Frontend Labs
⋯

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:

  1. Ask your mom (your computer's resolver) — she doesn't know either.
  2. Mom calls the big phone book office (the root name server) — they say "I don't know Netflix's number, but call the .com directory."
  3. Mom calls the .com directory — they say "I don't know Netflix's exact number, but call Netflix's own office."
  4. Mom calls Netflix's own office (their authoritative name server) — they give the real number: 52.38.36.82.
  5. Mom writes it down so she doesn't have to ask again for a while (caching).
  6. 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 dnsdiff tool 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 protoprobe lab in Chapter 14.
  • Happy Eyeballs in Go: net.Dialer already races IPv6 and IPv4 for you. Its FallbackDelay field (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.

Generated from real-life-guide-v1.md · 8 Oct 2026 16:36