Iptables

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

  • March 3, 2015

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