:Usage notes when you access HTTPDNS without using SDKs

Risk prevention

To prevent your business from being affected by resoling failures when you use the API to access HTTPDNS, we recommend that you perform the following operations:

1. Do not use a certain service IP address to resolve domain names. You can call the service IP address scheduling operation to obtain a list of service IP addresses and determine the service IP address by using polling algorithms. For more information, see Service IP address scheduling operation.

2. Use the LocalDNS of the operating system to resolve the domain name if no service IP address is available.

API operations

The API of HTTPDNS uses an initial IP address to obtain dynamic service IP addresses.

• Service IP address scheduling operation

• Resolve a domain name

• Authenticate resolving requests

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.

• API operations without authentication: All users can call these operations to initiate requests without signatures to resolve domain names, which may result in security risks. For example, you can call an operation without authentication to resolve a domain name by entering the following string in the address bar of your browser: https://47.74.222.190/(accountid)/d?host=DomainName. If the request is successful, HTTPDNS returns the resolving results and counts the number of performed resolving operations. The accountid field included in the request string indicates the account used to perform this operation.

• API operations with authentication: 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.

Asynchronous processing

Use asynchronous methods in your apps to access HTTPDNS. This way, your business does not need to be interrupted to wait for the resolving results.

For example, your app uses a fixed service IP address to access HTTPDNS and initiates synchronous requests to resolve domain name. In this case, if all requests sent to the service IP address are redirected to a secure black hole due to DDoS attacks, the business of the app is interrupted because no resolving results are returned from HTTPDNS.

IP address polling

Configure a service IP address pool and traverse all IP addresses in the pool to obtain an available service IP address each time you access HTTPDNS. This way, your service can still access HTTPDNS even if a service IP address becomes unavailable due to DDoS attacks.

Features of SDKs

If you use API operations but not SDKs to access HTTPDNS, you can develop custom logics based on the features of HTTPDNS SDKs.

Pre-resolving

HTTPDNS can pre-resolve a domain name and cache the resolving result within a validity period. You can set the validity period to the TTL of the resolving result or specify a longer period. The cached resolving results of the domain name can be immediately returned next time you resolve the domain name.

Automatic resolving result update

HTTPDNS can update the resolving results of all domain names during network switching. This feature generates additional traffics.

Service degradation

If you configure service degradation policies for specific domain names, these domain names are not resolved by using HTTPDNS.

Whether to return IP addresses whose TTLs expire

If you allow HTTPDNS to return IP addresses whose TTLs expire, HTTPDNS SDKs return these IP addresses and asynchronously update the results to obtain the latest IP addresses.

Whether to persistently save resolving results

• When an app uses the resolving results of a domain name to access a web page, you can choose to persistently save the resolving results to the local computer as caches. This way, the caches are loaded when the app is restarted, which improves the First Contentful Painting (FCP) of the web page.

• In this case, the TTL of the IP address that the app use for the first access may expire even if the IP address can still be used.

• Therefore, if the IP address of the server changes frequently, we recommend that you do not persistently save resolving results to avoid access issues.

• The resolving results saved to the local computer are used to improve the FCP of a web page only when the app access the page for the first time or after a network switchover. Subsequent resolving requests are still sent to HTTPDNS. HTTPDNS returns the resolving results and use the results to update the cache saved on the local computer.

Asynchronous resolving operations

• When you call asynchronous operations to resolve a domain name to an IP address, HTTPDNS queries the cache first. If the IP address corresponding to the domain name exists in the cache, the IP address is returned. If the IP address does not exist in the cache, HTTPDNS returns null, asynchronously resolves the domain name, and then uses the resolved IP address to update the cache.

• If HTTPDNS returns null, we recommend that you downgrade the resolution method to Local DNS to prevent service interruption.

Generation and usage of session IDs

• Session IDs can be obtained to track and troubleshoot historical issues.

• Session IDs are randomly generated and are 12 characters in length. The ID of a session remains unchanged throughout the lifecycle of an app.

• For more information, see the documentation of API usage.

Regions and service IP addresses

• You can update the service IP address of HTTPDNS based on regions. You can specify a region outside China.

• If you specify a region outside China, a service IP address outside China is returned for you to access HTTPDNS for domain name resolving.

Requests

The following code provides an example on how to verify an HTTPS request:

HttpURLConnection conn = (HttpURLConnection) new URL("").openConnection();
if (conn instanceof HttpsURLConnection) {
    ((HttpsURLConnection) conn).setHostnameVerifier(new HostnameVerifier() {
        public boolean verify(String hostname, SSLSession session) {
            return HttpsURLConnection.getDefaultHostnameVerifier().verify("203.107.1.1", session);
        }
    });
}