Anycast Technology Overview and Its Application in Internal DNS System Deployment

With the development of cloud computing, an increasing number of services in internal networks are hosted on virtual machines, causing the internal DNS system to experience a massive surge in query volume that exceeds the limits of physical hosts.

Traditional DNS architectures would require either scaling up a single DNS node’s capacity or adding many more DNS nodes, both of which bring drawbacks: larger single‑node failures impact more services, and more nodes consume IP addresses and increase operational complexity.

Anycast‑based DNS solves these problems by assigning a single IP address to multiple geographically distributed DNS nodes. Routing protocols automatically balance traffic and provide seamless failover when a node goes down, meeting the performance demands of the cloud era while reducing operational overhead.

Anycast Technology Overview

Anycast maps a unicast address to multiple hosts across the Internet; packets sent to that address are routed to the nearest host according to network topology.

Key advantages of Anycast include:

a) Load‑balancing characteristic : Multiple nodes share the same IP address, and users are directed to the nearest node via shortest‑path routing, achieving load distribution and lower latency.

b) DDoS mitigation : DDoS traffic is dispersed across many Anycast nodes, making it difficult for attackers to concentrate traffic on a single target.

c) Node‑level redundancy : If any service node fails, client requests are automatically routed to the next reachable node without manual intervention, providing redundancy.

Limitations: The shared unicast address cannot be used for client‑initiated requests because responses may not return to the original client. Consequently, Anycast is mainly suitable for protocols such as DNS.

iQIYI’s Anycast Practice

The team conducted internal Anycast validation to understand its impact on UDP and TCP services. Tests showed that most routers use per‑flow load balancing that preserves TCP session continuity, allowing both UDP and TCP services to be deployed on Anycast.

Findings include:

a) Anycast provides strong capacity for UDP‑based services.

b) Hash‑based ECMP load balancing in the network does not break TCP session continuity, enabling TCP services on Anycast.

To ensure rapid failover when a host or process fails, the team integrated DNS‑process monitoring plugins with OSPF (via Quagga). This allowed automatic route withdrawal and convergence, achieving automatic service migration upon DNS, server, or network failures.

Additionally, monitoring plugins collected request counts every five minutes to evaluate load‑balancing quality and guide node placement optimization.

Deployment of Anycast‑Based DNS System

Following validation, the DNS team launched an Anycast DNS service across multiple core data centers within the internal network. The system operates smoothly; in a single‑node failure scenario, traffic is switched to another node in less than 2 seconds, with users perceiving no impact.

The Anycast‑enabled DNS now possesses self‑healing, node‑level fault tolerance, significantly reducing operational pressure.

Future Outlook

The successful deployment confirms Anycast’s strong handling of UDP‑based services. The next step is to select suitable TCP services for Anycast testing, aiming to further improve system robustness and lessen the burden on operations engineers.