我熟悉 Active Directory 对 DNS 的依赖以及有关 Active Directory 命名中 DNS 的最佳实践（例如，使用专用于 AD 的公司域的子域）。不过，我对此有一个相当概念性的问题：
将 DNS 记录（实际上在任何地方）指向域控制器的必要性有多大？例如，假设我的网络拥有
example.com并且我正在考虑分配ad.example.com给域。由于域控制器是网络的权威 DNS 服务器，如果你调用它ad.example.com，即使没有为其添加 CNAME DNS 记录，域上的所有请求ad.example.com都将由域控制器正确完成 - 这并不重要如果没有外部请求。我错过了什么吗？添加 DNS 记录有什么区别，因为 DC 不应该从外部访问，无论如何？你能不做（功能上）就脱身吗？这个答案似乎暗示了这一点，但那里的 OP 也说他使用公共 DNS 记录。我知道每个人都在谴责它，但我在 AD 域方面的大部分经验是看到组织使用其根DNS 域作为 AD 域名（例如只是
example.com. 假设我也想走这条路（并且不会被劝阻），这样做时要采取的步骤/要考虑的事情是什么？我不断听到“冲突”，但不清楚这些冲突在什么意义上存在。是否只是对网站的请求example.com将转到域控制器本身，需要根据端口重定向请求？当您为 AD 重用根域时，处理这些冲突的“正确”方法是什么？
对于你的第一个问题，我不确定你在说什么。您是说您认为没有必要为您的域提供公共 DNS 记录吗？你是对的，从技术上讲，你没有。问题是，您的域命名空间应该在全球范围内是唯一的，如果它从属于您已经拥有的命名空间，那么您可以保证它是唯一的。如果您在稍后进行集成时拥有一个公共命名空间，这会让生活变得更加轻松
这个建议可以追溯到 Windows 2000 天，它仍然具有相关性。
对于第二个问题，如果您拥有命名空间，请不要，不要，将您的 AD 域放在该命名空间的根目录。始终、始终、始终为您的域创建从属命名空间。
您不希望域控制器暴露在 Internet 上。您将始终需要某种 DNS“垫片”来将您的域控制器与面向公众的 DNS 分开，在这种情况下，您不妨简单地将根命名空间托管在那里。
拥有一个单独的命名空间意味着您不会遇到保持脑裂 DNS有序的痛苦和痛苦。来自戴尔的链接很好地总结了您可能遇到的问题类型。
是的，有像 Infoblox “DNS Views” 这样的解决方案（甚至微软现在也提供类似的东西），但它也需要照顾和喂养。您需要熟练的人来正确设置和维护它。否则，根据戴尔的文章，如果您在没有这些额外好处的情况下为同一个命名空间拥有两个“权威”的不同系统，那么（它始终是 IME）可能会非常痛苦。
如果您在根命名空间中有 Web 服务，并且可能还有其他东西，例如用于批量电子邮件的其他命名空间（以使 SPF 更容易）或非 Windows 系统或几乎任何您可能希望与之共享命名空间的第三方服务，它是更好地保持您的域分开。如果您可能想要做这些事情（提示，如果它是任何描述的企业或公共组织，您将）。
这是通过默默无闻的一点点安全性。不多，可以肯定，但有一点。
从系统管理的角度来看，您的 DNS 委托和解析器要容易得多。您拥有根命名空间，并且该 DNS 服务器将下级域命名空间委托给对其具有权威性的 DC。任何域客户端都可以进行良好的安全 DNS 注册，根 DNS 仍然对根命名空间具有权威性。AD DNS 区域可以安全地设置为清除过时的记录，因为现代 Windows 客户端可以根据需要重新注册。当然，您仍然可以为您的服务器创建静态条目。
对于名称解析，DC 将其解析器配置为指向上游 DNS，对于外部和根区域名称解析，它对域和非域客户端都很好而且很干净。显然，您只允许您的内部非域客户端查询内部域名称空间，而不是外部客户端。
实际上，我还建议为内部非 Windows 主机设置一个单独的从属命名空间——它可以托管在上游 DNS 上，或者委托给 Windows DC，甚至是一个完全独立的 DNS 主机。或者，如果您只需要担心一些不错的现代 Linux，请将它们加入 AD 域，完成。
最后，自 2000 年以来我一直在管理 AD 域（以及之前的 NT 域），实际上我在域设计中遇到的第一个问题是它是否是在根命名空间中的裂脑 DNS 下完成的。可怕的“单一标签”域在域问题的排名中远远落后，因为它非常罕见。比这个根 AD 命名空间问题更罕见。
我现在支持这样的环境。该域有 1000 个帐户中的 10 个，自 2002 年以来一直存在。我们拥有数百个 Web 服务、云服务（多个云提供商）、第三方 SAAS 和 PAAS 集成、电话、具有不相交命名空间的外部域、Windows 和非 Windows环境中的非域系统——都与该根命名空间和/或内部 AD 交互。可怜的 DNS 设计权威和我实际上每个月都会出于某种原因花费数小时来处理它。有很多手动处理来解决它引起的问题。
另一种选择是注册一个完全不相交的命名空间，仅用于托管您的域，而所有公共内容都保留在主命名空间中。例如，为他们的公共命名空间注册一个 enterprise.com/.org 的实体，以及为他们的 Windows 域注册一个 enterprise.net.cc 或其他东西的实体。这很好，但是您需要额外的管理开销来注册 MXes 和 TXT 记录，并为您的不相交的命名空间创建自定义 UPN（可能）以与您的公共电子邮件地址/云服务等内容集成。可行，但要花更多的钱，而且工作并没有太多好处。而且您需要确保影子 IT 不会潜入使用“错误”的命名空间，然后突然之间它也必须可以公开访问。
TL; DR - 没有关于“正确”方法的好建议的原因是实际上没有正确且可管理的方法来做到这一点。将您的 AD 放在根命名空间中没有任何好处；如果有的话，会有很多缺点。
除非您在一个很小的环境中并且您并不真正关心您的 AD。在这种情况下，我实际上建议您根本不要打扰 AD，而直接转到Azure AD 基于云的身份。
当有其他 DNS 服务器对您拥有的域根具有权威性时，可以将子域用作林根，有时还可以管理开销。在异构环境中（使用 Linux、Solaris、其他使用 DNS 服务（例如 QIP（例如））的 Windows 服务器，您不想将其用于 Active Directory，因为您想要 AD 集成 DNS，这不是强制性的，但建议）在哪里您正在创建一个绿色字段 AD 设计，您专门为您的 DC 以及 DC 将管理的客户端和用户指定了一个域。在云世界中，您可以将根域添加到您的 UPN 后缀，因为您可能希望使用 GCP , Azure AD 服务。在 ADDNS 中，您为 AD 集成客户端和服务器的根域 DNS 创建存根。
冲突：我认为它更像是开销而不是冲突。我们在公共 DNS 中维护您的外部 DNS 记录，在您的私有 DNS/ADDNS 中维护内部记录。然后我们在 ADDNS/Private DNS 中使用 DNS 转发地址。特别是当您使用大量托管/云网站和应用程序时。