我们正在运行绑定作为caching名称服务器，这是我们的设置处理DNSfunction的3条规则：
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，因为我们没有托pipe任何区域（但是我注意到一些合法的客户端正在通过TCP进行查询），这就是我包含它的原因。
我的问题是关于第三行。 这条线用于来自上游DNS服务器的响应（对recursion查询的响应）。 我认为这条线是足够的，但后来我注意到在日志（我丢弃的数据包不符合任何允许线），有数十个UDP数据包来自源端口UDP / 53。
我最初的想法是：
1）这些是来自其他DNS服务器的合法响应，我的系统的连接跟踪未被识别为“相关”
2）这些是合理的回应，但是他们是“迟到的回应”，因此我的系统不认识他们。
你使用什么规则来caching域名服务器的响应？ 我应该允许ANY通过只匹配传入的源端口udp / 53而不pipe状态如何？ 你使用udp的连接跟踪机制（ESTABLISHED，RELATED）吗？
一切顺利，JFA
恕我直言，你应该特别允许在OUTPUT链（在UDP和TCP上）出口DNS查询，然后从RELATED入口规则中删除端口和协议特定的标志，例如：
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
换句话说，使用出口策略来控制每个协议的出站stream量，并使用状态匹配来控制入站响应。
默认的RHEL / CentOS iptables规则是这样工作的，虽然它们默认允许任何OUTPUT数据包。
是的，你会经常看到被拒绝的数据包，因为他们来不及匹配有状态的匹配。
连接跟踪和UDP没有任何意义。 由于UDP是无连接协议，所以没有连接来跟踪。
要完全符合RFC，您必须在端口53上侦听tcp和udpstream量。
当查询大小超过512字节时使用TCP，正如你所说的那样，通常用于区域传输等等，但是有时你也会看到合法的客户端也这样做。
从udp / 53看到很多连接的原因是因为很多名称服务器被configuration为在该端口上响应，而不是随机的高端口。 如果我是你，我会允许来自上游DNS服务器的udp / 53，并保留在那里。