DNS and CDNs
The Domain Name System (DNS) is the hierarchical, distributed naming system that translates human-readable domain names (e.g., example.com) into the IP addresses that computers use to route network traffic. Without DNS, users would need to memorize numeric addresses for every service they use; with it, the internet remains navigable while the underlying infrastructure (server IPs, hosting providers, even entire architectures) changes freely behind the scenes. A Content Delivery Network (CDN) is a geographically distributed network of proxy servers ('edge' or 'points of presence') that cache and serve content — static assets, and increasingly dynamic content too — from a location physically close to the requesting user, reducing latency and offloading traffic from origin servers. Together, DNS and CDNs form the first layer of a request's journey and are often the first two components sketched in a system design diagram for any internet-facing service.
Cricket analogy: Like a scoreboard translating a bowler's nickname into their official jersey number so commentators can track them regardless of team changes, while regional broadcast vans (CDN edges) relay the feed locally so fans don't wait for a signal from the main stadium.
How DNS Resolution Works
DNS resolution is a multi-step lookup: a client's resolver (often provided by the ISP or a public resolver like 8.8.8.8) queries a hierarchy of nameservers — root servers, then top-level-domain (TLD) servers (e.g., .com), then the domain's authoritative nameserver — caching each answer according to its time-to-live (TTL) to avoid repeating the full lookup on every request. This caching hierarchy is what makes DNS scale to billions of daily queries: most lookups are served from a cache at the resolver or even the client's operating system, and only a cache miss triggers the full recursive lookup chain. DNS also supports load distribution: a domain can resolve to multiple IP addresses (round-robin DNS) or, more powerfully, use geo-DNS to return different IPs depending on the requester's location, directing users to the nearest available data center or CDN edge node.
Cricket analogy: Like a fan asking a local club (resolver), who checks with the national board (root), then the state association (TLD), then the specific team's office (authoritative) for a player's contact — but once found, it's remembered (cached by TTL) so the lookup chain isn't repeated for every question, and a national board can direct fans to their nearest regional stadium (geo-DNS).
How CDNs Reduce Latency and Load
A CDN works by placing edge servers in many geographic locations (often dozens to hundreds of points of presence globally) and routing each user's request to the nearest healthy edge, typically via DNS-based or Anycast-based routing. On a cache hit, the edge serves the content directly without ever contacting the origin server, cutting round-trip latency from potentially hundreds of milliseconds (cross-continent) to single-digit milliseconds (local edge), while also shielding the origin from traffic spikes — a property especially valuable during flash-crowd events. Modern CDNs extend beyond static assets (images, CSS, JS, video) to cache API responses and even execute logic at the edge (edge computing/edge functions), further reducing the work the origin must do per request.
Cricket analogy: Like regional broadcast trucks (edge servers) near each stadium relaying the match feed to local viewers instantly instead of routing through the national broadcast center every time, and increasingly running live graphics processing on-site rather than sending raw feed back to headquarters.
1. Browser needs IP for www.example.com
2. Checks local cache -> miss
3. Asks recursive resolver (ISP/8.8.8.8)
4. Resolver -> root server -> .com TLD server -> example.com authoritative NS
5. Authoritative NS returns CDN-provided IP (geo-routed to nearest edge)
6. Browser connects to nearest CDN edge
7. Edge cache HIT -> serve content directly (fast)
Edge cache MISS -> edge fetches from origin, caches it, then serves itCloudflare and Akamai operate CDN networks with points of presence in hundreds of cities worldwide; during major live-streamed events, these networks can absorb traffic spikes of millions of simultaneous viewers precisely because most requests are served entirely from edge caches, and only a small fraction of 'first request' traffic ever reaches the origin infrastructure.
A common oversight is setting DNS TTLs too high (e.g., 24 hours) for records that may need to change quickly during an incident, such as failing over to a backup region — a long TTL means stale IPs remain cached at resolvers worldwide long after the authoritative record has changed, delaying failover. Conversely, TTLs set too low increase DNS query volume and add latency from more frequent lookups.
- DNS translates human-readable domain names into IP addresses through a hierarchical, cached lookup chain (root, TLD, authoritative nameserver).
- TTL-based caching at each level of the DNS hierarchy is what allows DNS to scale to handle enormous global query volume.
- Geo-DNS and round-robin DNS allow a single domain to route users to different, often nearer, IP addresses.
- A CDN caches content at geographically distributed edge locations, serving users from the nearest edge to reduce latency.
- CDNs shield origin servers from traffic spikes since most requests are served entirely from edge caches on a hit.
- DNS TTL configuration is a real trade-off: too high delays failover during incidents, too low increases query volume and latency.
Practice what you learned
1. What is the primary function of DNS?
2. How does DNS scale to handle billions of daily queries?
3. What happens on a CDN edge cache hit?
4. What is a risk of setting a DNS record's TTL too high?
5. How does geo-DNS improve user experience?
Was this page helpful?
You May Also Like
Client-Server Architecture
The foundational model where clients request resources or services from centralized servers, including its variations, benefits, and inherent limitations at scale.
CDN Caching and Edge Computing
Covers how Content Delivery Networks cache content close to users to cut latency, and how edge computing extends this to running logic near the request origin.
Load Balancing Algorithms
Surveys the algorithms load balancers use to distribute traffic across backend servers, from simple round robin to adaptive least-connections and consistent hashing.
Why Caching Matters
Explains the core motivation for caching in system design — reducing latency and load by storing frequently accessed data closer to where it's needed.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics