在上个系列《你的DNS服务真的安全么？》里我们介绍了DNS服务器常见的攻击场景，看完后，你是否对ddos攻击忧心重重？本节我们来告诉你，怎么破局！!

首先回顾一下DDoS攻击的原理。DDoS是Distributed Denial of Service的简称，即分布式拒绝服务攻击，其利用处于不同位置的足够数量的僵尸主机产生数目巨大的数据包对一个或多个目标实施DoS攻击，耗尽受害端的网络带宽、系统资源，使受害主机或网络丧失提供正常网络服务的能力。

【传统网络对DDoS攻击的防御】

那传统网络是怎么对DDoS攻击进行安全防御的呢？简单来讲，传统安全技术的防护手段，通常是代替server端来响应client发过来的请求，并通过client的下一步动作有无跟进继续请求，来判断该请求是否来自真实用户。因为如果是肉鸡发起的攻击行为，通常不会再有下一步的动作被匹配到。而如果某个特定的client IP一旦被认定为是真实请求的IP，则该IP会被放入对应的“白名单池”，后续一段时间内，当该IP继续请求时，便会被认为是合法的。可参考如下示意图：

这只是一个简单的原理模拟图，有些在策略上可能不一定适用黑白名单IP list。

【传统权威DNS服务器对DDoS的防御手段】 

知道了DDoS的常用防御手段，我们再来说说，对于传统的权威DNS服务器，是怎么防护DDoS攻击的。对于权威DNS而言，默认的请求都是基于UDP，而且DNS协议里面明确说明了DNS服务器可以限制为TCP提供的资源，所以权威DNS的DDoS攻击防御最重要的是如何防住UDP攻击。 但是UDP DDoS防御的最大的问题莫过于UDP没有会话，不能通过包的交互来判断某个请求是否为攻击行为，仅仅查看某个DNS数据报文是不可能区分是否为攻击请求或者真实用户请求的。因此传统安全技术首要地工作就在于需要将缺乏会话交互的UDP一来一回请求转换成为具有会话记录的UDP多来多回请求，它们会利用DNS协议的特点采用如下技术进行防御：
1、CNAME重传
利用DNS的特性，递归请求具有迭代查询一直到获取最终结果的特点，直接代替DNSserver给client返回一个伪造的唯一随机字符串cname域名，并根据该源IP是否继续发起针对该cname域名的请求来判定，该IP是否为正常请求。很显然，如果某个IP马上跟进发起了该cname域名的请求，则该IP是可被信任的；相对地，如果某个IP在规定的超时时间内并没有发起针对该cname域名的请求，则该IP将被判定为攻击者
2、TC重传
利用DNS的特性，在DNS请求client遇到DNS应答flag字段中TC标记为1时必然会发起TCP DNS请求的特点，直接代替DNS server给client返回一个伪造的空应答但该应答flag字段中TC标记为1，并根据该源IP是否继续发起针对该域名的TCP的DNS请求来判定，该IP是否为正常请求。很显然，如果某个IP马上跟进发起了TCP的DNS请求，则该IP是可被信任的；相对地，如果某个IP在规定的超时时间内并没有发起针对的TCP请求，则该IP将被判定为攻击者。 
3、首包丢弃
利用DNS的特性，在DNS请求client在超时时间内没有收到DNS应答时会重发该请求的特点，传统安全直接丢弃该首包请求，并根据该源IP是否继续发起针对这个域名的第二次请求来判定，该IP是否为正常请求。很显然，如果某个IP针对性地发起了第二次请求，则该IP是可被信任的；相对地，如果某个IP在规定的超时时间内并没有发起第二次请求，则该IP将被判定为攻击者。

由以上信息我们可以知道，这三种手段其原理都是通过将原来的DNS的UDP一来一回请求转换成为具有会话记录的UDP多来多回请求，并通过判断第二次请求的特点来判定该源IP是否为真实用户访问行为或者攻击行为，并随之进行对应的白名单/黑名单操作。

【传统方案在权威DNS防护中存在的问题】

以上的传统方案是不是就能完全保护我们的权威DNS了呢？其实还是存在一些防护的问题。以下我们总结了权威DNS防护可能遇到的问题：
1、 首先从首包丢弃来讲，这是在权威DNS防御中基本没有被采用的技术，原因主要是递归DNS在遇到权威查询请求被丢弃时会根据SRTT算法另外选择其他的权威服务器，导致传统安全基本上无法收到所谓的“第二次请求”，因此误杀的概率极高。同时权威丢弃递归发过来的查询，会对递归服务器的资源占用造成严重影响，这种情况下递归服务器可能会根据自身保护的策略直接丢弃该域名的正常请求，有可能造成更严重的故障。
2、 其次是TC重传，相对于CNAME重传的策略，TC重传主要的好处在于并没有从数据内容信息上去进行篡改，并没有“伪造”对应的应答；而重大的缺陷在于需要安全服务DNSserver端支持TCP的请求，这个在性能上是非常大的考验，带来的被打瘫的风险反而会进一步加大。另外，有一部分ISP的 LocalDNS根本不支持TCP也是一个重要的问题。
3、 再来谈CNAME重传，前文提到了CNAME重传最大的问题在于“伪造”了一个虚构的应答，正常流程中这个“伪造”的应答只起到中间传递的结果不会有其他方面的影响，但是现实情况中，ISP侧的各种“缓存递归分离”“缓存加速应答”技术都会对正常的流程进行篡改，导致前面提到的这个“伪造”的结果被当成正确的结果直接回给终端用户；更要命地是，ISP侧的DNS各种“优化TTL”的技术还会把这种问题严重放大，最终导致严重的故障。

针对这种问题，最终我们可能看见类似的错误结果：

总结，通过上面针对性的描述，我们大概知道了这些方法用在DNS上都有或多或少的问题。当然，其实还包括一些安全集群DNS会话状态数据一致性、互联网原生丢包带来的黑白名单误杀、伪造IP攻击影响真实IP带来的误杀等各种情况下的误杀，这部分误杀带来的影响也不可小视。

【权威DNS攻击的防护重点】

说了这么多，权威DNS究竟如何防？说真的，DNS系统本身的优异性能非常关键。打铁还需自身硬，还是建议选择一款性能优异的服务器作为权威的DNS服务器。从原理上来讲，传统安全把缺乏会话交互的UDP一来一回请求转换成为具有会话记录的UDP多来多回的策略比起单纯的回复一个DNS应答更耗费计算资源。比如在同样的性能条件资源下，回复一个所谓的“cname应答”或者“tc应答”，还不如直接回复原生的DNS应答，粗略比较下来两者之间耗费CPU指令集并没有什么差别。当然前提最重要的是DNS系统要有卓越的性能，超大的带宽，有能力媲美安全服务器甚至优于安全服务器。阿里云解析DNS具备单机千万级QPS，遍布全球的超大规模集群，具备anycast的架构、依托阿里巴巴大容量、稳定的基础网络，能够轻松抵抗过亿级的DDoS攻击。阿里云解析DNS绝对值得你的信赖。（–>云解析详情页）

说完了DDoS攻击防护，下一章我们将介绍DNS操作安全相关的内容。大家继续关注哦！

本文作者：kimi_nyn

原文链接

本文为云栖社区原创内容，未经允许不得转载。