☰

如何配置 BIND 作为引荐来源

tag-icon • tag-icon domain-name-system bind authoritative
如何配置 BIND 作为引荐来源

我在本地 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.comflags: 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

相关内容