![セキュアなダイナミックDNSとDHCPの難問](https://rvso.com/image/697385/%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2%E3%81%AA%E3%83%80%E3%82%A4%E3%83%8A%E3%83%9F%E3%83%83%E3%82%AFDNS%E3%81%A8DHCP%E3%81%AE%E9%9B%A3%E5%95%8F.png)
ベストプラクティスのアプローチについての意見を求めています。
- 現在、安全な動的 DNS 更新が無効になっている AD ドメインがあります (つまり、どのクライアントでも DNS レコードを更新できます)。これを変更したいと思います。
- 50 以上のリモート サイト (MPLS で接続され、それぞれにインターネット回線もあります) -- ローカル DHCP サーバー (Windows) を備えたサイトもあれば、Cisco スイッチで実行される DHCP を備えたサイトもあります。ローカル IT スタッフがいるサイトは、約 30 ~ 40% のみです。
- 一部のクライアントは DNS に AD を指定していますが (ほとんどのサイトには AD サーバーがありません)、他のクライアントは BIND リゾルバーを指定しています。ローカル サイトで BIND リゾルバーに多くを移行して、サイトのインターネット回線からインターネット解決を処理し、SaaS アプリと RPZ の最適な位置情報とパフォーマンスを実現します。パフォーマンスと回復力のために、AD ゾーンを BIND サーバーに従属させます。ただし、クライアントが BIND を指定している場合、当然、動的 DNS 更新は機能しません。
私たちは、標準化し、可能な限り安全に保つよう努めています。オプションを検討しています:
- AD でセキュア DNS 更新を有効にし、DHCP サーバーがクライアントに代わって DNS 名の更新を処理するようにします。誰でもオプション 81 ヘッダーを使用して DHCP 要求を送信できるため、セキュリティ上の価値は追加されないようです。また、Cisco デバイスがダイナミック DNS を安全に更新できるかどうかはわかりません (例: Kerberos を使用)。おそらくできないでしょう。
- #1 と似ていますが、更新にのみ MS DHCP を使用します (この場合、サイトにサーバー インフラストラクチャがない場合、DHCP は必ずしもオフィスにローカルである必要はありません)。
- 各サイトに AD サーバーを設置し、クライアントがプライマリ DNS (および DHCP) に使用できるようにし (クライアントからの安全な DNS 更新を直接処理します)、インターネット検索用の BIND サーバーも設置します。
- 3 番と同じですが、AD は内部とインターネットの両方を実行します。ただし、BIND ビューをかなり頻繁に使用するため、Server 2016 (現在は 2012) に移行しない限り、これが可能かどうかはわかりません。
中規模から大規模の組織に勤める皆さんは、どのようなことをしているのでしょうか?
答え1
私の 1000 を超える拠点ネットワークでは、明らかなコスト上の理由から、各拠点に AD DC を設置することをかなり前に断念しました。ネットワークがダウンすると、AD の有無にかかわらず、ユーザーはいずれにしても作業を完了できないという事実は言うまでもありません (産業システムは個別に処理されます)。DHCP/DNS にはさまざまなアプローチがありますが、主なものは次のとおりです。
- 専用アプライアンス (基本的に ISC DHCP と BIND をラップ) 上の集中 DHCP。これらは、特定のサービス アカウントを使用して、オプション 81 から AD DNS サーバーへの動的 DNS 更新を処理します。世界の他の地域では、これは依然として MS DHCP を使用して処理されています。DNS で動的に更新される名前を特に信頼しているわけではありませんが、これまではそれ以上のステップを踏む必要性を感じていません。これは、管理されていないデバイスがそもそもネットワークに接続できないように、ネットワークの境界セキュリティを大幅に強化する必要がある可能性が高いためです。
- データセンターと最大のユーザー拠点で利用可能なADドメインコントローラ上の内部DNS
- パブリック名解決専用のアプライアンス
- すべてのクライアントは AD DNS を指し、そこから外部ドメインのアプライアンスに転送されます。ここでは高度な機能はあまりありません。
この設定の主な問題は、パブリック リゾルバが 3 つのメイン データセンターにしか存在しないため、地理位置情報が機能しないことです。ほとんどのブラウザー リクエストは DNS を処理するクラウド フィルタリング サービスを通じてプロキシされるため、通常は大きな問題にはなりませんが、最近では、適切なデータセンターを選択するために正確な地理情報が必要となるビデオ サービス (Google Hangouts など) を使用する際に事態が複雑になっています。