---
title: "07 — DNS and CDNs: Names, Edges, and Why Geography Matters"
uid: dns-and-cdn
tags: ["dns", "cdn", "edge", "roadmap:system-design", "performance", "system-design"]
excerpt: "DNS resolves a name to a number; a CDN serves bytes from a machine close to the user. Two distinct layers that cooperate because of physics — the speed of light."
date: 2026-08-13T03:27:33+0000
source: https://www.aveshina.my.id/en/blog/dns-and-cdn
---

"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:

```figure
<svg viewBox="0 0 740 280" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="Pull vs Push CDN. Left, Pull: a user request hits the CDN edge, which on a miss fetches from the origin and caches; subsequent requests are served from the edge. Right, Push: the origin uploads content to the CDN directly; users always get cached content.">
  <defs>
    <marker id="cdnarrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto">
      <path d="M0,0 L10,5 L0,10 z" fill="#64748b"/>
    </marker>
  </defs>
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">

    <!-- PULL -->
    <text x="185" y="24" font-size="12" font-weight="700" fill="#1e1b4b" text-anchor="middle">Pull CDN</text>
    <text x="185" y="40" font-size="10" fill="#64748b" text-anchor="middle">fetch on first request</text>
    <rect x="30" y="60" width="80" height="36" rx="8" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <text x="70" y="83" font-size="11" font-weight="700" fill="#1e1b4b" text-anchor="middle">user</text>
    <rect x="160" y="60" width="100" height="36" rx="8" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.5"/>
    <text x="210" y="83" font-size="11" font-weight="700" fill="#422006" text-anchor="middle">CDN edge</text>
    <rect x="310" y="60" width="90" height="36" rx="8" fill="#dcfce7" stroke="#16a34a" stroke-width="1.5"/>
    <text x="355" y="83" font-size="11" font-weight="700" fill="#052e16" text-anchor="middle">origin</text>
    <path d="M110,78 L158,78" fill="none" stroke="#64748b" stroke-width="1.5" marker-end="url(#cdnarrow)"/>
    <path d="M260,78 L308,78" fill="none" stroke="#dc2626" stroke-width="1.5" stroke-dasharray="4 3" marker-end="url(#cdnarrow)"/>
    <text x="284" y="71" font-size="9" fill="#dc2626" text-anchor="middle">miss → fetch</text>
    <text x="185" y="125" font-size="10" fill="#1e1b4b" text-anchor="middle" font-style="italic">slower first hit; cached after TTL</text>
    <text x="185" y="142" font-size="10" fill="#1e1b4b" text-anchor="middle">good for heavy-traffic sites</text>

    <!-- PUSH -->
    <text x="555" y="24" font-size="12" font-weight="700" fill="#500724" text-anchor="middle">Push CDN</text>
    <text x="555" y="40" font-size="10" fill="#64748b" text-anchor="middle">origin uploads content</text>
    <rect x="430" y="60" width="80" height="36" rx="8" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <text x="470" y="83" font-size="11" font-weight="700" fill="#1e1b4b" text-anchor="middle">user</text>
    <rect x="540" y="60" width="100" height="36" rx="8" fill="#fce7f3" stroke="#db2777" stroke-width="1.5"/>
    <text x="590" y="83" font-size="11" font-weight="700" fill="#500724" text-anchor="middle">CDN edge</text>
    <rect x="670" y="60" width="60" height="36" rx="8" fill="#dcfce7" stroke="#16a34a" stroke-width="1.5"/>
    <text x="700" y="83" font-size="11" font-weight="700" fill="#052e16" text-anchor="middle">origin</text>
    <path d="M470,78 L470,140 L590,140 L590,98" fill="none" stroke="#64748b" stroke-width="1.5" marker-end="url(#cdnarrow)"/>
    <path d="M670,78 L640,78" fill="none" stroke="#16a34a" stroke-width="1.5" marker-end="url(#cdnarrow)"/>
    <text x="655" y="71" font-size="9" fill="#16a34a" text-anchor="middle">upload</text>
    <text x="555" y="160" font-size="10" fill="#500724" text-anchor="middle" font-style="italic">content placed once; max storage, min traffic</text>
    <text x="555" y="177" font-size="10" fill="#500724" text-anchor="middle">good for low-traffic or rarely-updated sites</text>
  </g>
</svg>
```

- **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/](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](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](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/](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](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](https://www.jscape.com/blog/load-balancing-algorithms)

```quiz
Q: A Pull CDN fetches content from the origin…
- whenever the origin uploads it
- on the first user request (a cache miss), then caches it for the TTL
correct: 1
explain: Pull CDNs grab content on first request and cache it. Push CDNs receive content when the origin uploads it directly.

Q: Which DNS record type points a name to another name (an alias)?
- A record
- CNAME
correct: 1
explain: A CNAME (canonical name) maps a name to another name. An A record maps a name directly to an IPv4 address.

Q: Why does a DNS change take time to reach all users?
- DNS changes require manual approval by each ISP
- each level of DNS caches the record for its TTL, so updates propagate only as caches expire
correct: 1
explain: DNS is heavily cached at every level. A change is visible only after each cache's TTL expires, which is why DNS propagation is not instant.

Q: A globally distributed user reports the site is slow, but the origin server is healthy. The most likely cause is…
- a bug in the application code
- geography — the origin is far from the user, and no nearby edge is serving them
correct: 1
explain: For far-away users, the floor on latency is distance. The fix is edge placement (CDN) or latency-based DNS routing to a nearer region, not application code.
```