How CDN node mapping actually works
Anycast, GeoDNS, CNAME flattening — here's what's actually happening between the browser and the edge.
There’s an interview question that used to be a rite of passage in backend engineering: “Walk me through everything that happens when a user types a URL and hits enter.” Most answers got stuck on DNS and TLS. The part most people glossed over — how the request actually lands on the right CDN node out of thousands distributed globally — is where the interesting engineering lives.
Get the mapping wrong and your users in Singapore are hitting a PoP in Frankfurt. The latency shows up in your P75 TTFB, in your bounce rate, and eventually in your revenue numbers.
It starts with a CNAME
When you put a CDN in front of your application, you don’t hand over your primary A record. You create a CNAME pointing a subdomain (say, assets.example.com) at a CDN-controlled domain (abc123.cdnprovider.net). The CDN controls that domain, so it controls what IP gets returned — and that’s where the routing logic lives.
assets.example.com. CNAME abc123.cdnprovider.net.
Simple enough. But the root domain (example.com) is a different story.
The CNAME flattening problem
DNS forbids placing a CNAME at the zone apex. Your root domain needs NS, SOA, and MX records — and those can’t coexist with a CNAME (RFC 1912, §2.4). DNS providers work around this with CNAME flattening: they resolve the CNAME chain on your behalf and return A/AAAA records directly, making the apex behave as if it has ordinary IP records.
It looks clean from the outside. The problem is that the DNS query now originates from the flattening service’s servers, not from your end user. Any location-based routing logic downstream only sees the flattening server’s location. A user in Berlin whose DNS provider flattens from London gets routed as if they’re in London. The consequences of that depend on which routing method your CDN uses.
The two routing approaches
Anycast — let BGP decide
Anycast operates at Layer 3. The CDN announces the same IP block from hundreds of PoPs simultaneously via BGP. The user’s packet enters the internet, routers apply standard BGP path selection, and it naturally arrives at the topologically nearest PoP — without any application-layer involvement.
The upside is elegance. It works automatically, it degrades gracefully under DDoS (a volumetric attack gets spread across every PoP advertising the IP), and it requires no geo-IP database. The downside is limited control: BGP optimises for AS path length and routing policy, not latency. The CDN can’t easily override those decisions when the network disagrees with you.
GeoDNS — explicit geographic steering
GeoDNS operates at Layer 7. When a resolver queries the CDN’s authoritative DNS, the system inspects the source IP, consults a geo-IP database, and returns a specific unicast IP — the address of whichever PoP is designated for that region.
This gives precise control: route users in France to Paris, keep EU data in EU nodes for GDPR compliance, shift traffic away from a degraded PoP in real time. The trade-off is the resolver problem. GeoDNS only sees the recursive resolver, not the end user. A user in Paris whose ISP resolves via a Netherlands-based server gets routed as if they’re Dutch.
| Anycast | GeoDNS | |
|---|---|---|
| Routing layer | Network (BGP) | DNS (application) |
| User location accuracy | True end-user topology | Resolver location (approximated) |
| DDoS resilience | Automatic distribution | DNS-level mitigation required |
| Granular control | Limited | High |
| Data sovereignty | Difficult to enforce | Straightforward |
The Cloudflare and Akamai archetypes
These two routing philosophies explain the architectural DNA of the two largest CDNs better than any marketing material.
Cloudflare is primarily Anycast. Every PoP advertises the same IP ranges. Routing is automatic, resilience is built in, and the operational surface is minimal. You give up fine-grained steering in exchange for simplicity and near-automatic DDoS absorption. For most web applications, that’s a very good trade.
Akamai is primarily GeoDNS. Its SureRoute and Intelligent Platform technologies build a control layer on top of DNS — real-time performance data, health checks, and custom routing rules influence which PoP is returned for any given query. This is why Akamai is the default choice for enterprises with data residency requirements, complex traffic shaping needs, or SLAs that must be enforced at the routing layer. The operational complexity is real, but so is the control.
Both companies use hybrid approaches in practice — Cloudflare has GeoDNS elements for initial user distribution, Akamai uses Anycast in parts of its network. But the dominant philosophy shapes how each platform behaves under pressure and how much leverage you have when something goes wrong.
What this means in practice
If you’re selecting a CDN or investigating a routing anomaly, the Anycast vs. GeoDNS question should be upstream of almost everything else:
- Data residency requirements — GeoDNS is non-negotiable. You need a hard guarantee about which PoPs serve which users.
- DDoS resilience as the primary concern — Anycast’s automatic distribution is hard to beat.
- Regional latency anomalies — if your monitoring shows unexpected latency from specific geographies that doesn’t track with distance, the resolver problem is usually the first thing to investigate.
- Root domain on a CDN — understand how your DNS provider handles CNAME flattening and whether it degrades your geo-routing accuracy.
Getting the routing architecture right is the precondition for everything else. Cache hit ratios, TTFB optimisation, and Core Web Vitals all depend on users landing on the right node in the first place. Tune the cache all you like — if the wrong PoP is serving the request, you’re optimising the wrong thing.