意外的 RCODE REFUSED - 耗盡日誌文件

我有一個我自己託管的網站，我使用 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;

完成此操作後，我現在在 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 響應時重複請求區域中的記錄）。修復是沒有轉發循環。這僅顯示為返回 SERVFAIL 的區域的一個重大問題，因為這些響應不會被記憶體。

至於是什麼發起了原始查詢（可能只是一個），幾乎可以是任何東西——用於網路訪問控制的 DNS 查找或類似的東西。

為了避免放大（也許比循環更好的描述），您需要確保您看到這些消息的 DNS 伺服器沒有將查詢轉發到可能轉發請求的伺服器。您在本地 DNS 伺服器上配置的伺服器是在您的控制之下還是在外部？

引用自：https://serverfault.com/questions/672566