我想使用 BIND 作为公司域的公共名称服务器。我正在使用全新安装的 ubuntu server 20.04.1 和 BIND 9.16.1。问题是 BIND 从未给出权威性答复。我可以使用 dig 看到这一点。为了找到问题所在,我尝试使用单个最小区域“example.com”,但没有任何成功。区域文件是 db.example.com:
example.com. 86400 IN SOA ns1.example.com. hostmaster.example.com. (
1 ; Serial
900 ; Refresh
300 ; Retry
86400 ; Expire
600 ) ; Negative Cache TTL
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN MX 10 mail.example.com.
ns1.example.com. 86400 IN A 123.123.123.123
mail.example.com. 86400 IN A 125.125.125.125
当然,上面的 IP 地址不是真正的 IP 地址,但 ns1.example.com 的 IP 地址是 BIND 正在运行的系统的公共 IP 地址。named-checkzone 对此很满意。在 named.conf.local 中,仅添加了以下几行:
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
};
命名的.conf.选项:
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no;
listen-on { any; };
listen-on-v6 { any; };
recursion no;
};
使用 dig 和 ANY 我可以看到区域文件中的所有记录,但 BIND 总是回答权限:0。此外,A 记录未出现在答案部分,而是出现在附加部分。不幸的是,我不能发布 dig 的原始输出,因为它看起来像垃圾邮件。该区域配置为主区域,NS 记录指向 BIND 正在运行的服务器的 IP 地址。另一个想法是,BIND 可能会尝试从根目录查询“example.com”,并且知道它不是真正的权威名称服务器。所以我也尝试对域“example.invalid”进行相同的操作,而这个域实际上不应该存在于任何地方。结果与“example.com”相同。我以前从未遇到过这个问题。我还能尝试什么来解决这个问题?
答案1
BIND 总是回答 AUTHORITY: 0。
这是正常的,这并不意味着响应不具有权威性。恰恰相反,此部分旨在包含记录,告知客户端权威性别的地方– 例如,如果您查询托管父com
区域甚至根区域的名称服务器,您将获得包含此部分中的 NS 记录的“推荐”响应。
据我所知,实际的权威回应不应该包含本节中的任何记录。
换句话说,你看到的是 dig 输出的错误部分。要确定响应是否具有权威性,查看“标志”部分– 旗帜aa
(权威解答) 为指标。
此外,A 记录不会出现在答案部分,而是出现在附加部分
这也是正常的。它们不会出现在答案部分,因为你的example.com
域名不具有任何 A 记录。
然而,它有一些记录类型(NS 和 MX)参考另一个具有 A 记录的域名。通常需要进行第二次查询才能将其解析为实际地址,但 DNS 服务器可以选择将这些 A/AAAA 记录包含在附加部分中。
因此,当您查询时dig example.com MX
,“答案”部分将包含 example.com 的 MX 记录(即您查询的内容),而“附加”部分将包含 mail.example.com 的 A/AAAA 记录(即您查询的内容)。没有查询,但服务器包含它们以加快速度)。