Deep Network Optimization in Baidu App: DNS and HTTPDNS Practices

1. Preface

Network optimization is recognized as a deep field among client‑side technologies. Baidu App therefore launches a series of deep network‑optimization articles, covering DNS optimization, connection optimization, and weak‑network optimization, to help developers learn and practice network techniques.

Baidu originated as a search engine; its network architecture follows standard Internet protocols and is fully HTTPS. In the mobile‑Internet era the overall architecture remains, but many client‑side optimizations are required.

DNS (Domain Name System) resolves domain names to IP addresses and is a prerequisite for HTTP. Optimizing DNS is therefore the first step in network optimization.

2. Background

DNS optimization must address two core problems:

1) Service unavailability caused by DNS hijacking or failures, which harms user experience and revenue.

2) Performance degradation due to inaccurate DNS scheduling, also affecting user experience.

Baidu App handles billions of requests daily and frequently encounters carrier‑level DNS hijacking or failures, making DNS optimization urgent.

Figure: Principle of carrier DNS hijacking or failure

3. HTTPDNS

To tackle the severe issues above, Baidu adopts HTTPDNS.

Standard DNS uses UDP to communicate with DNS servers. HTTPDNS uses the HTTP protocol, bypassing the carrier’s local DNS, preventing hijacking and improving resolution efficiency.

Figure: HTTPDNS principle

Baidu App’s HTTPDNS client is built on Baidu SYS team’s HTTPDNS service. The following diagram shows the server‑side deployment.

Figure: HTTPDNS deployment architecture

HTTPDNS operates over BGP. BGP routes traffic to the nearest Baidu service cluster. For third‑party domains, the service point queries the authoritative DNS from a CDN node within the carrier, returning the optimal IP.

Baidu App also implements a client‑side HTTPDNS SDK; its overall architecture is shown below.

Figure: Client‑side HTTPDNS architecture

DNS Interface Layer

The DNS interface layer abstracts low‑level details, providing a clean API to reduce the learning curve and improve development efficiency.

DNS Strategy Layer

The strategy layer combines multiple policies to keep HTTPDNS performant, stable, and highly available. The following subsections describe each policy.

1. Disaster‑Recovery Strategy

This critical strategy ensures service availability. When HTTPDNS is unavailable and no valid cache exists, a downgrade to the carrier’s local DNS is triggered, preserving availability at the cost of potential hijacking risk.

If both HTTPDNS and local DNS fail, a backup IP list is used.

A backup IP list consists of multiple IP groups per domain, dynamically updated from the cloud. Not all domains have backup lists; core domains are covered.

Selection of a backup IP uses a round‑robin (RR) algorithm to balance load while minimizing client overhead.

2. Security Strategy

HTTPDNS secures DNS queries by using HTTPS (TLS over HTTP), avoiding the insecurity of UDP/TCP DNS.

By requesting DNS data via a VIP (Virtual IP) over a direct IP connection, the client bypasses carrier local DNS, eliminating the impact of carrier failures or hijacking.

3. Task‑Scheduling Strategy

Two HTTP interfaces are provided:

• Multi‑domain interface – used during cold start or network change to pre‑fetch domain results, reducing later single‑domain requests.

• Single‑domain interface – invoked when a cached entry expires, returning the result for the specific domain.

4. IP Selection Strategy

The service returns a prioritized list of optimal IPs; the client selects the first one without additional connectivity checks to keep overhead low, relying on the disaster‑recovery strategy as a fallback.

5. Cache Strategy

DNS caching improves efficiency. TTL (Time‑To‑Live) values are dynamically set by the server; Baidu App currently uses a 5‑minute TTL for all domains.

6. Hit‑Rate Strategy

To maximize hit‑rate, Baidu App uses the multi‑domain interface during cold start/network switch and performs a local expiration check (60 s) before issuing a single‑domain request.

Basic Capability Layer

This layer supplies the underlying abilities required by the strategy layer, including IPv4/IPv6 stack detection, data transmission, and cache implementation.

1. IPv4/IPv6 Stack Detection

Baidu App uses UDP Connect to determine whether the current network uses IPv4 or IPv6 without incurring the cost of a TCP three‑way handshake.

Figure: UDP Connect principle

Detection is performed during cold start and network changes; the result guides whether IPv4 or IPv6 addresses are used. Currently Baidu App prefers IPv4 except in IPv6‑only networks. The industry‑standard Happy Eyeballs algorithm (RFC 6555, RFC 8305) is mentioned for future improvement.

2. Data Transmission

Provides network request and data parsing capabilities, including a three‑retry mechanism for failed HTTPDNS requests and safeguards against malformed responses.

3. Cache Implementation

Memory‑only caching is chosen to avoid stale data after app restarts, accepting a brief vulnerability during cold start.

4. HTTPDNS Best Practices

Although Baidu App’s network architecture is not yet unified, the following sections describe the current Android and iOS integrations.

HTTPDNS in Android Architecture

All Android traffic runs on OkHttp with a custom DNS module that replaces the system DNS with HTTPDNS.

Figure: Position of HTTPDNS in Android network stack

HTTPDNS in iOS Architecture

iOS traffic runs on Cronet (Chromium’s net module). Cronet is injected into URLSession via AOP, and the DNS module is extended to include HTTPDNS. Some traffic still uses native URLSession; a wrapper replaces domain names with IPs while preserving HTTPS validation, cookies, redirects, and SNI.

Figure: Position of HTTPDNS in iOS network stack

5. Benefits

DNS optimization yields two main benefits: preventing DNS hijacking and reducing network latency. In Baidu App’s Feed service, hijacking rates dropped from 0.12 % to 0.0002 % on iOS and from 0.25 % to 0.05 % on Android. Latency improvements were modest for domestic users due to already strong infrastructure, but would be more noticeable abroad.

6. Conclusion

DNS optimization is an ongoing topic. The practices described here are not perfect but will continue to evolve to safeguard Baidu App’s DNS capabilities.

7. Personal Insights

Engineers can improve network optimization by focusing on five areas:

1) Master fundamental knowledge, especially RFCs.

2) Visualize the invisible network using tools such as tcpdump, Wireshark, Fiddler, Charles, iNetTools, and network‑condition simulators.

3) Gain experience on platforms that generate diverse network issues.

4) Base optimizations on solid data collection and analysis across offline, gray‑release, and online environments.

5) Validate improvements with scenario‑specific analysis, recognizing that even well‑known solutions may not fit every case.

8. References

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/android_build_instructions.md

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ios/build_instructions.md

https://github.com/Tencent/mars

https://tools.ietf.org/html/rfc7858

https://tools.ietf.org/html/rfc6555

https://tools.ietf.org/html/rfc8305