Questions: Anycast Networking

Question 1

A company deploys DNS resolvers in five cities and wants clients worldwide to be automatically served by their geographically nearest resolver without any client-side configuration. Which approach achieves this?

• A. Assign each resolver a unique IP and configure split-horizon DNS to return geolocation-appropriate addresses
• B. Use DNS round-robin to distribute queries evenly across all five resolver IPs
• C. Assign all five resolvers the same IP prefix and have each advertise it via BGP — anycast routing directs each client to the nearest
• D. Deploy a centralized load balancer that inspects source IPs and proxies each query to the nearest resolver

Answer: (C)

Anycast assigns the same IP to multiple servers; each advertises that prefix via routing protocols (typically BGP). Routers between the client and Internet backbone see multiple paths to that prefix and select the one with the best metric — effectively the nearest node. No client configuration or centralized load balancer is needed. This is exactly how services like 8.8.8.8 and root DNS nameservers work globally.

Question 2

Why does anycast work well for DNS queries but poorly for long-lived TCP connections like video streaming?

• A. Anycast addresses cannot be used with TCP because TCP requires a connection-oriented protocol with a fixed endpoint
• B. A mid-session route change can redirect subsequent packets to a different server with no knowledge of the existing connection state, breaking the TCP session
• C. Video streaming requires more bandwidth than a single anycast node can provide
• D. TCP connections use port numbers that conflict with the anycast routing mechanism

Answer: (B)

TCP sessions accumulate state: sequence numbers, acknowledgment counters, socket buffers, and application session data. If a route change causes subsequent packets to arrive at a different anycast node mid-session, that server has none of this state and cannot continue the connection. For DNS (single UDP request-response pairs), this is harmless — each query is independent. The stateless nature of DNS is what makes it a perfect fit for anycast.

Question 3

In anycast, the routing infrastructure — not the client or a centralized coordinator — determines which physical server instance receives a given packet.

• T. True
• F. False

Answer: True

This is the elegant core of anycast: clients send packets to a single IP address with no knowledge of which server will receive them. BGP routing on the network's backbone makes the selection automatically by choosing the path with the best metric to whichever node advertised that prefix. The client needs no special configuration, and no centralized controller is involved — the distributed routing system handles the selection transparently.

Question 4

Anycast provides fault tolerance by maintaining a registry of most active servers and actively redirecting traffic away from servers that go offline.

• T. True
• F. False

Answer: False

Anycast resilience is passive, not active. When an anycast node fails and stops advertising its route, the BGP routing system simply reconverges: routers that previously had a route through that node select the next-best path to another node that is still advertising the same prefix. No registry, health-check system, or active redirection is needed. This makes anycast resilient by design — failure of one node is handled automatically by the same routing protocol that handles any link failure.

Question 5

Explain why anycast is well-suited to DNS but poorly suited to video streaming, in terms of the session state each protocol requires.

Model answer: DNS uses stateless UDP request-response pairs: each query is independent, and if routing changes between queries, a different server can answer the next one without any context. Video streaming requires a persistent TCP connection over which state accumulates — sequence numbers, buffering position, session authentication. If routing changes mid-stream and packets are redirected to a different anycast node, that server has no knowledge of the session and cannot continue it. Anycast's geographic routing instability is irrelevant for stateless queries and fatal for stateful sessions.

The statefulness of the application is the key variable. Short, independent transactions like DNS, NTP, or QUIC retries are natural fits. Applications requiring persistent sessions need either TCP connection pinning, flow-aware load balancers, or a different routing architecture entirely.