This topic explains frequently asked questions about intelligent parsing.
Q: Issues with inaccurate intelligent parsing scheduling
A: This method applies only to domain names that use Alibaba Cloud DNS. If your domain name is hosted on another provider's DNS server, contact your DNS server provider for assistance. For domain names using Alibaba Cloud DNS servers, if the intelligent parsing line you set up shows inaccurate scheduling, see Troubleshooting inaccurate intelligent parsing scheduling.
Q: How is the intelligent parsing feature billed?
A: The intelligent parsing feature is not billed separately. This cost is included in the Cloud DNS version fee. Additionally, different Cloud DNS versions support different parsing line ranges. For more information, see Pricing and Version comparison documents.
Q: How does intelligent parsing determine a visitor's geographic location?
A: Cloud DNS determines the visitor's geographic location through the egress IP of the LocalDNS used by the visitor.
Q: Can parsing lines be set by Chinese regions?
A: Yes, parsing lines can be set by Chinese regions. They support East China, North China, Central China, South China, Southwest China, Northwest China, and Northeast China. For more information, see Parsing line enumeration. Chinese regional lines are only supported in the Enterprise Edition of Cloud DNS.
Q: How can I use intelligent DNS to switch user request traffic to normal servers when a server fails?
A: Intelligent parsing does not support the automatic removal of faulty IPs or automatic switching. To achieve this effect, we recommend you refer to What is Global Traffic Manager 3.0.
Q: I have two servers on China Mobile and China Unicom lines respectively. Does Cloud DNS intelligent parsing support users accessing the nearest server?
A: Yes, the DNS parsing policy is as follows:
Parsing source | Returned IP address |
shift | Server IP address on China Mobile line |
China Unicom | Server IP address on China Unicom line |
Default | Server IP address on China Mobile line |
Based on the Carrier of the user request, the system returns the server IP address of the corresponding carrier, achieving proximity-based responses. For requests from carriers other than China Mobile or China Unicom, the system returns the China Mobile line IP address as the default fallback.
Q: Can intelligent parsing lines be configured with overlapping geographic locations? If supported, how does Cloud DNS respond to DNS requests?
A: For parsing sources based on Region, the following priority levels apply.
Parsing source | Parsing priority |
Singapore | High |
Asia | Medium |
Outside China | Low |
You can configure DNS records with overlapping geographic locations (for example, setting parsing lines to outside China, Asia, Singapore). If an end user is from Singapore, the system returns the parsing address specified by the Singapore line. If the end user's geographic location is not in Singapore but is in Asia, the system returns the parsing address specified by the Asia line. If the end user's geographic location is not in Asia but is in another continent, the system returns the parsing address specified by the outside China line.
Q: Is it possible to provide services only to users in China?
A: Yes, the DNS parsing policy is as follows:
Parsing source | Returned IP address |
Regions in the Chinese mainland | Server IP address |
Outside China | 127.0.0.1 |
In the DNS parsing policy, for requests from request sources in mainland China, the system returns the IP address of your actual server or an active node. For the Outside Mainland China group, which includes Hong Kong (China), Macao (China), Taiwan (China), and other regions, you can return an invalid IP address, such as 127.0.0.1 or 0.0.0.0, to block resolution from these locations.
A record resolution failures when the default line is a CNAME record
Problem description
A host record in Alibaba Cloud DNS is configured with two DNS records: a CNAME record for the default line and an A record for the Mainland China line. However, when a client in mainland China requests an A record, the CNAME record for the default line is returned instead.
Cause
When an end user on a non-default line requests a record type other than an A record, the authoritative DNS server returns the CNAME record. The local DNS server then caches this CNAME record. Because CNAME records have the highest priority, if the client later requests an A record, the request hits the CNAME record in the local DNS server's cache. The local DNS server returns the cached CNAME record instead of sending a new resolution request to the authoritative DNS server. This behavior is specified by the DNS protocol.
Solution
If you have other specific resolution lines configured, do not set the default line to a CNAME record. Remove the CNAME record from the default line. After the TTL of the local DNS cache on the carrier's side expires, DNS records will resolve correctly.