What is Anycast and How Cloudflare Uses It to Make DNS Instant

If you have used Cloudflare DNS at 1.1.1.1, you have used anycast without probably realizing it. The same IP address answers your DNS query whether you are in New York, Frankfurt, or Singapore — and in each case you are hitting a different physical server. This is anycast, and it is one of the more elegant pieces of internet infrastructure.

The Four Routing Types

IP has four transmission types. Unicast is a one-to-one communication: one source, one specific destination. Broadcast sends to all devices on a network segment. Multicast sends to a group of interested receivers. Anycast sends to the nearest of a group of receivers — or more precisely, to whichever node the routing infrastructure considers topologically closest.

Anycast uses standard IP routing. Multiple servers in different locations all announce the same IP address block to the internet via BGP. Routers propagate these announcements, and internet routing naturally directs traffic to the closest (lowest-cost) announcement. The clever part is that from the client perspective, there is just one IP address — the routing infrastructure handles the direction transparently.

Why DNS Is Perfect for Anycast

DNS queries are stateless and tiny. Each query is independent, there is no session to maintain, and the response is complete in a single exchange. This makes DNS an ideal fit for anycast: there is no problem with different queries from the same client going to different servers, because each query carries everything the server needs to answer it.

Cloudflare operates 1.1.1.1 and 1.0.0.1 via anycast from over 300 data centers worldwide. When your device sends a DNS query to 1.1.1.1, it routes to whichever Cloudflare node is closest in network terms. For users in Europe that might be Frankfurt or Amsterdam; for users in Asia it might be Singapore or Tokyo. The result is DNS resolution times often under 10 ms, compared to 50–100+ ms for queries going to a remote resolver.

How CDNs Use Anycast

Most large CDNs use anycast for their authoritative DNS at minimum, and many also use it for HTTP traffic. When you connect to a Cloudflare-proxied website, your TCP connection terminates at the nearest Cloudflare edge node. That node then either serves a cached response or fetches from the origin on your behalf. The origin server only sees traffic from Cloudflare infrastructure, not directly from clients.

This architecture gives CDNs several advantages simultaneously: low latency (traffic terminates near users), DDoS resilience (attack traffic gets spread across hundreds of nodes rather than hitting one location), and high availability (if one data center goes offline, BGP routing automatically shifts traffic to the next nearest).

Anycast vs. Geolocation-Based Routing

Anycast is sometimes confused with geolocation-based DNS routing, where different DNS answers are returned for different source IPs. Both result in users connecting to nearby servers, but they work differently. Geolocation routing uses DNS to direct clients — the DNS server returns a different A record depending on where the query comes from. Anycast uses the routing layer — the same IP is announced everywhere and routers make the direction decision.

Anycast has lower overhead (no database of IP-to-location mappings required, no per-query routing logic) and handles edge cases better (clients using a resolver far from their actual location will still be routed well because the routing decision happens at each hop). Geolocation routing is more controllable and lets you make more sophisticated decisions about which backend to send users to.

The Limitation: TCP State

Anycast works seamlessly for stateless protocols like DNS over UDP. For TCP, there is a complication: a TCP connection involves state (sequence numbers, window sizes, session data) that only exists at the specific server that accepted the connection. If a route change mid-session causes packets to reach a different anycast node, that node has no knowledge of the connection and will reset it.

In practice, CDNs solve this by using anycast to route the initial connection to the nearest edge, and then maintaining the session state at that edge for the duration of the connection. Route changes mid-session are rare enough that they do not cause practical problems for most traffic.