All Products
Search
Document Center

Alibaba Cloud DNS:FAQ

Last Updated:Jun 25, 2026

Global Traffic Manager

Global Traffic Manager concepts

GTM vs. SLB

A: Global Traffic Manager (GTM) uses DNS to resolve a domain name to multiple IP addresses, distributing application traffic by directing users to different IP addresses. It also uses health checks to dynamically update the list of IP addresses in DNS responses, which enables fault isolation and failover. End-user traffic connects directly to the service's IP address and does not pass through GTM. In contrast, Server Load Balancer (SLB) acts as a proxy to distribute user requests to different backend servers in real time. All user traffic must pass through the SLB instance.

In general, you use SLB for load balancing within a single region. When you have multiple SLB endpoints in different regions, you can use GTM for load balancing across them.

The following table compares GTM and SLB.

Feature

Network layer

Backend address

Weighted round-robin

Cross-region complexity

Failover time

Session persistence

Global Traffic Manager

Layer 3

Domain name, IP

Supported

Simple

Minutes

Not supported

Server Load Balancer

Layer 4, Layer 7

IP

Supported

Complex

Seconds

Supported

GTM vs. Alibaba Cloud DNS

A: Alibaba Cloud DNS provides domain name resolution services, converting domain names into IP addresses and supporting multiple types of resolution records. GTM extends the intelligent DNS resolution of Alibaba Cloud DNS with health checks and failover. It directs users to the nearest endpoint based on their geographic location and monitors service status in real time.

Access domain

Multiple domains per GTM instance

A: It depends.

If multiple service domains resolve to the same set of IP addresses, you can use CNAME records to point them to the same GTM access domain. Otherwise, each service domain requires a separate GTM instance.

1. Single GTM instance scenario

The service domain www.example.com resolves to 1.1.XX.XX and 2.2.XX.XX, and you require disaster recovery between them.

The service domain test.example.com also resolves to 1.1.XX.XX and 2.2.XX.XX, and disaster recovery is required between these two IP addresses.

In this scenario, both service domains resolve to the same set of IP addresses, so you only need one GTM instance. You can then create a CNAME record for both www.example.com and test.example.com, pointing them to the GTM access domain. For more information, see Configure the access domain.

2. Multiple GTM instances scenario

The service domain www.example.com resolves to 1.1.XX.XX and 2.2.XX.XX, and disaster recovery is required between these two IP addresses.

The service domain test.example.com resolves to 1.1.XX.XX and 3.3.XX.XX, and disaster recovery is required between these two IP addresses.

In this scenario, the service domains resolve to different sets of IP addresses. You must purchase a separate GTM instance for each service domain.

Accessing GTM CNAME domains

A: Yes. The GTM access domain is a directly accessible URL. You can also use it as the value of a CNAME record for other customer-facing service domains.

GTM failure detection

A: GTM monitors application services from multiple nodes worldwide. You can use a combination of monitoring nodes to trigger alerts and determine the overall health of a service. You can choose from Ping, TCP, or HTTP(S) health checks to monitor your application services and detect failures.

GTM failover time

A: Based on extensive testing, GTM Ultimate Edition can accurately detect a failure and initiate a failover in approximately one minute. Total recovery time is the sum of failure detection and network propagation times.

Important

Standard Edition can detect a failure and initiate a failover in approximately 3 minutes:

  • Failure detection time: With a health check interval of 60 seconds, a TTL of 60 seconds, and 2 consecutive failures, GTM can accurately detect a failure and initiate a failover in approximately 3 minutes.

  • Network-wide propagation time: GTM cannot guarantee a specific network-wide propagation time. It depends on the TTL cache settings of various Internet Service Providers (ISPs) and network conditions.

Ultimate Edition can detect a failure and initiate a failover in approximately 1 minute:

  • Failure detection time: With a 15-second health check interval, 1-second TTL, and 3 consecutive failures, GTM initiates a failover in about 1 minute.

  • Network-wide propagation time: GTM cannot guarantee a specific network-wide propagation time. It depends on the TTL cache settings of various ISPs and network conditions.

Domain names in address pools

A: Yes. A GTM address pool can contain either IP addresses or domain names, but you cannot mix both in the same address pool. If an address pool contains multiple domain names, GTM performs round-robin resolution for them by default.

GTM and intelligent DNS

A: Yes. GTM integrates intelligent DNS resolution. You can use GTM to perform intelligent DNS resolution for users from different Chinese ISPs, 7 regions, 6 overseas continents, and specific countries. This connects users to the nearest application endpoint, which improves access speed.

GTM and session persistence

A: No. GTM is a DNS-level management system. It uses DNS responses to route clients to the appropriate application service addresses. Clients connect directly to the application's IP address, not through GTM. Therefore, GTM does not see the HTTP traffic between the client and the server and cannot support session persistence.

