What Is Anycast DNS, and How Does It Improve Reliability?

When you query 1.1.1.1 from London and someone else queries it from Sydney, you are both talking to the same IP address, but not to the same server. Each of you reaches a machine a few milliseconds away in your own region. That trick is anycast, and it is the reason the world's largest DNS services can answer billions of queries a day with low latency and shrug off failures and attacks that would flatten a single data center. This article explains how anycast DNS works at the routing level, why it improves reliability, what its trade-offs are, and what it takes to run it yourself. It goes deeper into the mechanism than the brief mention in how DNS can be used for load balancing, and it complements, rather than replaces, using multiple DNS providers for redundancy.

What Is Anycast DNS?

Anycast is a network addressing method in which the same IP prefix is announced from many locations at once. Routers on the internet send each packet to whichever announcement looks "closest" according to their routing tables. Anycast DNS applies this to DNS servers: dozens or hundreds of servers around the world share the same IP addresses, and each query lands on one of them.

It helps to compare the main addressing models:

Model	One address maps to	Example
Unicast	Exactly one host	A typical web server at 198.51.100.10
Anycast	The nearest of many hosts	Public resolvers, root servers, managed authoritative DNS
Multicast	A group of hosts that all receive the packet	Local network discovery protocols
Broadcast	Every host on a network segment	DHCP discovery on a LAN

With unicast DNS, your name server at 198.51.100.53 lives in one place. Every query from every continent travels to it, and if that site goes offline, it is gone. With anycast, 203.0.113.53 exists in many places simultaneously, and the internet's routing system picks one for each user.

How Anycast Works Under the Hood

BGP Does the Routing

The internet is a collection of independent networks, called autonomous systems, that exchange reachability information using the Border Gateway Protocol (BGP). Each network announces the IP prefixes it can deliver traffic to, and its neighbors propagate those announcements onward.

To build an anycast service, an operator places DNS servers in multiple points of presence (PoPs) and has every PoP announce the same prefix, for example 203.0.113.0/24, from the same autonomous system number. Routers that receive several announcements for that prefix choose one using BGP's normal decision process, which favors local business preferences first and shorter AS paths after that. The result is that each region's traffic flows to a nearby PoP.

"Nearest" Means Network-Nearest

An important subtlety: BGP picks the best route by policy and path length, not by physical distance or measured latency. Most of the time the chosen PoP is also geographically close, but not always. A user in one city can be routed to a PoP several countries away because their ISP has a cheaper peering arrangement there. Operators tune this with more PoPs, direct peering with large ISPs, and BGP techniques such as prepending and communities.

The set of users that ends up at a particular PoP is called its catchment. Managing catchments is a large part of running a good anycast network.

Why DNS and Anycast Fit Together So Well

Anycast works best for short, stateless exchanges, and classic DNS is exactly that: a single UDP query and a single UDP response. If routing shifts mid-way and the next query goes to a different PoP, nothing breaks, because each server holds the same data and no session needs to be preserved.

TCP is more sensitive, because a route change mid-connection could send packets to a PoP that has no record of the session. In practice, routes are stable for the few hundred milliseconds a DNS-over-TCP exchange lasts, and large operators run DNS over TCP, DoT, and DoH on anycast addresses without issue.

How Anycast Improves Reliability

1. Automatic Failover at the Routing Layer

When a PoP fails, it stops announcing the prefix, either because a health check withdraws the route or because the BGP session drops with the server. Within seconds to a minute, routers converge on the next best announcement and traffic flows to another PoP. Clients do not change anything, there is no TTL to wait out, and the IP address never changes. This is a different, faster mechanism than record-swapping DNS failover, which depends on resolvers re-querying after a TTL expires.

2. DDoS Absorption

A distributed denial-of-service attack comes from many sources spread around the world. With anycast, each attacking source's traffic lands at its own nearest PoP, so the attack is naturally split across the whole network instead of concentrating on one site. A flood that would overwhelm any single data center becomes a manageable load per PoP. If one PoP is still saturated, the damage is limited to its catchment, and the operator can withdraw it or shift traffic. This is a key defense against attacks such as DNS amplification.

3. Lower Latency

Shorter network paths mean faster answers. Because DNS lookups happen before nearly every connection, cutting the round trip to the name server from 150 ms to 15 ms is noticeable, especially on cache misses. See whether DNS settings can affect website speed for how this shows up in page loads.

4. Capacity Scaling

Adding capacity is as simple as adding a PoP and announcing the same prefix from it. No DNS records, client settings, or delegations change.

Anycast in the Real World

Anycast is everywhere in DNS:

• The root zone. There are 13 root server identities, a through m, operated by 12 organizations, but they are served by well over 1,900 anycast instances worldwide. The "13" is a limit on addresses, not machines. See what root name servers are.
• TLD operators run their name servers on anycast for the same reasons.
• Public resolvers such as 1.1.1.1, 8.8.8.8, and 9.9.9.9 are anycast.
• Managed authoritative DNS providers almost all advertise anycast networks as a core feature. See what managed DNS is and whether it is worth paying for.

How to See Which Anycast Instance You Reach

Many anycast DNS operators answer special queries in the CHAOS class that reveal which instance answered. This is defined for id.server in RFC 4892, and hostname.bind is a long-standing BIND convention:

