エンジニアリングには独自のDNSゾーン、デリゲート、またはサブドメインが必要ですか？

組織のプライマリドメイン（ADを使用）example.comがあります。過去に、以前の管理者はdmn.com、lab.example.com、dmn-geo.comなどの他のいくつかのゾーンと、すべて異なるエンジニアリンググループ用のサブドメインとデリゲートを作成していました。私たちのDNSは今少し混乱しています。そしてもちろん、これはexample.comのワークステーションの誰かがこれらの他のゾーン/サブドメインのいずれか、またはその逆にシステムに接続する必要がある場合に問題を引き起こします（ゾーン転送と委任がそれらのほとんどのために適切に構成されていないため） 。

運用DNSはActive Directoryと統合されていますが、エンジニアリングシステムはADから分離する必要があります。

DNSを再編成し、これらのさまざまなエントリをすべて統合する方法について説明しています。私たちが取ることができる3つの異なる道を見る：

• 新しいゾーン、つまり「dmn.eng」を作成します。これは、DNSサーバーを使用してITによって管理されるか、ネームサーバーを使用してエンジニアリングされます。
• 新しいデリゲートeng.example.comを作成し、エンジニアリングDNSをそのサブドメインに統合し、エンジニアがデリゲートのネームサーバーを管理できるようにします。
• 委任なしで新しいサブドメインeng.example.comを作成し、サブドメインのDNSを自分で管理します。

デリゲートサブドメインを作成し、エンジニアがそのサブドメイン内の独自のDNS構造を完全に制御できるようにします。利点は、それらのDNSが機能しない場合、おそらく私のせいではないことです;）。ただし、何かが機能しない場合の責任についてはまだあいまいな部分があり、セットアップ、構成、および管理するためにエンジニアリングとの調整が必要になります。

サブドメインを委任しない場合、非実稼働DNSを処理する実稼働ITの作業が大幅に増えることを意味します（これは基本的に既に多くのことを行ってきました）。利点は、すべてのDNSを完全に制御できることであり、何かが機能しない場合は、それを修正することが誰の責任であるかについて疑いの余地はありません。また、geo.eng.example.comなどのデリゲートを追加して、エンジニアリングの柔軟性を高め、必要なときに制御できるようにすることもできます。

新しいゾーンdmn.engを作成することの必要性または利点について、私は本当に不確かです。

このような状況に対する業界のベストプラクティスと推奨事項は何ですか？エンジニアリングと生産の間でシームレスな名前解決を実装し、提供するのに最も簡単なソリューションは何でしょうか？欠けている可能性のある各ソリューションの潜在的な利点または落とし穴は何ですか？

もう少し情報を追加するために、私たちはかなり大きな製造会社です。これらのエンジニアは、R＆D、開発、およびQAで働いています。ラボには、しばしば独自のサブネットまたはネットワーク全体、DHCPなどがあります。組織とテクノロジーに関しては、ラボは独自の小さな世界のようなものです。

実稼働環境を保護するために、エンジニアリングラボとネットワークのネットワーク分離をある程度維持したいと考えています（エンジニアリングDHCPサーバーを信頼できるAD DHCPサーバーとして追加したエンジニアに関する以前の質問を参照してください）。ただし、ラボのワークステーションのユーザーは、本番ネットワークのリソースにアクセスする必要があります。または、本番ネットワークのワークステーションのユーザーは、ラボシステムに接続する必要があり、これはソートを正当化するのに十分な頻度で発生します-統合DNS

既存のデリゲートには、エンジニアリングによって管理されたDNSサーバーが既にありますが、これらのサーバーがセットアップされている異なるラボのエンジニア間の通信はないため、最も一般的な問題はサブドメイン間の名前解決の失敗です。エンジニアがこれらのデリゲートサーバーを所有しているため、NSエントリを修正して相互に通信させることはできません。したがって、ITが完全に所有する非委任DNSの利点です。しかし、生産とエンジニアリングのためにDNSを管理することは頭痛の種です。特に、エンジニアリングは毎日DNSを変更できるためです。しかし、BigHomieが答えで述べたように、これはおそらく、エンジニアリングが実際のDNS管理者を雇う（または指定する）必要があることを意味します。そしてその人と私はかなりよく知り合う必要があります。

