How do CDNs use DNS to route traffic?

Sajjad
DNS
10 Oct, 2026

CDNs use DNS as the switch that decides which of their servers each visitor connects to. When you put a site behind a CDN, you either point a hostname such as www.example.com at a CDN-provided name with a CNAME record, or you move your whole zone to the CDN's nameservers. From then on, the CDN's own DNS servers answer the final lookup, and they return the IP address of an edge server chosen for that visitor, based on their location, the health and load of each edge, and the CDN's own network conditions. Some CDNs return the same anycast address everywhere and let internet routing pick the nearest edge; others return different unicast addresses per region. Many use a mix of both.

Because the decision happens at lookup time, DNS settings such as TTLs, the client subnet extension and how your apex domain is configured directly affect how well a CDN can do its job. In this article you'll learn the two main ways a domain hands control to a CDN, how a CDN's DNS picks an edge server, how anycast and DNS-based steering differ, what you can see with dig, and the DNS details that matter when you set up or move between CDNs.

Why CDNs Rely on DNS

A CDN has servers in many cities around the world. To make a site faster, each visitor needs to reach a server that's close to them in network terms, healthy, and not overloaded. The CDN has to make that decision before the visitor's browser opens a connection, and the only thing that happens before a connection is the DNS lookup.

DNS gives CDNs several useful properties:

Every client does it: Browsers, apps and APIs all resolve the hostname first.
It's controlled by the CDN: Once a hostname delegates to the CDN's DNS, the CDN decides every answer.
It can vary by requester: The CDN can return different answers depending on which resolver is asking, and with ECS, roughly where the user is.
It can change quickly: Short TTLs let the CDN move traffic away from a failing or overloaded location within seconds or minutes.

How a Domain Hands Control to a CDN

There are two common ways to put a site behind a CDN.

Option 1: A CNAME to the CDN's Hostname

You keep your DNS where it is and add a CNAME record for each hostname you want to accelerate. The CDN gives you a target name in its own domain:

www.example.com.  3600  IN  CNAME  www.example.com.cdn.example.net.

When a resolver looks up www.example.com, your DNS provider returns the CNAME, and the resolver then looks up the CDN's hostname. That second lookup goes to the CDN's nameservers, which return the edge address. Some CDNs add further CNAMEs inside their own domains to separate configuration from routing, so the full chain can have several steps.

This is how many CDNs and cloud platforms work, including Amazon CloudFront, Fastly, Akamai and Azure Front Door, as well as hosting platforms that put their own CDN in front of your site.

Option 2: Moving Your Nameservers to the CDN

Some CDNs, Cloudflare being the best-known example, act as your authoritative DNS provider. You change your domain's nameservers at the registrar to the CDN's, and the CDN answers every query for your zone directly. For hostnames you've marked as proxied, it returns its own edge addresses instead of your origin's.

$ dig example.com NS +short
ada.ns.cdn-provider.example.
bob.ns.cdn-provider.example.

This avoids the extra CNAME lookup and makes it easy to proxy the apex domain, at the cost of moving your entire DNS to that provider.

Comparison

	CNAME setup	Full nameserver setup
Where your DNS lives	Your existing DNS provider	The CDN
Apex domain support	Needs ALIAS, ANAME, CNAME flattening or static IPs	Works natively
Extra lookups	At least one extra CNAME step	None
Switching CDNs	Change a CNAME	Move your whole DNS zone
Multi-CDN	Easier to combine with traffic steering	Ties DNS and CDN together

The Apex Domain Problem

A CNAME can't be placed at the zone apex (example.com itself), because the apex must also hold SOA and NS records and a CNAME can't coexist with other records at the same name. If you use the CNAME method and want example.com on the CDN, your options are:

A provider-specific ALIAS, ANAME or CNAME flattening feature, where your DNS provider resolves the CDN hostname itself and returns the resulting addresses.
Static anycast IP addresses that some CDNs offer for exactly this purpose, used in plain A and AAAA records.
A redirect from example.com to www.example.com, keeping only www on the CDN.

How a CDN's DNS Chooses an Edge Server

Once the query reaches the CDN's authoritative servers, they decide what to return. The exact methods are proprietary, but the inputs are well understood.

1. Where the Query Comes From

