意外的 RCODE REFUSED - 耗尽日志文件

Question

我有一个自己托管的网站，我使用 bind9 作为我的 DNS 服务器（托管我自己的名称服务器等）。

我遇到了流量带宽问题，并且我的系统日志充满了以下类型的问题：

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 相关。

我的问题是：

1. 有什么我可以做的防火墙明智或绑定配置来阻止这个吗？
2. 为什么我的绑定设置会尝试解析 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中尝试了以下方法来阻止递归。

allow-transfer {"none";};
allow-recursion {"none";};
recursion no;

完成此操作后，我现在在系统日志中看到以下内容：

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;

Answer 1

您的 DNS 转发器能否将请求转发回原始服务器？

如果是这样，这可能类似于我去年遇到的问题（请参阅Windows DNS 服务器在收到 SERVFAIL 响应时重复请求区域中的记录）。修复方法是不存在转发循环。这仅在返回 SERVFAIL 的区域中显示为严重问题，因为这些响应不会被缓存。

至于发起原始查询的内容（可能只有一个）可能是任何内容 - 用于 Web 访问控制的 DNS 查找或类似的内容。

为了避免放大（也许是比循环更好的描述），您需要确保您看到这些消息的 DNS 服务器不会将查询转发到可能将请求转发回来的服务器。您在本地 DNS 服务器上配置的服务器是在您的控制之下还是外部？