Meitu DNS Optimization Practices and Non‑Intrusive SDK Integration for Android

In the mobile Internet era, fierce competition among APP vendors makes user experience a top priority. Meitu, known for its high‑quality UI, focuses on DNS optimization to reduce latency and mitigate DNS hijacking, which are critical for a smooth user experience.

DNS resolves domain names to IP addresses before network connections. When a local cache miss or an expired record occurs, the client queries the ISP’s DNS server, which can introduce uncontrollable delays and security issues such as DNS hijacking.

Meitu’s Android products encounter DNS hijacking and latency fluctuations, leading to request failures or degraded performance. To address this, Meitu developed a DNS SDK that combines LocalDNS and HTTP DNS strategies.

1. LocalDNS vs HTTP DNS

LocalDNS suffers from carrier‑level caching, query forwarding, and NAT issues. HTTP DNS bypasses the carrier DNS by sending an HTTP request containing the domain name and client IP to a dedicated HTTP DNS server, which returns the resolved IP.

Advantages of HTTP DNS include eliminating abnormal domain resolution, precise traffic steering, and strong extensibility.

2. Mobile DNS Optimization Strategy

Meitu adopts a hybrid strategy: core API domains use HTTP DNS, while non‑core requests first try LocalDNS and fall back to HTTP DNS on abnormal conditions. Indicators for DNS quality include TTL anomalies, resolution latency, and IP connectivity tests.

Because Android’s native DNS APIs provide limited metrics, the SDK constructs custom DNS query packets and queries multiple ISP DNS servers directly.

Cache handling is improved with a lazy‑update policy: expired records are returned immediately while an asynchronous refresh updates the cache. Periodic scans clean up stale entries.

3. Non‑Intrusive SDK Integration

For HTTP requests, the SDK can replace the domain with an IP address (IP‑direct) and manually set the Host header:

URL htmlUrl = new URL("http://1.1.1.1/");
HttpURLConnection connection = (HttpURLConnection) htmlUrl.openConnection();
connection.setRequestProperty("Host","www.meitu.com");

HTTPS requires additional handling: the HostnameVerifier must verify the original domain, and SNI must be customized to present the correct certificate. Example:

final URL htmlUrl = new URL("https://1.1.1.1/");
HttpsURLConnection connection = (HttpsURLConnection) htmlUrl.openConnection();
connection.setRequestProperty("Host","www.meipai.com");
connection.setHostnameVerifier(new HostnameVerifier() {
    @Override
    public boolean verify(String hostname, SSLSession session) {
        return HttpsURLConnection.getDefaultHostnameVerifier()
                .verify("www.meipai.com", session);
    }
});

To avoid any URL or header manipulation for business code, the SDK replaces the system AddressCache via reflection with a custom cache that fetches records from the SDK. This makes Java‑level DNS resolution transparent for all libraries (OkHttp, HttpUrlConnection, etc.).

For native components (WebView, media players), the SDK hooks the getaddrinfo / gethostbyname2 functions. By modifying the ELF .rel.plt entries of loaded .so libraries, calls to the original resolver are redirected to a custom implementation ( my_getaddrinfo ), achieving full control over native DNS resolution without source changes.

4. Deployment Results

After deployment, DNS cache hit rates increased, reducing DNS lookup latency and shaving roughly 100 ms off total network request time. Success rates improved, and error rates (e.g., unknown host) decreased. The flexible policy configuration allowed each product to balance performance gains against operational costs.