我正在测试将 Debian 10 服务器升级到 Debian 11。该服务器运行 bind9 作为许多域的主要权威 DNS,并且在 Debian 10 上已经正常运行了两年。(BIND v.9.11.5)在新的测试 Debian 11 VPS(BIND 9.16.15)上,复制了站点特定的配置文件(目前仅针对 1 个测试域),当通过 IPv4 发送查询(A、AAAA、MX)时,bind9 正常工作,但使用 IPv6 时没有响应。
我有一个 nftables 防火墙,它允许端口 53 的传入数据包,如果我打开 UDP dport 53 的防火墙日志记录,则会显示所有 IPv6 和 IPv4 查询数据包。
当 bind9 启动时,它会在 syslog 中报告它正在监听 IPv6 地址。ss
显示监听 IPv6 的过程。
如果我使用rndc querylog
并查看日志文件,则会记录 IPv4 查询,但不会记录 IPv6 查询。
就好像传入的 UDP 数据包在防火墙和 bind9 之间丢失了一样。
没有其他进程在端口 53 上监听,因为如果我停止 bind9 的运行,ss 不会列出任何内容。
其他服务(例如 SSH)在 IPv6 上运行良好。
我named.conf.options
看起来像这样:
options {
directory "/var/cache/bind";
allow-query-cache { none; };
allow-query { any; };
recursion no;
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
listen-on-v6 port 53 { any; };
};
那么我还可以做哪些其他测试来解决这个问题?
(BIND 还存在第二个可能不相关的问题:区域传输到辅助 DNS 期间出现“权限被拒绝”错误。)
答案1
通过重启修复!
最近自动内核升级完成后,我可能应该这样做。这种行为显然没有任何意义。
更新:再次遇到类似问题后,我现在怀疑发生这种情况的原因是,我的系统之前已由其他软件安装了 iptables。如果 iptables 仍安装,其规则可能会保留在内核的网络配置中,而 nftables 则看不到。要修复此问题,我必须删除 iptables 包并清除内核中的所有 iptables 规则;后者会在我重新启动时发生。