HTTPDNS:Best practices

Scenario: Specific HTTPDNS service nodes are unavailable

Background information

In extreme cases, such as natural disasters, Internet service provider (ISP) blockages, and network failures, a single service entry point of HTTPDNS may become unavailable, which may affect domain name resolution.

Solutions

1. Startup IP address failover

   • Embed multiple startup IP addresses or domain names within the application to ensure continuous connectivity with HTTPDNS.

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

2. Dynamic update of the service IP address list

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

For more information, see Scheduling Service Interface.

3. Failover policy

   When you use HTTPDNS, an IP rotation mechanism is implemented. If an IP address is unreachable, the system rotates to the next IP address for retrying, ensuring that HTTPDNS remains unaffected even if one service IP address becomes unavailable. When a resolution request is sent to the server, the system retrieves an available service IP address from the global service IP address list. If the resolution using current service IP address is successful, the SDK continues to use this IP address for resolution throughout its lifecycle. If the resolution using the current service IP address fails, the system switches to the next IP address in the global service IP address list for retrying. If the retry also fails, the system returns null and attempts to switch to another service IP address again.

If all HTTPDNS service IP addresses fail to respond, fall back to using local Domain Name System (DNS), which is the native DNS chain of the operating system. If you use OkHttp as the network library to integrate HTTPDNS on Android, you can use the following code to use local DNS for 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. This way, your business does not need to be interrupted to wait for the resolution results.

Scenario: Performance bottlenecks caused by frequent queries

Background information

If a request to HTTPDNS is made for domain name resolution during each network request, the business latency and bandwidth consumption are significantly increased. Considering that the result of domain name resolution has a time to live (TTL) cache value, you can implement caching 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

   You can enable the connection reuse feature of the HTTP client to reduce the time required to establish a TCP connection and decreases resolution latency of HTTPDNS.

3. Persistent caching

   You can cache the resolution results persistently that are obtained last time. After the app restarts, the resolution results are preferentially loaded from the persistence layer. This improves the first loading speed.

Scenario: Access latency caused by cross-ISP resolution

Background information

When you use CDN-accelerated domain names or domain names that are configured with intelligent routing resolution, if the client caches the IP address obtained from DNS resolution based on the TTL value, issues may arise when the network environment changes. For example, the 4G network is changed to Wi-Fi or vice versa. In such cases, the cached IP address may no longer align with the optimal route for the new network environment, potentially leading to performance degradation in business-related network requests.

Solutions

1. Network environment monitoring

   • Monitor changes in the client network, for example, Wi-Fi is changed to mobile data.

   • Proactively refresh the local cache to ensure that the resolution results are compatible with the current network environment.

2. Speed testing and sorting

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

Scenario: A resolution request is hijacked or leaked

Background information

A resolution API without an authentication mechanism poses security risks, as it may be exploited by third parties to steal traffic and incur costs.

Solutions

1. Authentication resolution

   We recommend that you use API operations with authentication to resolve domain names. You can choose whether to disable API operations without authentication in the HTTPDNS console.

   • When you call these operations to resolve domain names, HTTPDNS uses a secret key to generate an encrypted string and includes the string in the request for authentication. The secret key is not included in the request, which reduces the risk of exposure to ensure security of the resolution request.

   • For more information, see Implement authenticated access.

2. Use HTTPS for secure communication

   • If you use the HTTPS protocol, custom certificate verification is required. The verification must be configured to point to 203.107.1.1 or resolvers-cn.httpdns.aliyuncs.com.

   • For information about the implementation on Android, see Best practices for using HTTPDNS with HttpURLConnection on Android.

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