dig @k.root-servers.net hostname.bind CH TXT +short
dig @1.1.1.1 id.server CH TXT +short

The first command returns the name of the K-root instance serving your location. The second returns an identifier, typically an airport-style code, for the Cloudflare PoP that answered. Run the same commands from a server on another continent and you will get different answers from the same IP address.

The NSID option from RFC 5001 provides the same information inside a normal query:

dig @l.root-servers.net . SOA +nsid

Look for an NSID: line in the OPT PSEUDOSECTION of the output. To see the network path, traceroute -n 1.1.1.1 from different locations shows traffic terminating in different cities. Measurement platforms such as RIPE Atlas let you run these queries from thousands of vantage points at once.

Running Your Own Anycast DNS

Most site owners get anycast by choosing a managed DNS provider. If you operate your own network, building it yourself requires:

1. Your own IP prefix and ASN. On the public internet, the smallest IPv4 prefix generally accepted is a /24, and for IPv6 a /48. Create RPKI Route Origin Authorizations for the prefix so networks that validate routes accept your announcements.
2. Multiple PoPs with BGP sessions to transit providers or internet exchanges.
3. Identical DNS data at every PoP, usually synced by zone transfers or a shared database.
4. Health-checked route announcements, so a PoP with a broken DNS service withdraws itself instead of black-holing its catchment.

Example: Announcing an Anycast Prefix with BIRD

On each PoP, the DNS server listens on an anycast address bound to the loopback interface:

sudo ip addr add 203.0.113.53/32 dev lo

Then the BIRD 2 routing daemon announces the covering /24 to the upstream router. This bird.conf uses documentation-range ASNs and addresses:

router id 198.51.100.2;

protocol device {
}

protocol static anycast_dns {
    ipv4;
    route 203.0.113.0/24 blackhole;
}

protocol bgp upstream1 {
    local 198.51.100.2 as 64500;
    neighbor 198.51.100.1 as 64496;
    ipv4 {
        import none;
        export where proto = "anycast_dns";
    };
}

The static protocol creates the /24 route inside BIRD, and the BGP session exports only that route to the upstream neighbor while importing nothing. Because no kernel protocol is configured, the blackhole route is never installed in the operating system's routing table. It exists only to be announced.

Withdrawing the Route When DNS Fails

A PoP that keeps announcing the prefix while its DNS server is down is worse than no PoP at all, because it attracts traffic and drops it. A simple health check fixes that by toggling the BIRD protocol:

#!/usr/bin/env bash
# /usr/local/bin/anycast-healthcheck.sh
ANYCAST_IP="203.0.113.53"
ZONE="example.com"

while true; do
    if dig @"$ANYCAST_IP" "$ZONE" SOA +time=2 +tries=1 +short | grep -q .; then
        birdc enable anycast_dns > /dev/null
    else
        birdc disable anycast_dns > /dev/null
    fi
    sleep 5
done

Every five seconds, the script queries the local DNS server for the zone's SOA record. If it gets an answer, it makes sure the announcement is enabled. If not, birdc disable anycast_dns withdraws the route, and BGP moves this PoP's catchment elsewhere. Run it as a systemd service so it restarts automatically. Production setups usually add hysteresis, such as requiring several consecutive failures, so a single slow response does not cause the route to flap.

Limitations and Trade-Offs

1. Routing is not latency-aware. BGP may send users to a suboptimal PoP. Operators monitor this and adjust.
2. Partial failures are hard to see. If a PoP's DNS works but returns stale data, routing will not notice. Monitoring must check answers, not just reachability.
3. Debugging is location-dependent. A problem reported by one user may only exist at one PoP. CHAOS queries and NSID help identify which.
4. Route flapping hurts. Unstable announcements can cause networks to dampen your routes. Health checks need sensible thresholds.
5. It is not a substitute for provider diversity. Anycast protects against site failures within one provider. A global configuration error or account problem at that provider can still take everything down, which is why many large sites combine anycast providers with secondary DNS at a second provider.
6. It does not choose answers. Anycast decides which server answers. If you want different users to receive different records based on location, that is GeoDNS, a separate technique that many anycast providers also offer.

---

Anycast DNS FAQ

Conclusion

Anycast DNS takes a simple idea, the same address in many places, and turns the internet's own routing system into a global load balancer and failover mechanism. Queries reach a nearby server, failed sites drop out of the routing table automatically, and attack traffic is spread thin across the whole network. It is why the root zone, the big public resolvers, and nearly every managed DNS provider rely on it.

For most site owners, the practical takeaway is to choose an authoritative DNS provider with a genuine anycast network, then add provider diversity for protection against failures anycast cannot cover. If you run your own network, anycast is achievable with BGP, a routing daemon like BIRD, and careful health checks, but the operational details, from catchment tuning to flap prevention, are where the real work lies.

Here are some useful references for going deeper on anycast DNS:

1. RFC 4786: Operation of Anycast Services — best current practice for deploying anycast services.
2. RFC 7094: Architectural Considerations of IP Anycast — the IAB's analysis of how anycast behaves and where it fits.
3. RFC 5001: DNS Name Server Identifier (NSID) Option — how to identify which anycast instance answered a query.
4. Root Server Technical Operations: root-servers.org — a live map of root server anycast instances worldwide.
5. Cloudflare Learning Center: What is Anycast DNS? — an accessible overview of anycast DNS and its benefits.