Microsoft AD統合DNSからInfobloxへの移行

Question

2つのドメインコントローラーと統合DNSを備えたADドメインがあります。マスターDNSとしてInfobloxに移行しているため、既存のゾーンをInfobloxに移行し、コントローラーがADゾーンの動的DNS更新を実行できるようにすることがアイデアです。安全にそれを行うための最善の行動方針は何ですか？

Ryan Bolger · Answer

まず、Infobloxプロフェッショナルサービスがこのプロセスを喜んでお手伝いします（ただし、お客様が喜んで支払うかどうかは分からない費用ですが）。

いずれにせよ、これは私が過去にうまく使用した高レベルの概要です。（注：グリッドトポロジがどのようなものであるかについては言及しなかったため、ADゾーンをホストする専用のグリッドメンバーが少なくとも2つあると仮定します。以下の概要では、グリッド内のすべてのメンバーではなく、それらの特定のグリッドメンバーのみを参照していると想定しています。）

準備作業（影響を受けるクライアントなし）

ゾーンをホストしているグリッドメンバーでDNSサービスを有効にします（まだ有効になっていない場合）。
ADのグリッドメンバーごとに GSS-TSIG アカウントおよび関連するキータブファイルを作成します。
キータブをグリッドにインポートして、関連するグリッドメンバーに割り当てます。
各メンバーのDNSプロパティでGSS-TSIG更新を有効にします（UpdatesタブではなくGSS-TSIG詳細タブ）。
ADゾーンに適切なネームサーバーグループを作成します。
- それらがDCのように動作し、それぞれがゾーンのプライマリネームサーバーとして自分自身で応答するようにするには、各ネームサーバーをグリッドプライマリにします。それ以外の場合は、標準グリッドのプライマリと1つ以上のセカンダリで問題ありません。
AD DCがクライアントの再帰リゾルバーである場合は、DNSビューまたはメンバーレベルで再帰が適切に有効になっていることを確認してください。
グリッドメンバーへのゾーン転送を許可するようにDCを構成します。
（オプション）DNSのDCをクライアントにポイントするDHCPサーバーがある場合は、リース時間を短くして、後で変更を加えたときに、より迅速に適用されるようにします。

プライマリDNSカットオーバー

各ゾーンについて（リバースゾーンを忘れないでください）：
- 空の権限のあるゾーンを作成し、それをネームサーバーグループに割り当てます。
- 必要に応じて、ゾーンのプロパティでAllow GSS-TSIG signed updatesを有効にします。 GSS-TSIGが機能している場合は、IPベースのACLは必要ありません。
- 必要に応じて、ゾーンのプロパティでAutomatically create underscore zonesおよびAllow GSS-TSIG-signed updates to underscore zonesを有効にします。 DCからの署名されていない更新を許可する必要はありません。
- ゾーンを選択した状態で、ツールバーのImport Zoneをクリックして、いずれかのDCからゾーンを1回だけ転送します。通常、関連するレコードを自動変換/作成するオプションを有効にしません。
- Digまたはnslookupを使用して、グリッドメンバーに対してインポートしたものを解決できることを確認します。特に、複数のグリッドプライマリを使用している場合は、各メンバーに対してSOAを照会すると、それ自体がプライマリとして返されることを確認してください。
- GUIで、インポートされたレコードのほとんどが「動的」ではなく「静的」であることに気付くでしょう。これは、時間が経過すると動的に再登録されるため、変化します。
グリッドメンバーをフォワーダーとして使用するようにDCを構成します。 これにより、DNSのDCを使用しているすべてのユーザーが、ゾーンが最終的にDCから削除されても、問題を適切に解決できます。
DCのTCP/IPプロパティでDNS構成を更新して、適切なグリッドメンバーを指すようにします。
- DCのA/PTRレコードを再登録するには、ipconfig /registerdns
- Netlogonサービスを再起動して、ADにドメイン関連のSRVレコードをすべて再登録させます。
- DCイベントログで登録エラーを確認する
- Infoblox syslogを確認することもできます。エラーが発生しても慌てないでください。 Windowsは、GSS-TSIGで再試行する前に、常に署名されていない更新を試みます。したがって、ログには更新の失敗が表示され、その後に更新の成功が表示されます。
- dcdiag /test:dnsもあなたの友達です。
- 別の肯定的な兆候は、Infoblox GUIでDC関連レコードが「静的」から「動的」に変換されることを確認しています。

この時点では、ロールバックはまだかなり簡単です。再指摘されたのはDCだけです。ただし、DCがレコードを動的に登録でき、グリッドメンバーに対してクエリを正常に実行できる限り、続行しても問題ありません。

DNSのDCをクライアントにポイントするDHCPサーバーがある場合、代わりに適切なグリッドメンバーをポイントするようにサーバーを更新します。リース時間がかなり短い場合は、一部のクライアントレコードが「静的」から「動的」に変化し始めるのがすぐにわかります。

この時点で、ノーリターンのポイントに到達しました。DCからゾーンを削除し始めます。 （ゾーンを回復することは明らかに不可能ではありません。しかし、メンテナンスウィンドウで強制的に実行させたくないので、面倒です。）転送を正しく構成した場合、ゾーンが削除された後も、DNSのDCを引き続きポイントすることで、問題を適切に解決できます。ただし、DCは、それがそこにある限り、独自のコピーを返すだけなので、ゾーンがなくなるまでは、本当に確信が持てません。

各ゾーンについて（リバースゾーンを忘れず、重要度の低いゾーンまたはAD固有でないゾーンを最初に優先する）：
- ADからゾーンを削除し、変更が複製されるのを待ちます
- DCのDNSキャッシュをクリアし、適切な方法でDNSサービスを再起動します。
- DCに対してゾーンのSOAクエリをテストします。そのゾーンのInfobloxに表示されるのと同じシリアルを返します。それが古いものである場合、DC =独自の古いキャッシュコピーがまだ返されている可能性があります。キャッシュされた結果が表示された場合は、DNSサービスキャッシュをクリアしてみてください。DCとクライアントでipconfig /flushdnsを試してください。

完了すると、DCにはゾーンがなくなり、サーバーを効果的にキャッシュします。残っているのは、静的DNS構成を持つ残りのホストを見つけて、グリッドメンバーに再度ポイントすることだけです。

DNSにDCを使用しようとしているクライアントがなくなったことを確認したら、クライアントのDNSロールを停止して削除できます。