エンジニアリングには独自のDNSゾーン、委任、またはサブドメインがあるべきですか？
組織のプライマリドメイン（ADを含む）example.comがあります。以前は、以前の管理者がdmn.com、lab.example.com、dmn-geo.comなどの他のいくつかのゾーン、およびサブドメインとデリゲートを作成しており、それらはすべて異なるエンジニアリンググループ用です。現在のDNSは少し混乱しています。そしてもちろん、これはexample.comのワークステーションの誰かがこれらの他のゾーン/サブドメインのいずれかでシステムに接続する必要がある場合、またはその逆の場合に問題を引き起こします（一部、ゾーン転送と委任がそれらのほとんどに対して適切に構成されていないため） 。
当社の本番DNSはActiveDirectoryと統合されていますが、エンジニアリングシステムは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サーバーを信頼できるADDHCPサーバーとして追加したエンジニアについて-そうすべきではありません発生する可能性があります）。ただし、ラボのワークステーションのユーザーは本番ネットワークのリソースにアクセスする必要があります。または、本番ネットワークのワークステーションのユーザーはラボシステムに接続する必要があります。これは、並べ替えを正当化するのに十分な頻度で発生します。 -統合DNSの。
既存のデリゲートには既にエンジニアリングによって管理されているDNSサーバーがありますが、これらのサーバーが設定されている異なるラボのエンジニア間には通信がないため、最も一般的な問題はサブドメイン間の名前解決の失敗です。エンジニアがこれらのデリゲートサーバーを所有しているため、NSエントリを修正して、それらを相互に通信させることはできません。したがって、ITが完全に所有する非委任DNSの利点です。プロダクションおよびエンジニアリングは、特にエンジニアリングがDNSを毎日変更できるため、頭痛の種です。しかし、BigHomieが彼の回答で述べたように、これはおそらくエンジニアリングが実際のDNS管理者を雇う（または指定する）必要があり、その人と私はかなりよく知り合う必要があります。
私は、任意のトップレベルドメイン名またはサフィックスを使用して新しいゾーンを作成するという考えも必ずしも好きではありませんが、すでに任意の名前の5つのゾーンがあるので、単一のゾーンに統合することは依然として改善です。組織内のさまざまなグループに個別のトップレベルゾーンを持っている他の企業が存在することは知っています。そのため、それが適切な時期と、そのアプローチの利点/欠点について知りたいです。
ちなみに、私はこの会社に数か月しか在籍しておらず、以前のAD/DNS管理者が会社を辞めたため、既存のDNS構造が存在する理由について言及する必要はありません。
今日の世界では、任意のトップレベルドメインで新しいゾーンを作成することはお勧めしませんこれらはいつでも「公式DNS」になる可能性があるためです。
私は個人的にサブドメイン委任シナリオを好みます。それはあなたがやろうとしていることに合っているように思われるからです。 （統合しますが、エンジニアリングを制御します）
エンジニアリングがレコードを追加/削除できるMSDNSのWebフロントエンドを見つけることもできるかもしれません。そのため、サーバー自体は引き続き実稼働ITによって所有され、「それら」が管理するのはDNSエントリだけです。
何よりもまず、使用する予定のdomain.tld（mit.edu）を所有していることを確認してください。これがインターネットに接続しない場合でも、それは重要ではありません。
少なくともある程度組織と一致するDNSの階層を持つことには大きな利点があります。これが行われるのは、ITサポートの観点からその部門を管理する人がいる場合のみです。これは、ADの目的のために別々のゾーンを持つことに関するものです。 Webアドレスなどは別のトピックであり、これは適用されません。私はDNS階層の厳格なルールを持っていないか、知りません。あなたの組織のニーズがそれを決定すると信じています。一部のゾーンにはサブドメイン（eng.mit.edu）が必要な場合と、不要なもの（hr.mit.eduなど）があります。もちろん、一貫性を保つために、oneトップレベルドメインのみが存在する必要があります。
そうは言っても、部門がサブドメインを必要とするかどうかは何によって決まりますか？これがワークステーション用である場合、彼らは独自のITサポートを持っていますか、それともそのようなシステムを管理できる人がいますか？そうでない場合は、dnsゾーンを使用してマシンが特定の部門にあることを指定しても意味がありません。他の多くの方法でジョブを正常に実行できます。これらはあなたが自分自身に尋ねなければならないだけの質問です。
各ゾーンを再評価して決定します
それでも関連性がある場合。そのゾーン内の何かをまだ指しているサーバーまたはワークステーションはありますか？
新しいゾーンを誰が管理するのか。言うまでもなく、ゾーンは新しい階層に移行する必要がありますが、ゾーンの転送アドレス/ネームサーバー情報を実装するだけですか、それともアクティブにゾーンを管理しますか ？
どのシステムがADから「分離」されていますか？これらはネットワーク認証や管理を必要としませんか？ DNSの観点からそれらを分離する理由は何ですか？あなたの疑惑を確認するために、それはすべて管理のしやすさについてです。エンジニアリングが必要な場合それ多くのDNS管理が必要な場合は、DNS管理者になる必要があります。
更新に基づいて情報を追加するために、私は個人的に独自のサブドメインeng.spacelysprockets.comとサブネットも提供します。適切なトラフィックが通過できるように、ネットワークの他の部分からファイアウォールで保護する必要があります。彼らが立ち去ってeng.eng.localまたはeng.bikesを作成したい場合、彼らを止めることはできませんし、それをサポートすることを強制されるべきでもありません*。
彼らがニースをプレイする場合は、サブゾーンを使用して、lab.eng.spacelysprockets.comとサブネットの一部を分割することを決定します。トラフィックをセグメント化できるように、それを通知することは、おそらく専門的な礼儀であるべきですが、誰もがそのように考えているわけではありません。
インフラストラクチャの実際のドメイン名は、管理に真剣に有利になるため、検討する必要があります。
*あなたとあなたはあなたは2つの異なるものである必要がありますが、私は余談です。