HTTPDNS:Implement authenticated access

1. Background

To protect your billing against potential fraudulent activities, we have designed an authentication mechanism. Follow the instructions in this document to implement this mechanism.

2. Authentication solution

Some existing users have products that access HTTPDNS without authentication. These products must continue to use the non-authenticated API operations.

To accommodate this, we provide a new authenticated API operation. You can gradually migrate new product versions to this new API operation. When the number of users on the old app version decreases to a certain level, you can turn on the signed access switch to prevent adverse impacts on your billing. The following figures illustrate this process.

2.1 Migration plan for existing users

• If you turn on the signed access switch, users of older product versions cannot access the HTTPDNS service.

• You can guide existing users to update their product versions and gradually migrate to the authenticated API operation.

• When the number of users for products that use the non-authenticated API operation drops to an acceptable level, you can manually turn on the signed access switch.

2.2 Plan for new users

• To avoid the additional integration cost of authentication, the signed access switch is turned off by default.

• If you only need the authenticated API operation, you can manually turn on the signed access switch.

2.3 Management of the signed access switch

• If the switch is turned off, security threats may occur.

• You can prevent charges resulting from attacks only by turning on the signed access switch.

3. Signature generation and authentication mechanism

3.1 Signature generation algorithm and examples

Authenticated API operations

• http://47.74.XXX.XXX/{account_id}/sign_d

• http://47.74.XXX.XXX/{account_id}/sign_resolve

Signature algorithm

sign = md5sum( host-secret-timestamp )

Authentication fields

Signature examples

• Example 1: Resolve a single domain name

  • Original request: http://47.74.XXX.XXX/{account_id}/d?host=www.aliyun.com

  • Assume that the secret key is IAmASecret and the signature expires at 15:00:00 on August 15, 2018 (UTC+8). The corresponding timestamp for this expiration time is 1534316400.

  • sign = md5sum("www.aliyun.com-IAmASecret-1534316400") = 60c71e98b6d7fcbb366243e224eab457

  • Authenticated request: http://47.74.XXX.XXX/{account_id}/sign_d?host=www.aliyun.com&t=1534316400&s=60c71e98b6d7fcbb366243e224eab457

• Example 2: Batch resolve domain names

  • Original request:

    http://47.74.XXX.XXX/{account_id}/resolve?host=www.aliyun.com,www.taobao.com

  • Assume that the secret key is IAmASecret and the signature expires at 15:00:00 on August 15, 2018 (UTC+8). The corresponding timestamp for this expiration time is 1534316400.

  • sign = md5sum("www.aliyun.com,www.taobao.com-IAmASecret-1534316400") = 12a3f6b1b14a46ca813ca6439beb59a4

  • Authenticated request: http://47.74.XXX.XXX/{account_id}/sign_resolve?host=www.aliyun.com,www.taobao.com&t=1534316400&s=12a3f6b1b14a46ca813ca6439beb59a4

Pros and cons of this solution

• Disadvantages

  • The time on the client may differ from the time on the server.

  • Storing the secret key on the client is risky because the key may be compromised.

• Advantages

  • You do not need to pull data from the server.

3.2 Authentication response

• If authentication is successful, the HTTP response returns the status code 200. The response format is the same as the one described in the API Response Description section of Resolve a single domain name.

• If authentication fails, the HTTP response returns the status code 403 or 400 and includes a specific error code. The response is in JSON format.

   { "code": "InvalidSignature" }

3.3 Status code description