2. 工业和信息化部 信息中心, 北京 100846
2. Information Center of Ministry of Industry and Information Technology, Beijing 100846, China
域名系统(domain name system,DNS)是逐级授权的分布式数据库,主要负责将域名映射到IP地址,是Internet重要的基础设施,网页浏览、电子邮件、文件传输等都依赖DNS来实现网络资源的寻址和定位。域名系统是由多个节点的域名服务器组成的一些链条,任何一环的薄弱都将影响整体的安全性能。
近年来,针对DNS的网络攻击事件越来越多。2013年初,全球最大的数字证书颁发机构Verisign的系统承受的攻击出自于域名解析系统服务器。2013年3月,欧洲反垃圾邮件组织Spamhaus突然遭受到高达300 Gbps的大流量DNS反射/放大DDos攻击。
域名系统自身的安全性问题和可用性问题,已经成为普遍关注的问题。当前DNS研究主要围绕域名服务器可用性的测量[1-3]、基于缓存中毒的检测[4]、异常流量数据的检测[5-6]、DNSSEC安全协议研究[7]以及结合域名进行僵尸网络追踪[8]等。文[9]首先提出了DNS依赖性概念,展示了DNS依赖性对DNS安全的重要影响,并追踪了大量域名之间的依赖关系。Deccio等[10-11]提出了DNS依赖性模型,讨论了可信计算基中的域名对解析指定域名的影响程度,并用0~1之间的数值量化了影响程度。文[12]首次实际测量了由于域外DNS服务器导致的流量和解析延迟变化情况,观察到60%的DNS流量使用的是域外的DNS服务器,这使解析延迟增加了大约47%。
综上可以看出,已有的研究在不同的研究目标上对域名服务体系的安全性展开了相关工作,但针对域名解析依赖对域名空间的安全性和脆弱性的研究比较浅显,对域名体系解析依赖关系结构研究不够深入,无法为更加合理的配置和管理域名提供有意义的建议。
本文从域名解析角度研究域名体系的可用性和可生存性,运用故障树法分析域名解析故障问题,挖掘保证域名解析成功的关键服务器集合和引起解析故障的关键服务器集合。研究结果可以帮助管理员发现域名解析中的重要域名服务器,提前做好防护工作。
1 基于故障树的域名解析故障分析方法由于域名解析过程存在着域名依赖关系,这些依赖关系决定了在域名解析过程中,如果某些域名服务器发生故障,正常的域名解析就不能完成。故障分析针对域名解析时域名服务器间的依赖关系图,运用故障树分析法分析域名解析过程中的关键服务器集合,挖掘域名体系中的重点保护目标。
1.1 域名解析的依赖关系DNS是Internet上最为关键的基础设施。作为全球最大也是最为成功的分布式系统,其效率和普及程度是其他服务所无法比拟的。为了处理规模问题,DNS使用了大量域名服务器,它们以层次方式组织,并且分布在全世界范围内。DNS通过授权和基础的规则管理各个域和区。管理员在配置域时,一般会把权威域名服务器放置在自己的管理域内。但多数DNS域的管理者会根据DNS协议规范[13-14]要求,为其管理的域配置多个权威服务器来增加域名解析的性能,并将DNS服务器分布在不同区域以增加域名解析的可靠性。然而在DNS协议规范中没提出任何机制来限制域之间的依赖关系,这导致一个域的依赖关系可能变得非常复杂。由于存在域外依赖的影响,使得域和域之间存在关联,域及权威DNS服务器形成复杂的依赖关系。因此,一个域名的解析可能会引起其他多个域名的一系列解析过程,这样就产生了域名解析过程中的依赖关系。
下面给出域名解析过程中依赖关系的定义。
定义1 如果域名u依赖于域名v,当且仅当域名v的解析结果影响域名u的解析结果。
依赖关系是具有传递性的,即如果域名u依赖于域名v,且域名v依赖于域名w,那么域名u也依赖于域名w。
存在域名解析依赖关系,主要由于以下3个原因。
1) 对父域的依赖:由于域名的解析过程是自顶向下的,一个域名的解析总是依赖于其父域。
2) 对权威域名服务器的依赖:权威域名服务器在资源记录中,其形式是域名而非IP地址,如果一个解析器从资源记录中找到了域名所属的权威域名服务器,则它需要先解析出这个权威服务器的IP地址,才可以向这个权威服务器发起域名解析请求。
3) 对别名的依赖:如果一个域名存在别名,则这个别名必须先被解析,因此,一个域名的解析总是依赖于其别名。
正是由于这些依赖关系的存在,所以在解析过程中,如果某些被依赖的服务器无法正常提供解析服务,那么就会造成域名解析的失败。
1.2 域名解析依赖关系图构建域名解析过程中的依赖关系,可以通过探测的方式获得。在探测过程中,需要对DNS应答包中的名字服务器记录的所有权威域名服务器进行解析依赖关系探测。分析汇总后的数据可以反映域名解析过程中,域名、域和名字服务器之间的内在关联。进一步挖掘这些数据,可以得到域名解析的依赖关系,从而构建域名解析依赖图,探究域名解析中存在的安全问题。
根据依赖关系的定义,可以构建域名解析依赖关系图,下面给出依赖关系图的定义。
定义2 域名解析依赖关系图可以定义为二元组:
$ {G_{\text{d}}} = \left( {{V_{\text{d}}}, {A_{\text{d}}}} \right). $ | (1) |
其中:Vd是节点集合,图中任意一个节点
下面说明如何根据域名解析依赖关系构建域名解析关系图。假设域edu.net及相关域的DNS服务器使用如表 1—6所示的参数进行配置,则域edu.net的域名解析依赖关系如图 1所示。
域 | 类型 | 值 |
edu.net | NS | dns1.edu.net |
edu.net | NS | dns2.edu.net |
edu.net | NS | ns1.edu.hk |
edu.net | NS | ns1.dfn.de |
dns1.edu.net | A | 202.0.2.1 |
dns2.edu.net | A | 202.0.2.2 |
域 | 类型 | 值 |
dfn.de | NS | ns1. dfn.de |
dfn.de | NS | ns2. dfn.de |
ns1. dfn.de | A | 202.0.4.5 |
ns2. dfn.de | A | 202.0.4.6 |
域 | 类型 | 值 |
net | NS | ns1.net |
net | NS | ns2.net |
ns1.net | A | 202.0.5.3 |
ns2.net | A | 202.0.5.4 |
edu.net | NS | dns1.edu.net |
edu.net | NS | dns2.edu.net |
edu.net | NS | ns1.edu.hk |
edu.net | NS | ns.dfn.de |
dns1.edu.net | A | 202.0.2.1 |
域 | 类型 | 值 |
hk | NS | ns1.hk |
ns1.hk | A | 202.0.6.8 |
edu.hk | NS | ns1.edu.hk |
edu.hk | NS | ns2.edu.hk |
ns1.edu.hk | A | 202.0.3.5 |
ns2.edu.hk | A | 202.0.3.6 |
域 | 类型 | 值 |
de | NS | ns1.de |
ns1.de | A | 202.0.7.8 |
dfn.de | NS | ns1. dfn.de |
dfn.de | NS | ns2. dfn.de |
ns1. dfn.de | A | 202.0.4.5 |
ns2. dfn.de | A | 202.0.4.6 |
域名edu.net的解析过程依赖其父域net域区的解析,只有net解析成功,才能进行edu.net的解析。另一方面,edu.net又依赖于其域区配置的NS记录中的4个DNS权威服务器, 其中ns1.edu.hk与ns1.dfn.de是域外依赖,即依赖于其他的域区。因为域名解析中存在域外依赖,使得域名解析的依赖结构不是域名系统的层次结构,而是形成如图 1所示的有向图。DNS的解析过程是一个从根服务器到权威服务器的传递信任行为,解析一个域名时需要多少DNS服务器参与进来以及哪些DNS服务器是关键节点是本文研究的重点。
1.3 基于故障树的关键域名服务器集合挖掘故障树分析[15] (fault tree analysis,FTA)技术是可靠性分析及故障诊断的有效工具,在分析系统故障模式、寻找薄弱环节、指导故障维修等工作中具有重要的参考价值。由于故障树分析特点,因此可以采用该方法对域名解析过程中可能出现故障的薄弱服务器进行挖掘,利用挖掘得到的域名服务器集合分析域名故障情况,从而对这些关键的域名服务器进行必要的管理和防护。
域名解析故障树将顶事件设为一个域名解析失败的故障,从而对该故障树的顶事件发生的情况进行定性分析,即挖掘引起域名解析故障的最小DNS服务器集合,相应的也可得到保证域名解析成功的最小DNS服务器集合。
1) 依赖关系图到域名解析故障树的转换
图 1展示的依赖关系体现了服务器之间的层级关系,需要挖掘节点之间的逻辑关系,将一棵依赖关系图转换成故障树。故障树节点事件的发生与否取决于其子节点事件的发生情况,并且不同类型子节点之间逻辑关系不同。
节点的祖先域区节点都是“或”的关系,例如域edu.net的祖先域区节点是net节点和根服务器节点,这2个节点任何一个发生故障,edu.net都不可能解析成功。
兄弟节点之间的关系根据节点类型不同,有如下2种情况。
a) 如果兄弟节点都是权威服务器,则兄弟节点是“与”的关系。因为只要有一个权威域解析成功,域名就可以解析成功。
b) 权威服务器点节点与CNAME节点是“或”的关系。例如,域名www.baidu.com的解析过程为权威域名服务器baidu.com将www.baidu.com的解析通过别名转移到www.shiften.com的解析。可见,使得www.baidu.com解析失败的原因,或者是权威服务器baidu.com失效,或者是别名www.shiften.com失效,或者两者都失效。
根据以上转换方式,图 1对应的故障树如图 2所示,故障树的顶事件表示域名edu.net解析失败,其故障发生是由椭圆表示的底事件引起的。这些底事件中哪些是关键服务器集合由下面的故障树定性分析挖掘得到。
2) 域名解析故障树的定性分析
域名故障树的定性分析可以采用布尔运算等手段计算得到对系统故障影响的关键集合。首先设域名故障树的底事件为Xi,顶事件为Φ,则Xi=0或1分别表示底事件发生与否,而Φ=0或1表示顶事件发生与否。域名故障树的结构函数是表示系统状态的布尔函数:
$ \mathit{\Phi} = \mathit{\Phi} \left( {\vec X} \right), \vec X = \left( {{x_1}, {x_2}, \cdots, {x_n}} \right). $ | (2) |
可以计算表示故障树中典型逻辑门的结构函数,其中:与门为
对于复杂系统,其结构函数是相当冗长繁杂的,可根据逻辑运算规则的概念对结构函数进行改写。通过计算得到最小割集(minimum cut set, MCS)和最小径集(minimum path set, MPS),即得到了域名解析对应的2种关键服务器集合。因此,求解域名故障树的MCS和MPS是FTA中的一项重要任务。
a) 基于MCS的引起域名解析故障的关键服务器集合挖掘。
MCS表明系统故障发生的途径。引起顶事件发生的最小的底事件集合称为MCS。因此可通过求取故障树的MCS来获取引起域名解析故障的关键服务器集合。挖掘算法如下:
Ⅰ) 从故障树顶事件开始,由上到下,顺次把上一级事件置换为下一级事件。遇到与门将输入事件横向并联写出,遇到或门将输入事件竖向串联写出,直到把全部逻辑门都置换成底事件为止,此时最后一列表示出基本事件组成的割集;
Ⅱ) 然后将割集简化,得到全部MCS;
Ⅲ) 当故障树所有事件无重复时,所得基本事件组成的割集即为全部MCS,即获得了域名可解析关键服务器集合,算法结束。
b) 基于MPS的保证域名解析成功的关键服务器集合挖掘。
径集是指其中的基本事件都不发生就能保证顶事件不发生的基本事件集合。若径集中包含的基本事件不发生,对保证顶事件不发生充分必要,则该径集称为MPS。
根据故障树的原理,对故障树的对偶树求MCS,就得到了原故障树的MPS。
MPS表明应该采取措施使一些初始原因不同时出现就可以避免事故,因此可通过求取故障树的MPS,挖掘保证域名解析成功的关键服务器集合。挖掘算法如下:
Ⅰ) 把故障树变换为与之相应的对偶树,即把故障树的故障发生事件用与其相反的故障不发生事件代替,把逻辑“与门”用逻辑“或门”代替、逻辑“或门”用逻辑“与门”代替,从而得到对偶树;
Ⅱ) 求对偶树的最小割集合,则对偶树的MCS就是原故障树的MPS,即获得了保证域名解析成功的关键服务器集合,算法结束。
2 实验与分析从单个域名解析和整体域名解析2个方面,使用基于故障树的域名解析故障分析方法分析域名解析可能存在的故障问题。
2.1 单个域名解析故障分析以域名www.hitwh.edu.cn为例,挖掘保证该域名解析成功的关键服务器集合和引起解析故障的关键服务器集合。域名解析数据是依照RFC1034[13]和1035[14]标准,通过发送和接收DNS域名查询请求包,模拟DNS迭代查询过程。从根节点开始发送域名查询请求包,对返回的响应包进行解析,提取出A记录、CNAME记录、NS记录。对于NS记录中的每个权威域名服务器,都会发送域名查询请求包,并记录权威域名服务器的响应状况。另外,在域名解析过程中,假设根名字服务器和顶级名字服务器处于正常状态,因此本文研究的域名解析依赖关系中的服务器只涉及顶级域以下的服务器,并在故障分析中忽略了服务器缓存的影响。
1) 解析过程中依赖的DNS服务器集合
从表 7可以看到域名www.hitwh.edu.cn的解析过程共依赖19个域名服务器,这19个域名服务器是在解析该域名时可能使用到的所有服务器。
域名服务器 | 服务器IP地址 |
DNS2.hitwh.edu.cn | 222.194.15.9 |
DNS1.hitwh.edu.cn | 222.194.15.6 |
cernet.net | 202.112.0.46 |
ns2.net.edu.cn | 202.112.0.13 |
dns.edu.cn | 202.112.0.35 |
edu.cn | 202.112.0.36 |
ws-fra1.win-ip.dfn.de | 193.174.75.178 |
ws-kar1.win-ip.dfn.de | 193.174.75.154 |
ws-mue1.win-ip.dfn.de | 193.174.75.166 |
cuhk.hk | 137.189.8.95 |
dns2.edu.cn | 202.112.0.13 |
ns2.cuhk.hk | 137.189.6.21 |
deneb.dfn.de | 192.76.176.9 |
tu-berlin.de | 130.149.7.201 |
ns.tu-berlin.de | 130.149.7.7 |
ws-ber1.win-ip.dfn.de | 193.174.75.142 |
NS2.CUHK.EDU.hk | 137.189.6.21 |
NS1.CUHK.EDU.hk | 137.189.6.1 |
ANYNS.CUHK.EDU.hk | 204.61.216.69 |
2) 引起域名解析故障的关键服务器集合
引起域名解析故障的关键服务器集合如表 8所示。从表 8可以看出该域名的解析过程中,有5个引起解析故障的关键服务器集合,其中最小的集合有2个域名服务器。这5个集合中,如果其中一个集合的所有域名服务器不能正常工作,则将导致域名解析失败。例如,如果集合编号为5的集合中的这2个服务器都不能正常工作,将会导致该域名解析失败。
集合 编号 |
域名服务器集 |
1 | deneb.dfn.de+dns.edu.cn+dns2.edu.cn+ns2. cernet.net+ns2.cuhk.hk |
2 | deneb.dfn.de+dns.edu.cn+dns2.edu.cn+ns2. cuhk.hk+ns2.net.edu.cn |
3 | ANYNS.CUHK.EDU.hk+NS1.CUHK.EDU.hk +NS2.CUHK.EDU.hk+NS3.CUHK.EDU.hk+ deneb.dfn.de+dns.edu.cn+dns2.edu.cn+ns2. cernet.net |
4 | ANYNS.CUHK.EDU.hk+NS1.CUHK.EDU.hk +NS2.CUHK.EDU.hk+NS3.CUHK.EDU.hk+ deneb.dfn.de+dns.edu.cn+dns2.edu.cn+ns2. net.edu.cn |
5 | DNS1.hitwh.edu.cn+DNS2.hitwh.edu.cn |
3) 保证域名解析成功的关键服务器集合
保证域名解析成功的关键服务器集合如表 9所示。表 9中域名服务器集就是保证域名解析成功的最小服务器集合。从表 9可以看出关键服务器集合有16个,只要一组保持可用,即可实现该域名解析成功。
集合 编号 |
域名服务器集 |
1 | DNS2.hitwh.edu.cn+NS2.CUHK.EDU.hk+ns2.cuhk.hk |
2 | DNS1.hitwh.edu.cn+NS2.CUHK.EDU.hk+ns2.cuhk.hk |
3 | DNS2.hitwh.edu.cn+NS3.CUHK.EDU.hk+ns2.cuhk.hk |
4 | DNS1.hitwh.edu.cn+NS3.CUHK.EDU.hk+ns2.cuhk.hk |
5 | DNS2.hitwh.edu.cn+NS1.CUHK.EDU.hk+ns2.cuhk.hk |
6 | DNS1.hitwh.edu.cn+NS1.CUHK.EDU.hk+ns2.cuhk.hk |
7 | ANYNS.CUHK.EDU.hk+DNS2.hitwh.edu.cn+ns2.cuhk.hk |
8 | ANYNS.CUHK.EDU.hk+DNS1.hitwh.edu.cn+ns2.cuhk.hk |
9 | DNS2.hitwh.edu.cn+deneb.dfn.de |
10 | DNS1.hitwh.edu.cn+deneb.dfn.de |
11 | DNS2.hitwh.edu.cn+ns2.cernet.net+ns2.net.edu.cn |
12 | DNS1.hitwh.edu.cn+ns2.cernet.net+ns2.net.edu.cn |
13 | DNS2.hitwh.edu.cn+dns.edu.cn |
14 | DNS1.hitwh.edu.cn+dns.edu.cn |
15 | DNS2.hitwh.edu.cn+dns2.edu.cn |
16 | DNS1.hitwh.edu.cn+dns2.edu.cn |
2.2 域名体系整体域名解析故障分析
整体域名解析故障分析是使用上述描述的域名解析故障分析法对大量域名的解析过程进行分析,并进行数据统计,从而从宏观上为域名体系整体风险估计提供必要的数据支持。
这里使用的域名数据来源于网络导航服务提供商Alex所提供的Top 50 000网站的排名数据,这些网站是访问量最高、最受关注的站点,提供的服务涵盖了新闻、娱乐、体育、在线游戏、电子商务、搜索引擎和论坛等各个方面,非常具有代表性。域名的解析依赖关系获取原理与节2.1相同。
1) 引起域名解析故障的最小服务器数量统计结果分析
在Alex Top 50 000的域名中,引起域名解析故障的最小服务器数量的统计分布结果如图 3所示。图 3表示最小域名服务器数量对应的域名数。在测试的50 000域名中,探测到的有效域名为45 185个,域名的故障服务器数值在[1, 13]区间内,平均值为2.87个。进一步统计显示:59.46%的域名所依赖的最小关键服务器数量为2,说明这是DNS域区的一般配置,如果这2台服务器处于同一个子网中,则此域名有较高的解析风险;90.25%的域名的值小于等于4,即对于绝大多数的域名,引发解析失败的最小服务器的数量不超过4台。但是在统计结果中,有0.31%域名的值低至1,这说明如果这一台域名服务器出现故障,依赖它的域名将解析失败,这也反映了在域名系统中,个别域名解析失效的风险极高,对于这种情况,管理人员在配置授权信息时应采用有效方式降低解析失效风险。
2) 保证域名可解析最小服务器数量统计结果分析
保证域名可解析的最小服务器数量的统计分布结果如图 4所示。保证域名可解析的最小服务器数量在[1, 7]区间范围内,平均值为1.44。进一步统计表明,96.55%的域名的可解析最小服务器集合值小于等于2,即对于绝大多数的域名,保证域名可解析所需的最小DNS服务器的数量不超过2台(不包括根域名服务器与顶级域名服务器)。在统计的50 000个域名中,有0.36%的域名的保证解析成功的最小服务器集合数量大于等于4,即只有这些DNS服务器都工作正常才能保证域名解析成功。这反映了个别域名区域配置存在不合理的依赖关系,对于这些不合理的依赖关系,它们将导致非必要的域名解析过程,加重DNS服务器的解析负载。
3 结论
域名系统对互联网的重要性是显而易见的,虽然人们已经开始重视域名系统的各种安全威胁和问题,但是对域名系统整体安全性的分析还处在起步阶段。本文从域名解析过程中存在的依赖关系入手,应用故障树分析法提出了域名解析故障分析方法,得到了域名解析过程中的保证域名可解析的关键服务器集合和引起解析故障的关键服务器集合。这些结果既可以帮助人们发现关键域名服务器集合,为安全防护提供目标,又可以在域名解析出现问题时快速找出产生故障的位置,为指导域名服务体系配置、管理、部署和升级提供切入点,提高域名服务体系服务能力。
[1] | Lee B S, Yu S T, Sekiya Y, et al. Availability and effectiveness of root DNS servers: A long term study [C]//Network Operations and Management Symposium. Osaka, Japan: IEEE, 2010: 862-865. |
[2] | Casalicchio E, Caselli M, Coletta A. Measuring the global domain name system[J]. IEEE Network, 2013, 27(1): 25–31. DOI:10.1109/MNET.2013.6423188 |
[3] | Krishnan S, Monrose F. An empirical study of the performance, security and privacy implications of domain name prefetching [C]//International Conference on Dependable Systems & Networks. Hong Kong, China: IEEE, 2011: 61-72. |
[4] | Son S, Shmatikov V. The hitchhiker's guide to DNS cache poisoning [C]//Security and Privacy in Communication Networks International ICST Conference. Singapore: Springer, 2010: 466-483. |
[5] | Dagon D. Large-scale DNS data analysis [C]//ACM Conference on Computer and Communications Security. Raleigh, NC, USA: ACM, 2012: 1054-1055. |
[6] | Kadir A F A, Othman R A R, Aziz N A. Behavioral analysis and visualization of fast-flux DNS [C]//European Intelligence and Security Informatics Conference. Odense, Denmark: IEEE, 2012: 250-253. |
[7] | Deccio C, Sedayao J, Kant K, et al. Quantifying and improving DNSSEC availability [C]//Proceedings of the International Conference on Computer Communication and Networks. Hawaii, USA: IEEE, 2011: 1-7. |
[8] | Choi H, Lee H. Identifying botnets by capturing group activities in DNS traffic[J]. Computer Networks, 2012, 56(1): 20–33. DOI:10.1016/j.comnet.2011.07.018 |
[9] | Ramasubramanian V. Perils of transitive trust in the domain name system [C]//Proceedings of the 5th ACM SIGCOMM conference on Internet Measurement. Berkeley, CA, USA: ACM, 2005: 379-384. |
[10] | Deccio C T, Chen C C, Sedayao J, et al. Quality of name resolution in the domain name system [C]//IEEE International Conference on Network Protocols. Princeton, NJ, USA: IEEE, 2009: 113-122. |
[11] | Deccio C. Quantifying and Improving DNS Availability [D]. Davis: University of California Davis, 2010. https://www.researchgate.net/profile/Jeff_Sedayao/publication/224256539_Quantifying_and_Improving_DNSSEC_Availability/links/0deec51ed48bf1f47b000000.pdf?inViewer=true&disableCoverPage=true&origin=publication_detail |
[12] | Fujiwara K, Sato A, Yoshida K. DNS traffic analysis: Issues of IPv6 and CDN [C]//IEEE/IPSJ 12th International Symposium on Applications and the Internet. Izmir, Turkey: IEEE, 2012: 129-137. |
[13] | RFC1034. Domain Names: Concepts and Facilities [S]. Fremont: IETF, 1987. |
[14] | RFC1035. Domain Names: Implementation and Specification [S]. Fremont: IETF, 1987. |
[15] | 罗航. 故障树分析的若干关键问题研究[D]. 成都: 电子科技大学, 2011. LUO Hang. Research on Several Key Problems Based on Fault Tree Analysis [D]. Chengdu: University of Electronic Science and Technology of China, 2011. (in Chinese) http://cdmd.cnki.com.cn/Article/CDMD-10614-1011054966.htm |