任意のトップレベルドメイン名またはサフィックスを持つ新しいゾーンを作成するという考えは必ずしも好きではありませんが、すでに任意の名前を持つ5つのゾーンがありますので、単一のゾーンに統合することは依然として改善です。組織内のさまざまなグループに個別のトップレベルゾーンを持つ他の企業が存在することを知っているので、それが適切なタイミングとそのアプローチの長所/短所について興味があります。

参考までに、私はこの会社に数か月しか滞在していなかったため、前のAD / DNS管理者が会社を辞めたため、既存のDNS構造が存在する理由について言及することはできません。

今日の世界では、任意のトップレベルドメインを持つ新しいゾーンを作成することはお勧めしません。これらのドメインはいつでも「公式のDNS」になる可能性があるためです。

個人的には、サブドメインの委任シナリオを好むでしょう。これは、あなたがやろうとしていることと合致しているようです。（統合しますが、エンジニアリングを制御します）

おそらく、エンジニアリングがレコードを追加/削除できるMS DNSのWebフロントエンドを見つけることもできます。そのため、サーバー自体はまだ運用ITによって所有されており、「それら」が管理するのはDNSエントリだけです。

何よりもまず、使用する予定のdomain.tldを所有していることを確認してください（mit.edu）。これが決してインターネットに接続しないとしても、それはポイントではありません。

組織と少なくともある程度一致するdnsの階層構造を持つことには大きな利点があります。ITサポートの観点からその部門を管理する人/人がいる場合にのみ、これが行われるのを見てきました。これは、ADの目的で個別のゾーンを使用することに関するものです。Webアドレスなどは別のトピックであり、これは当てはまりません。DNS階層の厳格なルールはありませんし、知りません。あなたの組織のニーズがそれを決定すると信じています。一部のゾーンにはサブドメイン（eng.mit.edu）が必要な場合と、そうでないゾーン（hr.mit.eduなど）があります。もちろん、一貫性を保つためにトップレベルドメインは1つだけにする必要があります。

そうは言っても、deptがサブドメインを必要とするかどうかを決定するものは何ですか？これがワークステーション用である場合、独自のITサポートを持っていますか、それともそのようなシステムを管理できる人ですか？そうでない場合、マシンが特定の部門にあることを指定するためにdnsゾーンを使用することは実際には意味がありません。これらは、あなた自身に問いかけるだけの質問です。

各ゾーンを再評価して決定します

1. それでも関連がある場合。まだそのゾーン内の何かを指しているサーバーまたはワークステーションがありますか？

2. 新しいゾーンの管理者。ゾーンを新しい階層に移行する必要があることは言うまでもありませんが、ゾーンの転送アドレス/ネームサーバー情報を実装するだけですか、それとも積極的にゾーンを管理しますか？

どのシステムがADから「分離」されていますか？これらはネットワーク認証や管理を必要としませんか？DNSの観点からそれらを分離する理由は何ですか？疑いを確認するために、管理のしやすさがすべてです。エンジニアリングでそれほど多くのDNS管理が必要な場合は、DNS管理者になる必要があります。

更新に基づいて情報を追加するには、個人的にサブドメイン、、eng.spacelysprockets.comおよびサブネットも提供します。適切なトラフィックが通過できるように、ネットワークの他の部分からファイアウォールで保護する必要があります。彼らが立ち去って作成したい場合、eng.eng.localまたはeng.bikesあなたがそれらを止めることができない場合、またはあなたはそれをサポートすることを強制されるべきではありません*。

彼らがうまくプレイしている場合、サブゾーンを使用してlab.eng.spacelysprockets.com、サブネットとサブネットの一部を分割することを決定します。そのトラフィックもセグメント化できるように知らせるのはおそらく専門的な礼儀でしょうが、誰もがそのように考えているわけではありません。

インフラストラクチャの実際のドメイン名は、管理上非常に有利になるため、考慮する必要があります。

*万一、あなたとなり、あなたは二つの異なるものですが、私は話を戻そう。