我们看到从缓存 DNS 服务器到外部服务器的 DNS 查询量很高（超过 2000 个请求/秒）。这可能已经发生了很长时间 - 由于我们的防火墙的性能问题，最近才曝光。与其他机构的同事交谈，很明显我们提出的问题比他们多。
我最初的想法是问题在于缺少 SERVFAIL 响应的缓存。进行更多调查后，很明显问题是来自 Windows DNS 服务器的失败记录的高级别请求。似乎在我们的环境中，从返回 SERVFAIL 的区域向其中一个 Windows DNS 服务器查询记录会导致来自所有Windows DNS 服务器对该记录的请求流。直到我在其中一个 Bind 服务器上添加一个假的空区域，请求流才会停止。
我明天的计划是验证 Windows DNS 服务器的配置——它们应该只是转发到缓存绑定服务器。我认为我们一定有什么问题，因为如果不是配置错误，我无法相信没有其他人遇到过这个问题。之后我会更新这个问题（可能关闭这个问题并打开一个新的、更清晰的问题）。
我们的设置是一对运行 Bind 9.3.6 的缓存服务器，它们可以由客户端直接使用，也可以通过我们的 Windows 域控制器使用。缓存服务器将查询传递给我们运行 9.8.4-P2 的主要 DNS 服务器——这些服务器对我们的域具有权威性，并将对其他域的查询传递给外部服务器。
我们看到的行为是像下面这样的查询没有被缓存。我已经通过使用 tcpdump 查看来自 DNS 服务器的网络流量来验证这一点。
[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
直接查询 google 的服务器表明我们收到了 REFUSED 响应。
[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 报告功能）。
我们的 DNS 服务器是否应该缓存这些负面响应？我阅读了http://tools.ietf.org/rfcmarkup?doc=2308但没有看到任何关于 REFUSED 的信息。我们没有在配置文件中指定 lame-ttl，所以我希望它默认为 10 分钟。
我相信这（缺乏缓存）是预期的行为。我不明白为什么与我交谈过的其他网站没有看到相同的内容。我已经尝试过运行最新稳定版本的 Bind 的测试服务器，它显示了相同的行为。我也尝试了 Unbound 并且也没有缓存 SERVFAIL 。在 djbdns here中有一些关于这样做的讨论，但结论是该功能已被删除。
绑定配置中是否有我们可以更改以影响此行为的设置？lame-ttl 没有帮助（无论如何我们都在使用默认值运行）。
作为调查的一部分，我在缓存 DNS 服务器上添加了一些虚假的空白区域，以覆盖导致大多数请求的范围。这减少了对外部服务器的请求数量，但不可持续（并且感觉也是错误的）。与此同时，我请一位同事从 Windows DNS 服务器获取日志，以便我们可以识别发出原始请求的客户端。
RFC2308 的相关部分是§7.1 Server Failure (OPTIONAL)。
我不知道有一个简单的配置指令可能会覆盖它，但如果您愿意，您可以将该区域转发到其他地方或直接提供它。
如果它直接导致防火墙问题，您应该检查 UDP 伪连接超时，如果它很高，DNS UDP 的缓存可以填充状态表。DNS 查询往往会被阻止，所以我希望你没有在防火墙上做（m）任何这些。
173.194/16 的一些反向区域似乎被打破。它们最多应该返回可缓存的 NXDOMAIN，而不是 SERVFAIL 或 REFUSED。
194.173.in-addr.arpa 由 ARIN 委托给 Google：
但是那些名称服务器不玩球，所有四个都返回 SERVFAIL 为
除了“粗鲁”之外，这曾经违反 ARIN 政策，但现在不再如此。但是其他区域也可以，试试 46.194.173.in-addr.arpa。或 65.194.173.in-addr.arpa。所以它似乎是故意和选择性的。
一旦我查看了 Windows DNS 服务器的配置（口头报告中丢失了一些东西），原因就很明显了。
每个 DC 都被配置为不仅将请求转发到两个缓存绑定服务器，而且还转发到所有其他 Windows DNS 服务器。对于成功的请求（包括 NXDOMAIN），这些请求可以正常工作，因为 Bind 服务器会回答，而且我们永远不会掉入其他 Windows DNS。然而，对于返回 SERVFAIL 的事情，一台服务器会询问所有其他服务器，而其他服务器又会询问 Bind 服务器。我真的很惊讶这并没有引起更多的痛苦。
我们将取消额外的转发，我完全预计请求量会大幅下降。