Using GTM and CDN

A: Yes. You can place the CDN in front of GTM. For more information, see Integrate CDN with GTM to improve access security and service availability.

CDN CNAMEs in GTM address pools

A: You can, but it is not recommended. CDNs have a vast number of nodes, while GTM has a limited number of health check nodes. This mismatch can lead to inaccurate monitoring and affect the reliability of health checks and failover.

DNS resolution issues (old IP or NXDOMAIN)

A: It takes time for Global Traffic Manager DNS records to take effect. Please wait. If the records still do not take effect after a long time, perform the following checks:

  1. Check if the TTL has expired: run dig www.example.com to view the TTL countdown.

  2. Check the CNAME configuration: run dig +trace www.example.com.

  3. Clear the local DNS cache using the appropriate command for your operating system (for example, ipconfig /flushdns on Windows).

Health check failures

A: If the health check consistently fails but you have confirmed that the service is running, follow these troubleshooting steps:

  1. Ensure your firewall allows traffic from the GTM probe IP address ranges.

  2. Test the health check path: run curl -H "Host: domain" http://ip:port/path.

  3. Check the server load and response time.

CNAME query fails for A-record access domain

According to the constraints in Configure an address pool, an Access Domain with type A supports address pools of type A and Domain Name. However, it responds only to A record queries. To respond to CNAME queries, you must change the access type of the Access Domain to CNAME.

Billing

Billing for shared addresses

A: The instances are billed independently. For subscription instances, billing is based on the number of probe tasks generated by the access domain. For pay-as-you-go instances, billing is based on the number of health check probes generated by the access domain.

Unintended GTM charges

A: The cause and solution for this issue are as follows:

Cause: You may have unintentionally enabled Global Traffic Manager (GTM) or a health check, resulting in charges for a pay-as-you-go instance. GTM pay-as-you-go instances are billed for DNS query volume, health check probes, and the number of access domains. Charges are incurred for any usage of these features under the pay-as-you-go model.

Solution:

  1. Log on to the GTM console and check for any unwanted GTM instances.

  2. After confirming that no services depend on them, delete the GTM instances to stop further billing.

Note: This action deletes the GTM instance, not the DNS records. After a GTM instance is deleted, DNS records (such as CNAME records) that point to the GTM access domain will no longer be valid, which may cause your service domain to become inaccessible. Before deleting an instance, assess the impact on your services. If necessary, first update your DNS records to point to the backend service IP address.

Alibaba Cloud DNS editions and GTM binding limits

A:

  • GTM does not have a free edition. Global Traffic Manager (GTM) is a premium feature available on a subscription or pay-as-you-go basis.

  • Using GTM with the Free Edition of Alibaba Cloud DNS: If you use the Free Edition of Alibaba Cloud DNS, you can point CNAME records from multiple service domains to the same GTM access domain. You can bind an unlimited number of service domains.

  • Limitations: The Free Edition has a minimum TTL of 600 seconds. This prevents minute-level failover, making the failover time longer than with a paid edition.

High query volume with GTM and paid DNS

A: Yes. Global Traffic Manager (GTM) and the paid editions of Alibaba Cloud DNS are separate products. GTM provides health checks and failover, while paid DNS editions provide a higher DNS query quota. If your daily number of DNS queries exceeds 100,000 (the limit for the Free Edition), we recommend that you purchase any paid edition of Alibaba Cloud DNS to increase your query quota.

Refunds for accidental GTM charges

A: Generally, charges incurred from unintentionally enabling GTM are non-refundable. However, as a gesture of goodwill, customer support may be able to apply a coupon as compensation, subject to their discretion. If you must request a cash refund, you must submit a ticket to have the case reviewed by a duty manager.

Scheduled automatic release

A: No. GTM instances do not support scheduled automatic release. You must manually delete the GTM instances and their associated probe templates to stop billing. Billing statements may be delayed (often by one day). Billing stops once the instance is deleted.

Alerts

Not receiving alert notifications

A: If you do not receive expected alert notifications, check the following:

  1. Check the alert rule: Confirm that the alert rule has been created and is enabled.

  2. Check contact status: On the alert contact management page, confirm that the recipient's phone number or email address has been verified.

  3. Check for spam or blocked messages: Check your email's spam folder or your phone's SMS blocklist to ensure the notification was not mistakenly filtered.

  4. Check health check logs: Confirm that a status change in the alert object (an address or address pool) triggered the alert rule.

Alert rule triggers

A: Alert rules are primarily triggered by changes in health check status. Common triggering events include:

  • Address unavailable: Triggered when an address fails a specified number of consecutive health checks.

  • Address recovered: Triggered when a previously unavailable address becomes available again.

  • Address pool unavailable: Triggered when all addresses in an address pool become unavailable.

  • Address pool recovered: Triggered when at least one address in an unavailable address pool becomes available again.