The CDN looks at the resolver's IP address, and at the EDNS Client Subnet (ECS) option if the resolver sends one, which carries a truncated version of the user's address. It maps that to a location and a network, using geolocation data and the CDN's own measurements of which networks it reaches well from which locations.

2. Edge Health and Capacity

The CDN continually monitors its own locations. An edge that's down, under maintenance or near capacity can be left out of answers, and traffic shifted to the next-best location.

3. Network Performance

Large CDNs measure latency and packet loss between their locations and the world's networks. They can prefer a slightly more distant edge if it has a better path to a particular ISP.

4. Your Configuration

Your plan, the regions you've enabled, and features such as geo-restrictions or price tiers that exclude expensive regions all constrain which edges can be returned.

5. Short TTLs

CDN answers typically have short TTLs, often between 20 and 300 seconds. That lets the CDN react quickly to changes, at the cost of more lookups. Your own CNAME record pointing at the CDN can usually have a longer TTL, since it rarely changes.

Anycast vs DNS-Based Steering

CDNs use two broad approaches to get users to the right place, and many combine them.

Anycast

With anycast, the same IP address is announced from many locations at once using BGP. The CDN's DNS can return the same address to everyone, and internet routing delivers each user's packets to the nearest location announcing it, in network terms.

$ dig www.example.com A +short
www.example.com.cdn.example.net.
192.0.2.80

A user in Tokyo and a user in London might both get 192.0.2.80, yet reach completely different servers. Anycast makes the resolver's location much less important and handles failover at the routing layer: if a location withdraws its announcement, traffic flows to the next one.

DNS-Based Steering

With DNS-based steering, the CDN returns different unicast addresses depending on where the query comes from. A resolver in Europe might get an address in Frankfurt, and one in Asia an address in Singapore.

This gives the CDN very fine control over which edge each population of users reaches, but it depends heavily on knowing where users are. That's where ECS and the resolver's location matter most. Without ECS, a user of a distant public resolver may be routed according to the resolver's location rather than their own.

	Anycast	DNS-based steering
Same IP for everyone	Yes	No
Who picks the location	BGP routing	The CDN's DNS servers
Sensitive to resolver location	Less	More, unless ECS is used
Failover	Routing changes, usually fast	DNS answer changes, limited by TTL
Fine-grained control	Limited by routing	High

Combined Approaches

Many CDNs return a small set of anycast addresses that differ by region, or use anycast for their DNS servers and DNS steering for the edge addresses. Anycast is also used almost universally for the CDN's authoritative nameservers themselves, so the DNS lookup is fast wherever the user is.

Seeing It for Yourself with dig

You can follow the chain for any CDN-hosted site.

Follow the CNAME Chain

$ dig www.example.com A +noall +answer
www.example.com.                    3600  IN  CNAME  www.example.com.cdn.example.net.
www.example.com.cdn.example.net.    60    IN  CNAME  edge-eu.cdn.example.net.
edge-eu.cdn.example.net.            20    IN  A      203.0.113.44
edge-eu.cdn.example.net.            20    IN  A      203.0.113.45

Notice the TTLs: your own CNAME lasts an hour, while the CDN's internal records last seconds. That's typical.

Compare Answers from Different Resolvers

Different resolvers are in different places and treat ECS differently, so they often get different edges:

for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  printf '%-10s ' "$r"
  dig @"$r" www.example.com A +short | tail -n1
done

Simulate a Client Subnet

Ask the CDN's authoritative nameserver directly with an ECS option to see whether answers vary by subnet. Find the nameserver for the CDN's domain, then query it:

dig cdn.example.net NS +short
dig @ns1.cdn.example.net www.example.com.cdn.example.net A +subnet=198.51.100.0/24

A CLIENT-SUBNET line with a non-zero scope in the response means the CDN used the subnet to pick the answer. Use real prefixes from the regions you care about, since documentation ranges don't map to real locations.

Check Which Edge You Reached

Many CDNs add a response header showing which location served the request. You can check it with curl:

curl -sI https://www.example.com/ | grep -iE 'server|via|x-cache|cf-ray|x-served-by|x-amz-cf-pop'

The header names vary by CDN, but they often include an airport-style code for the location.

Multi-CDN and DNS Traffic Steering

Larger sites sometimes use more than one CDN, for resilience or to get the best performance in every region. DNS is the natural place to decide which CDN each user gets.

A typical setup puts a traffic steering layer in front of the CDNs:

