DNSサーバーの移行について無知すぎて手も足も出なかったので前提理解を深めた

Last updated at 2025-04-30Posted at 2025-04-30

対象読者

あくまでもこれは今回の例であり、ドメインもGCPで管理しているパターンもあるでしょう。
本記事の内容は、クラウドサービスであれば何でも当てはまると思います、多分。

「DNSを移行する」＝「ドメインに紐づけるDNSのネームサーバーを変更する」
です。
DNSのネームサーバーはNSレコードの値になります。

作業としてはこちらのAWS公式サイトの手順が全てです。
考慮しておくべきは、準備作業をしたあと大体数日待ってから移行作業を行う必要があることです。

作業自体は簡単です。
ただし、サービスを停止しないために順番を守る必要があります。

NSレコードとSOAレコード以外の レコードをそのままAWSにも同じように作成するので、後からレコードの内容をコピペするために画面を確認します。
NSレコードとSOAレコードは、DNSサーバー固有の値になるので自動付与されたものを使います。

メモ

NSレコード
- そのドメインの権威DNSサーバーを指定するレコード
  各DNSサービスプロバイダー（GCPのCloud DNSやAWSのRoute53など）は、自社のDNSサーバーを指すNSレコードを自動的に設定
SOAレコード
- そのDNSゾーンの管理情報を含むレコードで、プライマリネームサーバー、管理者のメールアドレス、シリアル番号、更新間隔などの情報を持つ

ドメインのレジストラ(お名前ドットコム)では、「本ドメインはこのDNSサーバーを使いまーす」という設定があります。
移行前はGCP側のネームサーバーが入ってます。ネームサーバーは先程確認したNSレコードの4つの値です。
後でネームサーバーを変更するために設定画面を確認します。

Route53にて、使用しているドメインと同じ名前でホストゾーンを作成し、そこに先程GCPで確認したレコードを真似して作成します。
ホストゾーンを作成した時点で勝手に用意されているレコード(おそらくNSレコードとSOAレコード)はそのままにしておきます。

この勝手に用意されたNSレコードの4つの値をネームサーバーとして移行先の指定に使うので、メモしておきます。

個人的にはこれが一番のポイントかなと思ってます。
DNSレコードのTTLとは、DNSリゾルバーがレコードをキャッシュし、キャッシュされた情報を使用する期間のことです。
TTLが期限切れになると、リゾルバーはドメインのDNSサービスプロバイダに別のクエリを送信し、最新の情報を取得する、とのことです。

で、このTTLは1日以上(24時間以上)であることが多いようです。

つまり、NSレコードのTTLが例えば24時間のままDNSサーバーを移行すると、新しいDNSサーバーがWebサイト利用者側に反映されるのは最大24時間になるということです。

問題なく移行できた場合はこれでもいいのですが、
24時間後になって、もし何かしらの問題があって新しいDNSが動作せずWebサービスにアクセス出来なくなった場合、急いで元に戻したり修正したりしても、最大24時間は動作しない状況が続きます。
そうなるともう指をくわえて見てるしかありません。

そのため、TTLは60秒とかにしておきましょう。
設定方法は簡単で、GCPとAWSそれぞれのNSレコードの編集画面で、TTLを60秒に設定します。

TTLを60秒に戻したらすぐにキャッシュの期限が60秒になるわけではありません。
それ以前にすでにキャッシュされたレコードは元々のTTLの期間だけ保持されるので、この期限が切れるのを待つ必要があります。

ドメインのレジストラ(お名前ドットコム)で設定しているネームサーバーを変更します。
具体的には、前項で新たに作成したRoute53側のNSレコードの4つの値をコピペします。

60秒以上経ってWebサービスが問題なく利用出来れば、移行成功です。
念の為、複数のDNSリゾルバーを使って動作確認しておくと安心です。

移行先のDNSのTTLを24時間などの元の値に戻します。

今回、TTLを下げてキャッシュの期限切れを待つということを解説しましたが、体感ではもっと早く反映されてるように思います。設定変更を検知して自動でキャッシュをクリアする技術がありそうです。
その場合、実際はそういった「待つ」というのは必要ないかもしれません。