Twitterもやってます

ぜひともフォローをお願いします。

本題

さて今回は「サイトの移管」、更に「ドメインとDNSの切り替え（引っ越し）」にテーマを絞って書いてみます。

弊社ではなぜか下記アパレルECサイトを運営しております。

「EVERLAST」のオリジナルはアメリカのブランドでありますが、今年弊社が国内の企画・EC販売権含め一部のライセンスを取得しています。（注：あくまで一部であり、例えば「し〇〇ら」に売っているEVERLASTは弊社のライセンスとはまた違います）そこで国内他社がすでに運営していたサイトをドメインそのまま、弊社開発の新サイトに移管する形で今年の7/1新オープンの運びとなりました。

私はインフラ専任エンジニアではありませんが、ドメイン切替くらい5才児でもできんだろとの思いから、サイト開発のマネージメントの片手間で作業を全部引き受けたのですが、これが海外を巻き込んでいることもあり実にチェックポイントが多く面倒であったため、メモとして本記事を残したいと思います。

今回のサイト移管の条件は以下です。特殊な条件かもしれませんが、最終的にドメイン・DNSに関してやらなければならないことは一般のサイトの移管と変わらないかと思います。

弊社は移管を「受ける」側、リニューアルリリース日は7月1日
ドメインはそのまま、他社運営（カートベンダーのサービスを利用）のECサイトを自社開発のサイトに移管する
事情があってデータ移管が発生しないという希少（ラッキー）な案件のため、切替期間中に実施しないと行けない作業が少ない
それでも本国の許可もあり、前日からメンテナンス画面の表示が可能で、翌日のリリース時間もある程度幅が取れる
当然ながらメンテナンス期間開始の瞬間まで移管前サイト側がDNSを管理しドメインを使用しているので、それまで当該ドメインで何か試したり設定したりできない
メンテナンス開始が6月末日であり、移管前サイトはその日をもってカートベンダーと契約終了、旧インフラ環境は翌日の任意の時間に削除される　（つまり移管前サイトのリソースが一定期間残るなどが一切ない=戻せない）

では以下チェックポイントを並べます！

「ドメイン」所有権（A）は誰にあるのか

「DNSサーバー」管理者（B）は誰なのか

（両者を確認し、切替作業を依頼しておく）

当たり前なのですが、この2点については全く別の話なわけです。

例えば「お名前.comでドメインを購入し、DNSはAWS route53に変更する」なんて作業はきょうびのサーバーサイドエンジニアであればインフラ専任でなくてもほぼ誰でもやっているのであり、であれば少なくとも感覚的には理解しているはずのことですが（そして私もそうだったはずで、だからこそ今回もその程度だろとしか思ってなかった）なぜか上記はセットで管理されているという前提で本国に問い合わせてしまいました。要するに○日○時にDNSのAレコードをこちらのIPに向けてください、といった内容です。

そしたら全然話が噛み合わないわけです。最初は英語の問題かなと思いましたが。。（正確にはドメイン管理が本国アメリカではなく、そこからUKの業者に依頼されていたというのもありました。）

結局移管前サイトが採用している国内カートベンダーさんが（B）であることがわかり「あ、そうか」と気づきました。（A）と（B）って別か、と。そして当然そちらのほうが問題はシンプルになります。

（参考サイトー「route53 ドメイン移管とDNS変更は意味違うよって話（お名前comから、route53にDNS変更をする）」）

時差（UKとサマータイム8時間差）があるので、オープン日前日UK現地朝9時、日本時間オープン日前日の17時、にネームサーバーをこちらが指定したものに切り替えてねという作業を依頼しました。

本当はやっておくべきだったこと

本来切替時の新しいネームサーバーへの変更については（A）にだけでなく、同時に移管前の（B）にもお願いをすべきです。
そうすれば（A）の変更の浸透が完全でないがゆえに（B）へのアクセスが発生しても最終的に新サイトに飛ぶからです。

ただ今回この点について
・（A）の変更のあとに（B）の変更を行うのが理想であるが、前者が（海外業者のため）本当に時間通り行われるか自信がなかった
・ 次の日には潰される環境のDNS設定の変更を移管前の管理者にさすがに依頼しづらかった
という事情で（A）だけに変更を依頼したのですが、見事このあと後悔することに。。

（参考サイトー「噂のDNS浸透問題（リスク）の現象の答え」）

移管後のDNSサーバーは誰が用意するのか

上述の理由から自分達で用意しました。弊社で開発しているサイトはインフラにGCPを選択していたため、Cloud DNSを選択。ドメイン管理者にネームサーバーを伝えない限りスタンドアロンで存在しているだけなので、できることは全て下記のように設定しておきます。ここで表示されるネームサーバーを改めて（A）に伝えます。

移管前サイトのDNSサーバーのAレコードのTTL変更を短くしておく

（B）に対して移管日半月ほど前に当該ドメインから移管前サイトのIPに対するAレコードについてTTLをできる限り短縮して設定いただくよう依頼。そうしないと、移管後も移管前のDNSルートがキャッシュで残存する時間が長くなってしまい、移管後のレコードの浸透が遅くなってしまいます。

移管後のSSL証明書を用意する

移管後は我々が用意したWAFを通過するので、SSL証明書をWAF設定用に購入しました。（当然移管前のベンダーから証明書一式頂くなんてのは、常識的にないですね）

移管前ですから、購入後の認証が弊社側で行えません。ですからここはどうしても（B）にご協力仰ぐしかありません。同じく（B）に連絡し、証明書が「DNS認証」されるようにTXTレコードに認証局から指定されたテキストを登録していただきました。

WAFの用意をしておく

WAF(場合によってはCDNも)をスタンドアロンの状態で用意し、上記証明書を設定しておきます。（ローカルPCのhost.confを編集し擬似的にWAF経由でhttpsアクセス・確認できるような機構は恐らくどのWAFベンダーも用意しているはずなのでそれもしておく）

当該ドメインのメールアドレスの送受信の用意

問い合わせメールの受信先やシステムメールの送信元であるメールアドレスの諸々の用意です。〇〇@everlastjp.com のようなメールアドレスのことですね。

この部分での弊社の細かい対応・設定はセキュリティ事項なので詳細は割愛しますが、

当該ドメインのメールアドレスで送受信できる「用意」
メールサーバーのDKIMやDNSでのSPFレコードの設定

等をしておきます。しつこいですが「用意」のみであって実際の送受信は出来ません。同じメールアドレスが移管前サイトで使用されているからです。それは移管メンテナンス時間の間の確認事項となります。

長くなったので今回はここまで。。次回は移管日前当日に確認したことと、やっぱり起きたちょっとしたトラブルについてお話します。

ドメインとDNSの引越問題その１