07 — DNS and CDNs: Names, Edges, and Why Geography Matters

"Just the cloud" was how I mashed DNS and CDNs together, which made neither debuggable. Writing them down separated the two jobs cleanly: DNS translates a domain name into an IP address (hierarchical, cached, TTL-bound), and a CDN serves content from a machine geographically close to the user so the origin server doesn't have to. [1][3] They are distinct layers that often cooperate, and the reason they cooperate is physics — the speed of light.

The framing that clicked is that both layers exist to hide geography. The origin server lives in one data center. Users are everywhere. DNS is how a name finds that one box; a CDN is how the bytes get pre-staged near the users so most requests never reach the origin at all.

DNS: the hierarchical phonebook

A Domain Name System translates a domain like www.example.com into an IP address [1]. It is hierarchical — a few authoritative servers at the top, delegated downward — and heavily cached at every level, with each cache entry living for a time-to-live (TTL) that determines how long before it must be re-fetched. Because of caching and propagation delays, a DNS change is not instant; it takes up to the TTL to reach everyone [1].

The record types worth knowing, because they each do a distinct job:

• A record — points a name to an IPv4 address.
• CNAME — points a name to another name (an alias).
• MX — specifies mail servers for the domain.
• NS — specifies the authoritative nameservers for a domain or subdomain.

Managed DNS services (Cloudflare, Route 53) do more than resolve — some can route traffic by policy: skipping servers under maintenance, balancing across cluster sizes, doing A/B testing, or routing by latency and geography [1][2]. That last capability is where DNS starts to overlap with the CDN story.

CDN: serving bytes from the edge

A Content Delivery Network is a globally distributed network of proxy servers that serve content from locations close to the user [3]. Static assets — HTML, CSS, JS, images, video — are the natural fit, though some CDNs (CloudFront, for one) also handle dynamic content. The win is twofold: users get bytes from a nearby data center (lower latency), and the origin server stops having to serve requests the CDN already fulfilled (lower origin load) [3].

The two operating modes differ in who is responsible for putting content on the CDN:

• Pull CDN grabs content from the origin the first time a user requests it, then caches it for the TTL [3][4]. First hit is slow; everything after is fast. It minimizes storage on the CDN but can create redundant traffic if files expire and get re-pulled without having changed. Heavy-traffic sites suit pull CDNs — only recently-requested content stays cached, and traffic spreads evenly.
• Push CDN receives content whenever it changes on the origin — the origin uploads directly and rewrites URLs to point at the CDN [3]. The origin controls expiry and update timing. Content is uploaded only when new or changed, minimizing traffic but maximizing CDN storage. Low-traffic or rarely-updated sites suit push CDNs — content is placed once instead of re-pulled on a schedule.

Where DNS and CDN meet: latency-based routing

The overlap is real and worth seeing. Because DNS is the first thing consulted on every request, a smart DNS service can steer the user to the _nearest healthy_ CDN edge or origin region based on the user's geography or measured latency [2]. That is how a single domain like aveshina.my.id resolves to a different IP for a user in Singapore than for one in São Paulo — the DNS response itself is the routing decision. DNS picks the edge; the CDN serves the bytes.

How I use this

Two habits came out of these notes. First, anything static and publicly cacheable goes behind a CDN by default — there is rarely a reason to make the origin serve the same image a million times. Second, when a global user reports slowness, my first suspect is geography: which edge did DNS send them to, and is the origin in a region an ocean away? Most "the site is slow" tickets from far-away users are not bugs — they are the speed of light, and the fix is edge placement, not code.

References

[1] Cloudflare, "What is DNS?," 2024. [Online]. Available: https://www.cloudflare.com/learning/dns/what-is-dns/

[2] Amazon Web Services, "Routing policy — latency-based and geolocation," AWS Route 53 Developer Guide. [Online]. Available: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html

[3] D. Martin, "Content delivery network," system-design-primer (open source), 2024. [Online]. Available: https://github.com/donnemartin/system-design-primer#content-delivery-network

[4] Travel Blog Advice, "The differences between push and pull CDNs." [Online]. Available: http://www.travelblogadvice.com/technical/the-differences-between-push-and-pull-cdns/

[5] "Content delivery network," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Content_delivery_network

[6] JSCAPE, "Load balancing algorithms — weighted round robin." [Online]. Available: https://www.jscape.com/blog/load-balancing-algorithms