在我们上次的TW PCI扫描中，我们的一个标志是“DNS放大拒绝服务”。
目前，DNS服务器正在运行Bind 9.8.1-P1。 看起来像CVE是一个更老的版本：CVE-2006-0988，CVE-2006-0987。
给出的证据是：查找：一个26字节ANY查询[我的域名]导致了一个更大的答案，在283字节的大小。
所以，从外面的世界我运行一个挖：
taco $ dig -t NS . @[my domain] 为此我回来了：
; <<>> DiG 9.8.1-P1 <<>> -t NS . @[my domain] ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 54954 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; Query time: 47 msec ;; SERVER: [my ip address]#53([my ip address]) ;; WHEN: Mon Nov 25 15:53:24 2013 ;; MSG SIZE rcvd: 17
所以对我来说，似乎我的BIND服务器正在做正确的事情，拒绝。 但扫描是正确的，因为对于一个小的input它得到了一个更大的输出。 即使它不允许从外部recursion。
有没有办法使BIND根本不回答，或发送一个较短的回应？ 是否还有其他的事情需要我做，使TW PCI扫描快乐？
他们正在谈论的查询可能更像是dig -t any [your domain] @[your nameserver] ，这很可能会返回他们所指的那种较大的响应。
这是一个权威的名称服务器？ 如果是这样的话，除了速率限制查询之外，对reflection中使用的内容真的没有太多的了解。
DNSreflection对于整个互联网来说是一件令人讨厌的事情，但是我不明白为什么您的权威DNS服务器的带宽被滥用来放大DDoSstream量与您的PCI合规性有关。
Shane Madden的回答很重要 – 如果你将recursion限制在你自己的客户端，并拒绝给你定义的服务对象之外的那些客户，那么你正在为recursion服务做正确的事情。 不要在没有充分理由的情况下操作开放式parsing器 ，如果您决定由于某种原因需要这样做，则必须主动监视滥用并尽快阻止; 否则你是其他networking参与者的危险。
关于权威性的服务，他又是正确的 – 除了响应速度限制（RRL）之外，没有什么可以做的了。[对于什么值得ISC（BIND的作者，也是F根的运营商，十三根名称服务器） – 由此受到很大的影响，因为短查询长度，以及对任何查询的大量响应，都成为一个主要的放大因子。 只要UDP源欺骗很容易，我们就会忍无可忍。]
关于您当前的版本（BIND 9.8.1-P1）：假设您正在从ISC运行股票代码，有一些影响9.8.1-P1的未解决的漏洞可能需要解决。 其中大多数（如果被利用的话）在服务器因ASSERT或INSIST故障而崩溃时导致拒绝服务 – BIND 9实际上被devise为一旦检测到不一致的状态就会崩溃，而不是继续并可能冒险更差。
您可以通过查阅BIND安全matrix来find适用的安全公告列表根据您使用的function，并非以下所有漏洞都必须适用，但是您应该检查它们是否确定。 BIND 9.8目前在版本9.8.6-P1，或者你可以升级到BIND 9.9.4-P1，并获得免费的RRL（嗯，这是一个可选的编译，但一个额外的命令行参数的价格configuration你可以有它，并帮助使您的权威服务器不太吸引人的reflection目标。）
CVE Number Short Description 2013-6320 A Winsock API Bug can cause a side-effect affecting BIND ACLs 2013-4854 A specially crafted query can cause BIND to terminate abnormally 2013-2266 A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named 2012-5689 BIND 9 with DNS64 enabled can unexpectedly terminate when resolving domains in RPZ 2012-5688 BIND 9 servers using DNS64 can be crashed by a crafted query 2012-5166 Specially crafted DNS data can cause a lockup in named 2012-4244 A specially crafted Resource Record could cause named to terminate 2012-3817 Heavy DNSSEC validation load can cause a "bad cache" assertion failure 2012-1667 Handling of zero length rdata can cause named to terminate unexpectedly 2011-4313 BIND 9 Resolver crashes after logging an error in query.c