内容
下記オンプレミスからAWS上の名前解決の検証を行う記事の別パターンとなります。両方ともオンプレミスのDNS設定にDNSインバウンドエンドポイントへのフォワード設定を行い、Route53のプライベートホストゾーン内のレコードで名前解決を行います。下記記事との違いは別アカウントで作成したプライベートホストゾーンの関連付けを行っている点です。
構成
赤線の流れで名前解決（オンプレミスのDNSサーバからDNSインバウンドエンドポイントにフォーワード）を行った後、黄色線の流れでNLBにアクセスする環境を想定します。このアーキテクチャの特徴は緑線の流れとなります。Account Bで作成したexample.localというプライベートホストゾーンをAccount AのVPCに関連付けを行います。
構築
Account B側でexample.localというプライベートホストゾーンを作成します。その後、www.example.localというAレコード（エイリアスを有効化）を作成してNLBのDNS名と紐づけます。設定完了後のプライベートホストゾーンは下記の様な状態となります。
Account Bからプライベートホストゾーンの関連付けリクエストを行います。下記では上記Account Bで作成したプライベートホストゾーンのIDとAccout A側で紐づけるVPCのIDを指定します。
aws route53 create-vpc-association-authorization \
--hosted-zone-id Z00XXXXXXXXXXXX \
--vpc VPCRegion=ap-northeast-1,VPCId=vpc-0axxxxxxxxxxxxx
続いてAccout A側の作業になります。Accout A側で関連付けの承認を行います。
aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id Z00XXXXXXXXXXXX \
--vpc VPCRegion=ap-northeast-1,VPCId=vpc-0axxxxxxxxxxxxx
なお、上記の設定はRoute53コンソールから行うことは出来ません。
これでプライベートホストゾーンの関連付けが完了です。Account B側にログイン後、プライベートホストゾーンを確認すると、上記で指定したAccount A側のVPCがプライベートホストゾーンに紐づいていることが確認出来ます。
ここからEC2にログインして名前解決が可能であるか確認していきます。なおEC2側のDNSサーバの設定はこちらの記事と同様です。
現在の状態では、example.localに関する設定がないため、www.example.localの名前解決を行うことは出来ません。
nslookup www.example.local
;; communications error to 172.20.1.10#53: timed out
;; communications error to 172.20.1.10#53: timed out
;; Got SERVFAIL reply from 172.20.1.10
Server: 172.20.1.10
Address: 172.20.1.10#53
example.localドメインへのリクエストをDNSインバウンドエンドポイントに転送する設定を行った後、bindの再起動を行います。
vim /etc/named.conf
zone "example.local" IN {
type forward;
forward only;
forwarders { 172.20.1.20; 172.20.1.30; };
};
systemctl restart named
これでAccout Bから共有されたプライベートホストゾーンのレコードを使用して名前解決することが出来ました。
nslookup www.example.local
Server: 172.20.1.10
Address: 172.20.1.10#53
Non-authoritative answer:
Name: www.example.local
Address: 172.20.1.40
Name: www.example.local
Address: 172.20.1.50