我在本地网关系统上安装了 bind9，该系统当前已配置为 LAN 的递归解析名称服务器。我还想让它成为 LAN 上 RFC 1918 地址的权威，但对于这些地址的区域文件中未找到的同一域中的名称，则转到远程名称服务器。（具有 RFC 1918 地址的本地主机和通过远程服务器解析的公共名称都使用相同的 sld.tld。）我尝试将远程服务器的 NS 记录放入区域表中，但这不起作用。有什么办法吗？
我在 /etc/hosts 中有本地名称，但是某些服务要求它们能够通过 DNS 查找进行解析，而无法从 hosts 文件中解析它们。
答案1
我还想使其对我们 LAN 上的 RFC 1918 地址具有权威性，但对于在区域文件中找不到的同一域中的名称，则转到远程名称服务器。
您在这里遇到的问题是，权限不是那样运作的。没有 fallthrough 的概念。当服务器声明对某个区域的权限时，它对全部其中的数据，除非出现以下两种情况：
- 引荐（
NS记录）将权限委托给它。NS区域顶部的记录没有定义引荐。 - 在同一服务器上定义了具有更具体名称的重叠区域。
不幸的是，对于这个问题，不是从互联网收到的引荐并不是很有用。这是因为引荐只有在递归路径中遇到时才有用，而内部管理的 DNS 不会遵循这一路径。
您可以采用几种不同的方法来实现类似的最终结果。
解决方案 1：为内部 DNS 记录创建子域。
这是大多数公司的做法，也是迄今为止最容易管理的做法。
最简单的解决方案是为 RFC1918 设备创建一个新的、专用的“内部”子域。只要您没有尝试为 DNS 条目创建冲突的 DNS 定义，这种方法就可以奏效。（即同时www.example.com拥有公共 IP 和私有 IP）
需要访问此内部域的递归 DNS 服务器必须配置指向权威服务器的转发器。在 BIND 中，这些将是 类型的区域forward。
优点：
- 无冲突的命名空间。DNS 区域的所有权非常明确且定义良好。
缺点：
- 对于具有私有地址和公共地址的设备必须使用单独的名称。
- 面向互联网的命名空间的所有者不得创建与您的 DNS 记录相冲突的 DNS 记录。（你们双方都必须同意此政策）
解决方案2：使用响应策略拦截特定的DNS记录。
如果解决方案 1 不起作用，我们需要退一步思考一下，诚实面对自己。您的服务器才不是您尝试在其中创建 DNS 记录的命名空间拥有自己的权限。您正试图劫持您不负责运营的命名空间。与其尝试为您不负责的数据创建权威区域，为什么不使用为此目的设计的功能呢？
近年来，BIND 增加了一项新功能，称为响应政策区域（RPZ）。这允许您定义要拦截的查询的区域文件，以及服务器在看到这些查询时应提供的答案。这允许您管理要拦截的记录列表，而其他所有记录则按正常方式解析。
优点：
- 能够拦截特定查询，而无需尝试宣称对整个区域的权限。
缺点：
- 额外的 CPU 开销。除非我们谈论的是运营商级、面向客户的场景，否则我不会担心这一点。
- 用户困惑。他们可能不太清楚为什么通过你的服务器的查询会有不同的行为。
解决方案 3：拆分 DNS 地狱。
最后一种方法是存在多个版本的区域。一个面向互联网，一个或多个面向您的私有网络。
有两种常见的方法。
基于视图的方法。权威区域的两种版本都位于同一台服务器上。定义了基于源 IP 的多个视图，这些视图决定了用于提供答案的文件。
基于服务器的方法。一台服务器拥有面向互联网的区域版本，另一台服务器拥有面向私人的区域版本。与解决方案 1 类似，面向私人的区域版本仅对已定义转发器（将权限指向备用 DNS 服务器）的递归服务器可见。
基于服务器的方法往往不太好，因为任何必须在两个环境中都可见的记录都必须单独添加。如果服务器有不同的运营所有者，情况会变得更加复杂，因为需要让两个或多个团队参与到需要在多个环境中可见的 DNS 记录中。您的用户无法知道他们“简单”的添加记录请求涉及多个团队，并且除非团队沟通良好，否则经常会出错。
优点：
- DNS 记录可以具有一个根据请求来源而变化的值。
缺点：
- 用户困惑。他们不太清楚为什么通过您的服务器的查询会有不同的表现。如果多个团队操作服务器，他们将不知道需要向两个团队提交请求。
- 设计复杂性。
- 如果一条记录必须对多个环境可见，则必须将其添加到全部其中。它们返回的是不同值还是相同值并不重要。如果有人忘记将记录添加到环境中，它就根本不存在。
- 记录在一个环境中被更改但在其他环境中不会被更改的风险。
- 你会让我哭的。:'(