我们正在运行 Bind 作为缓存名称服务器，并且我们的设置中有 3 条规则用于处理 DNS 功能：
iptables -A INPUT -s $OUR_NETWORK -p udp --destination-port 53 -j ACCEPT
iptables -A INPUT -s $OUR_NETWORK -p tcp --destination-port 53 -j ACCEPT
iptables -A INPUT -p udp --source-port 53 -m state --state ESTABLISHED,RELATED -j ACCEPT
前两条规则适用于我们的客户端。请注意，我包括了 TCP，尽管我们不允许区域传输，因为我们没有托管任何区域（但我注意到一些合法客户端通过 TCP 进行查询），这就是我将其包括的原因。
我的问题是关于第三行的。此行用于上游 DNS 服务器的响应（对我们的递归查询的响应）。我认为这一行就足够了，但后来我在日志（我丢弃的与任何 ALLOW 行不匹配的数据包）上注意到有数十个 UDP 数据包来自源端口 UDP/53。
我最初的想法是：
1) 这些是来自其他 DNS 服务器的合法响应，但我的系统的连接跟踪并未将其识别为“相关”
2) 这些都是合法的回应，但它们是“迟来的回应”，因此我的系统无法识别它们。
您对缓存名称服务器的响应使用什么规则？我是否应该通过仅匹配传入源端口 udp/53 来允许任何内容，而不管状态如何？您是否对 udp 使用连接跟踪机制（ESTABLISHED、RELATED）？
祝一切顺利，JFA
答案1
恕我直言，您应该特别允许在您的 OUTPUT 链上进行出口 DNS 查询（当然，在 UDP 和 TCP 上），然后从RELATED入口规则中删除特定于端口和协议的标志，例如：
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
或者换句话说，使用出站策略根据每个协议控制出站流量，并使用状态匹配来控制入站响应。
默认的 RHEL/CentOS iptables 规则的工作方式如下，尽管它们默认允许任何 OUTPUT 数据包。
是的，您会经常看到被拒绝的数据包，因为它们太晚了，无法匹配状态匹配。
答案2
连接跟踪和 UDP 没有任何意义。UDP 是无连接协议，因此没有连接可跟踪。
为了完全符合 RFC 标准，您必须在端口 53 上监听 tcp 和 udp 流量。
答案3
当查询大小超过 512 字节时，使用 TCP，正如您所说，这通常用于区域传输等，但有时您也会看到合法客户端这样做。
您之所以看到大量来自 udp/53 的连接，是因为许多名称服务器都配置为在该端口上响应，而不是随机的高端口。如果我是您，我会允许来自上游 DNS 服务器的 udp/53 并保持原样。