在我们上次的 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 服务器似乎做了正确的事情并拒绝了。但扫描是正确的，因为对于一个小的输入，它得到了一个大得多的输出。即使它不允许从外部进行递归。
有没有办法让 BIND 完全不回答，或者发送较短的响应？我是否需要做其他事情才能让 TW PCI 扫描顺利进行？
答案1
他们正在谈论的查询可能更像是dig -t any [your domain] @[your nameserver]，这可能会返回他们所指的那种更大的响应。
这是权威名称服务器吗？如果是的话，那么除了限制查询速率外，你真的没有多少办法可以阻止它在反射中使用。
总体而言，DNS 反射对于互联网来说是一件坏事，但我不明白为什么滥用权威 DNS 服务器的带宽来放大 DDoS 流量与您的 PCI 合规性有关。
答案2
Shane Madden 的上述回答是正确的——如果您将递归限制在您自己的客户身上，并拒绝那些超出您所定义的服务范围的客户使用递归，那么您对递归服务做了正确的事情。 无正当理由请勿操作开放式解析器如果您出于某种原因决定需要这样做，您必须主动监控滥用行为并尽快阻止；否则您将对其他网络参与者构成危害。
关于权威服务，他再次说对了——除了限制响应速率 (RRL) 之外，你无能为力。[ISC（BIND 的作者，也是十三个根名称服务器之一 F 根的运营商）——深受其害，成为反思的主要目标之一，因为查询长度短，加上对 ANY 查询的响应大，产生了相当大的放大因素。只要 UDP 源欺骗仍然很容易，我们就会坚持下去。]
关于您当前的版本 (BIND 9.8.1-P1)：假设您正在运行 ISC 的库存代码，那么您可能希望解决影响 9.8.1-P1 的大量未解决漏洞。如果利用这些漏洞，当服务器因 ASSERT 或 INSIST 失败而崩溃时，大多数漏洞都会导致拒绝服务 - BIND 9 实际上是设计一旦检测到不一致的状态就崩溃，而不是继续运行并可能带来更糟糕的风险。
您可以通过查阅BIND 安全矩阵 根据您所使用的功能，下面的所有漏洞不一定都适用，但您还是应该检查它们以确保万无一失。BIND 9.8 当前版本为 9.8.6-P1，或者您可以升级到 BIND 9.9.4-P1 并免费获得 RRL（好吧，这是一个可选编译，但只需在配置时使用额外的命令行参数，您就可以拥有它并帮助使您的权威服务器成为不那么有吸引力的反射目标。）
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