HTTPDNS:Best practices

Scenario: Specific HTTPDNS service nodes are unavailable

Background information

In extreme cases, such as natural disasters, ISP blockages, and network failures, a single HTTPDNS service entry point may become unavailable, which affects domain name resolution.

Solutions

1. Startup IP address failover

   • Embed multiple startup IP addresses or domain names in your application to maintain continuous connectivity with HTTPDNS.

   • If the request fails, the next startup IP address is used automatically.

2. Dynamic update of the service IP address list

   The following flowchart shows how to obtain a service IP address by sending a request to a startup IP address.

For more information, see Scheduling Service Interface.

3. Failover policy

   HTTPDNS uses an IP rotation mechanism. If an IP address is unreachable, the system rotates to the next IP address, ensuring that HTTPDNS remains available even if one service IP address fails. When a resolution request is sent, the system retrieves an available service IP address from the global list. If the resolution succeeds, the SDK continues using this IP address throughout its lifecycle. If the resolution fails, the system switches to the next IP address in the list. If the retry also fails, the system returns null and attempts another service IP address.

If all HTTPDNS service IP addresses fail to respond, fall back to local DNS, which is the native DNS chain of the operating system. If you use OkHttp as the network library to integrate HTTPDNS on Android, use the following code for local DNS resolution:

List<InetAddress> result = okhttp3.Dns.SYSTEM.lookup(host);

val result: List<InetAddress> = Dns.SYSTEM.lookup(host)

For iOS, avoid performing Host replacement or request interception, and the original request will remain unchanged:

NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL:url];
// Send the request.
NSURLSession *session = [NSURLSession sharedSession];
NSURLSessionDataTask *task = [session dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
    if (error) {
        NSLog(@"error: %@", error);
    } else {
        NSLog(@"response: %@", response);
    }
}];
[task resume];

var request = URLRequest(url: url)
// Send the request.
let session = URLSession.shared
let task = session.dataTask(with: request) { (data, response, error) in
    if let error = error {
        print("error: \(error)")
    } else {
        print("response: \(response?.description ??  "")")
    }
}
task.resume()

4. Non-blocking resolution

   Use asynchronous methods in your apps to access HTTPDNS so that your business is not blocked waiting for resolution results.

Scenario: Performance bottlenecks caused by frequent queries

Background information

If HTTPDNS is queried for domain name resolution on every network request, business latency and bandwidth consumption increase significantly. Because resolution results have a TTL cache value, you can cache results based on this value.

Solutions

1. Local cache

   • According to the DNS standard RFC 104, the resolution results can be cached based on the TTL value.

2. Pre-resolving

2. Connection reuse

   Enable the connection reuse feature of the HTTP client to reduce TCP connection setup time and decrease HTTPDNS resolution latency.

3. Persistent caching

   Cache the most recent resolution results persistently. After the app restarts, the results are loaded from the persistence layer first, which improves initial loading speed.

Scenario: Access latency caused by cross-ISP resolution

Background information

When you use CDN-accelerated domain names or domain names configured with intelligent routing, the client may cache the resolved IP address based on the TTL value. If the network environment changes, for example, switching between 4G and Wi-Fi, the cached IP address may no longer match the optimal route for the new network, potentially degrading business network performance.

Solutions

1. Network environment monitoring

   • Monitor client network changes, such as switching from Wi-Fi to mobile data.

   • Proactively refresh the local cache to keep resolution results aligned with the current network environment.

2. Speed testing and sorting

   Use ICMP or TCP asynchronous testing to rank resolution results and prioritize the IP address with the fastest response time.

Scenario: A resolution request is hijacked or leaked

Background information

A resolution API without authentication poses security risks. Third parties may exploit it to steal traffic and incur costs.

Solutions

1. Authentication resolution

   We recommend using authenticated API operations for domain name resolution. You can choose whether to disable API operations without authentication in the HTTPDNS console.

   • HTTPDNS uses a secret key to generate an encrypted string and includes it in the request for authentication. The secret key itself is not transmitted, which reduces exposure risk and protects resolution requests.

   • For more information, see Implement authenticated access.

2. Use HTTPS for secure communication

   • If you use HTTPS, custom certificate verification is required. Configure the verification to point to 203.107.1.1 or resolvers-cn.httpdns.aliyuncs.com.

   • For information about the implementation on Android, see Use HTTPDNS with HttpURLConnection on Android.

   • For iOS scenarios, see Integrate HTTPDNS SDK for iOS.