我有一个自己托管的网站,并且使用 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 相关。
我的问题是:
- 我可以通过防火墙或绑定配置做些什么来阻止这种情况?
- 为什么我的绑定设置会尝试解析 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;
答案1
您的 DNS 转发器是否可以将请求转发回原始服务器?
如果是这样,这可能类似于我去年遇到的问题(见Windows DNS 服务器在收到 SERVFAIL 响应时反复请求区域中的记录)。修复方法是不要有转发循环。这只会在返回 SERVFAIL 的区域显示为一个重大问题,因为这些响应不会被缓存。
至于启动原始查询的内容(可能只有一个)可能是任何事情 - 用于网络访问控制的 DNS 查找或类似的东西。
为了避免放大(也许比循环更好的描述),您需要确保您看到这些消息的 DNS 服务器没有将查询转发到可能转发请求的服务器。您在本地 DNS 服务器上配置的服务器是否在您的控制之下,还是它们是外部的?
答案2
您的服务器肯定正在尝试解析“target-express.com”,但失败了。失败的原因是“target-express.com”的 NS 服务器设置不正确。(谷歌搜索“lame servers”)。执行“dig +trace”会显示该域的两个 NS 记录,但如果您查询这些域,则没有任何响应。
现在的问题是谁在查询你的服务器 -
1.合法的内部用户/应用程序-我不会担心这个。
2.未经授权的外部用户 - 您的 DNS 服务器应仅允许解析其具有权限的域。如果您不打算拥有开放的 DNS 服务器,则请在 DNS 配置中设置限制,以便只有允许的主机才能使用该服务器进行递归查询。
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 IN NS d.root-servers.net。 . 16978 IN NS i.root-servers.net。 . 16978 IN NS f.root-servers.net。 . 16978 IN NS b.root-servers.net。 . 16978 IN NS a.root-servers.net。 . 16978 IN NS k.root-servers.net。 . 16978 IN NS l.root-servers.net。 . 16978 IN NS h.root-servers.net。 . 16978 IN NS e.root-servers.net。 . 16978 IN NS j.root-servers.net。 . 16978 IN NS m.root-servers.net。 . 16978 IN NS g.root-servers.net。 . 16978 IN NS c.root-servers.net。 ;; 9 毫秒内从 8.8.8.8#53(8.8.8.8) 接收到 228 个字节 com. 172800 IN NS j.gtld-servers.net。 com. 172800 IN NS a.gtld-servers.net。 com. 172800 IN NS m.gtld-servers.net。 com. 172800 IN NS b.gtld-servers.net。 com. 172800 IN NS c.gtld-servers.net。 com. 172800 IN NS i.gtld-servers.net。 com. 172800 IN NS l.gtld-servers.net。 com. 172800 IN NS h.gtld-servers.net。 com. 172800 IN NS f.gtld-servers.net。 com. 172800 IN NS k.gtld-servers.net。 com. 172800 IN NS d.gtld-servers.net。 com. 172800 IN NS e.gtld-servers.net。 com. 172800 IN NS g.gtld-servers.net。 ;; 15 毫秒内从 199.7.91.13#53(d.root-servers.net) 接收到 496 个字节 target-express.com。172800 IN NS sec02.ns.esat.net。 target-express.com。172800 IN 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 root@svm1010:/var/tmp#