完全披露：我不是 AD 人员，所以这可能与某些显而易见的事情有关。如果是这样的话，我提前道歉 - 我确实尝试搜索过与此相关的先前问题。
我正在 AD 环境中安装基于 Linux 的 Web 应用程序服务器（原始 CentOS 5.x - 没有与 AD 的特殊集成）。该应用程序针对全局目录服务器执行 LDAPS 查询。为了发现要与哪个 AD 服务器通信，它会执行 DNS 查找与 AD 域（foo.int）相关的 A 记录。这个特定的查询似乎失败了（我仍在调查）。
但与此同时，我想确认几件事：
- 如果我将 Linux 服务器指向 Microsoft DNS 服务器，并查询 AD 域 (foot.in)，那么是否可以合理地假设我应该获得指向某些 GC 的 A 记录？
- GC 的 A 记录可用性是否相当标准？还是因环境而异？换句话说，是否有一些环境根本没有为 DC 发布内部 A 记录？
- 这些特定记录是自动管理/更新的吗，还是由管理员手动添加/编辑的？
答案1
如果我将 Linux 服务器指向 Microsoft DNS 服务器，并查询 AD 域 (foot.in)，那么是否可以合理地假设我应该获得指向某些 GC 的 A 记录？
不，你得到的只是域控制器 在域中不一定只是全局目录服务器。如果您只想要全局目录服务器，您可以查询；如果您只想要特定站点中的 GC，_gc._tcp.<your_AD_FQDN>您可以查询。这实际上是一个 SRV 类型的记录。_gc.<your_site_name>._sites.<your_AD_FQDN>
GC 的 A 记录可用性是否相当标准？还是因环境而异？换句话说，是否有一些环境根本没有为 DC 发布内部 A 记录？
所有 DC 都会有 A 记录，它应该是自动注册的。但如果关闭了 NIC 的自动 DNS 注册，如果没有人手动执行此操作，则可能没有 A 记录。如果关闭此功能，AD 将被破坏。
这些特定记录是自动管理/更新的吗，还是由管理员手动添加/编辑的？
、、和区域是自动管理的。A 记录_sites也应该如此，只要有人没有对配置进行愚蠢的操作来关闭这些功能。_msdcs_tcp_udp