我们看到从我们的cachingDNS服务器到外部服务器的高水平（超过2000个请求/秒）的DNS查询。 这可能发生了很长一段时间 – 最近由于我们防火墙的性能问题而被曝光。 与其他机构的同事交谈，很明显我们提出的问题比他们多。
我最初的想法是，问题是没有cachingSERVFAIL响应。 经过更多的调查，很明显，这个问题是来自Windows DNS服务器的失败logging的高层次请求。 在我们的环境中，似乎在返回SERVFAIL的区域中对某个Windows DNS服务器的logging进行单个查询会导致从所有 Windows DNS服务器获取该logging的请求stream。 请求stream不会停止，直到我添加一个假的空区域绑定服务器之一。
我明天的计划是validationWindows DNS服务器的configuration – 他们应该只是转发到caching绑定服务器。 我认为我们必须有什么错误，因为我不能相信没有其他人打这个，如果这不是一个错误的configuration。 之后我会更新这个问题（可能会closures这个问题并开启一个更清晰的问题）。
我们的设置是一对运行Bind 9.3.6的caching服务器，可以直接由客户端或通过我们的Windows域控制器使用。 高速caching服务器将查询传递给正在运行9.8.4-P2的主DNS服务器 – 这些服务器对我们的域是权威的，并将其他域的查询传递到外部服务器。
我们看到的行为是像下面这样的查询没有被caching。 我已经通过使用tcpdump查看来自DNS服务器的networking通信validation了这一点。
[root@dns1 named]# dig ptr 119.49.194.173.in-addr.arpa. ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> ptr 119.49.194.173.in-addr.arpa. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8680 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;119.49.194.173.in-addr.arpa. IN PTR ;; Query time: 950 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Mar 9 13:34:20 2014 ;; MSG SIZE rcvd: 45 直接查询谷歌的服务器显示，我们得到了拒绝的回应。
[root@dns1 named]# dig ptr 119.49.194.173.in-addr.arpa. @ns4.google.com. ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> ptr 119.49.194.173.in-addr.arpa. @ns4.google.com. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 38825 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;119.49.194.173.in-addr.arpa. IN PTR ;; Query time: 91 msec ;; SERVER: 216.239.38.10#53(216.239.38.10) ;; WHEN: Sun Mar 9 13:36:38 2014 ;; MSG SIZE rcvd: 45
这不仅发生在谷歌地址或反向查找，但很大一部分查询是针对这些范围（我怀疑是因为Sophos的报告function）。
我们的DNS服务器应该caching这些负面的回应？ 我阅读http://tools.ietf.org/rfcmarkup?doc=2308，但没有看到任何关于拒绝。 我们没有在configuration文件中指定lame-ttl，所以我希望默认为10分钟。
我相信这（缺lesscaching）是预期的行为。 我不明白为什么其他我曾经谈过的网站看不到同样的事情。 我试过一个testing服务器运行最新的稳定版本的绑定，并显示相同的行为。 我也试过Unbound，也没有cachingSERVFAIL。 这里有一些在djbdns这样做的讨论，但结论是，function已被删除。
是否有绑定configuration中的设置，我们可以改变来影响这种行为？ lame-ttl没有帮助（而且我们还是默认运行）。
作为调查的一部分，我们在cachingDNS服务器上添加了一些虚假的空区域，以涵盖导致大多数请求的范围。 这是减less了对外部服务器的请求数量，但不可持续（也感觉不对）。 与此同时，我要求同事从Windows DNS服务器获取日志，以便我们可以识别出提出原始请求的客户端。
RFC2308的相关部分是§7.1服务器失败（可选） 。
无论哪种情况，parsing器都可以caching服务器失败响应。 如果这样做，它不能caching超过五（5）分钟，并且它必须被caching在特定的查询元组中。
我不知道一个简单的configuration指令可能会覆盖这个，但如果你是如此倾向于你可以在其他地方转发该区域或直接服务。
如果它直接导致防火墙问题，你应该检查UDP伪连接超时，caching的DNS UDP可以填充状态表，如果它高。 DNS查询往往会阻止，所以我希望你没有在防火墙上做任何事情。
173.194 / 16的一些反向区域似乎打破了。 他们应该最后返回cachingNXDOMAINs而不是SERVFAIL或REFUSED。
$ dig 194.173.in-addr.arpa. ns +short NS4.GOOGLE.COM. NS3.GOOGLE.COM. NS2.GOOGLE.COM. NS1.GOOGLE.COM. $ dig @ns4.google.com 119.49.194.173.in-addr.arpa. ns ; <<>> DiG 9.8.4-P4 <<>> @ns4.google.com 119.49.194.173.in-addr.arpa. ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 63925 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available
ARIN将194.173.in-addr.arpa委托给Google：
$ dig @z.arin.net 194.173.in-addr.arpa. ns +auth ;; AUTHORITY SECTION: 194.173.in-addr.arpa. 86400 IN NS NS4.GOOGLE.COM. 194.173.in-addr.arpa. 86400 IN NS NS1.GOOGLE.COM. 194.173.in-addr.arpa. 86400 IN NS NS2.GOOGLE.COM. 194.173.in-addr.arpa. 86400 IN NS NS3.GOOGLE.COM.
但是那些名字服务器不玩球，全部四个返回SERVFAIL
$ dig @ns4.google.com 194.173.in-addr.arpa. soa
除了“粗鲁”之外，这个用来违反ARIN的政策，但是不再这样做 。 但其他区域的工作，尝试46.194.173.in-addr.arpa。 或65.194.173.in-addr.arpa。 所以它似乎是故意和select性的。
一旦我查看Windows DNS服务器的configuration（在口头报告中丢失了某些东西），原因就很明显了。
每个DCconfiguration为不仅将请求转发给两个caching绑定服务器，而且还转发给所有其他Windows DNS服务器。 对于成功的请求（包括NXDOMAIN），如果绑定服务器能够回答，那么我们就永远不会遇到另一个Windows DNS。 但是对于返回SERVFAIL的事情，一个服务器会询问所有其他服务器，然后再询问绑定服务器。 我真的很惊讶，这没有造成更多的痛苦。
我们将把额外的转发出去，我完全期望请求量大幅下降。