オンプレミス環境とパブリッククラウド環境の名前解決

●オンプレミス環境におけるDNS名前解決
移行前のオンプレミス環境においては、ディレクトリサービスおよび認証サービスとしてActive Directory(以下、AD)を利用しているケースが多く、ADに付随するDNSサーバで社内のDNSを管理しているケースが多く見られます。また、メールシステムや外部公開サイト向けのインターネット上の名前解決には、外部のDNSサービスと契約し管理しているケースが多いため、ADのDNSサーバを社内DNSとして利用している前提で話を進めます。

●パブリッククラウド環境におけるDNS名前解決
今回は、パブリッククラウドにおけるIaaSのシェアが最も高いAmazon Web Services (以下、AWS)を利用することを想定します。AWSには、Amazon Route 53(以下Route 53) というDNSサービスがあります。Route 53は信頼性が高いことに加え、多機能なDNSサービスです。社内でDNS名前解決をさせることも、インターネット上でDNS名前解決をさせることも可能です。
一方で、Route 53を活用する際にはオンプレミス環境で使っていたDNSサーバとは機能が異なる点があることを留意する必要があります。詳細は、AWSのWebページで確認が必要ですが、まずはAWS社が実施しているBlack Belt オンラインセミナー資料およびその動画を確認しておきましょう。ハイブリッドクラウド環境を検討する際には下記「Amazon Route 53 Resolver 編」に分かりやすく解説されています。具体的な内容については、次章で解説します。

・Amazon Route 53 Resolver 編
　資料：https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-Route53-Resolver_0530_v1.pdf
　動画：https://www.youtube.com/watch?v=6nf6vIQha1g

AWSとのハイブリッド構成でのDNS名前解決構成

AWSとのハイブリッド構成でのDNS名前解決の基本構成は上図のようになります。「Amazon Route 53 Resolver for Hybrid Clouds」という機能が用意されており、ADサーバ(兼DNSサーバ)とAWSのRoute 53 ResolverがDNS問合せを相互にフォワードして、システム全体で統一的なDNS名前解決が構成できるようになっています。ADサーバからRoute 53 Resolver向けのフォワードでは、Inbound Endpoint※を経由し、Route 53 ResolverからADサーバへのフォワードではOutbound Endpoint※を経由する構成となります。
※Inbound Endpoint、Outbound Endpointとは、外部とDNS名前解決通信をするための、IPアドレスを持ったインターフェースです。

Route 53は以下3種類のDNSゾーンの名前解決が可能です。(括弧内はAWSドキュメント上での名称)


①インターネット名前解決ゾーン(Internet Public DNS Zone)
　いわゆるインターネット上のDNSゾーンです。xxx.com/ xxx.co.jp/ xxx.netなど。

②Amazon管理VPCプライベートDNSゾーン(Amazon-provided private DNS hostnames)
　Amazonが生成、管理するDNSゾーンで、VPC内に閉じたプライベートネットワークで使用し、ユーザ側が操作できないもの(.ec2.internal/ .compute.internal/ .amazonaws.com)が含まれます。

③ユーザ管理VPCプライベートDNSゾーン(Amazon Route 53 Private Hosted Zone)
　上記②に対して、ユーザ側が生成、管理できるDNSゾーンです。VPC内に閉じたプライベートネットワークで使用するDNSゾーンを定義し、レコード登録が可能です。DNSゾーン名も、ユーザ側で決定可能です。具体的な使い方として、AWS上のリソースのDNS名は、非常に長くユーザフレンドリーではないため、③側でCNAMEとして別名を登録するケースや、DR切り替え時にDNSのレコード変更で切り替えを行うケースなどに利用します。

その他、「Amazon Route 53 Public Hosted Zone」という、インターネット上でユーザ側が管理できるゾーンもありますが、今回の構成では使用しないため、説明を割愛しています。

AWSとのハイブリッド構成でのDNS名前解決の注意点

AWSとのハイブリッド構成においては、前段で説明した構成およびDNSゾーンの種類を理解した上で、以下の3項目について注意する必要があります。

1）「③ユーザ管理VPCプライベートDNSゾーン」はADドメインのDNSゾーンのサブドメインにできない
　DNS名前解決を統合管理する際は、できるだけドメインを増やさないことが原則となります。そのため、AWS上の「③ユーザ管理VPCプライベートDNSゾーン」を既存ADドメインのDNSゾーンのサブドメインにしたいと考えますが、Route 53上の制約によってこの構成はとれません。そのため、独立したDNSゾーンとして構成する必要があります。

2）DNS逆引きゾーンが必要な場合は、ADサーバ上に逆引きゾーンを持たせた方が良い
　日立製作所のJP1などの一部ソフトウエアではDNSの逆引き(IPアドレスからホスト名を特定する問合せ)が必要となります。AWSとのハイブリッド構成においては、逆引きゾーンはADサーバ上に配置し、AWSからはフォワード時のルールで逆引きゾーン問合せをADサーバに転送する設定をする構成を推奨します。理由は以下2点です。
　・DNSゾーンは、システム全体で原則1箇所にしか持てない(複数箇所に持たせると正確なDNS名前解決ができない)ため
　・ADドメイン上では、ドメイン参加しているサーバ、クライアントがDNSレコード(逆引きレコードを含む)を自動更新可能であり、
　　管理負荷を軽減できるため

3）「②Amazon管理VPCプライベートDNSゾーン」の名前解決は、VPC外部から利用する場合、結果が変わる可能性がある
「②Amazon管理VPCプライベートDNSゾーン」は、AWSのVPC内を想定したものとなっており、オンプレミス環境などのVPC外から名前解決しようとするとプライベートのIPアドレスとして解決したいケースで、グローバルIPアドレスが返ってきてしまうなど、意図しない名前解決となるケースがあります(下図参照)。意図しない名前解決をしている場合は、ADサーバ上で、パケットキャプチャを行い、DNSの問合せの転送先(フォワード先)の宛先を確認すると、原因が判明するケースが多くあります。

まとめ

今回は、オンプレミス環境とAWSとのハイブリッドクラウド環境を構成する際のDNS名前解決について、基本構成と注意点を解説しました。実際の検討シーンでは、AWS側のAZ冗長化やBCPを想定したDR切り替え時を加味して、さらに深くDNS名前解決について検討していく必要があります。当社JSOLでは、AWSに限らずAzure(Microsoft社)、Google Cloud(Google社)を含めて、オンプレミス環境からのクラウドリフトやハイブリッドクラウド構成での構築実績、運用実績が多くありますので、お困りの際にはぜひご相談ください。

※本記事に記載されている製品・サービス名称は、各企業・団体の商標または登録商標です。