新的绑定服务器未返回递归域。到目前为止我发现：
当客户端查询服务器时，我可以看到使用 tcpdump 进入和离开发送到转发器的递归查询，以及被查询的根服务器。
我使用了已知的良好配置，因此问题肯定是新服务器设置所特有的。与之前的服务器和此服务器不同的一点是，之前的服务器只有一个接口，而此服务器通过与其所服务的客户端不同的接口进行解析。
如果我指定另一个 DNS 服务器（包括我的转发器），我可以从服务器本地执行 DNS 查找。
本地服务器成功为本地域提供服务。
日志没有显示任何表明配置错误的错误。
有人能让我恢复理智吗？
来自客户端查询的服务器本地 nslookup 示例：
:~$ nslookup
> google.com
Server: <isp-dns-ip>
Address: <isp-dns-ip>#53
Non-authoritative answer:
Name: google.com
Address: 216.58.213.14
Name: google.com
Address: 2a00:1450:4009:816::200e
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> google.com
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find google.com: SERVFAIL
> wdcds01.home.int
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: wdcds01.home.int
Address: 192.168.76.100
我的选项配置（已过滤；配置中的实际 IP 地址）：
acl "trusted"{
localnets;
127.0.0.1;
192.168.0.0/24;
192.168.76.0/24;
192.168.251.0/24;
172.22.15.0/27;
};
options {
directory "/var/cache/bind";
dnssec-validation auto;
recursion yes;
querylog yes;
auth-nxdomain no; # conform to RFC1035
listen-on port 53 { any; };
forwarders {
8.8.8.8;
8.8.4.4;
<isp-dns-ip>;
192.168.76.100;
};
allow-query-cache {trusted;};
allow-query {trusted;};
allow-recursion {trusted;};
forward first;
};
日志文件条目示例：
:~$ tail /var/log/named/named.log
07-Sep-2022 09:14:17.443 fetch: ./DNSKEY
07-Sep-2022 09:29:30.217 obtaining root key for view _default from '/etc/bind/bind.keys'
07-Sep-2022 09:29:30.217 dnssec-validation auto: WARNING: root zone key not found
07-Sep-2022 09:29:30.217 using built-in root key for view _default
07-Sep-2022 09:29:30.225 fetch: ./DNSKEY
07-Sep-2022 09:29:34.877 fetch: google.com/A
07-Sep-2022 09:29:34.905 fetch: com/DS
07-Sep-2022 09:29:35.781 fetch: google.com/AAAA
07-Sep-2022 09:29:38.098 fetch: google.com/A
07-Sep-2022 09:29:38.130 fetch: google.com/AAAA
:~$ tail /var/log/named/querylog
07-Sep-2022 09:23:32.678 client @0x7f93f800a3e0 192.168.76.139#37679 (249.76.168.192.in-addr.arpa): query: 249.76.168.192.in-addr.arpa IN PTR + (192.168.76.1)
07-Sep-2022 09:23:32.678 client @0x7f93f800a3e0 192.168.76.139#37679 (250.76.168.192.in-addr.arpa): query: 250.76.168.192.in-addr.arpa IN PTR + (192.168.76.1)
07-Sep-2022 09:23:32.682 client @0x7f93f800a3e0 192.168.76.139#37679 (251.76.168.192.in-addr.arpa): query: 251.76.168.192.in-addr.arpa IN PTR + (192.168.76.1)
07-Sep-2022 09:23:32.682 client @0x7f93f800a3e0 192.168.76.139#37679 (252.76.168.192.in-addr.arpa): query: 252.76.168.192.in-addr.arpa IN PTR + (192.168.76.1)
07-Sep-2022 09:23:32.686 client @0x7f93f800a3e0 192.168.76.139#37679 (253.76.168.192.in-addr.arpa): query: 253.76.168.192.in-addr.arpa IN PTR + (192.168.76.1)
07-Sep-2022 09:23:32.690 client @0x7f93f800a3e0 192.168.76.139#37679 (254.76.168.192.in-addr.arpa): query: 254.76.168.192.in-addr.arpa IN PTR + (192.168.76.1)
07-Sep-2022 09:29:34.877 client @0x7f93f4030510 192.168.76.96#63128 (google.com): query: google.com IN A + (192.168.76.1)
07-Sep-2022 09:29:35.781 client @0x7f93fc070540 192.168.76.96#63129 (google.com): query: google.com IN AAAA + (192.168.76.1)
07-Sep-2022 09:29:38.098 client @0x7f93ec008360 192.168.76.96#63130 (google.com): query: google.com IN A + (192.168.76.1)
07-Sep-2022 09:29:38.130 client @0x7f93f4030510 192.168.76.96#63131 (google.com): query: google.com IN AAAA + (192.168.76.1)
缩短并过滤后的 tcpdump 输出显示了来自客户端请求的传出递归查找：
:~$ sudo tcpdump -i enp4s0 udp port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp4s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:33:02.595825 IP <my-ext-ip>.40697 > dns.google.domain: 21779+% [1au] A? google.com. (51)
09:33:02.620007 IP dns.google.domain > <my-ext-ip>.40697: 21779 1/0/1 A 216.58.213.14 (55)
09:33:02.622853 IP <my-ext-ip>.37233 > <isp-dns-ip>.domain: 54096+ PTR? 4.4.8.8.in-addr.arpa. (38)
09:33:02.624007 IP <my-ext-ip>.57821 > dns.google.domain: 6972+% [1au] DS? com. (44)
09:33:02.632941 IP <isp-dns-ip>.domain > <my-ext-ip>.37233: 54096 1/0/0 PTR dns.google. (62)
09:33:02.633410 IP <my-ext-ip>.49292 > <isp-dns-ip>.domain: 52131+ PTR? 35.0.168.192.in-addr.arpa. (43)
09:33:02.642956 IP <isp-dns-ip>.domain > <my-ext-ip>.49292: 52131 NXDomain 0/0/0 (43)
09:33:02.648993 IP dns.google.domain > <my-ext-ip>.57821: 6972$ 2/0/1 DS, RRSIG (367)
09:33:02.655919 IP <my-ext-ip>.39385 > dns.google.domain: 44121+% [1au] DS? com. (44)
09:33:02.680136 IP dns.google.domain > <my-ext-ip>.39385: 44121$ 2/0/1 DS, RRSIG (367)
09:33:02.682891 IP <my-ext-ip>.58887 > <isp-dns-ip>.domain: 44625+% [1au] DS? com. (44)
09:33:02.692994 IP <isp-dns-ip>.domain > <my-ext-ip>.58887: 44625 1/0/1 DS (80)
09:33:02.696743 IP <my-ext-ip>.44152 > e.root-servers.net.domain: 44834 [1au] DS? com. (44)
09:33:02.714204 IP e.root-servers.net.domain > <my-ext-ip>.44152: 44834*- 2/0/1 DS, RRSIG (367)
... and so on for all root servers.
答案1
我的日志设置为忽略 lame 服务器错误。我将 lame 服务器日志设置为审计通道以查看错误：
logging {
channel audit_log {
// Send the security related messages to a separate file.
file "/var/log/named/named.log" versions 10 size 50m;
severity info;
print-time yes;
};
category lame-servers { audit_log; };
};
然后我看到了如下错误：
07-Sep-2022 15:38:10.988 broken trust chain resolving 'something.com/DS/IN': 8.8.4.4#53
我通过设置选项dnssec-enable no;&关闭了 DNSSEC 验证dnssec-validation no;。然后我重新启用了 dnssec，重新启动了服务器并进行了几次查找，然后重新启用了验证。
自此以后，一切正常。