工程是否应该拥有自己的 DNS 区域、委托或子域？

Question

我们有我们组织的主域（带有 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 条目以使它们相互通信 - 因此具有 IT 完全拥有的非委托 DNS 的优势。但是为生产和工程管理 DNS是一件令人头疼的事，尤其是因为工程每天都会更改 DNS。但是正如 BigHomie 在他的回答中提到的，这可能意味着工程将不得不雇用（或指定）一个真正的 DNS 管理员；那个人和我必须相当熟悉。

我也不一定喜欢创建具有任意顶级域名或后缀的新区域的想法，但是我们已经有 5 个其他具有任意名称的区域，因此合并为一个区域仍然是一种改进。我确实知道存在其他公司，它们确实为组织中的不同群体设置了单独的顶级区域，所以我很好奇什么时候合适，以及这种方法的优点/缺点是什么。

仅供参考，我只在这家公司工作了几个月，之前的 AD/DNS 管理员离开了公司，所以我没有任何可参考的任何现有 DNS 结构存在的原因。

Answer 1

在当今世界，我不建议创建具有任意顶级域的新区域，因为它们可能会在任何时候成为“官方 dns”。

我个人更喜欢子域委托方案，因为它似乎适合您尝试做的事情。（合并但控制工程）

也许您甚至可以找到一个用于 MS DNS 的 Web 前端，工程师可以在其中添加/删除记录，以便服务器本身仍由生产 IT 拥有，而“他们”管理的唯一内容就是 DNS 条目。

Answer 2

首先，确保您拥有计划使用的 domain.tld (mit.edu)。即使这永远不会连接到互联网，那也不是重点。

拥有至少在某种程度上与组织相匹配的dns 层次结构有巨大的好处。我只看到有人/人员在 IT 支持方面管理该部门时才会这样做。这是关于为了 AD 目的而拥有单独的区域。网址等是一个单独的主题，这不适用于那个。我没有或不知道任何关于 dns 层次结构的硬性规则，我相信您的组织的需求会决定这一点。有些区域可能需要子域（eng.mit.edu），而有些则不需要（例如 hr.mit.edu）。当然，为了一致性，应该只有一个顶级域。

话虽如此，是什么决定了部门是否需要子域？如果这是针对工作站，他们是否有自己的 IT 支持，或有能力管理此类系统的人员？如果没有，那么使用 dns 区域来指定机器在某个部门中真的没有意义，还有许多其他方法可以很好地完成这项工作。这些只是你需要问自己的问题。

我会重新评估每个区域并确定

1. 如果它仍然相关。是否仍有服务器或工作站指向该区域中的任何内容？

2. 谁将管理新区域。毋庸置疑，该区域必须迁移到您的新层次结构，但是您只是为该区域实施转发地址/名称服务器信息，还是会主动管理该区域？

哪些系统与 AD“隔离”？这些不需要网络身份验证和/或管理吗？从 DNS 的角度将它们分开的原因是什么？为了证实您的怀疑，一切都与易于管理有关。如果工程需要那么多 dns 管理，他们应该让自己成为 DNS 管理员。

要根据您的更新添加信息，我个人也会给他们自己的子域eng.spacelysprockets.com、 和子网。它应该被防火墙与网络的其余部分隔离，并允许适当的流量通过。如果他们想离开并创造，eng.eng.local或者eng.bikes您无法阻止他们，您也不应该被迫支持*。

如果他们玩得很好，请使用子区域并决定要中断lab.eng.spacelysprockets.com和子网的一部分，那就在他们身上。让您知道可能应该是专业的礼貌，以便您也可以细分流量，但每个人都不会这么想。

您的基础设施的真正域名会严重给您带来管理优势，您应该考虑一下。

*你是否应该和会你是两个不同的东西，但我离题。