Anycast CDN vs. DNS-based CDN: What's the Difference and How Should a Typical Website Choose?

If queries for the same CDN domain from Beijing, Shanghai, and Singapore return three different IPs, this is usually interpreted as DNS-based traffic steering. If all three return the same IP but connect to nodes in different cities, the CDN may be using Anycast.

Both approaches direct users to distributed CDN nodes, but they select nodes at different stages:

DNS-based steering selects an entry address during domain resolution; Anycast lets internet routing choose the actual access node when the user connects to the IP.

This does not mean the two architectures are mutually exclusive. Many CDNs first use DNS to assign users to a region, network line, or address pool, then use Anycast within that pool. Others let global users resolve to the same Anycast IP while using DNS for domain onboarding, IPv4 and IPv6 responses, and product policy control.

Ordinary websites should understand this difference, but there is no need to switch CDNs just because a vendor promotes “global Anycast.” What matters is where target users are routed, whether the actual connection is stable, whether traffic can fail over, and whether access results across regions and ISPs meet business requirements.

How an Anycast CDN selects nodes

Anycast allows nodes in multiple locations to advertise the same IP address or IP prefix.

For example, a CDN advertises the same address from Tokyo, Singapore, Los Angeles, and Frankfurt:

203.0.113.20

Users querying the domain all receive:

www.example.com → 203.0.113.20

But where the user actually connects is determined by BGP routing:

东京用户
   └── 203.0.113.20 → 东京或附近节点

新加坡用户
   └── 203.0.113.20 → 新加坡或附近节点

德国用户
   └── 203.0.113.20 → 法兰克福或附近节点

RFC 4786’s description of Anycast service operationdescribes Anycast as having multiple independent instances of the same service address, with the internet routing system delivering packets to one of them. In global BGP deployments, a relatively stable egress path is usually selected for the same destination address.

Note that the node selected by routing is not necessarily the closest on a map. BGP focuses more on network reachability, carrier policy, route attributes, and peering relationships, so the following can occur:

• A user in city A connects to a node in city B;

• Two ISPs in nearby locations enter different nodes;

• The region is unchanged, but the access point changes after the user switches ISPs;

• The same IP takes different network paths at different times.

So the claim that “Anycast automatically selects the physically closest node” is not accurate. A better description is that network routing, based on currently visible paths and routing policy, takes the user to one of the nodes advertising that address.

How a DNS-steered CDN selects nodes

DNS steering happens before the user establishes an HTTP or HTTPS connection.

A typical process is:

用户查询：www.example.com
        ↓
CNAME：www.example.com.cdn-provider.example
        ↓
CDN权威DNS根据地区、运营商、健康状态或策略选择答案
        ↓
返回：203.0.113.31
        ↓
用户连接该IP

Users from other regions may receive a different answer:

北京电信 → 203.0.113.31
广州移动 → 203.0.113.42
新加坡   → 203.0.113.53

DNS steering can select an entry point based on various conditions, such as:

• The location of the recursive DNS resolver;

• The ISP operating the recursive DNS resolver;

• Client subnet hints provided by EDNS Client Subnet;

• Node health status;

• Current capacity and business policies;

• IPv4 or IPv6 protocol;

• Domain, plan, or customer-defined rules.

AWS Route 53’slatency-based routing documentationprovides a clear example: after receiving a query, the authoritative DNS service selects the region expected to provide lower latency from the configured regions and returns the corresponding record.

However, DNS steering usually sees the recursive resolver that performs the query on the user’s behalf, not the browser itself. If a user in Guangzhou uses a public DNS service with a different egress location, the CDN may return a node based on the resolver’s location, and the result may not suit the user’s actual network.

The core difference between Anycast and DNS steering

This table describes typical designs; not all CDNs use exactly the same implementation. Vendors may use different steering architectures across products, regions, and plans.

Anycast CDNs also need DNS

A common misconception is: “Once you use Anycast, you no longer need DNS steering.”

In practice, users access a domain, so they still need DNS to obtain A or AAAA records:

www.example.com
        ↓ DNS
203.0.113.20
        ↓ Anycast路由
某个CDN接入节点

DNS is still responsible for:

• Mapping business domains to Anycast addresses;

• Returning IPv4 and IPv6 entry points;

