2013年8月25日凌晨，.CN域名凌 晨出现大范围解析故障，经分析.CN的根域授权DNS全线故障，导致大面积.CN域名无法解析。事故造成大量以.cn和.com.cn结尾的域名无法访 问。直到当日凌晨4点左右，CN根域名服务器的解析才有部分恢复。此后，经CNNIC确认，国家域名解析节点遭受到有史以来规模最大的拒绝服务***，导致 访问延迟或中断，部分网站的域名解析受到影响。而距本次事故发生一个月之后，本月24号，CNNIC和工信部终于揪出了本次***事件的始作俑者--一名来 自山东青岛的***。
据调查发现，该***本意是要***一个游戏私服网站，使其瘫痪，后来他为了更快达到这个目的，直接对.CN的根域名服 务器进行了DDoS***，发出的***流量堵塞了.CN根服务器的出口带宽(据工信部数据：***时峰值流量较平常激增近1000倍，近15G)，致使.CN 根域名服务器的解析故障，使得大规模的.CN域名无法正常访问。
DDoS***背后的利益链条
大家可能会有疑问，看似普通的DDoS***其背后究竟隐藏着什么？一句话：为了利益。本次事故中***者使用的手法(譬如***一些“私服”的网站或主机) 并不罕见，且近些年有愈演愈烈的趋势。自国内的互联网事业兴起以来，国内有一些常年进行DDoS***的组织或个人，胁迫某些“私服”游戏的运营团队并收取 “保护费”，如果不合作便采取DDoS暴力***，使其无法正常运营。而这些“私服”的运营团队本身业务就涉及侵权，所以他们在遇到DDoS威胁时绝不敢报 警或维权，往往是被迫接受。这种恶性循环的结果就是这些网络中的恶意胁迫越来越肆无忌惮，这些从事DDoS***商业行为的组织或个人也演变成了各式各样的 “网络黑帮”，各式黑色产业链也层出不穷。由于当今互联网上DDoS***的门槛已经越来越低，雇主可以购买DDoS***服务，***可指定时间、指定流量、 指定***效果。总的来说，同行业间的恶意竞争是导致DDoS***愈演愈烈的最大原因，同时被***后定位***者所花费的成本较高也是这类事件层出不穷的重要 原因。
为何选择针对DNS服务器进行DDoS***
一直以来作为网络基础设施的DNS系统，给我们提供了访问互联网的便利，用户只需记住域名就可以访问到互联网上的对应主机。当你在浏览器中输入一个域名时，DNS的解析过程就开始了，一般的DNS解析过程如图1、图2所示：
图1:DNS解析的一般过程(有缓存时)
图2：DNS解析的一般过程(无缓存时)
下面来聊一聊现有互联网上运行的DNS系统所可能遭受到的风险。大家应该都了解，根域名服务器是DNS系统中最高级别的域名服务器，全球一共有13台， 多数分布在美国。首先，DNS系统是一个中心化的树形结构，很容易遭受DDoS***，且越靠近中心***效果越为显著；其次，现有DNS系统的迭代查询方 式，对根域和顶级域解析服务器依赖非常严重；再次，现有互联网上存在着大量开放式的DNS域名服务器，这些服务器通常拥有强大的性能和带宽，利用DNS反 射技术的放大效应，可以产生近其带宽百倍的***流量。所以这些开放式的DNS服务器极其容易成为***们青睐的DDoS***“肉鸡“。这对整个互联网的基础 设施都是巨大的安全威胁。
在对现有DNS协议的风险评估上，DNS协议是很脆弱且不安全的。为什么说DNS协议很脆弱呢？一方面DNS 协议是明文协议，协议里带的信息可以很容易的被篡改、伪造，使得DNS协议易成为暴露用户行为的工具；另一方面，若在现有协议传输上采用加密手段，现有 DNS体系无法承受加密带来的开销和技术升级的成本。
正因为DNS系统的脆弱性和其协议设计上的缺陷，所以历史上针对DNS的***事件也比较多，影响比较大有2013年针对Spamhaus的***事件、2009年5.19断网、2008年DNS缓存投毒，以及2002年全球根域名服务器被***等等。
深入剖析本次.CN被***事件
从本次.CN根服务器被DDoS***的手法上来看，有两种可能性，一种可能是***使用DDoS方法***某个.CN域名，而较大的***流量或海量的查询请 求却把该.CN域名上一级根服务器打挂；第二种可能是***直接把DDoS***矛头指向了.CN的根域名服务器。针对DNS系统，常见的DDoS***手法 是：
1)传统DDoS***： 流量型(以堵塞网络带宽为主要***目的)，包括UDP洪水***；TCP流量***；资源消耗型(以消耗目标机器可用资源为***目的)，包括SYN洪水***，ACK洪水***，ACK反射***，慢速消耗***等；
2)DNS特有DDoS***：DNS反射***(放大效应)、DNS查询***(僵尸主机发起的海量请求)、变域名***：构造随机域名(或畸形域名)的查询请求，利用僵尸网络对目标域名或主机进行***(如图3所示)。
图3：DNS QUERY洪水***原理
为了最大限度的降低命中DNS缓存的可能，一般***者在构造***包时都会随机伪造查询源IP地址、伪造随机源端口，伪造随机查询ID以及待解析的域名。 从笔者获取到本次.CN***的数据包来看(见下图4)，***者就是把经过特殊构造的海量的随机域名的查询请求直接发给了.CN的根服务器，也就是上文中提 到的变域名***方式。不过，笔者认为其中可能还混合有其他一些诸如UDP洪水、DNS放大和DNS僵尸查询等DDoS***，最终的目的就是让被***网络的 链路带宽超出服务的带宽，让目标机或集群处理能力超出极限，从而达到DNS解析不能提供正常服务的状态。
图4：.CN的***数据包(部分)
后续：DNS***的新趋势
在笔者看来，本次针对.CN根服务器的***为我们再一次敲响了互联网基础设施安全性的警钟，建议主管部门加强对基础设施的保障力度，以避免此类事故重演。
从笔者的日常工作中也能够发现不同针对DNS基础系统的***手法，譬如今年3月份针对国际公司Spamhaus的300G超大流量的DDoS***，*** 者主要采取的手法就是DNS反射***，这种***技术的特点就是利用互联网上开放的DNS递归服务器作为***源，利用“反弹”手法***目标机器。***原理如 图5所示：
图5：DNS反射***的原理
在DNS反射***手法中，假设DNS请求报文的数据部分长度约为40字节，而响应报文数据部分的长度可能会达到4000字节，这意味着利用此手法能够产 生约100倍的放大效应。因此，对于.CN遇袭事件，***者只需要控制一个能够产生150M流量的僵尸网络就能够进行如上规模(15G)的DDoS***。 据不完全统计，国内外总计有超过250W台开放DNS服务器可以充当这种“肉鸡”，开放的DNS服务器简直是互联网上无处不在的×××。
我们如何应对这种DDoS***？
我们DNS系统的运维人员在日常部署时要尽量做到DNS应用的负载均衡，提升DNS服务器的处理性能，尽量将解析节点分散，能够做到按不同的IDC或城 市实现冗余和容灾机制，通过这些手段可以有效的减轻大流量DDoS***发生时所带来的危害。但是如上文所言，针对于如此不堪一击的DNS系统，我们未来还 能够从哪些方面出发去应对一般规模或是超大规模的DDoS***呢？笔者认为有如下一些解决方案可以值得尝试。
第一，在你的主机遭受DDoS***时，最简单的是在本机做策略，譬如iptables等，或是事先将主机kernel加固以应对随时可能出现的风险，但是这种方法不能解决DDoS的根本问题，且非常不灵活。
第二，若通过对流量和***报文分析已知DDoS***类型，那么也可以通过配置一些策略来减轻***带来的危害。譬如对DNS反射***的防护，首先若被*** 的服务器并未提供DNS业务，那么可以通过设置访问控制策略直接阻断所有的DNS请求/回应；如果被***的服务器是DNS相关服务器，那么最有效的方法是 配置DNS服务器，只响应合法区域的查询。不过这种方法需要一定的专业知识，需要运维人员介入，同样是不灵活的。
第三，提供充足的带宽 和性能很强的DNS服务器，也就是俗称的“堆机器，拼资源”，不过这种方法也如同饮鸩止渴，期望“魔高一尺，道高一丈”是不太现实的。不过建议管理人员还 是需要对DNS服务器的上联链路的负载情况及时做好监控，避免因链路拥塞导致丢包的情况出现，同时还是需要在物理带宽上投入一定的资源以防止上联链路拥 塞。
第四，在互联网的核心路由入口侧部署专业的DDoS流量检测设备和DDos流量清洗设备，通过DDoS检测设备与清洗设备之间进行 的策略联动，及时对恶意的***行为进行发现、清洗、阻断，这也是当下较为为业界所认可的防护方案。通过DNS协议的自身特点，依托Intel、 Tilera和Cavium等高效的硬件平台，开发专门针对DDoS流量清洗的系统。这里可以构建专用的DNS防护算法，如DNS QUERY FLOOD防护算法、DNS反射***防护等，用于从根本上过滤掉***流量。
但对于大量的中小网站、企业而言，花费重金购买防护资源是不 现实的，不过现在随着互联网云技术的发展，很多大型互联网公司都提供了云主机服务，如腾讯云，阿里云等，并且免费提供专业的DDoS检测、清洗防护功能， 如果广大业务运营者担心自己的业务或主机会遭受到DDoS***，选择现有的云服务也不失为一种有效的解决方案。
除了上述提到的几种解决 方案，还有一些业界比较成熟的方案值得我们借鉴。比如CloudFlare公司采用的Anycast技术，该技术基于IP路由原理实现了自动流量负载均 衡，在发生DDoS***时，这种技术能够有效的将***流量分流到不同区域的防护节点，进行流量清洗。该方案已经成功的在用户环境中部署。
最后，随着网络上DDoS***规模的不断扩大，DDoS工具的自动化，资源充足和带宽充裕，***发起DDoS***成本越来越低，而针对DDoS的***对 抗，又是一个博弈对抗的过程。在非技术层面上，事先需要制定好应急预案和应对措施，如业务的自身调整、与运营商的沟通和应急措施同步。当DDoS***发生 时，需要多个部门间快速的响应，实施应急方案和及时同步处理结果。同时，建议从立法上，对这类***进行严惩，提升***违法的成本。