[注：这个问题的解决scheme是完美的，通过偏离标题所示的东西]。
我正面临着Windows Server 2003 DNS服务的一个小问题。 在我的公司里，我运行Microsoft DNS服务器（172.16.0.12），对我公司的内部网进行名称parsing（域名以dev.nls。parsing为IP 172.16 。 ）结束，并且还configuration为DNS转发器将其他域名（如* .google.com，* .sf.net）转发到Internet真正的DNS服务器。 这个内部的DNS服务器永远不会为外部世界的用户提供服务。
而且，我们正在公司的防火墙内部运行一个邮件服务器（为一个真正的 Internet域@ nlscan.com提供接收邮件）
请注意，172.16.0.10和202.101.116.9是不一样的物理机器。 202是一个防火墙机器，将端口25和110的端口转发到内部网地址172.16.0.10。
现在我的问题：如果公司局域网内的用户想要解决mail.nlscan.com，它parsing为202.101.116.9。 这是正确和可行的，但不好，因为邮件stream量去防火墙机器然后反弹到172.16.0.10。 我希望我们的内部DNS服务器可以拦截名称mail.nlscan.com并将其parsing为172.16.0.10。 所以，我希望我可以在172.16.0.12的“hosts”文件中写一个条目来做到这一点。 但是，Microsoft DNS服务器如何识别这个“hosts”文件呢？
也许你build议，为什么不让内部网用户使用172.16.0.10来访问我的邮件服务器？ 我不得不说，这是不方便的，假设用户（员工）在他的笔记本电脑上工作，白天在办公室和家里夜间。 当他在家时，他不能使用172.16.0.10。
在我们的内部DNS服务器上为nlscan.com创build一个区域是不可行的，因为nlscan.com域的名称服务器位于我们的ISP上，它负责parsingnlscan.com下的其他主机名称和子域名。
先谢谢你。
[编辑]
正如WesleyDavid所build议的，我遵循简单地创build名为mailserver.nlscan.com的区域的解决scheme， 并在该区域中放置一个无名的Alogging 。 时间certificate这个效果很好。
这篇文章的后半部分是错误的。 基于我在网上读过的一些东西（如果它在网上，它必须是真的），我感到印象深刻的是，Windows DNS服务器服务创buildcaching任务的一部分也是将其主机文件加载到caching以及其本地区域数据。 我四处搜寻，找不到这方面的确凿证据。 我在自己的Server 2008 R2机器上testing了这个理论，发现hosts文件没有用来构buildDNS服务器的caching。
不过，我相信我有一个稍微优雅的解决scheme，Massimo。 而不是创build整个nlscan.com区域的权威区域，只需创build一个名为mailserver.nlscan.com的区域，并在该区域中放置一个无名的Alogging。 无名的Alogging将与该区域本身具有相同的名称，您可以为其指定所需的IP地址。 nlscan.com下的所有其他域名以及nlscan.com本身都将通过公共DNS进行parsing。
我刚刚在我自己的Server 2008 R2 DNS服务器上testing了这个，并且能够通过公共DNS服务器parsing我的朋友的网站（nessus.nl），但是特定的子域名（blog.nessus.nl）parsing为Apple.com的IP地址。 尝试一下，看看它是否适合你。
老年人，错误的职位开始：
如果我的理解是正确的（编辑：而不是），当DNScachingbuild立在Server 2003机器上时，它从主机文件以及区域数据中提取条目。 在您的Server 2003机器的hosts文件中放置172.16.0.10 mailserver.nlscan.com应该可以解决这个问题。 更改主机文件后重新启动DNS服务。
在任何Windows计算机（特别是Server 2003 DNS计算机）上使用ipconfig / displaydns来查看您的主机文件条目。 另外请记住，负面响应会caching在您的客户端中，因此请始终在您正在尝试的客户端上运行ipconfig / flushdns。 否则，当你想知道为什么你的客户不能parsing刚input到区域/主机文件中的名称时，你最终会滥用自己的硬件对象。 =）
你试过这个，失败了吗？
希望让内部用户获得资源的内部IP，而外部用户获得这些资源的外部IP是常见的。 它被称为裂脑DNS。 您有一台面向互联网的DNS服务器，另一台面向本地用户的内部DNS服务器。 内部用户在您的networking上使用DHCP，在您的DHCP服务器上通告内部DNS服务器。 当你的用户不在办公室时，他们的DHCP服务器将把它们分配给只知道外部区域的DNS服务器。
你似乎想要分裂大脑的DNS没有实际托pipe区域内部。 您build议在内部托pipe区域是有问题的，因为您不希望用户在家中工作时获取内部IP，但这样做没有任何意义，因为当他们在家时，他们将从不同的DHCP服务器获取IP这不会公布您的内部DNS服务器。 它将公布他们的ISP的DNS服务器，它只会知道你的外部区域，因此只会提供外部IP地址。
最后，我不认为你要求DNS服务器从DNS服务器上的hosts文件提供logging。 DNS服务器从其区域文件提供logging。 该DNS服务器上的本地主机文件将条目传播到仅适用于该计算机上的查找的本地客户端parsingcaching中。 这些条目不是由不同的机制的DNS服务器提供的。
阅读分裂的大脑DNS – 这是处理这种情况的正常方法。
Wes：我不确定是谁欺骗了你，但是我想澄清一下hosts文件的用法：hosts文件由DNS客户端parsing器组件使用，而不是由DNS服务器组件使用。 当DNS服务器充当DNS客户端时，DNS服务器上的hosts文件中的条目将被使用。 例如，我的W2K8 DNS服务器的主机文件中的条目是这样的：
1.1.1.1 test.test.com
被加载到DNS服务器的DNS客户端caching中（而不是服务器caching）。 如果我从我的DNS服务器ping test.test.com，它会按预期返回1.1.1.1。 如果我在DNS服务器上运行nslookup并询问test.test.com，它将返回为test.test.com注册的正确的公共IP地址，因为DNS服务器上的DNS客户端组件现在要求DNS服务器组件进行parsing（就像任何其他的DNS客户端一样）。 这是一个令人困惑的想法，但是DNS服务器也是一个DNS客户端，当DNS客户端组件被调用时，它的行为就像任何其他的DNS客户端一样，通过查看它自己的DNS客户端caching，从主机文件加载。 只有当DNS客户端组件使用DNS服务器组件（通过查询其TCP \ IP属性中configuration的DNS服务器（应该指向自己）），DNS服务器的caching才会被填充正确的信息。
任何查询DNS服务器的DNS客户端将总是得到“真正的”答案，而不是主机条目，因为DNS服务器的DNS客户端caching被服务器本身（作为DNS客户端）使用，而不是由DNS服务器组件使用。
据我所知，没有办法使Windows DNS使用hosts文件来处理名称parsing; 但这不是必需的。
您可以安全地在您的内部DNS服务器上创build一个与公共Internet区域名称相同的区域; 会发生什么情况是，您的服务器将使用自己的数据处理该区域中名称的请求，而不是将这些请求转发给该区域的权威名称服务器; 这有时被称为“阴影”，因为它使内部客户端不能使用“真实”公共区域，而是用“假”数据来回答。
你应该注意的是，你应该填充这个内部区域，所有你需要的名字，甚至在需要的时候使用公共IP地址。 否则，内部客户将无法解决这些名称。
假设您的公共区域如下所示：
www.nlscan.com 202.101.116.8 mail.nlscan.com 202.101.116.9
您希望内部客户端将mail.nlscan.comparsing为172.16.0.10; 没关系，所以你在你的内部DNS服务器上创build一个“nlscan.com”区域，并在其中放入“mail.nlscan.com – > 172.16.0.10”。
但是现在你的内部客户端不能parsing“www.nlscan.com”，因为服务器认为它对该区域是权威的，所以它不会回答查询（因为它不知道该主机），但它也不会转发给任何人。
为了解决这个问题，你需要把“www.nlscan.com”放在你的内部区域。 如果您希望您的客户以这种方式访问它，您可以指向其真实的公共IP地址，也可以使用与“mail.nlscan.com”相同的redirect，如果“www”也由您的防火墙到一些内部服务器。
同样的原则适用于区域内的任何名称。
此设置不会影响外部客户端，也不会影响临时在networking之外的任何用户，因为内部“影子”区域永远不会从Internet中看到。
Nevermind主机文件，只需在DNS mail.domain.com中添加一个新的区域，并在该区域添加一个主机。 将名称留空（它将自动使用区域的名称）并input本地邮件服务器的IP地址;-)