【Amazon.co.jp限定】 ロジクール 静音 ワイヤレス トラックボール マウス M575SPd Bluetooth Logibolt 無線 windows mac iPad OS Chrome トラックボールマウス マウス ブラック M575 M575SP 国内正規品 ※Amazon.co.jp限定 壁紙ダウンロード付き
￥7,700 (2025年5月1日 13:14 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
【Amazon.co.jp限定】USBメモリ 1TB 大容量 USB3.0・Type-C 高速データ転送 メモリー フラッシュメモリ 外付け 容量不足解消 スマホ用可能 Mac Windows PC Pad対応 360度回転 合金製 耐衝撃 防塵仕様 バックアップ タイプC USBメモリー 携帯便利 コンパクト
￥2,999 (2025年5月1日 13:06 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
【Amazon.co.jp限定】 バッファロー WiFi ルーター 無線 LAN Wi-Fi 6 11ax AX3000 2,401+573Mbps 日本メーカー 【 iPhone 16e / 16 / 15 / 14 / Nintendo Switch / PS5 動作確認済み 】 スマート 引っ越し エコパッケージ ブラック WSR-3000AX4P/NBK
￥9,980 (2025年5月1日 13:14 GMT +09:00 時点 - 詳細はこちら価格および発送可能時期は表示された日付/時刻の時点のものであり、変更される場合があります。本商品の購入においては、購入の時点で当該の Amazon サイトに表示されている価格および発送可能時期の情報が適用されます。)
- DNSサーバーが何かは分かる
- クラウドのDNSサービスを使用している
- DNSサーバーの設定は触ったことも、見たこともない
- ドメインのレジストラはお名前ドットコム
- GCPのクラウドDNSからAWSのRoute53へ移行する
- サービスを止めずに移行する
あくまでもこれは今回の例であり、ドメインもGCPで管理しているパターンもあるでしょう。
本記事の内容は、クラウドサービスであれば何でも当てはまると思います、多分。
「DNSを移行する」＝「ドメインに紐づけるDNSのネームサーバーを変更する」
です。
DNSのネームサーバーはNSレコードの値になります。
作業としてはこちらのAWS公式サイトの手順が全てです。
考慮しておくべきは、準備作業をしたあと大体数日待ってから移行作業を行う必要があることです。
作業自体は簡単です。
ただし、サービスを停止しないために順番を守る必要があります。
移行元(GCPクラウドDNS)のDNSレコードを確認
NSレコードとSOAレコード以外の レコードをそのままAWSにも同じように作成するので、後からレコードの内容をコピペするために画面を確認します。
NSレコードとSOAレコードは、DNSサーバー固有の値になるので自動付与されたものを使います。
メモ
- NSレコード
- そのドメインの権威DNSサーバーを指定するレコード
各DNSサービスプロバイダー（GCPのCloud DNSやAWSのRoute53など）は、自社のDNSサーバーを指すNSレコードを自動的に設定
- そのドメインの権威DNSサーバーを指定するレコード
- SOAレコード
- そのDNSゾーンの管理情報を含むレコードで、プライマリネームサーバー、管理者のメールアドレス、シリアル番号、更新間隔などの情報を持つ
ドメインのレジストラで紐づけているネームサーバーを確認
ドメインのレジストラ(お名前ドットコム)では、「本ドメインはこのDNSサーバーを使いまーす」という設定があります。
移行前はGCP側のネームサーバーが入ってます。ネームサーバーは先程確認したNSレコードの4つの値です。
後でネームサーバーを変更するために設定画面を確認します。
移行先(AWS Route53)のDNSレコードを作成
Route53にて、使用しているドメインと同じ名前でホストゾーンを作成し、そこに先程GCPで確認したレコードを真似して作成します。
ホストゾーンを作成した時点で勝手に用意されているレコード(おそらくNSレコードとSOAレコード)はそのままにしておきます。
この勝手に用意されたNSレコードの4つの値をネームサーバーとして移行先の指定に使うので、メモしておきます。
移行元と移行先の両方のNSレコードのTTLを下げる
個人的にはこれが一番のポイントかなと思ってます。
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の期限切れを待つ
TTLを60秒に戻したらすぐにキャッシュの期限が60秒になるわけではありません。
それ以前にすでにキャッシュされたレコードは元々のTTLの期間だけ保持されるので、この期限が切れるのを待つ必要があります。
ドメインのレジストラ(お名前ドットコム)で設定しているネームサーバーを変更します。
具体的には、前項で新たに作成したRoute53側のNSレコードの4つの値をコピペします。
60秒以上経ってWebサービスが問題なく利用出来れば、移行成功です。
念の為、複数のDNSリゾルバーを使って動作確認しておくと安心です。
移行先のDNSのTTLを24時間などの元の値に戻します。
今回、TTLを下げてキャッシュの期限切れを待つということを解説しましたが、体感ではもっと早く反映されてるように思います。設定変更を検知して自動でキャッシュをクリアする技術がありそうです。
その場合、実際はそういった「待つ」というのは必要ないかもしれません。
Views: 0
