Anycast DNS: How Global DNS Networks Work

## What Anycast Means In standard IP routing (unicast), one IP address identifies one host. When you connect to `203.0.113.1`, your packet travels to a single specific machine. Anycast DNS breaks this assumption: the same IP address is announced from multiple physical locations, and BGP routing automatically delivers each incoming packet to the topologically nearest announcing node. From the client's perspective, anycast is invisible. The client sends a query to a single IP. The network decides where that query lands. Two clients in Tokyo and New York querying `1.1.1.1` (Cloudflare's resolver) will reach different physical servers in different data centers, but both receive the same IP address and the same DNS response. ## Why BGP Makes Anycast Work BGP (Border Gateway Protocol) is the internet's routing protocol — the system by which autonomous systems (AS) advertise which IP ranges they can reach and at what cost. Anycast exploits BGP's nature: when multiple AS nodes advertise the same prefix (`1.1.1.0/24` from 300 cities simultaneously), each router on the internet builds a route table entry that points toward the closest (fewest BGP hops, best path attributes) advertising node. When a client's ISP forwards a DNS query to `1.1.1.1`, the ISP's router looks up its BGP route for `1.1.1.0/24` and finds the closest Cloudflare PoP — perhaps 2 hops away in a local exchange point. The query never travels to San Francisco or London unless those are genuinely closer. ## Anycast in the DNS Root Zone The 13 DNS Root Zone nameservers (A through M root) use anycast extensively. There are not 13 physical machines — there are hundreds of instances worldwide, all sharing the same 13 anycast IP addresses. As of 2024, there are over 1,700 root server instances globally. ```bash # The 13 root server addresses dig . NS # Check which anycast instance you reach dig +short CHAOS TXT id.server @a.root-servers.net # Returns something like "bna1.a.root-servers.net" — a location code ``` The `id.server` CHAOS query reveals which physical instance served your request. Researchers use this to map anycast topology and catchment areas. ## How Managed DNS Providers Use Anycast Enterprise Managed DNS providers like Cloudflare, NS1, Amazon Route 53, and Dyn operate anycast networks for Authoritative DNS Server service. When you delegate your domain to Cloudflare's nameservers (`mia.ns.cloudflare.com`, `sam.ns.cloudflare.com`), those nameservers resolve to anycast IPs announced from hundreds of data centers. The operational benefits: **Latency**: Queries are served from the geographically nearest PoP. For a global user base, this means sub-10ms DNS resolution from major population centers. **Resilience**: If one city's infrastructure fails — hardware failure, power outage, DDoS attack — BGP automatically reroutes to the next-nearest node within seconds (BGP convergence time). No manual failover is needed. **DDoS absorption**: Volumetric DDoS attacks against a DNS server (query floods of billions of queries per second) are distributed across all anycast nodes simultaneously. An attack that would saturate a unicast server's uplink is diluted across a global network. **Capacity scaling**: Adding capacity is as simple as standing up new anycast nodes and announcing the same prefixes. Queries naturally flow to the new nodes. ## Anycast for Recursive Resolvers DNS Resolver operators (ISPs, public resolver providers) also use anycast for their resolvers: - Google: `8.8.8.8` and `8.8.4.4` — anycast across hundreds of Google PoPs - Cloudflare: `1.1.1.1` and `1.0.0.1` — anycast across 300+ cities - Quad9: `9.9.9.9` — anycast across 200+ exchange points For end users, the practical result is that the latency to a recursive resolver is nearly always under 20ms regardless of location, and the resolver's DNS Cache (TTL) is shared across the catchment area of each PoP. ## Anycast vs. Latency-Based Routing Anycast routing is controlled by the network layer (BGP) and makes decisions based on routing topology, not actual measured latency. This usually produces excellent results but can occasionally route clients suboptimally when routing policy or BGP path selection leads to a more distant node. geodns-location-routing (GeoDNS) is a DNS-layer technique where the nameserver returns different answers based on the client's IP address geography — useful for directing users to the nearest application server. Anycast and GeoDNS are complementary: anycast gets the DNS query to a nearby nameserver quickly; GeoDNS returns the closest application IP Address in the answer. See GeoDNS: Location-Based DNS Routing for how GeoDNS is implemented. ## Running Your Own Anycast DNS Operating an anycast DNS network requires: 1. **Your own ASN**: You need a BGP autonomous system number (available from regional internet registries — ARIN, RIPE, APNIC). 2. **Provider-Independent IP block**: A PI prefix (/24 minimum for IPv4) that you own and announce yourself. 3. **BGP peers or transit**: Agreements with IXPs or upstream transit providers at each PoP. 4. **DNS software**: BIND, PowerDNS, or Knot DNS on each node, all serving identical zone data. 5. **Zone synchronization**: All nodes must serve consistent data. Use AXFR/IXFR zone transfers from a hidden primary, or distribute zone data via a configuration management system (Terraform, Ansible). The complexity barrier is real. For most organizations, delegating authoritative DNS to a Managed DNS provider is the pragmatic choice. Only large enterprises with stringent control requirements or carriers operating their own resolver networks typically build their own anycast infrastructure. ## Anycast and DNS Propagation Because anycast nodes are independent servers, a zone update must propagate to all nodes. Managed DNS providers handle this with proprietary distribution systems that push changes to all PoPs within seconds. When DNS Propagation discussions refer to "propagation time," they conflate two different things: the time for the zone change to reach all authoritative anycast nodes (seconds to minutes for modern providers) and the time for cached records to expire across the resolver network (governed by TTL (Time To Live) values, which can be hours or days). For geographic response differentiation on top of anycast infrastructure, see GeoDNS: Location-Based DNS Routing. For health-check-based failover layered over anycast nameservers, see DNS Failover and Load Balancing. DNS Record Helper