How CDNs Use DNS to Route Users

The CNAME chain

A CNAME record says that one name is an alias for another. The resolver follows the alias and keeps going until it finds the address records at the end. With a CDN, that chain usually crosses at least one boundary between zones run by different operators:

Here is what that looks like from the command line:

$ dig +noall +answer www.example.com A
www.example.com.            3600  IN  CNAME  example.cdn.example.net.
example.cdn.example.net.    300   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 can be long-lived because it rarely changes. The CDN's final records are short, so the CDN can move users to a different site within seconds if one gets busy or fails. Some CDNs add an intermediate CNAME, as above, to separate the customer-facing name from the steering logic.

The CNAME approach has one well-known limit: a CNAME cannot exist at the zone apex, because the apex must also hold SOA and NS records. CDNs and DNS providers work around this with ALIAS records, CNAME flattening, or by giving you fixed anycast addresses for the apex. CNAME at the Apex: ALIAS and Flattening explains the options.

DNS-based steering

In a DNS-steered CDN, each site has its own addresses, and the CDN's authoritative servers choose which site's addresses to return. The choice can weigh the estimated location of the requester, measured network latency from that area, how loaded each site is, and whether it is healthy. This is a specialized form of the technique described in GeoDNS and DNS Load Balancing.

The catch is that the CDN's name servers never see the user. They see the recursive resolver that is asking on the user's behalf. That works well when users sit close to their resolver, as with most ISP resolvers. It works less well when a user in one city relies on a public or corporate resolver whose queries leave from somewhere else. The CDN then picks an edge near the resolver, which may be far from the user.

EDNS Client Subnet

EDNS Client Subnet (ECS), defined in RFC 7871, Client Subnet in DNS Queries, lets a resolver pass along part of the client's address. Instead of the full address, the resolver sends a truncated prefix, commonly a /24 for IPv4 or a /56 for IPv6. The CDN can then answer for the client's network rather than the resolver's location, and it returns a scope length telling the resolver how widely it may reuse that answer from cache.

You can see ECS in action with dig, which can add the option itself:

$ dig +noall +answer +subnet=198.51.100.0/24 example.cdn.example.net A @ns1.cdn.example.net
example.cdn.example.net.    20    IN  A      198.51.100.200

$ dig +noall +answer +subnet=192.0.2.0/24 example.cdn.example.net A @ns1.cdn.example.net
example.cdn.example.net.    20    IN  A      203.0.113.44

ECS is a trade-off. It improves edge selection, but it reveals part of each user's address to every authoritative server along the way, and it splits the resolver's cache into many smaller per-subnet caches, which lowers hit rates. RFC 7871 itself discusses these privacy concerns. Some public resolvers send ECS only to authoritative servers that ask for it, and some do not send it at all.

Anycast instead of DNS steering

Many CDNs take a different approach: they announce the same IP prefixes from every site using BGP, and their DNS returns the same addresses to everyone. The network decides which site each user reaches, based on routing between the user's provider and the CDN. If BGP is unfamiliar, start with BGP Basics: How Internet Routing Works; DNS Anycast Explained covers the same technique applied to name servers.

In practice many CDNs combine the two. They use anycast for robustness and DDoS absorption, and DNS to pick between several anycast groups or to move traffic away from a region during maintenance.

Troubleshooting CDN DNS

When a CDN-fronted site misbehaves for some users, start by establishing what each group of users is being told:

• Query your own authoritative servers to confirm the CNAME to the CDN is what you expect.
• Query the CDN hostname through several resolvers and compare the answers. Different addresses are normal; failures or empty answers are not.
• Check the TTLs. If you recently changed the CNAME, resolvers may still hold the old target until your old TTL expires.
• If the CDN publishes HTTPS records, check them too, since browsers may use them for protocol and address hints; see SVCB and HTTPS DNS Records.

Also watch for the opposite problem. When you stop using a CDN, remove the CNAME. A record that still points to a CDN hostname you no longer control can let someone else claim that hostname on the CDN and serve content as your domain. Subdomain Takeover Attacks: What They Are and How to Stop Them explains the risk.

How DNS Panopticon helps

Website Recon follows the CNAME chain and matches CNAME suffixes, name servers, and the AS number of each resolved address against its provider catalog, so it can tell you when a name sits behind a CDN. When it detects one, it stops there and warns that the origin may be hidden, rather than guessing. Domain Visualizer resolves the domain's public records live and shows the names, record types, and values in its graph, which makes long CNAME chains easy to follow. With the paid plan, Domain Visualizer Advanced also lists subdomains from Certificate Transparency logs and shows which still resolve, a useful way to spot old CNAMEs to a CDN you no longer use.