情况：
在DR站点上混合使用Linux和Windows主机。在发生灾难的情况下，如果生产站点中的SERVER不可用，DR上的SERVER_DR将打开并join到同一个Windows域。这样做是为了防止主站点不可用，我们不想删除SERVER表单AD的原始logging。
我想解决的问题是DR站点中的名称parsing。进程和脚本正在使用DNS名称SERVER，因此在DR站点请求中SERVER应该转换为SERVER_DR。 我们无法在Windows DNS上进行任何操作。
我的想法是使用BIND来解决这个问题.DR中的主机应该能够使用AD进行身份validation。因为他们不需要访问Windows域中的DR站点以外的任何其他内容，应该简化问题。
DR主机需要访问的服务主要是文件共享和SQL服务器。我相信SQL服务器可能是一个问题，因为他们使用SPN
这带来了在DR站点中使用BIND对BIND持有的BIND的想法，但是当Windows DR主机需要对AD进行身份validation时，我可以看到可能的问题，因为如果我没有记错的话，他们需要使用未被logging的logging。由于我之前提到的原因，从AD委托区域。
解决这个问题值得麻烦吗？我的一个同事build议为每个Windows DR主机使用hosts文件。但是看起来相当丑陋，并不是很多，我设置BIND的时间可能会被浪费。
HOSTS文件不会使AD身份validation正常工作。 ADauthentication需要只有DNS服务器才能提供的SRV RR（因为HOSTS文件只是A RR）。
看看这里：re：关于使用BIND来支持AD的更早的答案： 使用BIND9和DHCPD来支持Windows域
如果您的Windows服务器计算机名称不同，您将无法正常使用某些软件。 只是尝试将非DR名称“别名”到具有不同计算机名称的Windows服务器将适用于某些协议，但其他协议则会平坦地放在他们的脸上（例如，AD中的SPN与计算机“绑定”名）。
我不清楚为什么你不能在灾难恢复站点使用Windows DNS。 我认为你可以启动Windows DNS服务器，如果情况变得更糟，请将_msdcs.domain.com区域委托给现有BIND基础结构中的Windows DNS服务器。
我想我需要更多地了解你要完成的任务，以及为什么你有这样的限制，但总的来说，我会努力使DR环境尽可能接近生产环境。在将操作转移到灾难恢复环境中时，您所做的工作量极less。
有一个简单的方法可以使灾难恢复站点上的主机将“SERVER”parsing为SERVER_DR的IP地址，同时仍然保持所有的AD DNS工作正常。 你需要做的是为所有的服务器引用使用别名。
我通常的做法是craete一个新的领域（如mydomain.site）不AD集成。 这使您可以为不同的DNS服务器使用不同的区域文件。 然后将所有对服务器的引用改为server.mydomain.site。 这使您的用户可以使用一个单一的服务器名称，解决任何适合该网站的名称。
NB for Windows文件共享与CNAME别名一起使用，需要为LanManServer服务添加registry项。 有关详细信息，请参阅http://support.microsoft.com/kb/281308 。 这适用于W2k8以及2k和2k3。
我强烈build议您使用Windows DNS来托pipe.site域。 如果你真的无法说服你的系统pipe理员来帮忙，那么你可以使用BIND并将Windows DNS服务器configuration为fowarders。 然后，BIND将parsing.site域，而Windows将用于包括AD域在内的所有其他域。 然而，这使事情变得更加复杂，所以如果可以的话，我会尽量避免。
JR
PS重新“NB为Windows文件共享使用CNAME别名”
使用别名的一点是，您可以使用UNC名称（如\ myserver.mydomain.site \ share）来浏览共享或映射networking驱动器，其中名称“myserver.mydomain.site”将parsing为目标服务器的IP地址，可以parsing到不同站点的不同IP地址。 默认情况下，除非服务器名称与真实服务器名称相匹配，否则LanManServer服务将不允许浏览，并且您将收到类似“networking上存在重复名称”的错误消息。 这样做是为了增加安全性。 我提到的知识库文章描述了如何closures名称检查，以便像上述工作的UNC名称。
其实我经常使用这个技巧，因为它可以很容易地将文件共享移动到不同的服务器上。 这不是DFS的替代品，但是可以是一个有用的技巧。