• Handling CNAME onboarding;

• Controlling address pools for different domains or products;

• In some cases, performing region- or line-level selection.

Therefore, you cannot determine whether a CDN uses Anycast just by whether it requires CNAME configuration. Both DNS-steered and Anycast CDNs may use CNAME onboarding.

Likewise, receiving the same IP from global queries is only a clue for Anycast; it does not by itself prove that the IP uses Anycast. It could simply be a fixed single-point address, a regional entry, or a load balancer address.

DNS steering may also return an Anycast IP

Another common architecture is DNS grouping first, followed by Anycast access within each group:

用户DNS查询
     ↓
按区域分配地址池
     ↓
亚洲地址：203.0.113.20
欧洲地址：203.0.113.30
     ↓
每个地址又由区域内多个节点Anycast公布

In this case, Beijing and Singapore may see the same Asia Anycast IP, while London sees a different Europe Anycast IP.

So dividing CDNs simply into “Anycast CDN” and “DNS-steered CDN” helps explain the principles, but it cannot fully describe the real architecture of large CDNs. Many networks actually use hybrid steering.

For website operators, the valuable question is not “which type is it,” but:

DNS先把用户分到了哪个地址池？
这个地址在用户网络中进入了哪个节点？
节点异常后如何切走？
切换需要多久？
切换期间已有连接会怎样？

The same IP does not mean the same node

With Anycast, different regions seeing the same IP can be completely normal.

For example:

北京：203.0.113.20
上海：203.0.113.20
新加坡：203.0.113.20

The IP string is the same in all three locations, but the routing endpoints may differ.

This is why IP geolocation lookups are often misleading. A database may show:

• The location of the IP registry;

• The network operator’s address;

• A representative data center;

• A historical collection location;

• A generic label for the address block.

It does not necessarily represent the edge data center that a given request actually reaches.

Conversely, different IPs returned by DNS do not guarantee three different physical servers. Different IPs may lead to the same data center, the same node cluster, or the same Anycast network.

For more on interpreting IP changes, seeWhy Do Different Regions See Different CDN Node IPs?.

How failover works when Anycast fails

When an Anycast node or data center becomes unavailable, the CDN can stop advertising the route from that location, and the internet may then send new traffic to other nodes still advertising the address.

From the perspective of DNS answers, this process may cause no change:

故障前：203.0.113.20 → 节点A
故障后：203.0.113.20 → 节点B

The advantage is that users do not have to wait for a DNS answer to change, and the IP address can remain the same.

But this does not mean the switch is completely seamless:

• Route changes require propagation and convergence time;

• Established TCP or QUIC connections may be interrupted;

• The new node’s cache state may differ;

• If the route withdrawal scope is incorrect, users may be sent to a farther node;

• If a node’s service is unhealthy but its route is still advertised, traffic may continue to enter the failed node.

Anycast only solves the problem of “how to serve the same address from multiple locations.” It does not automatically handle application health checks, configuration synchronization, cache consistency, or session handling.

How failover works when DNS steering fails

DNS steering can use health checks or manual policies to switch subsequent queries to other nodes:

故障前：
www.example.com → 203.0.113.31

切换后：
www.example.com → 203.0.113.42

But when a user receives the new answer is affected by multiple cache layers:

浏览器DNS缓存
操作系统DNS缓存
本地路由器缓存
运营商或公共递归DNS缓存
权威DNS返回记录的TTL

Even after the authoritative DNS is updated, some users may continue using the old IP for a period. Established long-lived connections also do not automatically migrate because the DNS answer changed.

Setting a very low TTL can shorten some cache periods, but it is not an “instant failover” button. An excessively low TTL also increases query frequency and makes the stability of authoritative DNS and steering systems more important.

To learn more about DNS caching, TTL, and the impact of recursive resolvers, seeDoes Slow DNS Resolution Slow Down a CDN? How to Troubleshoot Domain Resolution Time.

Why EDNS Client Subnet affects DNS steering

Authoritative DNS usually sees the recursive resolver’s IP, not the end user’s IP. EDNS Client Subnet (ECS) lets a recursive resolver include partial client subnet information in queries, helping authoritative DNS return answers closer to the user’s location.

RFC 7871defines this DNS extension, which carries network information about the query origin and the network scope to which subsequent answers apply.

