DNS Smart Resolution and CDN Routing: GSLB and Line-based Splitting

The Domain Name System (DNS) is often called the "phonebook of the Internet": it translates human-readable domain names into machine-readable IP addresses. For a CDN, DNS is more than a lookup tool — it is the first gate of traffic routing. Which node a user is directed to depends largely on DNS resolution policy.

1. DNS Resolution Basics

1.1 Recursive Resolvers and Authoritative Servers

A full resolution usually involves two kinds of servers:

  • Recursive resolver: accepts client queries and chases the answer step by step, typically run by ISPs or public DNS (Google, Cloudflare);
  • Authoritative nameserver: actually holds the records and returns the final answer — the last stop in the resolution chain.

1.2 The 8-Step Lookup

With no cache, the path is browser → recursive resolver → root server → TLD server → authoritative server, each returning a pointer until the IP reaches the browser. It all happens "behind the scenes," but every hop adds latency.

1.3 TTL and Caching

Results are cached at the browser, OS, and resolver levels for a duration set by TTL (Time to Live). Higher TTL means faster repeat lookups but slower propagation of DNS changes. Lowering TTL before node switches or failover is standard practice.

2. Smart Resolution: The Core of CDN Routing

2.1 From "One Domain, One IP" to On-Demand Answers

Normal resolution returns a fixed IP for a domain. A CDN's authoritative DNS instead inspects the requester and dynamically returns the best node IP. This is "smart resolution": the same domain yields different results for different regions and ISPs.

2.2 Routing Dimensions

  • Geographic proximity: return the nearest node based on resolver location;
  • ISP lines: distinguish carriers such as telecom, Unicom, and Mobile to avoid cross-carrier bottlenecks;
  • Health checks: probe node availability in real time, removing failed nodes and directing traffic to healthy ones;
  • Load and cost: factor in node load, bandwidth cost, and more.

This capability is usually called GSLB (Global Server Load Balancing) and underpins CDN, multi-CDN load balancing, and dynamic acceleration.

2.3 Anycast and DNS Working Together

Many CDNs use Anycast: multiple nodes share one IP, and the network layer routes to the nearest node automatically. DNS only needs to return one (or a few) IPs, and routing logic moves down to the network layer, making failover faster and more transparent. For Anycast fundamentals, revisit how CDN works.

3. Typical DNS Splitting Scenarios

3.1 Domestic and Overseas Splitting

Sites serving both domestic and overseas users often use smart resolution to route each group to the right nodes, sometimes combined with overseas CDN acceleration. This is the common shape of hybrid "global acceleration + domestic compliant lines" architectures.

3.2 Multi-Provider Switching

In multi-CDN provider comparisons and disaster recovery, DNS can act as a master switch, distributing traffic across providers by line or by ratio for canary rollouts and failover.

3.3 Subdomain-Level Routing

By configuring different resolution policies for different subdomains, you can route APIs, static assets, and downloads to the most suitable paths for fine-grained control.

3.4 A Line-Based Configuration You Can Copy

For a common "domestic + overseas" site, in a DNS panel that supports line-based resolution, you typically define several "line → node IP" mappings per A/AAAA record, matched top-down by priority:

Record Line Returned IP Purpose
www Default (fallback) Overseas node IP Visitors not matched elsewhere
www Telecom Telecom access IP Domestic Telecom users
www Unicom Unicom access IP Domestic Unicom users
www Mobile Mobile access IP Domestic Mobile users
api Default API cluster VIP APIs take a dedicated entry

The default fallback line must always exist: when a specific line has no healthy node, DNS falls back to the default record instead of failing resolution. Combined with health checks, the panel automatically switches that line to a backup IP when a node goes down.

The standard TTL migration flow is worth memorizing: if a record's TTL is 86400 seconds and you plan to switch nodes, lower the TTL to 60 seconds one or two days before the change, wait for caches to refresh, then change the IP, watch for 24 hours with no issues, and finally restore the daily TTL. This "lower TTL → change record → observe → restore" sequence is what keeps DNS changes incident-free.

4. 16IDC View: Getting Full Value from DNS Routing

In 16IDC's practice, DNS smart resolution is one of the most overlooked yet most effective optimizations. Some advice:

  • Health checks first: routing policy is worthless without accurate node health data;
  • Control TTL: use moderate TTL (300-600s) day to day, and temporarily lower it to about 60s before changes;
  • Mind cache layers: ISP recursive resolver caches lag, so allow time for worldwide propagation after changes;
  • Harden security: pair smart resolution with DNSSEC and domain resolution troubleshooting to prevent hijacking and misjudgment.

DNS is the "first mile" of CDN routing and the foundation of the CDN network experience. Getting resolution policy right often improves time-to-first-byte more directly than blindly adding nodes.

Reference: RFC 7871 EDNS Client Subnet https://www.rfc-editor.org/rfc/rfc7871

Source: https://www.cloudflare.com/learning/dns/what-is-dns/