他サーバーで取得したドメインをAWSでhttps化する その3(NSレコードの移し替え )

前回までで、ロードバランサーへのSSL証明書のアタッチとポート443の開放は終わりました。
次に、というか最後に必要なのが、他サーバーからのネームサーバーの変更とNSレコードの移し替えです。
ネームサーバーは、どこのレコードでリクエストをルーティングするか、NSレコードはそのルーティングの内容を定めているものらしいです。

今ドメインのネームサーバーはスターサーバーのものになってるので、ドメインに関する情報はスターサーバーのレコードを参照しています。
これを、対象ドメインのネームサーバーを、Route53の対象ドメインのホストゾーンのネームサーバーにすることで、Route53のレコードを参照させます。
で、そのRoute53のレコードを、スターサーバーの現行のレコードから全コピします。
以下では順番は逆なんですけども(最初にルーティング元を変えてしまうと作業が終わるまでアクセスできなくなってしまうので)。

以下は、作成したホストゾーン。
Route53のホストゾーンはメインドメインのみでOK。

AレコードにはエイリアスをOnにして、対象ドメインをロードバランサーに紐づけています(値でロードバランサーを選択)。
直接EC2に流したい時は、EC2のIPアドレスを入力してください。

これで、対象ドメインへのリクエストは全て当該ロードバランサーへ流されます。
ただし、ドメインを取得したスターサーバーでのネームサーバーがRoute53のものになっていればの話です。
今はまだドメインのネームサーバーがスターサーバーのものなので、ルーティングはスターサーバーがしており、ロードバランサーに流す設定にはなっていません。
このネームサーバーの移行は最後にします。

レコードの移し替え

スターサーバー

スターサーバーのレコードを全てRoute53に移し替えます。

Route53

MX は優先順位もレコード登録しなければなりません。
また、Route53では同じドメイン、同じタイプのレコードは値を複数行にして一つのレコードにまとめます。

この時点ではまだNSはスターサーバーに向いているので、普通にアクセスしてもスターサーバーがルーティングしており、digコマンドを使ってCNAMEなどを調べてもスターサーバーがルーティングする値しか得られません。
それを、

dig ドメイン @Route53でのドメインのホストゾーンのNS

とすることで、
Route53でのルーティングの結果が得られます。
@以下を加えることで、どのDNSサーバーでの値かを指定できます。

この、スターサーバーでのルーティングの結果と、Route53でのルーティングの結果が全て同じになれば、Route53でルーティングを開始してもOKということです。

ネームサーバーの変更

ということで、ルーティングの大元であるネームサーバーも変えます。

このスターサーバーのネームサーバーを、Route53のホストゾーンのNSに登録しなおします。
これで、このドメインはまず、Route53でルーティングしますよということになり、そこから、Route53のホストゾーンのレコードでルーティングされるわけです。

確認としては、

dig ドメイン @8.8.8.8

で行うのが一般的なようです。
8.8.8.8は、GoogleのPublic DNSのサーバーのIPv4です。
この値を見て、反映を確認します。
まぁ色んなアクセスがあると思うけど、GoogleのDNSにちゃんと反映していれば大丈夫でしょう、といった感じ。

これにて、あとは各サーバーのキャッシュ更新ができれば、どこからそのドメインにアクセスしても、当該ロードバランサーにリクエストがいきます！

いやぁ勉強になりました。
A、CNAME、NSって並列になってるけど、NSだけ一個上のレイヤーの気がします…。
そこが同じ概念だと思っていたのが今回はハマった根源だった気が。