我们发现从我们的缓存 DNS 服务器到外部服务器的 DNS 查询数量很高（每秒超过 2000 个请求）。这种情况可能已经持续了很长时间 - 最近才发现，因为我们的防火墙存在性能问题。与其他机构的同事交谈后，很明显我们发出的查询比他们多。
我最初的想法是，问题在于 SERVFAIL 响应缓存不足。经过进一步调查，很明显，问题在于 Windows DNS 服务器对失败记录的请求量过大。在我们的环境中，似乎对其中一个 Windows DNS 服务器的单个查询，查询来自返回 SERVFAIL 的区域的记录，会导致来自全部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
直接查询谷歌的服务器表明我们收到了拒绝的响应。
[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 中有一些关于这样做的讨论这里但结论是该功能已被删除。
我们是否可以更改 Bind 配置中的设置来影响此行为？lame-ttl 没有帮助（而且我们无论如何都在使用默认设置运行）。
作为调查的一部分，我在我们的缓存 DNS 服务器上添加了一些虚假的空白区域，以覆盖导致大多数请求的范围。这减少了对外部服务器的请求数量，但不可持续（并且感觉也不对劲）。与此同时，我请一位同事从 Windows DNS 服务器获取日志，以便我们能够识别发出原始请求的客户端。
答案1
RFC2308 的相关部分是§7.1 服务器故障（可选）。
在任何一种情况下，解析器都可以缓存服务器故障响应。如果这样做，它不得将其缓存超过五 (5) 分钟，并且必须针对特定查询元组 <查询名称、类型、类、服务器 IP 地址> 进行缓存。
我不知道是否有一个简单的配置指令可以覆盖这一点，但如果您愿意的话，您可以将该区域转发到其他地方或直接为其提供服务。
如果它直接导致防火墙问题，您应该检查 UDP 伪连接超时，如果 DNS UDP 缓存很高，则可能会填满状态表。DNS 查询往往会被阻止，所以我希望您没有在防火墙上执行任何这些操作。
173.194/16 的一些反向区域似乎已损坏。它们应该最坏的情况下返回可缓存的 NXDOMAIN 而不是 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
194.173.in-addr.arpa 由 ARIN 委托给 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。因此它似乎是经过深思熟虑且有选择性的。
答案2
当我查看 Windows DNS 服务器的配置时，原因就很明显了（口头报告中丢失了一些内容）。
每个 DC 都配置为不仅将请求转发到两个缓存 Bind 服务器，而且还转发到所有其他 Windows DNS 服务器。对于成功的请求（包括 NXDOMAIN），这将正常工作，因为 Bind 服务器会应答，我们永远不会转到其他 Windows DNS。但是对于返回 SERVFAIL 的内容，一个服务器会询问所有其他服务器，而其他服务器又会依次询问 Bind 服务器。我真的很惊讶这并没有造成更多麻烦。
我们将取消额外的转发，我完全预计请求量将大幅下降。