However, not all resolvers support ECS, and not all CDNs use it in the same way. It also involves two practical trade-offs:

• The more specific the client subnet passed along, the more precise the location estimate may be—but the greater the privacy exposure;

• Generating more DNS answers by subnet reduces the reuse efficiency of recursive caches.

So after users switch to a different ISP DNS or public DNS, they may receive different CDN IPs. This does not necessarily mean one DNS is hijacked; it may simply reflect differences in recursive resolver location, ECS support, and caching policy.

How to tell which steering method a website likely uses

With only external observation, you can collect DNS and network results from multiple regions, but do not draw conclusions from a single symptom.

Step 1: Check CNAME, A, and AAAA records

dig www.example.com CNAME +noall +answer
dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer

Record:

CNAME链
IPv4地址
IPv6地址
TTL
查询时间
使用的递归DNS

Step 2: Compare answers from different recursive DNS resolvers

dig @1.1.1.1 www.example.com A +noall +answer
dig @8.8.8.8 www.example.com A +noall +answer

If the answers differ, DNS steering may be in use—or different resolvers may simply have cached results from different times.

Public DNS services may also use Anycast, so queries from a command line go to a resolver node closer to the tester. This cannot simulate the real user environment in Beijing, London, or New York.

Step 3: Test actual connections from different regions

curl -sS -o /dev/null \
  -w 'ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/

What is truly valuable is to record both:

测试地区和运营商
DNS返回地址
实际连接地址
TCP连接时间
TLS完成时间
TTFB
状态码

If different regions receive the same IP but show clearly different connection times and network paths, Anycast may be in use; if different regions consistently receive different IPs, DNS-based regional or line steering may be in use.

Both phenomena are only one piece of evidence. You can use CDNChart’sCDN detection toolto view CNAME, A/AAAA, ASN, and vendor clues, then combine multi-region website speed tests to observe actual connection results.

Step 4: Compare network paths

traceroute www.example.com

or:

mtr -rwzc 30 www.example.com

Run tests from multiple regions against the same IP. If the paths ultimately enter different regions or network entry points, this further supports an Anycast assessment.

But traceroute also has limitations:

• Some nodes do not reply to ICMP;

• Intermediate routers may be hidden;

• The return path may differ from the forward path;

• Networks such as MPLS may not reveal the real internal path;

• IP geolocation may be inaccurate.

Therefore, external tests can usually only indicate “suspected Anycast” or “suspected DNS steering”; they cannot fully reconstruct a vendor’s internal routing design.

Is Anycast always faster than DNS steering?

Not necessarily.

Anycast’s advantage is that it uses a stable address and relies on network routing to select the entry point, which may reduce dependence on fine-grained DNS geolocation. But if an ISP sends traffic to a distant node, Anycast can also cause detours.

DNS steering can return different nodes by region and ISP, making it easier to implement fine-grained policies in markets with significant network differences. But if recursive DNS location is inaccurate, TTLs cache old answers, or authoritative DNS steering is misconfigured, it can also assign users to unsuitable entry points.

What determines access speed is the entire path:

DNS解析
→ 节点选择
→ 网络路由
→ TCP或QUIC连接
→ TLS握手
→ CDN缓存
→ 回源
→ 内容传输

Steering technology is only one part of that. A well-designed DNS-steered CDN may be faster than an Anycast CDN with poor routing quality—and vice versa.

Is Anycast always more resistant to DDoS?

Anycast allows multiple nodes to advertise the same service address, so attack traffic may be distributed across multiple network entry points. It is therefore often used for large public services and DDoS protection networks.

But “using Anycast” does not mean “automatically having unlimited protection capacity.” Actual protection results also depend on:

• Total network capacity;

• Regional scrubbing capacity;

• Attack detection and traffic diversion policies;

• Cooperation with upstream carriers;

• Route control capabilities;

• Single-node capacity and isolation design;

• Application-layer WAF, rate limiting, and bot management;

• Whether failed nodes can withdraw routes promptly.

DNS steering can also distribute traffic across nodes or switch to a backup network. When choosing a DDoS-protected CDN, verify the protection boundaries, scrubbing locations, and fault-handling methods; do not rely only on whether Anycast is advertised.

How much should ordinary websites care?

