Evolution and Practice of iQIYI Internal DNS Architecture in Hybrid Cloud

iQIYI initially deployed most of its services on a private cloud. Over time, the private‑cloud model showed limitations in cost, elasticity, and regional coverage, while public‑cloud services matured and began to meet iQIYI’s needs. iQIYI therefore adopted a hybrid‑cloud deployment that combines private‑cloud resources with multiple public‑cloud providers.

In a hybrid‑cloud environment the private‑cloud and public‑cloud belong to different DNS systems. Achieving unified domain‑name management and secure, efficient inter‑cloud communication became a major challenge. This article describes the evolution of iQIYI’s internal DNS architecture and the practical solutions applied in hybrid‑cloud scenarios.

Internal DNS Evolution

DNS is a fundamental network service. In iQIYI’s production environment, services are diverse and complex, requiring high‑performance, high‑stability, and low‑latency internal DNS. To satisfy these requirements, iQIYI’s DNS architecture has evolved into a multi‑layer design that incorporates Anycast.

1.1 Private‑cloud Internal DNS Architecture

The private‑cloud DNS adopts a four‑layer hierarchy:

Host DNS: Deployed on each host (physical machines, VMs, containers). Provides >90% cache hit rate and forwards unresolved queries to the downstream cache DNS.

Cache DNS: Receives queries from Host DNS, caches responses, and forwards cache misses to the Authoritative DNS. Anycast is used so that all cache DNS instances share the same IP, simplifying configuration.

Authoritative DNS: Stores all internal authoritative domain records. Returns region‑specific addresses for internal domains; forwards non‑internal queries to the Recursive DNS.

Recursive DNS: Performs recursive resolution for non‑internal domains and returns results back through the hierarchy.

Advantages of this layered architecture include:

Multi‑level caching reduces load and latency.

Host‑level caching (>90% hit) dramatically lowers backend DNS traffic.

Anycast‑based cache DNS ensures consistent address configuration, elastic scaling, and fault‑tolerant operation.

Authoritative DNS provides unified data management and optimal service scheduling.

1.2 DNS Architecture Evolution

Generation 1: Simple authoritative DNS with master/slave mode.

Generation 2: Added Host DNS and Cache DNS to offload pressure from the authoritative layer.

Generation 3: Integrated Anycast, achieving elastic scaling and simplified host DNS configuration.

1.3 Anycast‑Enabled Internal DNS

Anycast assigns a single IP address to multiple geographically distributed DNS servers. Packets sent to this address are routed to the nearest server, providing load balancing and proximity benefits. iQIYI’s platform automates deployment, one‑click up/down, and fault detection, removing failed nodes automatically.

Hybrid‑Cloud DNS Challenges

Public‑cloud providers each operate independent DNS services that cannot resolve private‑cloud domains or perform cross‑cloud resolution. To achieve unified configuration, management, and global service, iQIYI adopted an Anycast + directional‑forwarding solution and integrated public‑cloud DNS into the existing management platform.

Key Issues Addressed

Deploying Anycast IPs inside VPCs.

Binding Anycast to cloud networks where the underlying physical network is invisible.

Ensuring interoperability between iQIYI’s authoritative DNS and public‑cloud DNS.

Providing correct resolution for mixed private‑cloud and public‑cloud domains.

Supporting special cases where public‑cloud DNS must resolve iQIYI internal domains.

Practical Deployment

Anycast address sinking: Create an auxiliary address range inside the VPC and allocate a dedicated subnet for the Anycast IP.

DNS service sinking to public cloud: Use LB + VM deployment. The load balancer holds the Anycast IP, forwards traffic to backend cache DNS instances, which in turn query authoritative DNS (private‑cloud or public‑cloud) as needed.

Request flow:

Business host sends DNS query to Anycast IP (LB).

LB performs DNAT, preserving the source IP and directing the request to a specific cache DNS server.

Cache DNS checks its local cache; on miss, it forwards to the authoritative DNS.

The response traverses back through the LB to the business host.

Special scenarios:

When cache DNS and business servers share the same subnet, ARP is answered by the gateway, forcing three‑layer forwarding to the LB.

Cache DNS cannot use the Anycast IP directly because the LB would become a dead‑end; this scenario is still under investigation.

Private‑cloud to Public‑cloud Resolution

Three approaches were evaluated:

Route public‑cloud DNS address blocks into the private network (risk of address conflict).

Deploy a NAT gateway in the public cloud to translate traffic (adds cost).

Deploy a proxy in the public cloud to bridge DNS services (chosen solution).

Private‑cloud ↔ Public‑cloud Service Interconnection

Similarly, three solutions were considered; the proxy‑based approach was adopted to ensure reliable DNS resolution across clouds.

Public‑cloud Resolving Private‑cloud Domains

Configure DNS forwarding in the public cloud to forward private‑cloud domain queries to iQIYI’s authoritative DNS, ensuring cross‑cloud name resolution.

Conclusion

The iQIYI internal DNS has progressed from a simple master/slave setup to a multi‑layer Anycast architecture, and finally to a hybrid‑cloud solution that delivers unified configuration, centralized management, and global service. The current fourth‑generation DNS combines Anycast technology, platform‑driven automation, and cross‑cloud interoperability to provide transparent, secure, stable, and high‑performance name resolution for iQIYI’s worldwide services.