我们拥有组织的主域（带有 AD）example.com。过去，以前的管理员创建了其他几个区域 - 例如 dmn.com、lab.example.com、dmn-geo.com 等 - 以及子域和委托，所有这些都用于不同的工程组。我们现在的 DNS 有点乱。当然，当 example.com 工作站上的某人需要连接到任何其他区域/子域中的系统时，这会导致问题，反之亦然（部分原因是大多数区域/子域的区域传输和委托配置不正确）。
我们的生产 DNS 与 Active Directory 集成，但工程系统应该与 AD 隔离。
我们正在讨论重组 DNS 和整合所有这些不同条目的方法。我认为我们可以采取三种不同的方法：
- 创建一个新区域，即“dmn.eng”。这可以由 IT 部门使用我们的 DNS 服务器进行管理，也可以由工程部门使用其名称服务器进行管理。
- 创建一个新的委托人 eng.example.com，将工程 DNS 合并到该子域中，并让工程师管理委托人的名称服务器。
- 创建一个没有委派的新子域 eng.example.com，并自行管理该子域的 DNS。
我赞成创建一个委托子域，让工程师完全控制该子域内自己的 DNS 结构。这样做的好处是，如果他们的 DNS 不起作用，很可能不是我的错 ;)。但是，当某些东西不起作用时，责任仍然存在一些模糊性，需要与工程部门协调来设置、配置和管理。
如果我们不委派子域名，那么生产 IT 处理非生产 DNS 的工作量将大大增加（我们实际上已经做了很多工作）。这样做的好处是，我们可以完全控制所有 DNS，当出现问题时，毫无疑问应该由谁来负责修复。我们还可以添加委派，例如 geo.eng.example.com，以便在工程师需要时为他们提供更大的灵活性和控制力。
我确实不确定创建新区域 dmn.eng 的必要性或好处。
那么，对于这种情况，行业最佳实践和建议是什么？哪种解决方案最容易实施，并在工程和生产之间提供无缝名称解析？我可能忽略了每种解决方案的哪些潜在优势或缺陷？
补充一点信息，我们是一家相当大的制造公司。这些工程师从事研发、开发和质量保证工作。实验室通常有自己的子网或整个网络、DHCP 等。就组织和技术而言，他们就像一个自己的小世界。
我们希望为工程实验室和网络保持一定程度的网络隔离，以保护我们的生产环境（参考先前的问题关于将工程 DHCP 服务器添加为权威 AD DHCP 服务器的工程师 - 这不应该发生）。但是，实验室工作站上的用户需要访问我们生产网络中的资源，或者我们生产网络上工作站上的用户需要连接到实验室系统，这种情况发生的频率足以证明某种统一 DNS 的合理性。
现有的委托人已经有由工程部门管理的 DNS 服务器，但这些服务器所在的不同实验室的工程师之间没有通信，因此最常见的问题是子域之间的名称解析失败。由于这些委托服务器归工程师所有，我无法更正 NS 条目以让它们相互通信 - 因此非委托 DNS 的优势在于完全由 IT 部门拥有。但管理生产 DNS和工程部门的工作很令人头疼，尤其是工程部门每天都会更改 DNS。但正如 BigHomie 在他的回答中提到的，这可能意味着工程部门必须雇佣（或指定）一名真正的 DNS 管理员；而且我必须和这个人非常熟悉。
我不一定喜欢创建一个具有任意顶级域名或后缀的新区域的想法，但我们已经拥有 5 个具有任意名称的其他区域，因此合并为一个区域仍是一种改进。我确实知道其他公司确实为组织中的不同组设置了单独的顶级区域，所以我很好奇什么时候这样做合适，以及这种方法的优点/缺点是什么。
仅供参考，我在这家公司只工作了几个月，之前的 AD/DNS 管理员就离开了公司，所以我不知道为什么现有的 DNS 结构会存在。
答案1
在现今世界里，我不建议创建具有任意顶级域名的新区域，因为这些可能随时成为“官方 DNS”。
我个人更喜欢子域委派方案，因为它似乎适合您尝试做的事情。（合并但将控制权交给工程部门）
也许您甚至可以找到 MS DNS 的 Web 前端，工程人员可以在其中添加/删除记录，这样服务器本身仍然归生产 IT 所有，而“他们”管理的唯一东西就是 DNS 条目。
答案2
首先，确保你自己的您计划使用的 domain.tld (mit.edu)。即使它永远不会连接到互联网，那也不是重点。
拥有一个 DNS 层次结构有巨大的好处，至少有些与组织相匹配。我只见过有人在 IT 支持方面管理该部门时这样做。这是关于为 AD 目的设置单独的区域。Web 地址等是另一个主题，本文不适用于此。我没有或不知道任何针对 DNS 层次结构的硬性规定，我相信您的组织的需求会决定这一点。有些区域可能需要子域（eng.mit.edu），有些则不需要（例如 hr.mit.edu）。当然，应该只有一顶级域名以确保一致性。
话虽如此，是什么决定了部门是否需要子域名？如果这是用于工作站，他们是否有自己的 IT 支持，或者是否有能够管理此类系统的人员？如果没有，那么使用 DNS 区域来指定机器位于某个部门真的毫无意义，还有许多其他方法可以很好地完成这项工作。这些只是你必须问自己的问题。
我会重新评估每个区域并确定
如果它仍然相关。是否还有服务器或工作站指向该区域中的任何内容？
谁将管理新区域。毋庸置疑，区域必须迁移到您的新层次结构，但您是否只为该区域实现转发地址/名称服务器信息，或者您是否将积极管理该区域？
什么系统与 AD 是“隔离”的吗？这些不需要网络身份验证和/或管理吗？从 DNS 的角度来看，将它们分开的原因是什么？为了证实你的怀疑，这一切都是为了便于管理。如果工程需要那很多 DNS 管理，他们应该自己聘请 DNS 管理员。
根据您的更新添加信息，我个人会给他们自己的子域名eng.spacelysprockets.com和子网。它应该与网络的其余部分隔离开来，并允许适当的流量通过。如果他们想继续创建eng.eng.local或者eng.bikes您无法阻止他们，您也不应该被迫支持他们*。
如果他们表现良好，使用子区域并决定要断开lab.eng.spacelysprockets.com子网的一部分，那就由他们决定了。出于职业礼貌，你应该让你知道，这样你就可以分割流量，但并不是每个人都这么想。
为您的基础设施提供真正的域名将为您带来管理优势，您应该考虑它。
*你应该和将要你们是两码事，但我离题了。