linda

通常来讲，在域名解析的过程中，有关我们自己的二级域名的权威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 ：

• abc.com 的 name server 是什么？--> ns1.abc.com，它负责解析abc.com域。
  
• ns1.abc.com 的IP是多少？  --> 不知道，去问 abc.com 的 name server吧！
  
• abc.com 的 name server 是什么？--> ns1.abc.com，它负责解析abc.com域。
  
• ns1.abc.com 的IP是多少？ -->  不知道，去问 abc.com 的 name server吧！
  
• 。。。 。
  

如果使用其他域的域名做解析服务器，则只要保证那个域名可以正常解析就好了。


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授权过程：

• 一般大点的公司都会自建DNS权威Name Server（即部署一个BIND）；
  
• 然后在域名注册商上注册NS（注册NS的域名和IP，IP即Glue记录）；
  
• 然后在域名注册商上配置业务域名的Name Server为刚才注册的NS域名；
  

这样一组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获取的“authoritative answer”记录信息（Authority Section），应该替换掉之前从上级NS的“additional information”中获取的信息；
  
• 如果缓存数据中存在从“authoritative answer”记录中获取的信息（Authority Section），NS应答中的“additional information”的相关信息应被忽略。
  

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

答案是肯定的，不过有一点限制条件。经我的测试和抓包分析，BIND对顶级域返回的Glue记录的“认可”情况如下：

• Root根返回的GLUE记录，BIND都是认的（即便是跨域的NS指引）
  
• 顶级域返回的GLUE记录，如果NS的域名后缀（.com、.net等）与所查询域名的后缀相同，BIND也是认的
  
• 顶级域返回的GLUE记录，如果NS的域名后缀（.com、.net等）与所查询域名的后缀不同，BIND是不认的
  

即只要我们把业务域名的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、最终方案：

• 单独在一个或两个二级域名上注册NS，该域名下不设置业务主机名
  
• 上述NS的主机域名在BIND服务器上做CDN智能解析（通过VIEW功能）
  
• 在业务的二级域名注册商上配置使用上述NS做权威解析服务器
  
• 但业务的二级域名与NS的二级域名不相同，且顶级域后缀也不同
  

2、方案示例：

• 在 ucdns.net和ucdns.com 这2个二级域名上注册NS，该域名上不承载业务，NS分布于四个机房
  
• ns1.ucdns.net和ns1.ucdns.com，注册1个电信IP、1个联通IP、1个移动IP、1个美国IP
  
• ns2.ucdns.net和ns2.ucdns.com，注册1个电信IP、1个联通IP、1个移动IP、1个美国IP
  
• ns3.ucdns.net和ns3.ucdns.com，注册1个电信IP、1个联通IP、1个移动IP、1个美国IP
  
• 上述NS的域名在权威域名解析服务器BIND上做CDN智能解析
  
  
• 其他非 .net后缀 的业务域名，使用 ns1/2/3.ucdns.net 做权威NS
  
• 如果还有 .net后缀 的业务域名，使用 ns1/2/3.ucdns.com 做权威NS
  

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/