第2章：DNS解析与就近调度
你打开一个网页，几毫秒之内，DNS就把域名变成了IP地址。嗯，这个过程看起来很简单，但背后藏着整个CDN调度的起点。说白了，DNS是就近访问的第一道关卡。如果DNS配错了，后面再好的调度算法也白搭。
2.1 DNS工作原理：从递归到迭代
很多人觉得DNS就是查个表而已。其实它的查询链路比你想象的长得多。我举个实际例子：用户访问 www.example.com，流程是这样的——
- 浏览器先查本地缓存。没有命中？那就走第二步。
- 向本地DNS递归服务器（通常是运营商分配的）发起查询。
- 递归服务器从根域名服务器问到顶级域名服务器（.com），再问到权威服务器（example.com）。
- 权威服务器返回
www.example.com的IP地址。 - 递归服务器把结果缓存并返回给用户。
这里面有一个关键点：递归服务器的位置决定了调度能有多准。为什么？因为GSLB（全局负载均衡）通常只能看到递归服务器的IP，看不到用户真实IP。你想想看，如果你的递归服务器在北京，用户却在洛杉矶，那调度岂不是乱套了？
核心结论：CDN就近调度依赖的是递归服务器的地理位置，而不是最终用户的真实位置。如果递归服务器离用户太远，调度就会“跑偏”。
2.2 基于DNS的GSLB：用权威服务器做负载均衡
GSLB全称是Global Server Load Balancing，翻译过来就是全局负载均衡。它利用DNS的权威服务器来做决策——当递归服务器来查询某个域名时，权威服务器根据请求来源（递归服务器IP）返回不同的IP地址。比如：
- 上海的用户查
img.cdn.example.com，GSLB返回上海节点的IP（比如1.1.1.1）。 - 纽约的用户查同样域名，GSLB返回纽约节点的IP（比如2.2.2.2）。
我在项目中遇到过这么一个问题：某个海外客户抱怨访问我们CDN慢，排查后发现他的递归服务器在美国中部，但GSLB把他调度到了新加坡节点。为什么？因为GSLB配置时把北美区域和东南亚区域的地理范围重叠了……后来我们调整了IP地理库，问题才解决。
| GSLB决策要素 | 说明 |
|---|---|
| 递归服务器源IP | 最常见，但精度受限于递归服务器位置 |
| EDNS Client Subnet (ECS) | 携带用户真实IP段，精度更高 |
| 健康检查状态 | 自动剔除故障节点 |
| 负载策略 | 按权重、区域、或自定义规则分配流量 |
避坑指南：我曾经在给海外客户做方案时，忘开ECS。结果大量用户被调度到错误的地区。后来强制打开ECS，配合白名单灰度上线，才恢复正常。一定要确认你的权威DNS和递归服务器都支持ECS，否则白搭。
2.3 智能DNS解析策略：让调度更聪明
智能DNS就是把GSLB能力再包装一层，加入更精细的分流逻辑。常见的策略有这几种：
- 基于地理区域的解析：按国家、省份、甚至城市粒度返回不同IP。比如北京的用户走联通节点，上海的用户走电信节点。
- 基于运营商的解析：移动用户返回移动CDN节点，联通用户返回联通节点，避免跨网拥堵。
- 基于权重的多IP返回：同一个域名返回多个A记录，权重控制流量比例，适用于A/B测试或灰度发布。
- 基于健康探测的动态调整：如果某个节点挂了，智能DNS自动不再返回它的IP。
举个例子。某电商平台做双十一活动，需要把30%的流量导到新上线的新加坡节点做压测。他们用智能DNS把东南亚用户（新加坡递归）权重设为30%，其他区域不变。上线后一看，流量平稳，没有出现大范围故障。这就是智能DNS的灵活性。
2.4 从DNS到就近调度的完整链路
我们把这几个环节串起来，用一张图说明白：
注意：图中“用户直接连接节点”那条线只是理想情况。实际上，用户连接的是GSLB返回的IP，如果CDN节点部署了anycast，用户网络会路由到最近的节点；如果用的是普通IP，就跟DNS抢答没关系了。
2.5 实战：配置一个简单的智能DNS策略
假设我们有一个CDN服务商，域名是 cdn.mycompany.com。北京有节点B1，上海有节点S1。我们希望电信用户解析到B1，联通用户解析到S1。用Bind9的 view 语句可以做：
view "telecom" {
match-clients { 电信IP段; };
zone "cdn.mycompany.com" {
type master;
file "/etc/bind/zones/db.telecom";
};
};
view "unicom" {
match-clients { 联通IP段; };
zone "cdn.mycompany.com" {
type master;
file "/etc/bind/zones/db.unicom";
};
};然后在 db.telecom 里写：
cdn.mycompany.com. IN A 1.1.1.1 ; B1的IP
cdn.mycompany.com. IN AAAA 2001::1在 db.unicom 里写：
cdn.mycompany.com. IN A 2.2.2.2 ; S1的IP嗯，就是这么简单。但你要注意，这个方案依赖运营商IP段的准确性。我曾经遇到过IP库过期导致用户匹配错误的情况，后来我们每周从APNIC同步一次IP段数据，才解决了这个问题。
2.6 总结几个关键点
- DNS就近调度的核心是权威服务器根据请求源返回不同结果。
- 递归服务器的位置决定了调度精度，ECS是重要的辅助技术。
- 智能DNS策略可以叠加地理、运营商、权重、健康探测等多维度，但配置越复杂，维护成本越高。
- 不要迷信DNS调度可以解决一切问题，它只能做到“IP级别的就近”，其他优化（比如传输层优化）还得靠别的技术。