Board logo

标题: 【DNS】权威NS的记录如何做CDN智能解析 [打印本页]
作者: linda    时间: 2016-8-24 13:34     标题: 【DNS】权威NS的记录如何做CDN智能解析

通常来讲，在域名解析的过程中，有关我们自己的二级域名的权威NS信息，是从顶级域获取的，而相关授权 Name Server 也是提前在域名注册商的管理页面中配置的，似乎无法对权威NS这一层做CDN智能访问（除了BGP anycast routing，后文也有介绍）。
本文就是为了解决这个问题而进行的一个研究，较详细的介绍了一些背景知识和相关思路，提供一个没有BGP条件的次优的解决方案。
一、引言：典型的域名解析查询过程域名解析是一个相对复杂的过程，需要多个环节，遍历多个DNS服务器，才能获取域名的IP地址。解析过程如下图：




（图片引用自阿里公共DNS网站的知识中心页面）

以解析 www.qq.com 为例，再详细示意上述过程如下：


（我原以为腾讯是做了NS级别的CDN智能解析的，从上图、以及我本地BIND测试抓包来看，其实是没有做的）


二、优化准备：背景知识

1、Glue记录的作用


如果使用本域下的域名来做解析服务器，必须在上级域指示出这个服务器域名对应的IP（Glue records），否则会陷入死循环（先有鸡还是先有蛋的问题）。
举个例子，要解析www.abc.com ：
如果使用其他域的域名做解析服务器，则只要保证那个域名可以正常解析就好了。


2、Cache解析器如何选择权威NS
在进行递归查询时，Local DNS是如何选择权威NS服务器的呢？

BIND：请求RTT时间（从发起查询请求到接收到回应的时间）越小，该权威NS被选择的几率越大。

（图片截取自 DNS-OARC 的研究报告）


3、BGP anycast routing 技术
anycast routing实际是依赖自己的BGP网络，使得在不同机房（地区）的服务器可以对外宣告相同的服务IP（段）。每一个宣告点从内部来看都是能提供完全一致的服务的不同节点，每个节点周围的用户会优先访问到离自己“最近”的节点，当一个节点的路由撤销后，之前访问这个节点的用户会访问到次近的节点上，整个过程基本是无损的（依赖于BGP的路由收敛时间）。
目前互联业内大家接触到的使用anycast有Google的 Public DNS 8.8.8.8 和 8.8.4.4：
Google Public DNS is hosted in data centers worldwide, and uses anycast routing to send users to the geographically closest data center.
以及CloudFlare的CDN节点；另外，实际上所有的DNS Root根节点也都是anycast的，单个根实际都是有几十个甚至上百个节点，每个节点还有若干服务器（感兴趣的可以看看k-root有多少个节点 http://k.root-servers.org/ ）。
阿里公共DNS在多个骨干网节点机房部署DNS服务器集群，采用BGP anycast技术宣告统一服务IP 223.5.5.5 和 223.6.6.6，接收并应答客户请求。


三、优化思路

1、我们遇到的难题

域名的Name Server授权过程：
这样一组NS就成为了业务域名的权威Name Server，同时在权威NS上也是为二级域名授权相同的NS记录。

一般情况下，公司会使用本域下的主机域名来做解析服务器，在 Local DNS 首次查询业务域名时，从顶级域来获取二级域名的授权信息，然后进行后续查询，此时我们一般认为NS这一级，只能通过BGP anycast routing技术来解决就近访问的问题。
如上面 www.qq.com 的解析查询过程中，当 Local DNS 从顶级域 X.gtld-servers.net 获取到 qq.com 的授权NS和IP后，直接向对应的NS IP发起了后续查询，而此时 Local DNS 基本上是随机挑选一个NS IP来使用的（在后续的更多查询当中才会通过基于SRTT的算法进行优化选择）。

2、BGP anycast之外的出路

Local DNS首次访问权威NS那一层，只能用BGP anycast routing技术了；

Local DNS缓存里的权威NS那一层，我们是否能做些什么呢？注意是缓存里的，因为Local DNS都是Cache服务器。
根据 rfc2181 5.4.1 Ranking data 一节的描述，域名解析器对于域名服务器返回的资源记录的处理，是有其优先级规定的：


换一个思路，如果我们将域名的NS授权给他域的解析服务器，是否可以让BIND重新发起对这个NS域名的解析，从而为我们创造CDN解析的条件，进而将Local DNS缓存中的权威NS的IP信息替换掉呢？

答案是肯定的，不过有一点限制条件。经我的测试和抓包分析，BIND对顶级域返回的Glue记录的“认可”情况如下：
即只要我们把业务域名的NS授权给一个顶级域后缀与本域不同的域名下的解析服务器，就可以让BIND重新发起对这个NS域名的解析查询。如网易将163.com 授权给了 nsX.nease.net ，Local DNS 会发起对 nsX.nease.net 的查询，得到结果后才会再向 nsX.nease.net 权威NS发起针对 www.163.com 的解析查询。

（如图，第4步的时候，网易NS是可以对 nsX.nease.net 做CDN智能解析的，可惜没有做）

四、最终方案（测试可行）
1、最终方案：

2、方案示例：

3、方案特点：
牺牲 Local DNS 首次解析业务域名的耗时（即多了几个解析NS域名的步骤），利用权威NS的authoritative应答的优先级高于顶级域返回的GLUE记录的优先级的特点，将Local DNS 的缓存中的有关业务域名的授权信息（glue）给替换成CDN智能解析后的权威应答信息（authauthority 和 authanswer），从而换取后续 Local DNS 查询业务的权威NS的速度。


BIND cache dumpdb 中的glue记录：


BIND cache dumpdb 中的 authauthority 和 authanswer 记录：

原文：https://blog.gesha.net/archives/574/



欢迎光临 中神通公司交流论坛 (http://trustcomputing.com.cn/bbs/) Powered by Discuz! 6.0.0