我目前正在为我的家庭实验室设置 DNS 服务器。我创建了一个与实验室域（假设）相对应的区域文件home.lab，现在服务器知道它是该区域的权威服务器，并且可以响应有关 的查询device.home.lab。
现在我想在其他设备上使用此 DNS 服务器，以便它成为该home.lab区域的权威，但我还需要它们仍然能够解析全球互联网域。似乎没有办法将终端主机设置为仅将其用于home.lab查找，而将其用于其他用途。到目前为止，我可以看到几个解决方案：
- 设置此服务器以递归解析其他区域（这将起作用，如上所述在这个问题中）
- 当服务器被要求提供除其自身区域之外的区域时，请服务器引用根服务器进行响应，然后让客户端自行递归地向层次结构进行询问
- 设置另一个 DNS 服务器，当被请求时，
home.lab它将转发来自权威 DNS 服务器的答案，否则将转发缓存的答案
第一种选择似乎不太好，因为权威服务器还承担着其他域的递归解析器的双重职责。第二种选择效率低下，因为客户端必须手动解析每个新域的层次结构，这可能会非常慢。
因此，目前看来，第三个选项是最好的。我该如何在 BIND9 中进行设置，以及/或者我应该考虑其他解决方案吗？
答案1
第一个选项似乎不太好，因为权威服务器还要承担其余域的递归解析器的双重职责。
对于小型 LAN/家庭实验室的使用来说，这并不是什么问题。
（例如在 Active Directory 环境中，管理员指示所有客户端直接使用托管 AD DNS 区域的 AD DC，而不是专用的解析器 - 这就是不必要，但并不完全是坏事。
可能存在一些极端情况（例如 DNSSEC AD 标志），但我相信它们会导致不是不是将解析器功能添加到权威服务器，而是相反，让机器像解析器一样使用权威服务器，这是已经正在做。
第二种方法效率低下，因为客户端必须手动解析每个新域名的层次结构，这可能会非常慢。
这也行不通，因为大多数客户只是存根解析器——它们不会遵循推荐。
另一方面，完整的解析器将缓存引荐。您一直使用的公共 DNS 解析器（无论是 ISP 还是 Google 或其他）也必须解析每个新域的层次结构 - 它当然不会保留世界上所有 DNS 记录的完整副本 - 但它并不慢，因为至少第一级（TLD）通常缓存在内存中，而且典型域的层次结构级别本来就不多。
因此，目前看来，第三个选项是最好的。我该如何在 BIND9 中进行设置，以及/或者我应该考虑其他解决方案吗？
在 BIND9 中，创建一个type static-stub指向 homelab 身份验证服务器的区域。（它类似于type forward区域，但“static-stub”希望直接指向权威服务器，而“forward”希望链接到另一个解析器。我不确定确切的区别。）
对于所有其他域，您可以像forwarders{}在全局 BIND 配置中一样指定上游服务器。这不是必需的 - BIND9 本身能够从根 DNS 服务器一路追踪引荐（只要配置了“根提示”伪区域，默认情况下就会这样做），这实际上不是很慢（尽管肯定比将请求转发到具有自己的大量缓存的上游服务器慢）。
一种常见的替代方案是 Unbound（它更侧重于用作解析器，仅具有最少的权威服务器功能）。Unbound 的配置类似，只是区域类型改为stub“static-stub”。要进行 Unbound 转发查询，请配置"."为“type: forward”区域。
请记住，发明自定义 TLD 不会很好地与 DNSSEC 验证配合使用，因为根区域有 NSEC 记录证明不存在，因此lab.您可能需要明确将您的域排除在验证之外，无论是在 LAN 解析器中，有时在主机本身中。只有域才home.arpa.保留用于此类用途（故意未签名的 NS 记录）。
（或者，你可以使能够DNSSEC，签署您的内部区域，并在所有验证解析器上指定自定义“信任锚”。虽然家庭实验室实际上不需要 DNSSEC，但这里的优势在于添加信任锚可能比添加排除更容易，尤其是在 BIND 中。）