クラウド環境とオンプレ環境を連携させる際、相互のActive Directoryフォレスト間でホスト名を解決できない問題は意外と発生しやすいものです。特にAWSのAD環境とオンプレ環境が分離して存在する場合、名前解決が片方向にしか働かないと運用面で大きな障害となります。そこで本記事では、DNSを活用して両者の環境をシームレスにつなぐためのポイントや設定例を詳しく解説します。
AWSとオンプレのフォレスト間で起きるDNSの課題
AWS上で独自のActive Directoryフォレストを構築し、オンプレミスにも別のフォレストが存在するケースは多いです。通常、このような構成ではAWS側のホスト名はAWSのDNSサーバーで解決可能ですが、オンプレ側のクライアントがAWS側のホスト名を問い合わせても応答が得られない状況に陥りがちです。これは単にDNSサーバーが異なるドメインに関する情報を保持していない、または適切な転送設定が行われていないことが主な要因です。
問題の背景
- AWS環境とオンプレ環境が別々のDNSサーバーを運用
それぞれが独立したDNSゾーンやフォレストを管理し、相互に名前解決のルートが用意されていない。 - ファイアウォールやセキュリティ設定でDNSクエリがブロック
UDP/TCPの53番ポートが制限されている場合、DNSクエリが届かずタイムアウトしてしまう。 - 条件付きフォワーダーやスタブゾーンなどの設定不足
Windows Server DNSの機能を正しく利用しなければ、相手フォレストのレコードを取得できない。
なぜDNSフォワーディングが必要になるのか
通常、DNSサーバーは自分が管理するドメイン名に対する問い合わせのみ応答し、管理外のドメイン名に対しては上位(ルートヒント)やフォワーダーへリクエストを転送します。AWS環境で運用しているドメインはインターネット上に公開されていないプライベートドメインであることも多く、オンプレ環境では一般的なインターネットDNSサーバーに問い合わせても名前解決が成功しません。こうしたケースでは「AWSのドメインに関する問い合わせはAWSのDNSへ投げる」という転送先を明示的に教えてやる必要があります。
DNSの基礎とフォレスト間解決の仕組み
異なるフォレスト間でDNS解決を可能にするには、いくつかの方法があります。その前に、DNSの基本的な動作やサーバーの役割を再確認しておきましょう。
DNS問い合わせフローの基本
- クライアントがホスト名を問い合わせる
- ローカルキャッシュを参照
- キャッシュになければDNSサーバーへ問い合わせ
- DNSサーバーは自分が管理しているドメインなら自分のゾーン情報を確認
- 管理外のドメインならフォワーダーまたはルートヒントへ問い合わせ
- 応答が帰ってきたらクライアントへ返す
このフローにおいて、AWS側のドメイン(AWSフォレスト)に関するレコードをオンプレDNSが知っているか否かが最大のポイントです。知らなければ、フォワーダー設定やゾーン転送設定がない限りは永遠に「名前解決できない」ままとなります。
DNSサーバーの種類と役割
- プライマリゾーン(Primary Zone):
レコードの作成や更新が行われる正規のマスターゾーン。Active Directory統合ゾーンであればADレプリケーションを通じて複数DNSサーバー間でレコードの同期も可能。 - セカンダリゾーン(Secondary Zone):
プライマリゾーンのレコードを丸ごと複製し、読み取り専用で保持するゾーン。ゾーン転送が必要になる。 - スタブゾーン(Stub Zone):
主要なDNSサーバー情報(NSレコードなど)のみを複製し、本来のDNSサーバーへの問い合わせ窓口として機能するゾーン。小規模かつトラフィックを抑えたい場合などに利用。 - 条件付きフォワーダー(Conditional Forwarder):
特定のドメインに対する問い合わせを、指定したDNSサーバーへ強制的に転送する設定。最もシンプルに相互解決を実現しやすい。
コンディショナルフォワーダーでAWSとオンプレをつなぐ方法
もっともポピュラーなアプローチとして、Windows Server DNSで「AWSドメインはAWSのDNSサーバーへ」「オンプレミスドメインはオンプレDNSサーバーへ」といった条件付きフォワーダーを設定する方法があります。以下では、オンプレ側からAWS側への名前解決を可能にする設定手順を例示します。
Windows Server DNSでの設定手順
- DNSマネージャーを起動
Windows Server上で「サーバーマネージャー」→「ツール」→「DNS」を選択し、DNSマネージャーを開きます。 - サーバープロパティのフォワーダータブへアクセス
左ペインから該当DNSサーバーを右クリックし、「プロパティ」を開き、「フォワーダー」タブを確認します。 - 新しいフォワーダーを追加
「フォワーダー」タブで「編集」をクリックし、ドメイン名としてAWSで運用しているドメイン(例：aws.example.local)を入力します。 - AWS側DNSサーバーのIPアドレスを設定
追加したドメインに対して問い合わせを転送する先として、AWS環境で機能しているDNSサーバーのプライベートIPを入力します。 - OKで保存
設定を反映させると、オンプレのDNSはaws.example.localに関する問い合わせを自動的にAWSのDNSへ転送するようになります。
PowerShellで設定する場合の例
# 新しい条件付きフォワーダーを作成する例
Add-DnsServerConditionalForwarderZone `
-Name "aws.example.local" `
-MasterServers 10.0.1.10,10.0.1.11 `
-ReplicationScope "Forest"上記のようにAdd-DnsServerConditionalForwarderZoneコマンドレットを利用し、AWS側DNSのアドレスを指定することで設定が可能です。また、同様の設定をAWS側DNSにも施しておくと、AWSフォレストからオンプレミスフォレストのホスト名も解決できます。
スタブゾーンやセカンダリゾーンを活用するシナリオ
条件付きフォワーダーだけでなく、スタブゾーンやセカンダリゾーンを使った方法もあります。これらはゾーンの情報をどこまで複製するかによって使い分けます。
スタブゾーンのポイント
- NSレコード、SOAレコードのみを複製
余計なレコードは持たず、問い合わせ時には本来のDNSサーバーへ再問い合わせを行う。そのためゾーン転送の負荷は軽い。 - メリット
・DNS参照先を自動的に最新化できる
・本家DNSサーバーの変更を反映しやすい - デメリット
・全レコードはキャッシュされないため、問い合わせは都度スタブゾーンを参照し、そこからさらに本家DNSを参照する
セカンダリゾーンのポイント
- 全レコードを複製
ゾーン転送で完全なレコードをコピー。読み取り専用なので変更は本家DNSでのみ行われる。 - メリット
・レコードをローカルで完結して照会できるため高速応答が期待できる
・本家DNSがダウンしていてもレコードを保持している限りは名前解決が可能 - デメリット
・ゾーン転送のトラフィックが発生するため、AWSとオンプレ間のネットワークに負荷がかかる場合がある
・管理対象のゾーンが大規模な場合、ゾーン転送設定のメンテナンスが煩雑になる
実践的な構成例
以下に、AWSとオンプレ環境を連携させる際のDNS設定例を表でまとめてみます。構成に応じて最適解は変わるため、自社の要件に合わせて選択してください。
| DNS設定方法 | メリット | デメリット | 適用シナリオ |
|---|---|---|---|
| コンディショナルフォワーダー | 設定が簡単・最小限の変更で相互フォレスト解決が可能 | DNSサーバー間の双方向設定が必要 | 小規模～中規模環境、まずは素早く相互解決を実現したい場合 |
| スタブゾーン | NSレコードのみを取得するため転送負荷が小さい | 名前解決時に追加の問い合わせが発生し、応答までやや時間がかかる場合も | 大規模環境だが全レコードのゾーン転送を避けたい場合 |
| セカンダリゾーン | ローカルにレコードを保持するため高速で安定した応答が可能 | ゾーン転送のトラフィック増加と管理コスト | DNSクエリが非常に頻繁に発生する環境、WAN回線の信頼性を高めたい場合 |
ファイアウォールやセキュリティ設定の考慮
フォレスト間でDNSを相互に解決するためには、DNSクエリを通過させる必要があります。AWS環境の場合、VPCのセキュリティグループやネットワークACL、オンプレ側ではファイアウォールやルーターなど、多層的なセキュリティ設定が考えられます。以下のポイントを確認しましょう。
- 53番ポート(UDP/TCP)の許可
DNSクエリは通常UDPで行われますが、応答が大きい場合はTCPも使用します。双方ともに通信を許可しておく必要があります。 - 特定サブネットや特定IPからのアクセスを制限していないか
AWS側とオンプレ側で相互アクセスを許容するルールを設定しているかを確認します。 - VPNやDirect Connectなどの経路
AWSへの接続形態がVPNやDirect Connectの場合、トンネルや専用線の設定でDNSパケットを通すようにしておく必要があります。トンネル終端機器でのフィルタリングに注意してください。
AWS環境特有のDNS統合ポイント
AWSではRoute 53などを利用してDNSを管理することもできます。AWS Managed Microsoft ADを使うケースでは、AWSが管理するActive Directoryドメインがあり、そのDNSが自動的に構成される場合もあります。以下の要点に気を付けましょう。
- Route 53のプライベートホストゾーンとの連携
AWSのVPC内でプライベートゾーンを運用している場合、オンプレからは直接参照できないため、条件付きフォワーダーでAWS内のDNSに問い合わせるようにします。 - AWS Managed Microsoft ADの場合
ドメインコントローラーがAWSのManagedサービスで運用されているため、こちらのDNSにオンプレのドメインを転送する設定や、オンプレ側DNSにAWSのレコードを転送する設定を行います。 - 冗長構成の配慮
複数のDNSサーバーを設定し、可用性を高めるのが理想です。AWS側DNSが冗長化されていないと、障害発生時にオンプレから名前解決できなくなる可能性があります。
トラブルシューティングのコツ
設定を行ったにも関わらず、名前解決が上手くいかない場合は以下のポイントをチェックしましょう。
- クライアント側のDNS設定
クライアントが指しているDNSサーバーのIPアドレスが正しいか、DNSサフィックスが正しく設定されているかを確認。 - NSLOOKUPコマンドによる検証
「nslookup ホスト名 DNSサーバーIP」の形式で直接問い合わせを行い、応答が得られるかを確認します。
例:
nslookup aws.example.local 192.168.1.10これで即座に応答がなければ、DNSフォワーダー設定や通信経路に問題がある可能性が高いです。
- DNSキャッシュのクリア
テストを繰り返す場合、キャッシュに古い情報が残っていると誤解を招きます。
ipconfig /flushdnsでクライアント側のキャッシュをクリアしてから再度検証を行いましょう。
- イベントビューアやサーバーログの確認
Windows ServerのDNSログやイベントビューアを確認すると、転送に失敗した理由などがエラーメッセージとして出力される場合があります。タイムアウトや権限不足などの原因究明に役立ちます。
まとめと運用上の注意点
- フォレスト間のDNS解決は必須
AWSとオンプレの環境を連携させるうえで、相互にホスト名を解決できない状態は大きなリスクです。ログインやアプリケーション間通信に支障をきたすだけでなく、フォレストトラストなどの高度な機能も正しく動作しません。 - コンディショナルフォワーダーが最もシンプル
小規模～中規模の環境であれば、まずは条件付きフォワーダーから導入するとよいでしょう。設定やトラブルシューティングが容易で、互いのDNSを相互解決するまでのステップが少ないのが魅力です。 - 大規模環境ではスタブゾーンやセカンダリゾーンも検討
ゾーン情報の規模や問い合わせ頻度、ネットワーク帯域などを考慮して、最適な方法を選定することが重要です。 - ネットワークやセキュリティ設定を並行して見直す
DNSの設定だけではなく、ファイアウォールやルーティングの問題など、関連する要素が複雑に絡んでいる場合が多いです。問題解決には総合的な視点が必要となるため、分野をまたいだチーム連携が求められます。
相互にDNS解決ができるようになれば、AWSのリソースをオンプレからシームレスに利用できるようになります。サーバーの運用管理やドメイン参加、ファイル共有などもスムーズに行えるようになるため、ハイブリッドクラウドのメリットを十分に引き出せるでしょう。今後も環境が拡張していくことを見据えて、DNS設定を含めた設計を常にブラッシュアップしていくことが大切です。
コメント