DNS调度原理解析

网易数智

于 2017-07-26 18:12:45 发布

阅读量506

点赞数

文章标签： java 分布式面试缓存 linux

DNS，现代互联网发展最不可或缺的服务之一，我们从访问网页到发送电子邮件，无时不刻都使用着DNS为我们提供的服务。大家都知道，DNS的核心工作就是将域名翻译成计算机IP地址，一个完整的DNS解析过程如下:

1. 用户发出www.sina.com.cn的域名解析请求，首先查询本地缓存中是否有该域名对应的IP，如果有直接返回，否则，进行第二步；

2. 本地缓存服务器向根域名服务器发起DNS查询请求，根域名服务器会发送一个回复说，.cn的域名我已经委派给.cn这台域名服务器了，给你这台服务器的地址，你去哪里查吧。

3. 本地缓存服务器收到这个答复后又向.cn域名服务器查询，如此迭代，最后.sina.com.cn的DNS服务器会收到这个请求，返回域名的实际IP给本地缓存服务器。

4. 本地缓存服务器收到这个答复后，会将这条记录返回给客户端，同时将该记录写入自己的缓存中，以便备查。

●●●

DNS调度原理

现在，大部分应用和业务都采用域名作为服务的入口，因此用DNS来负载均衡和区域调度是非常普遍的做法，网易云也有着一套基于DNS的调度系统。某些用户在进行直播推流时用的并不是网易云的直播SDK，而是一些第三方的推流软件，如obs，这样就不能使用我们的GSLB全局调度服务器来调度。对于这些用户，我们使用DNS调度的方式，对不同地域的请求返回不同解析结果，将请求调度到离用户最近的服务器节点，从而减少延迟访问。

咋一看，DNS调度这么简单方便，那为什么不让所有的用户都走DNS调度呢？想知道原因？来，我们继续讲。

●●●

地理位置调度不准确

在DNS解析过程中，与权威服务器通信的只有dns缓存服务器，所以权威服务器只能根据dns缓存服务器的IP来进行调度。因此DNS调度有一个前提：假定用户使用的缓存DNS与用户本身在同个网络内，即至少在同一个AS(自治域)内，在该前提下，DNS的解析才是准确的。通常情况下，用户使用ISP提供的本地缓存(简称localDNS)，local DNS一般与用户在同个网络内，这时候DNS调度是有效的。

但近些年，不少互联网厂商推广基于BGP Anycast的公共DNS (Public DNS)，而这些 Anycaset IP的节点一般是远少于各个ISP的节点，例如可能广州电信用户使用了某公共DNS，但该公共DNS里用户最近的是上海电信节点，甚至更极端的如Google DNS 8.8.8.8，在中国大陆没有节点(最近的是台湾)。而不幸的是国内有不少用户使用了Google DNS，这其实降低了他们的网络访问体验。总的来说，使用公共DNS，实际上破坏了上文的前提，导致DNS区域调度失效，用户以为得到了更快更安全的DNS解析，但实际得到了错误的解析，增加了网络访问延迟。

传统DNS协议的区域调度过程示例如下图，假定某业务以foo.163.com对外提供服务，在北京和东京各有一个节点，业务期望国内大陆的用户访问北京节点，而非大陆用户则访问东京节点。因为权威是根据DNS缓存来决定返回的结果，所以当用户使用不用的DNS缓存时，可能会解析到不同的结果。

2011年，Google为首的几家公司在提出了一个DNS的扩展方案edns-client-subnet(以下简称ECS)，该扩展方案的核心思想是通过在DNS请求报文里加入原始请求的IP(即client的IP)，使得权威能根据该信息返回正确的结果。目前，该方案仍处于草案阶段。该方案很好地解决了上述提到的remote DNS导致解析不准确的问题，但也带了一些问题：

至少需要 cache 和权威都支持，才能完成完整的 ECS 解析；
ECS 给 cache 增加了很大的缓存压力，因为理论上可能需要为每个IP段分配空间去缓存解析结果

●●●

规则变更生效时间不确定

当缓存服务器向权威服务器查询得到记录之后，会将其缓存起来，在缓存有效期内，如果收到相同记录的查询，缓存服务器会直接返回给客户端，而不需要再次向权威查询，当有效期过后，缓存则是需要再次发起查询。这个缓存有效期即是TTL。

虽然 DNS 的缓存机制在大多数情况下缩短了客户端的记录解析时间，但缓存也意味着生效同步的延迟。当权威服务器的记录变更时，需要等待一段时间才能让所有客户端能解析到新的结果，因为很可能缓存服务器还缓存着旧的记录。

我们将权威的记录变更到全网生效这个过程称为 propagation，它的时间是不确定的，理论上的最大值即是TTL的值，对于记录变更或删除，这个时间是记录原本的TTL，对于记录新增则是域的nTTL值。

如果一个域名记录原本的TTL是18000，可以认为，变更该记录理论上需要等待5个小时才能保证记录能生效到全网。假设该域名的业务方希望缩短切换的时间，正确的做法是，至少提前5个小时修改记录，仅改小TTL，例如改为5分钟，等待该变更同步到全网之后，再进行修改指向的操作，确认无误再将TTL修改为原本的值。

虽然DNS协议标准里建议缓存服务器应该记住或者缩短TTL的值，但实际上，有一些DNS缓存会修改权威服务器的TTL，将其变大，这在国内几大运营商中是很常见的。例如，某域记录的TTL值实际上设置为60，但在运营商的DNS缓存上，却变成600或者更大的值，甚至还有一些DNS缓存是不遵循TTL机制。这些都会影响域名的实际生效时间。

●●●

高可用

为避免受DNS缓存的影响，需要保证DNS中A记录的IP节点高可用性。对此，网易云DNS调度系统采用的方案是在同一区域的多台直播服务器节点之间做负载均衡，对外只暴露一个虚IP，这样，即使某台服务器宕机，负载均衡能迅速感知到，排除故障节点，而对DNS而言，因为虚IP不变而不受影响。