寻找有关最佳实践方法的一些意见。
- 目前有一个 AD 域，其安全动态 DNS 更新已禁用（例如，任何客户端都可以更新 DNS 记录）。希望摆脱这种情况。
- 50 多个远程站点（通过 MPLS 连接并且每个站点也都具有互联网电路）——一些站点具有本地 DHCP 服务器（Windows），许多站点具有由 Cisco 交换机运行的 DHCP。只有大约 30-40% 的站点拥有本地 IT 人员。
- 一些客户端指向 AD 以获取 DNS（但大多数站点没有 AD 服务器），其他客户端指向 BIND 解析器。将更多客户端转移到本地站点的 BIND 解析器，以处理站点 Internet 线路之外的 Internet 解析，从而为 SaaS 应用以及 RPZ 提供最佳地理位置和性能。我们将 AD 区域从属于 BIND 服务器，以实现性能和弹性。但是，如果客户端指向 BIND，显然动态 DNS 更新将不起作用。
我们正在尝试标准化并尽可能保证安全。查看选项：
- 在 AD 中启用安全 DNS 更新，并让 DHCP 服务器代表客户端处理 DNS 名称的更新。这似乎不会增加任何安全价值，因为任何人都可以发送带有选项 81 标头的 DHCP 请求。此外，不确定 Cisco 设备是否可以安全地更新动态 DNS（例如使用 Kerberos）。猜测不行。
- 与 #1 类似，但仅使用 MS DHCP 进行更新（如果站点没有服务器基础设施，在这种情况下 DHCP 不一定是办公室本地的）。
- 在每个站点安装 AD 服务器，供客户端用作主 DNS（和 DHCP）（并直接处理来自客户端的安全 DNS 更新）。还配备 BIND 服务器用于 Internet 查询。
- 与 #3 相同，但 AD 可同时用于内部和 Internet。但是，我们大量使用 BIND 视图，因此不确定这是否可行，除非我们迁移到 Server 2016（现在为 2012）。
你们这些在中型到大型组织中工作的人是做什么的？
答案1
在我的 1000 多个位置网络中，我们很久以前就放弃了在每个位置都安装 AD DC，原因显而易见，更不用说如果网络中断，用户无论如何都无法完成任何工作，无论有没有 AD（工业系统是单独处理的）。我们为 DHCP/DNS 采用了各种方法，但主要方法是：
- 专用设备上的集中式 DHCP（本质上是 ISC DHCP 和 BIND 的包装）。它们使用特定服务帐户处理从选项 81 到 AD DNS 服务器的动态 DNS 更新。在世界其他地方，这仍然使用 MS DHCP 来处理。我们并不特别信任在 DNS 中动态更新的名称，但到目前为止，我们还没有觉得有必要更进一步，因为这很可能需要在网络上提供更好的边界安全性，以便非托管设备首先无法接入网络。
- 数据中心和最大用户位置上可用的 AD 域控制器上的内部 DNS
- 公共名称解析专用设备
- 客户端全部指向 AD DNS，然后转发到外部域的设备。这里没有太多高级功能。
此设置的主要问题是地理定位不起作用，因为只有 3 个主要数据中心有公共解析器。这通常不是一个大问题，因为大多数浏览器请求都是通过处理 DNS 的云过滤服务代理的，但最近当我们使用视频服务（例如 Google Hangouts）时，事情变得复杂了，因为准确的地理信息会帮助我们选择正确的数据中心。