Abstract
Anycast routing assigns the same IP address to multiple nodes in different geographic locations, letting BGP direct each resolver’s queries to the topologically nearest instance. DNS is the canonical use case: operators running authoritative or recursive resolvers with anycast addresses get automatic failover, reduced query latency, and absorption of volumetric DDoS traffic without a dedicated global load balancer. Cloudflare’s 1.1.1.1 and Google’s 8.8.8.8 both rely on anycast, and the same mechanism is accessible to organizations running their own global DNS infrastructure with BGP-speaking routers. This article covers how anycast is configured for DNS, how failover behaves under link or server failure, and what operators need to monitor to keep anycast routing healthy.
Configuring Anycast for DNS
The setup has two parts: assigning the anycast address to the loopback interface on each resolver node, and advertising the anycast prefix via BGP from each PoP. The loopback assignment is straightforward - add the anycast IP (say, 198.51.100.1/32) as a secondary address on lo0 or a dummy interface on every resolver node. The resolver process binds to this address. From the OS’s perspective it is a local address; the routing layer handles directing external packets to the nearest node.
BGP advertisement requires a router at each PoP that peers with upstream transit providers and announces the anycast prefix. The prefix must be the same across all PoPs; BGP’s route selection at the resolver’s upstream will choose the path with the lowest AS path length or the highest local preference, depending on the transit provider’s policies. Most operators use communities to signal the geographic scope of an advertisement - for example, tagging routes with NO_EXPORT to limit an announcement to a single region during maintenance, or using a well-known no-advertise community to withdraw from a specific upstream without withdrawing globally.
BIRD 2 and FRRouting are the two most common BGP daemons used at the resolver layer for anycast setups. Both support health-check-driven withdrawal: a script or daemon monitors whether the resolver process is healthy and injects or withdraws the loopback prefix from the routing table accordingly, which then propagates to the BGP advertisement.
Failover Behavior and Convergence
When a resolver node fails, the BGP session to its upstream drops (or the health check withdraws the prefix), and the route is withdrawn. BGP convergence across the transit network typically takes between 30 and 180 seconds, depending on the number of iBGP reflectors, the hold timer configuration, and the transit provider’s propagation speed. During this window, queries directed to the failed node will time out from the client’s perspective.
Operators reduce the client-visible impact in two ways. First, setting aggressive BGP hold timers (3-9 seconds with 1-3 second keepalives) accelerates withdrawal detection, though this must be balanced against session stability under high CPU load. Second, running multiple anycast nodes at the same PoP (an iBGP cluster sharing the same loopback prefix) means that local traffic redistributes within the PoP without waiting for BGP convergence, as the remaining nodes at the PoP continue advertising the prefix.
Anycast does not provide session stickiness. DNS is stateless (each UDP query is independent), which makes it well-suited to anycast. Protocols with persistent sessions - HTTPS, TCP-based APIs - require additional mechanisms like consistent hashing or flow affinity at the anycast boundary to avoid session teardown on BGP topology changes.
Monitoring Anycast Health
The challenge with anycast is that you are effectively monitoring N independent nodes that all answer to the same address, so standard uptime checks from a single vantage point are blind to regional failures. A resolver can be reachable from one continent but completely unreachable from another if a BGP announcement was withdrawn for a specific region.
Effective anycast monitoring requires distributed probes. Services like Catchpoint, ThousandEyes, and the RIPE Atlas network (which offers free measurement credits to resource holders) run synthetic DNS queries from globally distributed nodes and report latency and reachability by vantage point. Operators should configure alerts on regional latency spikes (which indicate that traffic has been rerouted to a more distant PoP) as well as hard failures (SERVFAIL or timeouts from specific regions).
BGP route visibility tools - Hurricane Electric’s BGP Toolkit and RIPE’s RIS Live stream - let operators verify that the anycast prefix is being advertised and received globally, and can catch cases where a route was accidentally withdrawn or a community-tagged withdrawal was applied more broadly than intended.