配置为这样做时，bind9不会递归。

Question

新的绑定服务器不会返回递归域。到目前为止，我发现的是：

当客户端查询服务器时，我可以看到发送给转发器的递归查询使用tcpdump输入和离开，以及被查询的根服务器。

我使用了已知的良好配置，因此问题必须针对新的服务器设置。与以前的服务器和这个服务器不同的是，以前的服务器只有一个接口，而这个服务器通过与它所服务的客户端不同的接口进行解析。

如果我指定另一个DNS服务器(包括我的转发器)，我可以在本地从服务器执行DNS查找。

本地服务器成功地服务本地域。

日志不会显示任何可能会出现配置错误的错误。

有人能治好我的理智吗？

从客户端查询从服务器查找本地nslookup：

:~$ nslookup
> google.com
Server:         
Address:        #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;
        ;
        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 .40697 > dns.google.domain: 21779+% [1au] A? google.com. (51)
09:33:02.620007 IP dns.google.domain > .40697: 21779 1/0/1 A 216.58.213.14 (55)
09:33:02.622853 IP .37233 > .domain: 54096+ PTR? 4.4.8.8.in-addr.arpa. (38)
09:33:02.624007 IP .57821 > dns.google.domain: 6972+% [1au] DS? com. (44)
09:33:02.632941 IP .domain > .37233: 54096 1/0/0 PTR dns.google. (62)
09:33:02.633410 IP .49292 > .domain: 52131+ PTR? 35.0.168.192.in-addr.arpa. (43)
09:33:02.642956 IP .domain > .49292: 52131 NXDomain 0/0/0 (43)
09:33:02.648993 IP dns.google.domain > .57821: 6972$ 2/0/1 DS, RRSIG (367)
09:33:02.655919 IP .39385 > dns.google.domain: 44121+% [1au] DS? com. (44)
09:33:02.680136 IP dns.google.domain > .39385: 44121$ 2/0/1 DS, RRSIG (367)
09:33:02.682891 IP .58887 > .domain: 44625+% [1au] DS? com. (44)
09:33:02.692994 IP .domain > .58887: 44625 1/0/1 DS (80)
09:33:02.696743 IP .44152 > e.root-servers.net.domain: 44834 [1au] DS? com. (44)
09:33:02.714204 IP e.root-servers.net.domain > .44152: 44834*- 2/0/1 DS, RRSIG (367)
... and so on for all root servers.

Answer 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-validation no;，我关闭了DNSSEC验证。然后，我重新启用了dnssec，重新启动了服务器，进行了几次查找，然后重新启用了验证。

从那以后一切都很顺利。