我熟悉 Active Directory 对 DNS 的依赖以及有关 Active Directory 命名中 DNS 的最佳实践（例如，使用专用于 AD 的公司域的子域）。不过，我对此有一个相当概念性的问题：
DNS 记录（实际上在任何地方）指向域控制器有多必要？例如，假设我的网络拥有
example.com并且我正在考虑分配ad.example.com给域。由于域控制器是网络的权威 DNS 服务器，如果您调用它ad.example.com，即使没有为其添加 CNAME DNS 记录，域控制器也会正确满足域上的所有请求ad.example.com- 并且外部请求是否正确并不重要。我遗漏了什么吗？既然 DC 无论如何都不应该从外部访问，那么添加 DNS 记录有什么区别？您能不这样做吗（功能上）？这个答案似乎表明如此，但那里的 OP 也说他使用公共 DNS 记录。我知道每个人都谴责它，但我对 AD 域的大部分经验是看到组织使用他们的根DNS 域作为 AD 域名（例如
example.com）。假设我也想走这条路（并且不会被劝阻），那么在这样做时要采取哪些步骤/考虑哪些事情？我一直听说“冲突”，但不清楚这些冲突存在的意义。是否只是对网站的请求example.com会转到域控制器本身，它需要根据端口重定向请求？当您重用 AD 的根域时，处理这些冲突的“正确”方法是什么？
答案1
对于你的第一个问题，我不确定你的意思。你是说你认为没有必要为你的域名提供公共 DNS 记录吗？你说得对，你不需要，技术上问题是，你的域名空间应该是全球唯一的，如果它从属于你已经拥有的命名空间，那么你可以保证它是独一无二。如果你有一个公共命名空间，那么以后集成时就会轻松很多
这个建议可以追溯到 Windows 2000 时代，并且仍然适用。
对于你的第二个问题，如果你拥有一个命名空间，那么不要，不要，将您的 AD 域置于该命名空间的根目录。始终、始终、始终为您的域创建一个从属命名空间。
您不希望域控制器暴露在互联网上。您总是需要某种 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 命名空间问题少见得多。
我现在正在支持这样的环境。该域有数万个帐户，自 2002 年以来一直存在。我们有数百个 Web 服务、云服务（多个云提供商）、第三方 SAAS 和 PAAS 集成、电话、具有不相交命名空间的外部域、环境中的 Windows 和非 Windows 非域系统 - 所有这些都与该根命名空间和/或内部 AD 交互。可怜的 DNS 设计权威和我每个月都会因为这样或那样的原因而花费数小时为此烦恼。需要进行大量手动处理才能解决它引起的问题。
另一个选择是注册一个完全不相交的命名空间，仅用于托管您的域，而所有公共内容仍保留在主命名空间中。例如，实体为其公共命名空间注册 enterprise.com/.org，为其 Windows 域注册 enterprise.net.cc 或类似名称。这完全没问题，但您需要额外的管理开销，即注册 MX 和 TXT 记录，并为不相交的命名空间创建自定义 UPN（可能），以便与您的公共电子邮件地址/云服务等集成。可行，但需要多花一点钱和多做一点工作，而实际上并没有太多好处。而且您需要确保影子 IT 不会使用“错误”的命名空间潜入，然后突然它也必须公开访问。
TL;DR - 没有关于“正确”做法的好建议的原因是，实际上没有恰当的并且易于管理。将 AD 放在根命名空间中没有任何好处；如果放在那里，会有很多缺点。
除非你处在一个很小的环境中，而且你真的不在乎你的 AD。在这种情况下，我实际上建议你根本不要考虑 AD，直接去Azure AD 基于云的身份。
答案2
当有其他 DNS 服务器对您拥有的域根具有权威性时，可以使用子域作为林根，有时也用于管理开销。在异构环境中（对于 Linux、Solaris 和其他使用 DNS 服务（例如 QIP）的 Windows 服务器，您不会希望将其用于 Active Directory，因为您需要 AD 集成 DNS，虽然这不是强制性的，但建议使用) 您正在创建绿地 AD 设计，您专门为您的 DC 以及 DC 将管理的客户端和用户指定了一个域。在云世界中，您可以将根域添加到您的 UPN 后缀，因为您可能想要使用 GCP、Azure AD 服务。在 ADDNS 中，您可以为您的 AD 集成客户端和服务器的根域 DNS 创建一个存根。
冲突：我认为这更像是一种开销，而不是冲突。我们在公共 DNS 中维护您的外部 DNS 记录，在私有 DNS/ADDNS 中维护内部 DNS 记录。然后我们在 ADDNS/私有 DNS 中使用 DNS 转发地址。特别是当您使用大量托管/云网站和应用程序时。