DNS — how a domain name becomes a server

Computers on a network address each other by IP address (93.184.216.34), not by name — but no one wants to memorize a string of numbers for every website they visit. DNS (Domain Name System) is the system that translates a human-friendly domain name (example.com) into the actual IP address a browser needs to connect to. This translation step happens before the HTTP request from the earlier lesson can even be sent — the browser needs an address to send it to first.

This whole exchange typically happens in milliseconds, and is almost entirely invisible — a real, multi-step lookup happening before every single request to a domain your browser hasn't recently visited. Caching at nearly every step (the browser's own cache, the resolver's cache, and more) is what keeps this fast in practice — the full multi-server chain only runs on an actual cache miss, which is relatively rare for popular domains.

A domain's DNS configuration is a set of records, each with a specific type telling DNS servers what kind of answer to return for that name. A and AAAA records are the ones directly answering "what's the IP address" (AAAA for the newer, longer IPv6 addresses; A for the original IPv4 format). CNAME lets one name point at another name instead of directly at an IP — useful for pointing several subdomains at the same underlying target without repeating the actual IP address in multiple places.

Every DNS record has a TTL (Time To Live) — how long a resolver is allowed to cache that answer before checking again. This is exactly why updating a domain's DNS (pointing it at a new server, say) doesn't take effect everywhere instantly: any resolver that already cached the old answer keeps serving it until that cached entry's TTL expires. A low TTL means changes propagate faster, at the cost of resolvers having to re-check (and re-load) the record more often; a high TTL means better caching efficiency, at the cost of slower propagation when something actually changes.

DNS is also a real point of leverage for the scaling and reliability ideas covered earlier: a domain can have multiple A records pointing at multiple different IP addresses (multiple servers), and different resolvers might get handed different ones — a crude, DNS-level form of load balancing, distinct from but complementary to the load-balancer-in-front-of-a-server-pool approach covered in its own lesson. Some DNS providers also route requests to whichever server is geographically closest to the requester, directly serving the same latency-reduction goal a CDN serves.