今までオンプレミス環境にあるサーバたちのホスト名に対する名前解決するには、DNSサーバを立ててやるのは通常かと思いますが、クラウド盛んになっている今は、わざわざ手間をかけてDNSサーバを立てるケースはだんだん少なくなってくるでだろう。
　今回は、DNSサーバの役割を持っているAWSのサービス（Route53）を使って、実際プライベート環境で名前解決できるかを検証し、本記事にまとめてみました。

前提条件

　今回Route53の検証はメインだったため、事前にネットワーク（VPC、サブネット）、サーバ（EC2）など準備済みであること

構成

今回は下記のようなプライベート環境にてサーバ同士をRoute53を使って名前解決してみた。
検証構成イメージ図

Route53の設定

サービスメニューからRoute53を選択

ホストゾーンの作成

ドメイン名の設定：今回は検証のため、適宜hyron.netとする
プライベート環境で名前解決したいため、タイプを「プライベートホストゾーン」を選択する。

ホストゾーンに関連するVPCの情報、上記の構成図で10.60.0.0/16のVPCを関連付ける

暫く立つと、下記ような画面となり、ホストゾーンが作成されていることを確認する。
「hyron.net」ドメインに対する、SOA及びNSコードが自動割り振られていたことを確認する。

次に、レコードを作成する
web側のAレコードをホストゾーンへ追記します

ope側のAレコードをホストゾーンへ追記します

追加されたレコードが完全に浸透されるまで少々時間かかるが、ステータス確認では、「INSYNC」となってれば大丈夫です。

先ほど追加したweb及びopeのAレコード情報は、↓こんな形で登録されていることを確認できる。

この状態では、理論的に、サーバ同士で名前解決できているはずですので、
早速テストしてみましょう

webサーバからpingコマンドで名前解決できるかどうかを確かめる

うん、応答がない。。。
opeサーバからpingコマンドで名前解決できるかどうかを確かめる

うん、こちらも反応ないか
いろいろ原因を探ってみました。どうやらVPC側の「DNS解決を有効化」するだけでは不十分です。併せて「DNSホスト名を有効化」する✔も入れないといけないようです。
早速VPCの設定を変えてみました。
設定変更前のVPC状態

設定変更後のVPC状態

この状態で、もう一回名前解決実施してみます。
先と同じく、webサーバからopeホスト名に対するpingできるかどうかを確認する

ope.hyron.netに対して、ちゃんと10.60.3.65のIPアドレスが返ってきたことを確認できた。
digコマンドでopeサーバのIP見えるかどうかも確かめる

ホスト名に対する応答があり、名前解決されたことが分かります。

opeサーバからwebホスト名に対するpingできるかどうかを確認する。

今回はweb.hyron.netに対して、ちゃんと10.60.4.99のIPアドレスが返ってきたことを確認できた
digコマンドでwebサーバのIP見えるかどうかも確かめる

ちゃんと名前解決できたことを確認しました。やったー！

まとめ

今回はまったところとしては、VPCを作成するときに、「DNSホスト名を有効化」に✔入れていなかったのが原因でした。ちなみに、これ以外に、AWSの仕様として、プライベートゾーンに作成するドメインについては、「.local」を付けてはいけないようです。検証とかどうしても.localつけたくなちゃうだよね。そこも注意しましょう

　プライベート環境においてRoute53を使ってちゃんと名前解決できることを確認しました。
本記事の記載内容については、少しでもお役に立てれば幸いです。