Two Names for Every Machine

Machines are addressed by numbers (IP addresses); people are addressed by names. DNS (Domain Name System) is the distributed database that maps example.com → 93.184.216.34. It is the first network call every application makes, so DNS failures or latency are magnified across everything you build. Unlike a single phone book, DNS is hierarchical, distributed, and cached — design decisions that let it survive at internet scale.

The Hierarchy

A fully-qualified domain name is read right-to-left, each label delegating authority to the level above:

www.shop.example.com.
   ^   ^     ^      ^
   │   │     │      └─ root "."
   │   │     └──────── TLD: com  (authoritative at Verisign/ICANN registry)
   │   └────────────── second-level: example  (your domain registrar)
   └────────────────── third-level: www       (you control via DNS records)

The root servers know the TLD servers; the TLD servers (.com, .org, .io…) know the authoritative nameservers for each domain; your authoritative nameserver (often your registrar or a DNS provider) holds the actual records. The chain of delegation is what makes DNS trustable without a central authority.

Record Types

Operationally, the ones you’ll touch daily are A/AAAA (point a name at a server), CNAME (alias — only for names, never the zone apex), and TXT (prove domain ownership for TLS/email). Misconfigured CNAME at the apex (“CNAME on the root domain”) is a classic mistake — use an ALIAS/ANAME record or an A record instead.

How Resolution Works

Two modes, best understood as your computer asking the internet for directions:

• Recursive resolver — typically your ISP or Cloudflare/Google (8.8.8.8). It does the walking for you: queries root → TLD → authoritative → returns the answer. Your machine asks one resolver.
• Authoritative server — holds the records and returns definitive answers for its domain.

Your browser
  └─▶ Recursive resolver (8.8.8.8)
        ├─ root server:  "ask the .com TLD"
        ├─ .com TLD:     "ask ns1.example.net"
        └─ ns1.example.net (authoritative): "www = 93.184.216.34"  →  cache it!

The resolver caches the answer for the record’s TTL (time-to-live, seconds). Caching is why DNS changes propagate slowly, why dig with +trace is your debugging weapon, and why lowering TTL before a migration is standard practice — you drain stale caches gracefully. When you see “DNS propagation,” you’re really seeing TTLs expiring across resolvers.

DNS at the Edge

DNS isn’t just a phone book — it’s a load-balancing and routing layer hiding in plain sight:

• DNS-based load balancing — a name returns several A records; clients pick one (round-robin across data centers).
• Geo / latency routing — the resolver’s location or IP determines which answer you get (us-west vs eu-west), which is how CDNs steer you to the nearest edge.
• Split-horizon DNS — internal vs external answers for the same name (internal db.internal → private IP; public → natted address).

These are the cheapest “load balancer” that exists — no packet inspection, just an answer. Their limit is the same as any DNS scheme: TTL-bound staleness and no real-time health awareness. The job “shift traffic from DC-A to DC-B” is, in many orgs, a DNS change.

Load Balancers

A load balancer (LB) sits in front of a set of servers and distributes traffic. Two flavors, defined by which layer they inspect:

• L4 (transport) load balancer — forwards TCP/UDP connections by the four-tuple. Fast, protocol-agnostic, sees no URLs. Works for databases, TLS, any TCP service.
• L7 (application) load balancer — terminates/inspects HTTP. Routes by URL path, host header, cookies; can rewrite, add headers, run health checks, and do TLS termination.

Distribution algorithms: round robin, least connections, least response time, IP hash (sticky by client), random. The staleness of “sticky sessions” is a warning sign — prefer stateless services so any backend can serve any request (that’s where the idempotency work from HTTP pays off).

Critical features:

• Health checks — probe backends (GET /healthz, or TCP connect) and stop routing to failing ones. A good LB removes dead servers automatically.
• Draining — on deploy, stop sending new connections while letting in-flight requests finish. Without draining, deployments drop requests.
• TLS termination — many LBs decrypt TLS once, offloading the crypto from app servers (then the internal hop is usually still HTTPS/TLS for defense in depth).

Reverse Proxy vs Forward Proxy

• Forward proxy — sits in front of clients (your browser → proxy → internet). Used for egress filtering, caching, privacy, and corporate policy. It stands for the client.
• Reverse proxy — sits in front of servers (client → proxy → your backend). Used for TLS termination, caching, load balancing, rate limiting, and hiding your backend topology. It stands for the server.

A reverse proxy is typically an L7 LB (nginx, HAProxy, Envoy, Caddy). The mental model: “forward proxy hides the client; reverse proxy hides the server.”

Practice Trajectory

1. dig example.com and read the answer section, TTL, and the authoritative server. Then dig example.com +trace to watch the delegation chain.
2. Add an A record for test.<yourdomain> pointing at a VPS, set TTL to 60, and watch it resolve — then change it and observe propagation delay.
3. Run two python3 -m http.server instances on different ports and put an nginx reverse proxy in front of them with round-robin; curl -i repeatedly and observe both backends answering.
4. dig mx gmail.com and dig txt <some-domain> — identify MX priority and SPF TXT content by eye.
5. Explain to someone why DNS-based load balancing can’t do health checks, and where that limitation forces you to use an L7 LB.

When It’s the Right Tool