我在本地网关系统上绑定了9，该系统当前configuration为我们LAN的recursionparsing域名服务器。 我也想让我们的局域网上的RFC 1918地址具有权威性，但是在区域文件中找不到相同域名的远程域名服务器。 （通过远程服务器parsing的RFC 1918地址和公有名称的本地主机都使用相同的sld.tld。）我试过在区域表中放置远程服务器的NSlogging，但这不起作用。 有没有办法做到这一点？
我在/ etc / hosts中拥有本地名称，但是有些服务要求通过DNS查找来parsing它们，并且不会从hosts文件parsing它们。
我也想让我们的局域网上的RFC 1918地址具有权威性，但是在区域文件中找不到相同域名的远程域名服务器。
你遇到的问题是权威不能这样工作。 没有穿透的概念。 当服务器声明一个区域的权限时，它对于其中的所有数据是权威的，除了两种情况：
NSlogging）委托权威。 区域顶部的NSlogging不定义引荐。 不幸的是，对于这个问题，没有收到来自互联网的推介并不是非常有用。 这是因为引用仅在recursionpath遇到时才起作用，而内部pipe理的DNS不遵循recursionpath。
有几种不同的方法可以在这里完成类似的最终结果。
这是大多数公司所做的，而且是迄今为止最容易pipe理的。
最简单的解决scheme是为RFC1918设备创build一个新的专有“内部”子域名。只要您不尝试为DNS条目创build冲突的DNS定义，这种方法就行得通了。 （即同时拥有公共和私有IP的www.example.com ）
需要访问此内部域的recursionDNS服务器必须configuration指向权威服务器的转发器。 在BIND中，这些将是typesforward区域。
优点：
缺点：
如果解决scheme1不起作用，我们需要退后一步，诚实地对待自己一会儿。 您的服务器不具有您试图在其中创buildDNSlogging的名称空间的权限。您试图劫持您不负责操作的名称空间。 与其试图为不具有权威性的数据创build权威区域，为什么不使用为此目的而devise的function？
近年来，BIND收到了一个名为响应政策区 （RPZ）的新function。 这使您可以定义要拦截的查询的区域文件，以及服务器在看到时应提供的答案。 这允许您pipe理您想要截取的logging列表，其他所有其他解决scheme也是如此。
优点：
缺点：
最后的方法是存在多个版本的区域。 一个面向互联网，一个或多个面临你的私人networking。
有两种常用的方法。
基于视图的方法。 这两个版本的权威区域都位于同一台服务器上。 定义了基于源IP的多个视图，这些视图决定了用于提供答案的文件。
基于服务器的方法。 一台服务器拥有面向互联网的区域版本，另一台服务器拥有该区域的私密版本。 类似于解决scheme1，面向私人版本的区域只有recursion服务器才能看到，该服务器已经定义了指向备用DNS服务器权限的转发器。
基于服务器的方法往往是丑陋的，因为任何必须在两个环境中都可见的logging必须单独添加。 如果服务器拥有不同的运营所有者，则这变得更加复杂，因为需要在多个环境中使两个或更多个小组参与DNSlogging。 您的用户无法知道多个团队参与其“简单”添加logging的请求，并且球会经常被放弃，除非良好的团队沟通。
优点：
缺点：