Hybrid Cloud Anycast DNS Architecture and Implementation at iQIYI

In the early planning of iQIYI's infrastructure, business applications were primarily deployed on a self‑built IDC (private cloud). As the business grew, the private‑cloud model showed limitations in cost control, elastic scaling, and regional coverage, prompting the gradual introduction of public‑cloud resources and the formation of a hybrid‑cloud network architecture.

Anycast is a networking technique where multiple servers share a single IP address, automatically routing user requests to the nearest or least‑loaded node. DNS (Domain Name System) acts as the Internet's address book, translating human‑readable domain names into machine‑readable IP addresses, and serves as a foundational service for higher‑level applications.

When extending the existing IDC DNS architecture to a hybrid‑cloud scenario, several problems emerged: the private‑cloud DNS was built on Anycast with unified IPs, but public‑cloud deployments reside in overlay (virtual) networks, making the underlying physical network invisible. Consequently, directly implementing Anycast DNS in the public cloud was difficult, leading to inconsistencies in deployment and maintenance.

In the private‑IDC setting, iQIYI adopted a multi‑layer Anycast DNS architecture. Multiple IDC sites deploy DNS services and announce the Anycast IP via dynamic BGP, achieving a single DNS entry IP for the entire internal network. This design improves reliability, scalability, response speed, and reduces failure rates and maintenance costs.

For the hybrid‑cloud environment, an LB + DNS solution was initially proposed. The goals were: (1) all business hosts use a unified Anycast IP as the sole service address; (2) DNS servers across IDC and public cloud are managed centrally with automated deployment and lifecycle control; (3) a single DNS service IP can resolve both private‑cloud and public‑cloud domain names, providing global service.

However, the LB‑based approach cannot fully replicate true Anycast behavior because the Anycast IP resides within a VPC subnet, and failure of the load balancer or its backend DNS servers cannot be quickly withdrawn, limiting flexible control over IP activation and deactivation.

To overcome these drawbacks, iQIYI collaborated with the public‑cloud infrastructure team to design an Enterprise Router (ER) + Anycast DNS solution. The public‑cloud ER supports BGP for dynamic Anycast IP advertisement, GRE VPN tunnels for overlay‑underlay integration, and side‑mount deployment that does not disrupt existing networks.

Implementation steps include: Connecting the private IDC and public cloud via dedicated lines; the ER is side‑mounted to the Singapore VPC. Establishing GRE VPN tunnels between cloud DNS servers and the ER. Deploying Bird routing software on cloud DNS servers to form BGP sessions over the GRE tunnel. Configuring the Anycast DNS IP on cloud DNS servers and advertising it to the ER via BGP. The ER learns the Anycast route and propagates it within the VPC.

DNS request flow in the hybrid cloud: Servers in the VPC send queries to the Anycast DNS IP; the VPC route points to the ER. The ER forwards the query through the GRE tunnel to the backend DNS server. The DNS server, configured with the Anycast IP, responds to the client.

Compared with the LB approach, the ER‑based design achieves true Anycast DNS across private and public clouds, enabling unified management, flexible node activation/deactivation, and rapid failover between IDC and cloud clusters.

As of now, the public‑cloud ER Anycast DNS solution has been deployed and is running stably on iQIYI's Singapore node, providing transparent, unified, and elastic domain resolution for all business units. Future work includes extending the solution to other public‑cloud providers to realize a fully unified global Anycast DNS service.