【DNS】权威NS的记录如何做CDN智能解析

      访问: 7,236 次      评论    

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

  1. abc.com 的 name server 是什么?--> ns1.abc.com,它负责解析abc.com域。

  2. ns1.abc.com 的IP是多少?  --> 不知道,去问 abc.com 的 name server吧!

  3. abc.com 的 name server 是什么?--> ns1.abc.com,它负责解析abc.com域。

  4. ns1.abc.com 的IP是多少? -->  不知道,去问 abc.com 的 name server吧!

  5. 。。。 。 

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


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

  1. 一般大点的公司都会自建DNS权威Name Server(即部署一个BIND);

  2. 然后在域名注册商上注册NS(注册NS的域名和IP,IP即Glue记录);

  3. 然后在域名注册商上配置业务域名的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 记录:



添加新评论