If a website’s users are concentrated in one region and the business is mainly a corporate showcase, blog, or small to medium-sized e-commerce site, there is usually no need to make a decision based on the technical labels “Anycast” and “DNS steering.” More important is to test:

• Whether access is stable in key user regions;

• Whether local ISPs have clearly slow routes;

• Whether IPv4 and IPv6 performance is consistent;

• Whether TLS, TTFB, and download speeds are reasonable;

• Whether the service can recover when a node fails;

• Whether caching, origin fetch, and security features meet requirements;

• Whether plan costs and technical support are a good match.

The following types of businesses should pay closer attention to steering methods:

Users are distributed across multiple countries and regions.

You need to confirm how each region selects nodes, whether cross-continent detours occur, and where traffic will fail over.

The domestic market involves multiple ISPs.

Interconnection quality between China Telecom, China Unicom, China Mobile, and other networks may differ. Fine-grained DNS line steering, regional Anycast, or a combination of both can affect actual results.

Real-time interactive, gaming, and live streaming services.

These services are more sensitive to jitter, packet loss, path changes, and long-connection stability. Do not look only at first byte; also monitor route changes and connection continuity during the session.

High-availability or multi-CDN architectures.

Multi-CDN usually selects vendors through DNS or a higher-layer traffic steering system, while each CDN may use Anycast internally. For details, seeCan One Website Use Multiple CDNs? How to Interpret Results from Multiple Providers.

Businesses with high DDoS risk.

You need to confirm how Anycast entry points, scrubbing centers, route withdrawal, backup networks, and application-layer protection work together—not just the number of nodes.

What questions should you ask when choosing a CDN?

Rather than asking only “Are you Anycast?”, break the questions down more specifically:

主要用户地区通过什么方式选择节点？
是否按运营商或网络线路进行调度？
IPv4和IPv6是否采用相同覆盖范围？
同一Anycast地址在哪些地区公布？
节点故障时通过BGP还是DNS切换？
DNS调度记录的TTL是多少？
递归DNS定位错误时如何处理？
是否支持ECS，使用到什么网段范围？
故障节点退出后，已有连接如何处理？
能否提供目标地区的测试域名和实时数据？

A vendor that can answer these questions clearly is more useful than one that simply displays the phrase “global Anycast network.”

Frequently asked questions

Does an Anycast CDN always resolve to only one IP?

Not necessarily. A CDN may provide multiple IPv4 or IPv6 Anycast addresses, or may first return different address pools through DNS. Multiple IPs do not mean Anycast is not in use.

If different regions resolve to the same IP, is it definitely Anycast?

Not necessarily. The same IP may be an Anycast entry point, or it may simply be a fixed single point, regional gateway, or load balancer address. You also need to consider multi-region network paths, ASN, latency, and vendor information.

If different regions resolve to different IPs, is it definitely DNS steering?

It usually indicates that DNS answers differ, but this may also result from different cache times, record rotation, or configuration changes. Repeat the queries at the same time across multiple real regions.

Does changing public DNS affect the CDN node?

It may. CDN authoritative DNS may return addresses based on recursive resolver location or ECS information. After switching resolvers, users may get a different node, but different does not necessarily mean faster.

Will traffic fail over immediately after an Anycast node fails?

Immediate failover cannot be guaranteed. Route withdrawal and BGP convergence take time, and established connections may be interrupted. Recovery time depends on the CDN’s routing, health checks, and network design.

Does a lower DNS TTL always mean faster failover?

Not necessarily. A low TTL helps users obtain new answers faster, but recursive DNS, operating systems, and applications may still cache old answers, and existing connections will not automatically migrate because of a DNS update. TTL must also balance failover speed against query load.

Is Anycast better for global websites, while DNS steering is better for domestic websites?

It cannot be divided that simply. Global CDNs also often combine DNS steering, and domestic networks can also use Anycast or regional Anycast. Judge based on node coverage, ISP routes, routing quality, and actual test results.

Which should ordinary websites prioritize?

Ordinary websites do not need to use Anycast or DNS steering as the sole selection criterion. First compare success rates in target regions, P50/P95 latency, TLS, TTFB, download performance, and failover capability. If two providers perform similarly, then consider steering architecture, logging, cost, and technical support.