Signature Mechanism

Last Updated: Sep 29, 2017

The DNS service performs authentication on each access request. Therefore, whether sent via HTTP or HTTPS, each request must contain signature information. The DNS uses ‘Access Key ID’ and ‘Access Key Secret’ symmetric encryption to verify the identity of request senders.

The Access Key ID and Access Key Secret are officially issued to visitors by Alibaba Cloud (visitors can apply for and manage them at Alibaba Cloud’s official website). The Access Key ID indicates the identity of the visitor. The Access Key Secret is the secret key used to encrypt and verify the signature string on the server. It must be kept strictly confidential and should only be known to Alibaba Cloud and the user.


When a user calls an API, the following method is used to sign the request:

  • The Canonicalized Query String is constructed using the request parameters.

    • The request parameters are ordered alphabetically by parameter names (this includes the “public request parameters” and user-defined parameters for the given request interfaces described herein, but not the Signature parameter mentioned in “Public Request Parameters”).


      • This sorting method is strictly case sensitive.
      • When a request is submitted using the GET method, these parameters are the parameter section of the request URI (i.e., the section in the URI following “?” and connected by “&”).
    • The name and value of each request parameter are encoded. The names and values must be URL encoded using the ‘UTF-8 character set’. The URL encoding rules are as follows:

      • The characters A-Z, a-z, 0-9, and “-“, “_”, “.”, “~” are not encoded;
      • Other characters are encoded in “%XY” format, with XY representing the characters’ ASCII code in hexadecimal notation. For example, the English double quotes (“) are encoded as %22
      • Extended UTF-8 characters are encoded in “%XY%ZA…” format.
      • It must be noted that the English space ( ) is encoded as %20, rather than the plus sign (+).

      Note: Generally, libraries that support URL encoding (e.g., Java’s are all encoded according to the rules for the “application/x-www-form-urlencoded” MIME-type. Specifically, replace the plus signs (+) with %20, the asterisks (*) with %2A, and %7E with the tilde (~) to generate coded strings that match the above encoding rules.

    • Connect the encoded parameter names and values with the English equal sign (=).

    • Then, order the parameter name and value pairs connected by equal signs in alphabetical order and connect them with the & symbol to produce the Canonicalized Query String.
  • Follow the rules below to construct the string used for signature calculation by using the Canonicalized Query String constructed in the previous step:

    1. StringToSign=
    2. HTTPMethod + “&” +
    3. percentEncode(“/”) + ”&” +
    4. percentEncode(CanonicalizedQueryString)


    • HTTPMethod is used for request submission, e.g., ‘GET’.
    • percentEncode("/") is the coded value for the character “/“ according to the URL encoding rules described in 1.b, namely, “%2F”.
    • percentEncode(CanonicalizedQueryString) is the encoded string of the Canonicalized Query String constructed in Step 1, produced by following the URL encoding rules described in the preceding section.
  • As defined in RFC2104, the above signature sting is used to calculate the signature’s HMAC value. Note: The Key used for calculating the signature is the Access Key Secret held by the user, ending with the “&” character (ASCII:38) based on the SHA1 hashing.

  • According to Base64 encoding rules, encode the above HMAC value into a string. This gives you the signature value.

  • Add the obtained signature value to the request parameters as the ‘Signature’ parameter to sign the request.

Note: When the obtained signature value is submitted to the DNS server as the final request parameter value, the value will be URL encoded like other parameters according to RFC3986 rules.


Take DescribeDomainRecords as an example. The request URL prior to signing is as follows:

  2. ?TimeStamp=2014-08-15T11%3A10%3A07Z
  3. &Format=xml&AccessKeyId=testid
  4. &Action=DescribeDomainRecords
  5. &SignatureMethod=HMAC-SHA1&
  6. &SignatureNonce=1324fd0e-e2bb-4bb1-917c-bd6e437f1710
  7. &SignatureVersion=1.0
  8. &Version=2015-01-09

Thus, the StringToSign is:

  1. GET
  2. &%2F&AccessKeyId%3Dtestid
  3. &Action%3DDescribeDomainRecords
  4. &Format%3Dxml&
  5. &SignatureMethod%3DHMAC-SHA1
  6. &SignatureNonce%3D1324fd0e-e2bb-4bb1-917c-bd6e437f1710
  7. &SignatureVersion%3D1.0
  8. &TimeStamp%3D2014-08-15T11%253A10%253A07Z
  9. &Version%3D2015-01-09

Assuming that the “Access Key ID” is “testid”, the “Access Key Secret” is “testsecret”, and the Key used for HMAC calculation is “testsecret&”, the calculated signature value will be:

  1. SmhZuLUnXmqxSEZ/GqyiwGqmf+M=

The signed request URL is (note the added Signature parameter):


For details regarding request signing and submission, see How to Call Interfaces.

Thank you! We've received your feedback.