www.example.com.            300  IN  CNAME  www.steering.example.org.
; The steering provider then answers with a CNAME to one CDN or the other:
; www.steering.example.org.  60  IN  CNAME  www.example.com.cdn-a.example.net.
; www.steering.example.org.  60  IN  CNAME  www.example.com.cdn-b.example.net.

The steering provider, often a managed DNS service with weighted, geographic, latency-based or real-user-measurement routing, chooses a CDN for each query. If one CDN has problems, its share can be cut to zero within a TTL or two.

Multi-CDN brings its own work: both CDNs must have the same configuration, valid TLS certificates for your hostnames, and access to your origin.

DNS Details That Matter When Using a CDN

Keep Your Origin Hostname Separate

The CDN needs to know where to fetch content from. Use a dedicated origin name, such as origin.example.com, pointing at your server's real IP. Don't point the CDN at www.example.com if that name itself resolves to the CDN, or you'll create a loop.

If you're relying on the CDN to hide your origin's IP address, be careful about which other records reveal it. Old A records, mail servers on the same IP and historical DNS data can all expose it. Firewall the origin so it only accepts traffic from the CDN's published IP ranges.

Domain Verification and Certificates

CDNs need to prove you control the hostname before they serve HTTPS for it. They typically ask you to add a TXT or CNAME record for domain validation, or they validate automatically once the CNAME points at them. If you use CAA records, make sure they allow the certificate authority your CDN uses, otherwise certificate issuance fails.

HTTPS Records

Some CDNs publish HTTPS (type 65) records, which tell browsers in the DNS response itself that a site supports HTTP/3 and other connection options, saving a round trip. If your zone is hosted by the CDN, this may happen automatically. You can check with:

dig www.example.com HTTPS +short

Switching CDNs Safely

When you move from one CDN to another:

Set up the new CDN completely, including certificates, before changing DNS.
Test it by pointing a test hostname at it, or with curl --resolve to send a request to the new edge directly.
Lower the TTL on your CNAME a day or so before the switch.
Change the CNAME to the new CDN's hostname.
Keep the old CDN running until traffic has drained, at least a few times the old TTL.

To test a new edge before switching, resolve the new CDN's hostname and send a request to that address with your real hostname:

NEW_IP=$(dig www.example.com.newcdn.example.net A +short | tail -n1)
curl -sI --resolve "www.example.com:443:${NEW_IP}" https://www.example.com/

FAQ: How CDNs Use DNS

The CNAME hands the final lookup to the CDN's own DNS servers. That lets the CDN choose which edge server address to return for each visitor, based on location, health and load, without you changing your DNS provider.

Yes, but you can't use a plain CNAME at the zone apex. Use your DNS provider's ALIAS, ANAME or CNAME flattening feature, static anycast IPs from the CDN, move your DNS to the CDN, or redirect the root domain to www.

Short TTLs let the CDN change which edge it returns within seconds or minutes, so it can route around failures, congestion and maintenance. Your own CNAME pointing to the CDN can use a longer TTL because it rarely changes.

Not necessarily. Anycast CDNs often return the same address everywhere and let routing choose the location, while DNS-steered CDNs return different addresses for different regions. Many CDNs use a mix of both.

It can. A CDN that uses DNS-based steering sees the resolver's location, and the user's subnet only if the resolver sends EDNS Client Subnet. Anycast CDNs are much less affected by which resolver you use.

Check the response headers with curl -I. Many CDNs include a header naming the location or server that handled the request, often with an airport-style code.

Yes. A DNS traffic steering service can return a CNAME to one CDN or the other for each query, using weights, geography or performance data. Both CDNs need matching configuration and valid certificates.

Conclusion

CDNs use DNS to decide which edge server each visitor connects to. A CNAME or a nameserver change hands the final lookup to the CDN's DNS, which then returns an address chosen by location, health, load and network performance. Anycast lets one address reach the nearest location through routing, DNS-based steering returns different addresses per region, and short TTLs let the CDN change its mind quickly.

Understanding this makes CDN setups much easier to get right. Use a separate origin hostname, handle the apex domain with flattening, ALIAS or static IPs, keep CAA and verification records in order, and use dig and curl to see which edge your users are really reaching. When it's time to switch or add a CDN, DNS is also the tool that lets you do it gradually and safely.