相信很多坛友搭建的DNS服务器都采用的开源软件吧，如BIND、Unbound等，ANSSI近期发布了一个严重漏洞的升级提醒，特将原文翻译，分享给大家：
法国网络与信息安全局（ANSSI）在三个主要的开源DNS递归解析软件中，包括BIND、Unbound和PowerDNS中发现了一严重的漏洞。
攻击者可以利用该漏洞对具有漏洞的对象进行拒绝服务（DoS）攻击，或者是利用具有漏洞的解析软件对第三方进行分布式拒绝服务（DDoS）攻击。
所有未打补丁的BIND（CVE-2014-8500）、Unbound（CVE-2014-8602）以及PowerDNS Recursor（CVE-2014-8601）的各版本都容易受到这种攻击。打过补丁的版本分别是BIND 9.9.6-P1、BIND 9.10.1-P1、Unbound 1.5.1和PowerDNS 3.6.2。
ANSSI建议网络运营商尽快升级其DNS软件。
为了让大家更好地了解该攻击，我附上了iDNS攻击的概述及技术细节，有翻译不准确的地方，还请各位专家和业界同仁谅解。
【iDNS攻击】
域名系统（DNS）是一个层次式数据库，用来发布各种内容，从IP地址到管理策略，它的一个特性就是数据的分散化。事实上，域名拥有者可以将一个孩子域（称为“子域”）的权力授权给第三方。然后这个第三方就可以在这个子域下存储他所定义的内容或将该域名下的任何子域名重新授权给另一个第三方。
ANSSI－法国网络与信息安全局－发现了在几种DNS解析器的DNS授权机制中存在着漏洞。具体来说，是一个解析器在解析一个域名时，没有清晰的（或完全没有）的请求数量限定。
iDNS（Infinitely Delegating Name Servers无限授权域名服务器）攻击，如在附件中所描述的，通过一个单一查询诱使解析器跟随一个无限的授权链不断发起查询。这样做可能会导致两种类型的拒绝服务（DoS）的情况，具体表现因解析器的不同而有所不同。
一方面，某些解析器同时跟随所有的授权，从而产生网络流量爆发，导致分布式拒绝服务攻击，就攻击包的数量而言，流量被大大放大了。这样的流量爆发，完全是使用合法的和正确配置的解析器，而不需要进行IP地址欺骗。
在另一方面，持续的拒绝服务尝试会导致在由攻击者所控制的授权（或称权威）域名服务器与被攻击的解析器之间产生数十万的“恶意的”请求与响应，从而影响解析器的可用性或性能。后果可能是完全的服务中断，或者是过度的资源消耗和服务质量的下降，比如正常情况下响应时间的明显增加。
所有未打补丁的BIND（CVE-2014-8500）、Unbound（CVE-2014-8602）以及PowerDNS Recursor（CVE-2014-8601）的各版本都容易受到这种攻击，只是严重性的程度不同而已。ANSSI还发现当含有来自不受信任的第三方的区时，只是作为授权（或称权威）域名服务器的BIND也可能受到这种iDNS攻击。这些软件已经在实验室的PoC实验中被证明具有这样的漏洞，这个问题也得到相关DNS制造商的证实，并提供了补丁或者其软件的修复版本。打过补丁的版本分别是BIND 9.9.6-P1、BIND 9.10.1-P1、Unbound 1.5.1和PowerDNS 3.6.2。
OpenDNS、谷歌公共DNS和基于Windows Server2012的Microsoft DNS并没有这样的问题。
ANSSI建议所有的DNS解析器软件制造商对解析一个单个域名所发出的请求的数量进行核查并设立门限。当ANSSI就上述建议了解在实际操作中的反馈时，OpenDNS证实他们已经采用了类似的解决策略，而没有影响到正常的运营。
ANSSI建议网络运营商应尽快提升自己的DNS软件，ANSSI还建议网络运营商，评估使用中间设备所可能带来的风险，这些设备可能被这种攻击或其变体所产生的网络流量爆发所淹没。
【技术细节】
1技术细节
1.1 技术概念回顾
域名授权（domain delegation）是指在DNS区中加入一个名称服务器（NS）资源记录（RR）。该NS资源记录的“所有者名称”（owner name）字段表明父区域和子区域之间的分界，而 “RDATA”字段表示主机名，该主机名是一个域名，并与IP地址资源记录（可以是IPv4 地址，或AAAA IPv6地址）相关联。
由“RDATA”字段中指定的主机名可以是被授权的域名的子域名或另一个不同的域名的子域名。
因此有两种符合RFC的授权：
需要glue记录的授权：如果主机名是被授权域名的子域名，那么就会出现鸡生蛋蛋生鸡的问题。事实上，为了得到与该主机名相关联的IP地址，我们需要跟随域名的授权，这就是为什么该主机名被放在首位进行解析的原因。此问题通过添加一个非授权的IP地址资源记录来解决，这就是“glue”记录。
无glue的授权：如果主机名是另一个不同的域名的子域名，为了跟随该授权，解析器会暂停最初的请求，并试图对主机名进行递归解析。一旦获得了与该主机名对应的IP地址，最初的查询就会被继续。
1.2 DNS解析器的拒绝服务
iDNS的攻击原理是通过特别的授权，将一个域名授权给其一个子域名，并以此类推，从而建立了一个无限的域名链。
这样的场景可以通过自定义一个授权DNS服务器并提供这样的授权信息来实现。
iDNS攻击的漏洞源于没有明确地限制，如果有的话，即为域名解析器为了解析一个请求所能发出的请求的数量。
跟随这些无休止的授权，结果可能是下面的任何一种：
将内存完全消耗，从而导致内核内存溢出并中止DNS服务
高CPU利用率
在默认的配置下，将防火墙的连接跟踪表占满
有用的缓存记录被无用的授权信息所替代
1.3 流量放大
有些DNS解析器软件会跟随区域之外的glue记录，最重要的是，他们会同时跟随几个非授权glue信息。我们已经在实验室实验中证明，这种行为可以被攻击者利用来实现流量放大。据我们测量，带宽放大因子为1，包数量的放大因子为10。
这种攻击可以实现是得益于定制的授权名称服务器以特制的符合RFC的DNS响应包应答查询。
进一步研究攻击，我们观察到了更多的实现方式。一些攻击方式在受害人不回答发送到他的DNS查询时更具侵略性，这样可以攻击任何非DNS的服务器。与此相反，一些攻击方式当受害者回答“REFUSED”或“SERVFAIL” 时更具侵略性。这些问题的答案可以从不是被查询域名的授权服务器的授权DNS服务器或从实施了对递归功能的访问控制的递归域名服务器处轻松获得。
2对策和解决办法
ANSSI建议DNS解析软件厂商实现以下防御策略，以缓解这些潜在漏洞：
方案一：设立门限并核查某个解析客户端发起的一个域名解析请求所发出的查询总数
方案二：设立门限并核查向一个域名服务器发出的并发查询总数，如果达到限制，则延缓这些查询
。
这些建议被证明是类似于OpenDNS已经部署的免受这种攻击的预防措施。他们的软件限制了递归深度，包括限制向每个目标发起的查询的数量，限制跟随每个授权所查询的域名服务器的数量，并且不为glue获取额外的或权威性的记录。最重要的是，每个客户端的查询时间是有限定的，当时间到了，客户端就会收到SERVFAIL错误消息，并且递归过程停止尝试解析该名字或任何相关记录。
以上这些建议，是针对软件开发者的。对于那些把自己的DNS服务器保护在防火墙后面的网络架构师应该遵循以下建议：
方案三：如果检测到攻击，并且连接跟踪表可能达到最大值，暂时增加连接跟踪表的最大值，并最终调整与该表相关的散列桶计数。
该建议可以在Linux主机的系统防火墙和基于Linux的网络防火墙中通过sysctl修改net.nf_conntrack_max的值和修改nf_conntrack内核模块的HASHSIZE值来实现。
方案四：如果方案三不足以阻止攻击，DNS流量的连接跟踪超时门限可以进行微调，以减少一个连接在跟踪表中保持的时间。
这个建议可以在提供DNS服务的Linux系统中通过以下的Netfilter和iptables的策略来实现：
ncft命令定义一个新的连接跟踪超时策略（每状态连接2秒）
# nfct timeout add reduced-dns-timeout-policy inet udp unreplied 2 replied 2
下面的iptables策略用我们定义的值改写了默认的超时政策
# iptables -t raw \
-I OUTPUT \
-o $OUTPUT_INTERFACE \
-s $RESOLVER_IP_ADDRESS \
-p udp \
--sport 1024: \
--dport 53 \
-j CT --timeout reduced-dns-timeout-policy
# iptables -t raw \
-I PREROUTING \
-i $OUTPUT_INTERFACE \
-d $RESOLVER_IP_ADDRESS \
-p udp \
--dport 1024: \
--sport 53 \
-j CT --timeout reduced-dns-timeout-policy
网络管理员需要知道的nfct功能可能并没有被包含在某些GNU/ Linux发行包中。
类似这样的策略也可以被应用到转发DNS流量的基于Linux的网络防火墙中。
方案五：如果方案三和方案四建议不足以阻止连接跟踪系统被占满的风险，作为最后的一个临时手段，可以将出网络DNS流量的连接跟踪完全禁用。
这个建议可以在提供DNS服务的Linux系统中通过以下的iptables策略来实现：
以下两个策略将DNS流量授权为无状态：
# iptables -t filter \
-I OUTPUT \
-o $OUTPUT_INTERFACE \
-s $RESOLVER_IP_ADDRESS \
-p udp \
--sport 1024: \
--dport 53 \
-j ACCEPT
# iptables -t filter \
-I INPUT \
-i $OUTPUT_INTERFACE \
-d $RESOLVER_IP_ADDRESS \
-p udp \
--dport 1024: \
--sport 53 \
-j ACCEPT
下面的两个策略关闭了对DNS流量的连接跟踪：
# iptables -t raw \
-I OUTPUT \
-o $OUTPUT_INTERFACE \
-s $RESOLVER_IP_ADDRESS \
-p udp \
--sport 1024: \
--dport 53 \
-j NOTRACK
# iptables -t raw \
-I PREROUTING \
-i $OUTPUT_INTERFACE \
-d $RESOLVER_IP_ADDRESS \
-p udp \
--dport 1024: \
--sport 53 \
-j NOTRACK
类似这样的策略也可以被应用到转发DNS流量的基于Linux的网络防火墙中。
建立和拆除这些策略时，必须格外小心。的确，如果这些策略被不合顺序地插入或删除，合法的数据包就可能被丢弃。删除这些规则必须以相反的顺序来完成，并且在移除关闭流量跟踪策略后，需要停下观察一段时间，再移除对无状态流量的授权。
