![如何配置 BIND 作为引荐来源](https://linux22.com/image/780178/%E5%A6%82%E4%BD%95%E9%85%8D%E7%BD%AE%20BIND%20%E4%BD%9C%E4%B8%BA%E5%BC%95%E8%8D%90%E6%9D%A5%E6%BA%90.png)
我在本地 BIND 中创建了一个区域:
zone "labs" {
type master;
file "/etc/bind/db.labs";
};
zone "foo.labs" {
type master;
file "/etc/bind/db.foo.labs";
};
/etc/bind/db.labs:
@ 3600 IN SOA labs. root.labs. (
2019041900
3600
600
604800
600 )
3600 IN NS ns1.labs.
3600 IN NS ns2.labs.
3600 IN NS ns3.labs.
ns1 IN A 172.16.238.100
ns2 IN A 172.16.238.110
ns3 IN A 172.16.238.120
/etc/bind/db.foo.labs:
@ 3600 IN SOA labs. root.labs. (
2019041900
3600
600
604800
600 )
3600 IN NS ns.foo.labs.
ns IN A 172.16.238.200
该 BIND 实例正在监听,172.16.238.100
并且我还有另一个服务器正在监听172.16.238.200
,它将为 提供 A 记录foo.labs
。
我希望我的 BIND 实例充当引用,这意味着如果我查询,dig @172.16.238.100 foo.labs
我应该获得 NS 记录(例如,与根服务器相同的行为。dig @a.gtld-servers.net. google.com A
为我提供 NS 记录,因为它充当引用)
但截至目前:
dig @labs_bind9 foo.labs A
;; QUESTION SECTION:
;foo.labs. IN A
;; AUTHORITY SECTION:
foo.labs. 600 IN SOA labs. root.labs. 2019041900 3600 600 604800 600
dig @labs_bind9 foo.labs NS
;; QUESTION SECTION:
;foo.labs. IN NS
;; ANSWER SECTION:
foo.labs. 3600 IN NS ns.foo.labs.
;; ADDITIONAL SECTION:
ns.foo.labs. 3600 IN A 172.16.238.200
在这种情况下,缺少什么来强制 BIND 提供 NS 记录?如何使 BIND 作为参考,我没有在文档或示例中看到任何内容。
答案1
我希望我的 BIND 实例充当引荐,这意味着如果我查询 dig @172.16.238.100 foo.labs,我应该获得 NS 记录(与根服务器的行为相同,例如。dig @a.gtld-servers.net.google.com A 为我提供 NS 记录,因为它充当引荐)
让我们看看这里发生了什么
#dig @a.gtld-servers.net. google.com A
; <<>> DiG 9.10.3-P4-Debian <<>> @a.gtld-servers.net. google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56733
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 172800 IN AAAA 2001:4860:4802:34::a
ns2.google.com. 172800 IN A 216.239.34.10
ns1.google.com. 172800 IN AAAA 2001:4860:4802:32::a
ns1.google.com. 172800 IN A 216.239.32.10
ns3.google.com. 172800 IN AAAA 2001:4860:4802:36::a
ns3.google.com. 172800 IN A 216.239.36.10
ns4.google.com. 172800 IN AAAA 2001:4860:4802:38::a
ns4.google.com. 172800 IN A 216.239.38.10
;; Query time: 87 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Wed Sep 07 14:03:26 +06 2022
;; MSG SIZE rcvd: 287
在这里,您请求 DNS 服务器以递归方式为您a.gtld-servers.net.
解析名称的 IPv4 ( )。google.com
flags: qr
但a.gtld-servers.net.
对于区域来说它没有权威性google.com
并且不允许递归查询(参见;; WARNING: recursion requested but not availabl
),所以对于您的 A 查询来说它的答案是“无” ANSWER: 0
。
但是,由于该区域a.gtld-servers.net.
的权威名称服务器com.
会非常友好地告诉您哪些名称服务器负责该google.com.
区域,因此您应该向这些服务器询问google.com
名称的 IPv4 地址(请参阅;; AUTHORITY SECTION:
)。
这些 NS 记录称为委派记录。
此外,它还会报告这些名称服务器的 IP 地址,以便您提前了解它们,从而避免委派记录解析循环(请参阅;; ADDITIONAL SECTION:
)。
这些 A 记录称为胶水记录。
因此你可能会得到这样的结果:
/etc/bind/db.labs:
@ 3600 IN SOA labs. root.labs. (
2019041900
3600
600
604800
600 )
3600 IN NS ns1.labs.
3600 IN NS ns2.labs.
3600 IN NS ns3.labs.
foo IN NS ns.foo.labs. ; delegation for foo.labs.
ns.foo.labs. IN A ip_of_ns.foo.labs. ; glue record
ns1 IN A 172.16.238.100
ns2 IN A 172.16.238.110
ns3 IN A 172.16.238.120