web-dev-qa-db-ja.com

内部DNSサーバーとしてのドメインコントローラー

私たちの会社の環境は急速に成長しており、現在ドメインコントローラーのアップグレードを進めていますが、その前に簡単なサニティチェックを行い、可能な限り最善を尽くしているかどうかを確認したいと思いました。

プライマリHQサイトに注目すると、3つのドメインコントローラー(2つは仮想、1つは物理)があり、すべてWindows Server 2008 R2を実行しています。 Windows Server 2012 R2に移行したい。私はWindowsの「アップグレード」を信じていません。サーバーや環境をアップグレードの成果物から解放するために、常に「移行」を好みます。

2つの仮想DCは、すべてのワークステーションとメンバーサーバーにすべてのDNSサービスを提供します。ワークステーションはDHCPオプションを通じてDNSアドレスを取得しますが、すべてのメンバーサーバーは静的に構成されたDNSサーバーIPを持っています。

質問:すべてのワークステーションとサーバーのDNSリゾルバーとしてドメインコントローラーを使用するのは通常ですか、それとも新しい専用DNSサーバーを作成する必要がありますか?

質問:ワークステーションとサーバーのドメインコントローラーの実際のIPをDNSリゾルバーに使用することは良い習慣ですか、それとも仮想IP /負荷分散を使用する必要がありますか?

4

すべてのワークステーションとサーバーのDNSリゾルバーとしてドメインコントローラーを使用するのはまだ普通ですか、それとも新しい専用DNSサーバーを作成する必要がありますか?

私の会社には2000以上のクライアントと4つのドメインコントローラがあります。そのうちの2つもDNSサーバーとして機能しており、4年間問題はありません。

ワークステーションとサーバーのドメインコントローラーの実際のIPをDNSリゾルバーに使用することは良い方法ですか、それとも仮想IP /負荷分散を使用する必要がありますか?

繰り返しになりますが、2000以上のクライアントの場合、問題なく実際のDNSリゾルバーIPを使用します。

私はこれらのメトリックを一種の「参照」として提供します。クライアントの数によっては、DNSの負荷が高くなり、私のトポロジーが適用されない場合があります...しかし、DC + DNSを使用すると安全に移動できます

Microsoftによると、

ほとんどの場合、すべてのドメインコントローラにDNSサーバーをインストールします

ただし、ここで記事全体を読むことができます

5
krisFR

DCをDNSサーバーとして使用することは非常に合理的です。また、非常に多くのものと直接通信する必要があるため、それらを実際に非表示にすることはできません。

DNSサーバーとしてそれらを使用したくない唯一の理由は、DNSの負荷が高すぎて、多くのクエリが同じ名前に対するものである場合です。この時点で、キャッシュする中間リゾルバーを使用します。または、BINDのようなサービスをより適切に提供するために、DNSで豪華なことをしたい場合。後で変更する必要がある場合は、いつでもDNSオプションを変更できます。ドメインコントローラーが3つ以上ある場合は、各サブネットのDNSサーバーを変更して、負荷のバランスをとることもできます。

このようなDCを使用することによるセキュリティリスクはほとんどゼロです。

4
Falcon Momot

私はデータポイントとして、金融サービス業界のフォーチュン200で働いており、約1年間、企業のDNSホストマスターを務めていました。組み込みのMicrosoft DNSソリューション(およびSOAのリゾルバーアドレスとネームサーバーをIPエニーキャストするためのF5 LTM)を使用していましたが、これは機能しましたが、私たちの目的には最適ではないと判断しました。

好意のポイント

  • Active Directoryの一部として無料
  • 基本的な使用には十分に機能します
  • DHCPクライアントのDNSレコードの自動登録(クライアントがWindowsクライアントの場合、Mac、Linux、SunOSの場合はそれほど多くありません)

さらに必要な理由

  • 許容できるようにするために、仕様に厳密に準拠していないため、不正確または不可能な情報(zone-apexでのCNAMEを含む)が許可されています。これには、承認されていないRFCが提案されていましたが、どちらかに空白があるレコードがはるかに悪いレコード名または応答値。これは、BINDベースのすべてのことで地獄を混乱させます)
  • 関連付けられたA、TXT、SRV、PTRレコードの同期を維持するメカニズムは十分ではなく、手動で調整するのにかなりの時間を費やしました
  • 統合DHCPデーモンはHAにスプリットスコープを必要としました。つまり、障害状態では、標準トラック(およびISCベースのソリューションで使用)ではなく、利用可能なプールの半分が失われますDHCPフェイルオーバー( https:/ /kb.isc.org/article/AA-00502/0/A-Basic-Guide-to-Configuring-DHCP-Failover.html
  • PTRレコードに基づいてIPの枯渇/可用性/密度を簡単に視覚化する標準のメカニズムはありませんでした

上位層の統合されたDHCP + DNS + IPAMソリューションの実装を完了し、振り返ることはありません(動的なゾーン同期とIPエニーキャストの実行を含む)。

もちろん、注意点があります。SRVレコードの登録がActive Directoryサービスの検出で機能し、Windows Cluster Serverのレコードの登録と登録解除が機能するためです。すべてのドメインコントローラとMS Cluster Serverボックスを含むACLを作成し、それらが動的DNS更新を実行できるようにする必要があります。データの整合性と健全性を保証するには、他のすべてのホストと他のすべてのレコードについて、DHCPデーモンまたはGUI/APIを介してのみ更新することを許可する必要があります(つまり、ホワイトリストにないすべてのボックスの動的DNS更新とAXFRを許可しません) )。

1
DTK