像大多数组织一样，我们维护各种分裂的领域，原因是真实的。 由于我们做了什么，我们经常在域的不同实例中使用相同的名称来指向不同的版本，这是我们维护的一个要求。 最近出现的是，这正成为分裂之间的障碍。 在最简单的情况下，我们希望能够向内部用户提供对example.com的访问权限，这个权限既存在于内部也存在于外部。
我们希望能够以example.com的forms访问内部版本，并以ext.example.com的forms访问外部版本。 我们可以从外部提供商将外部区域传输到我们的内部BIND服务器。
我已经在BIND服务器中configuration了一个视图，但没有configuration客户端匹配项，因此它所做的只是为该区域预制区域传输。 然后，我试图在名称为ext.mypna.com的“内部”视图中使用相同的文件作为主文件。 完成此操作后，所有logging都将被绑定为“超出区域的数据”。
筛选内部服务器上的区域文件与外部提供程序，我发现区域传输被标记为“$ ORGIN external.com”和“external.com IN SOA”。 将它们还原为@允许BIND再次使用区域文件，但只是在更新后才会被刷新。
有没有一个标准的方式来实现这种架构？
如果我正确地理解了你，你运行单独的独立DNS服务器，并且每个服务器（每个子网或networking位置我确实希望你有多个实例）包含不同的不协调信息。 这是不可持续的。 几年前，我确实inheritance了类似的东西，这是我们最大的烦恼，错误和中断源，直到我们将其彻底删除并build立了一个全新的DNS设置。
而不是维护多个主人负责自己的区域，创build一个拥有多个视图的所有区域的主人。 在任何地方设置奴隶（在同一地点的另一个奴隶，在其他物理地点更多，把他们在身体上和逻辑上接近你的用户的位置）。 复制所有的奴隶，或者只有一些意见，如果你知道你的一些奴隶不会服务于某些networking的请求。 一旦到位，所有的服务器将具有完全相同的数据。 你只需要确保你的视图是正确定义的，所有的客户端都将得到他们需要的结果，而不pipe他们使用的服务器。
几个提示实施：
在你的区域文件中使用$ INCLUDE，这样个别的视图文件只有在不同视图中有不同的条目（例如，你的ext.example.com可能会parsing到相同的IP，无论视图如何，所以它会进入常见的包含文件，而example.com将特定于每个视图文件）。
对于复制，您可能希望为每个DNS服务器提供多个IP地址 – 每个视图一个。 这样做，因为视图使用客户端IP地址来确定要服务的内容 – 这也包括来自从站的XFER请求。 所以，你必须1）为每一个奴隶，添加一个，只有一个IP地址到每个视图; 2）在从站上，使用named.conf中的transfer-source指令，以便XFER源自正确的IP。 这里有更详细的解释相同的想法： http : //coding.infoconex.com/post/2010/04/26/Bind-DNS-e28093-Configuring-multiple-views-on-primary-and-secondary-DNS-servers的.aspx
另外，看看你是否可以从你的networkingpipe理员获得帮助。 在某些情况下，DNS重写可以使单独的视图不必要。