我有一个我自己托pipe的网站，我使用bind9作为我的DNS服务器（托pipe我自己的域名服务器等）。
我有一个stream量带宽的问题，我的系统日志充满了以下types的问题：
error (unexpected RCODE REFUSED) resolving 'target-express.com/AAAA/IN': 193.95.142.60#53 error (unexpected RCODE REFUSED) resolving 'target-express.com/A/IN': 2001:7c8:3:2::5#53 在今天的系统日志中，有144258个这样的实例，都与target-express.com相关。
我的问题是：
我已经在named.conf中检查了我的转发器，它们都不匹配日志中显示的IP（它们基本上都是不同的IP，不仅仅是193.95.142.60）。
我的iptables读取：
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere REJECT all -- anywhere loopback/8 reject-with icmp-port-unreachable ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT icmp -- anywhere anywhere icmp echo-request LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: " REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere
更新 ：
我已经在named.conf.options中尝试了以下内容来阻止recursion。
allow-transfer {"none";}; allow-recursion {"none";}; recursion no;
一旦我这样做，我现在在syslog中看到以下内容：
Mar 4 00:02:21 mail named[29037]: client 127.0.0.1#42139: query (cache) '24.124.41.103.in-addr.arpa/PTR/IN' denied Mar 4 00:02:22 mail named[29037]: client 127.0.0.1#58405: query (cache) '45.124.41.103.in-addr.arpa/PTR/IN' denied Mar 4 00:02:24 mail named[29037]: client 127.0.0.1#48692: query (cache) '106.49.174.61.in-addr.arpa/PTR/IN' denied
为了摆脱上述，我补充说：
additional-from-cache no;
您的DNS转发器可以将请求转发回原始服务器吗？
如果是这样，这可能是像去年我遇到的问题（请参阅Windows DNS服务器获得SERVFAIL响应时重复请求区域中的logging ）。 修复是没有转发循环。 这只会显示为返回SERVFAIL的区域的重大问题，因为这些响应不会被caching。
至于什么引发了原始查询（它可能只有一个）可能只是任何东西 – networking访问控制的DNS查找或类似的东西。
为了避免放大（可能是比循环更好的描述），您需要确保您看到这些消息的DNS服务器不会将查询转发给可能转发请求的服务器。 您在本地DNS服务器上configuration的服务器是您的控制权还是外部？
当然你的服务器正试图解决“target-express.com”，它是失败的。 它失败的原因是“target-express.com”的NS服务器没有正确设置。 （谷歌的“蹩脚的服务器”）。 做'挖+跟踪'显示该域的两个NSlogging，但如果你查询这些域，没有任何反应。
现在的问题是谁在查询你的服务器 –
1.合法的内部用户/应用程序 – 我不担心这一点。
2.没有授权的外部用户 – 您的DNS服务器应该允许parsing只有他们权威的域名。 如果你的意图是不要有一个开放的DNS服务器，然后在你的DNSconfiguration限制，以便只有允许的主机可以使用服务器进行recursion查询。
root @ svm1010：/ var / tmp＃dig @ 8.8.8.8 target-express.com NS + short root @ svm1010：/ var / tmp＃dig + trace target-express.com NS ; > DiG 9.7.0-P1> + trace target-express.com NS ;; 全局选项：+ cmd 。 16978在NS d.root-servers.net。 。 16978在NS i.root-servers.net。 。 16978在NS f.root-servers.net。 。 16978在NS b.root-servers.net。 。 16978在NS a.root-servers.net。 。 16978在NS k.root-servers.net。 。 16978在NS l.root-servers.net。 。 16978在NS h.root-servers.net。 。 16978在NS e.root-servers.net。 。 16978在NS j.root-servers.net。 。 16978在NS m.root-servers.net。 。 16978在NS g.root-servers.net。 。 16978在NS c.root-servers.net。 ;; 在9 ms内从8.8.8.8＃53（8.8.8.8）中收到228个字节 COM。 172800在NS j.gtld-servers.net。 COM。 172800在NS a.gtld-servers.net。 COM。 172800在NS m.gtld-servers.net。 COM。 172800在NS b.gtld-servers.net。 COM。 172800在NS c.gtld-servers.net。 COM。 172800在NS i.gtld-servers.net。 COM。 172800在NS l.gtld-servers.net。 COM。 172800在NS h.gtld-servers.net。 COM。 172800在NS f.gtld-servers.net。 COM。 172800在NS k.gtld-servers.net。 COM。 172800在NS d.gtld-servers.net。 COM。 172800在NS egtld-servers.net。 COM。 172800在NS g.gtld-servers.net。 ;; 在15毫秒内从199.7.91.13＃53（d.root-servers.net）收到496字节 target-express.com。 172800在NS sec02.ns.esat.net。 target-express.com。 172800在NS auth02.ns.esat.net。 ;; 在221毫秒内从192.48.79.30＃53（j.gtld-servers.net）收到120个字节 ;; 在111毫秒内从192.111.39.112＃53（sec02.ns.esat.net）收到36个字节 root @ svm1010：/ var / tmp＃dig @ sec02.ns.esat.net。 target-express.com。 soa + short root @ svm1010：/ var / tmp＃dig @ auth02.ns.esat.net。 target-express.com。 soa + short 根@ svm1010：/ var / tmp中＃