我的问题和这一个，但接受的答案和评论并没有帮助我解决问题。我会在这里放出我拥有的整个设置。
BIND9 版本 - BIND 9.11.5-P4-5.1+deb10u6-Debian (Extended Support Version)，
操作系统 -Debian Buster (10.11)
named.conf：
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
named.conf.options：
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
//forwarders {
// 0.0.0.0;
// };
//========================================================================
// 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 { any; };
//hide version number from clients for security reasons.
version "not currently available";
};
named.conf.local：
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
named.conf.default-zones：
// prime the server with knowledge of the root servers
zone "." {
type hint;
//Default
//file "/usr/share/dns/root.hints";
file "/etc/bind/db.fake.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
db.fake.root：
; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$TTL 86400
@ IN SOA ns. root.unimar.io. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
@ IN NS ns
ns IN A 127.0.0.1
$ORIGIN unimar.io.
uniapp IN A 10.120.0.12
当我重新启动服务时它会运行，但在日志中收到以下警告消息：
Nov 25 11:03:11 unimarDNS named[1145]: zone 255.in-addr.arpa/IN: loaded serial 1
Nov 25 11:03:11 unimarDNS named[1145]: zone 127.in-addr.arpa/IN: loaded serial 1
Nov 25 11:03:11 unimarDNS named[1145]: zone localhost/IN: loaded serial 2
Nov 25 11:03:11 unimarDNS named[1145]: all zones loaded
Nov 25 11:03:11 unimarDNS systemd[1]: Started BIND Domain Name Server.
Nov 25 11:03:11 unimarDNS named[1145]: running
Nov 25 11:03:11 unimarDNS named[1145]: lame server resolving '.' (in '.'?): 127.0.0.1#53
Nov 25 11:03:11 unimarDNS named[1145]: lame server resolving '.' (in '.'?): 127.0.0.1#53
Nov 25 11:03:11 unimarDNS named[1145]: managed-keys-zone: Unable to fetch DNSKEY set '.': failure
Nov 25 11:03:11 unimarDNS named[1145]: resolver priming query complete
当我尝试访问dig主机时，我得到了以下信息：
root@unimarDNS:/etc/bind# dig uniapp.unimar.io
; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> uniapp.unimar.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39791
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8da51eb1b4443aeda9f03e38619f5190efb0dc3cd3c88f68 (good)
;; QUESTION SECTION:
;uniapp.unimar.io. IN A
;; Query time: 1 msec
;; SERVER: 10.120.0.13#53(10.120.0.13)
;; WHEN: Thu Nov 25 11:04:16 EET 2021
;; MSG SIZE rcvd: 73
我在日志中得到了这个：
Nov 25 11:04:16 unimarDNS named[1145]: lame server resolving '0.debian.pool.ntp.org' (in '.'?): 127.0.0.1#53
Nov 25 11:04:16 unimarDNS named[1145]: lame server resolving '0.debian.pool.ntp.org' (in '.'?): 127.0.0.1#53
Nov 25 11:04:16 unimarDNS named[1145]: lame server resolving '1.debian.pool.ntp.org' (in '.'?): 127.0.0.1#53
Nov 25 11:04:16 unimarDNS named[1145]: lame server resolving '1.debian.pool.ntp.org' (in '.'?): 127.0.0.1#53
Nov 25 11:04:16 unimarDNS named[1145]: lame server resolving '2.debian.pool.ntp.org' (in '.'?): 127.0.0.1#53
Nov 25 11:04:16 unimarDNS named[1145]: lame server resolving '2.debian.pool.ntp.org' (in '.'?): 127.0.0.1#53
Nov 25 11:04:16 unimarDNS named[1145]: lame server resolving '3.debian.pool.ntp.org' (in '.'?): 127.0.0.1#53
Nov 25 11:04:16 unimarDNS named[1145]: lame server resolving '3.debian.pool.ntp.org' (in '.'?): 127.0.0.1#53
请问有人能告诉我我做错了什么吗？
编辑
我确实喜欢@Nikita Kipriyanov 在下面的评论中所建议的。
该问题中的解决方案不起作用，因为 BIND 要求根区域已签名。我不明白为什么要尝试重新定义根服务器，而不是直接为所需区域创建授权服务器？这非常不必要。如果系统与互联网断开连接，互联网查找无论如何都会失败。
答案1
我确实喜欢@Nikita Kipriyanov 在下面的评论中所建议的。
该问题中的解决方案不起作用，因为 BIND 要求根区域已签名。我不明白为什么要尝试重新定义根服务器，而不是直接为所需区域创建授权服务器？这非常不必要。如果系统与互联网断开连接，互联网查找无论如何都会失败。