一、常规DNS调度策略原理
以CDN系统为例（其他业务系统大多采用类似的策略），来说明一下多地域部署服务如何实现用户访问请求调度的。
Step 1:客户端（假设IP地址为IP1）向Local DNS（假设IP地址为IP2）发出域名解析请求（假设请求的域名为www.taobao.com）
Step 2:Local DNS代理客户端向权威服务器发起域名解析请求
Step 3：权威服务器根据域名(www.taobao.com)和IP2（对应的地域和ISP）进行调度并返回对应的解析结果。
Step 4: 客户端根据调度返回的IP发起业务访问请求。
二、调度精确性问题
2.1 问题描述
从上面的调度过程可以看出，业务系统会根据客户端的local dns IP来判断客户所处地域和运营商，并根据该地域和运营商来调度到就近的服务节点。
可以看出，当客户的Local DNS与客户的地域和运营商不匹配时，此时按照Local DNS来调度就会出现调度不精确的问题。
下面看几个来自客户的反馈（探测结果来自AliCDN昆仑探测工具）：
探测的客户端IP和Local DNS IP以及对应的地域，运营商如下所示：
| 客户端IP | 220.249.84.** |
220.249.84.** |
| 客户端归属 | 武汉联通 | 武汉联通 |
| Local DNS IP |
183.61.13.** |
222.73.134.** |
| Local DNS 归属 | 珠海电信 | 上海电信 |
很容易看出，Local DNS地域和运营商与客户端都不匹配，此时按照Local DNS IP调度会对用户体验造成非常大的影响（国内跨运营商的访问延迟和带宽都存在非常大的问题，相信大家有深刻体验）。
2.2 问题影响面
根据我们的经验，影响的客户端占比在3%-7%之间。
2.3 原因
无线场景下主要由于以下两个方面因素导致：
（1）国内三大运营商Local DNS布点不足且不均匀，大量流量集中在2000个以内的Local DNS上，大的Local DNS对应的流量超过5Gb
（2）很多手机（尤其是山寨机）Local DNS配置不准确
如果扩展到全网（含有线访问请求），还需要考虑一个因素：
（3）公共DNS（如google 8.8.8.8，阿里的223.5.5.5,223.6.6.6）导致调度系统无法识别Local DNS的具体位置。
三、解决办法
业界当前常见的解决思路都是通过获取客户端的IP来精确定位客户端地域和运营商，实现上，有三种方式：
（1）HTTPDNS
客户端通过HTTP请求向httpdns服务器发出域名解析请求，此时httpdns服务器可以拿到客户端的精确IP，并基于客户端IP进行调度。
（2）edns client subnet
通过dns包中加入客户端IP信息，使得DNS调度系统可以拿到客户端IP并进行调度。
（3）http 302跳转
当调度系统给出的调度结果不准确时，业务服务器仍然可以根据客户端IP来判断调度是否合理，并且在必要时通过302跳转来实现重定向进而实现精确调度。
三种方式的优缺点对比如下：
| 客户端修改 | Local DNS修改 | 权威DNS修改 | 系统开销 | 使用范围 | |
| HTTPDNS | 有 | 无 | 低 | 最广 | |
| edns client subnet | 无 | 需支持edns client subnet | 需支持edns client subnet |
低 | 中等 |
| http 302 | 有(需支持302跳转) | 无 | 高 | 最差 |
HTTPDNS综合来看是最优的解决方案，当前阿里云已经推出了
HTTPDNS商业化产品。
