This article explains the line priority rules for intelligent DNS resolution!

　　Many people, when configuring Smart DNS, mistakenly believe that simply entering the IP addresses of various ISPs is sufficient. However, they often discover that a Beijing Mobile user, despite having a nearby Mobile node, is resolving to a China Unicom IP address—resulting in page loading three times slower. The underlying reason is often a misunderstanding of line priority rules. Smart DNS line priority resolution is essentially a matching logic that proceeds from fine-grained to coarse-grained, prioritizing precision. While the implementation varies slightly among different service providers, the core principle remains highly consistent.

　　I. How Does Smart DNS Determine "Where the User Came From"?

　　Before understanding the priority rules, it's crucial to clarify a commonly misunderstood detail: Smart DNS doesn't see the user's local IP address, but rather the exit IP address of the user's configured LocalDNS (Local Recursive DNS).

　　The system determines the source in three ways:

　　LocalDNS supports EDNS (optimal case): Prioritizes reading the user's real IP subnet carried in the ECS extended field, achieving city-level accuracy.

　　LocalDNS does not support EDNS (fallback): Uses the LocalDNS's exit IP address for approximate determination. If a user uses a public DNS, the exit IP address may be in a different location, leading to inaccurate location tracking.

　　LocalDNS indirectly supports EDNS: requests are forwarded through a secondary node, resulting in even worse location accuracy.

　　Understanding this helps explain why some users' DNS resolutions are always off-target—the problem likely lies with LocalDNS itself, not with incorrect smart DNS configuration.

　　II. Line Priority Rules: Exact Matching Preferred

　　This is the core of this article. The line matching logic of major cloud vendors is highly consistent; the following rules are compiled from multiple documents.

　　General Matching Order (from high to low)

　　Core Principle: Within the same type of route, the more granular the route, the higher its priority. For example: "Beijing" > "North China" > "China Region"; "Singapore" > "Asia" > "Overseas".

　　III. The Role of the Default Route: The Last Line of Security

　　The default route plays a fallback role in Smart DNS, with the lowest priority, used to match requests that "miss other routes".

　　Configuration Recommendation: Always configure a default route, and do not set the default route as a CNAME record.

　　This is a common pitfall: If the default route is configured with a CNAME record, while other precise routes are configured with A records, once LocalDNS caches the default route's CNAME record, all subsequent resolution requests will prioritize returning the CNAME record, rendering the precise route's A record useless.

　　IV. Route-Specific Resolution vs. Weighted Resolution: Don't Confuse Them

　　Many people confuse these two concepts, but they address different problems:

　　Route-specific resolution: answers "Which node should this user go to?"—routing based on the user's origin (ISP/region).

　　Weighted Resolution: This answers the question "How is traffic distributed among multiple servers on the same line?"—by allocating traffic according to weighted proportions.

　　Both methods can be used in combination: First, use line-specific resolution to direct "Beijing Telecom" users to a designated cluster. Then, assign weights of 3 and 1 to two servers on that line respectively, achieving traffic distribution based on performance.

　　V. FAQs

　　Q: When both geographic location line and carrier line match simultaneously, which takes priority?

　　A: Geographic location line takes priority. As can be seen from the Volcano Engine's matching order, "Geographic Location - Mainland China - Region - Province" ranks before "Carrier Line - Carrier - Mainland China - Region".

　　Q: Why does the user still match the default line even though I configured an exact line?

　　A: There are three possible reasons: the user's LocalDNS exit IP address is misaligned, causing a failure to match the exact line; the LocalDNS caches old results from the default line (TTL not expired); the default line has a CNAME record configured, causing cache pollution.

　　Q: Can the default line be set to a "general node" IP?

　　A: Yes, and it's recommended. The default line is for backup. It's suggested to configure a general IP from a backup data center to ensure that all users not covered by the precise line can get DNS resolution results.

　　Q: What granularity of line configuration is supported?

　　A: It supports carrier-level (China Telecom/China Unicom/China Mobile), region-level (North China/East China/South China), province-level (Beijing/Shanghai/Guangdong), and city-level (Shenzhen/Hangzhou). Lines in the Greater China region (East China, North China, etc.) usually require an enterprise plan.

　　Q: Is the location determination by Smart DNS always accurate?

　　A: Not necessarily. Its accuracy depends on two factors: whether the IP geolocation database is updated in a timely manner; and whether the user's LocalDNS supports the ECS protocol. If the user uses a public DNS that does not support ECS, the location may be inaccurate.

　　The core of Smart DNS's line priority rule is: the more precise the line, the higher the priority; the process stops once a match is found, and it proceeds down the hierarchy. Mastering these rules allows you to precisely control the DNS resolution strategy, ensuring that "telecom users go through telecom, mobile users go through mobile, and Beijing users go through the Beijing node," truly achieving "the right person goes through the right door." Remember three points when configuring: always leave a default line as a fallback; do not set a CNAME record on the default line; and use testing tools to verify that the DNS resolution results for different regions are as expected.