ドメイン移管でサイトは止まる？｜お名前.comからさくらへ移管する手順とダウンタイム対策
先日、ENVY DESIGNで、あるお客様のドメインをお名前.comからさくらインターネットへ移管する対応をしました。サーバーはすでにさくらで契約済みで、以前こちらで代理取得していたドメインの管理をお客様側に戻すために、レジストラ（ドメインの登録事業者）だけをお名前.comからさくらへ移す、という案件です。
このとき、お客様から「移管する際に、サイトが見えなくなる時間帯はありますか？」というご質問をいただきました。ドメイン移管を任されたとき、同じ不安を持たれる方は多いのではないでしょうか。
この記事では、この実例を追いながら、ドメイン移管でサイトが止まる場合と止まらない場合を、手順に沿って基礎から解説します。専門用語はそのつど噛み砕いていくので、ドメインまわりに詳しくない方でも、読み終えるころには、どの作業でサイトが止まり得るのかを、ご自身で判断できるようになるはずです。
ステップ1：登場人物を「3つの役割」に分ける
まず土台として、ドメイン名でサイトが表示される仕組みを、役割の異なる3つに分けて押さえます。ここを分けて捉えられると、あとの判断がぶれません。
レジストラ：ドメインの登録事業者
レジストラは、ドメインの登録・管理を担う事業者です。お名前.comやさくらインターネットなどがこれにあたります。「このドメインの持ち主は誰で、どの事業者の管理下にあるか」を扱う立場で、ドメイン移管とは、このレジストラを別の事業者へ切り替える手続きを指します。今回の案件では、この部分をお名前.comからさくらへ移すことがゴールでした。なお、ドメインやサーバーの契約名義をどうすべきかについては、ドメインやサーバーの手配・契約の費用と名義はどうなりますか？で別途整理しています。
DNS：ドメイン名を実際のサーバーに結びつける仕組み
DNSは「Domain Name System（ドメイン・ネーム・システム）」の略で、ドメイン名を、実際のサーバーの住所（IPアドレス）に変換する仕組みです。この変換のことを「名前解決」と呼びます。人が覚えやすいドメイン名を、機械が使うIPアドレスに翻訳してくれるもの、と考えると分かりやすいと思います。
その「どのドメインは、どのサーバーの住所か」という答えを持っているのが、ネームサーバーです。ネームサーバーには、答えが「レコード」という形で登録されていて、Webサイトの宛先を示すAレコードや、メールの宛先を示すMXレコードなどがあります。訪問者がドメイン名でアクセスすると、このネームサーバーに登録されたAレコードをたどって、正しいサーバーへ案内される、という流れです。
このAレコードですが、Webサーバー会社のネームサーバーを使う場合は、あらかじめ正しい値が設定されていることが多いです。たとえばさくらインターネットのサーバーにドメインを追加すると、そのドメインのAレコードには、さくらのサーバーのIPが自動でセットされます。ふだんサイトを立ち上げるときにAレコードをあまり意識せずに済むのは、このためです。
Webサーバー：サイトのデータが置かれている場所
Webサーバーは、サイトのデータそのものが置かれている場所です。DNSがこのサーバーを指し示すことで、訪問者に正しくサイトが表示されます。今回の案件では、サーバーはすでにさくらにあり、ここは移さないので手を触れません。
ステップ2：今のネームサーバーがどこを向いているかを確認する
土台を押さえたら、最初の実作業は現状確認です。今このドメインのネームサーバーがどこを向いているかを確認します。ターミナルで「dig 対象ドメイン NS +short」を実行するか、お名前.comであれば管理画面の「ネームサーバー情報」で確認できます。
今回、実際に確認したところ、ネームサーバーはさくら（dns.ne.jp）ではなく、お名前.comのDNS（01.dnsv.jp〜04.dnsv.jp）を向いていました。お名前.comでドメインを取得したときに、ここでAレコードを管理して、さくらのサーバーへつないでいた、という状態です。
ここで、ネームサーバーの扱いには、名前が似ていて混同しやすい2つの操作があることに触れておきます。この2つを分けて理解できると、以降の手順がつながります。
一つめは、「どのネームサーバーを使うか」の指定です。「このドメインの答えは、このネームサーバーに聞いてください」という宛先を切り替える操作で、これはレジストラの管理画面（お名前.comなら「ネームサーバー設定」）で行います。二つめは、「レコードの中身」の設定です。Aレコードでどのサーバーを指すか、といった実際の値を編集する操作で、これは今ネームサーバーが指している事業者の画面で行います。今回はネームサーバーがお名前.comを指していたので、Aレコードはお名前.comのDNSレコード設定の画面で管理されていました。
ステップ3：確認結果から、自分のケースを見分ける
確認できたネームサーバーの値によって、進め方が3つに分かれます。
ひとつめは、すでに移管先（たとえばさくらの ns1.dns.ne.jp / ns2.dns.ne.jp）を向いているケースです。この場合、DNSは移管元に依存していないので、レジストラ移管をしてもDNS作業は不要で、ダウンタイムは生じません。
ふたつめは、CloudflareやAmazon Route 53のような、レジストラともWebサーバー会社とも独立した第三者のDNSサービスを向いているケースです。この場合も、DNSは移管元に紐づいていないため、移管の影響を受けません。基本的にはひとつめと同じく、そのまま移管できます。
みっつめが、もっとも注意が必要な、移管元の事業者が提供するDNS（お名前.comの01〜04.dnsv.jpなど）を向いているケースです。今回のドメインは、まさにこのみっつめに当てはまりました。次に、このケースがなぜ危ないのかを説明します。
ステップ4：なぜ「移管元のDNS」だと危ないのかを理解する
移管元の事業者が提供するDNSを使っている場合、注意すべき仕様があります。
お名前.comの無料のDNSレコード設定は、そのドメインが他社へ移管されて完了すると、レコードが削除されます。つまり、今回のようにネームサーバーがお名前.com（dnsv.jp）を向いたまま移管を完了させてしまうと、その時点でお名前.com側のDNSが答えを返せなくなります。移管の直後はしばらくキャッシュで表示され続けるため気づきにくいのですが、キャッシュが切れた時点で名前解決ができなくなり、サイトもメールも止まります。これが、ドメイン移管でもっとも多いトラブルです。
言い換えると、止まるかどうかを分けているのは「DNSをどこで持っているか」です。今回のように、DNSが移管元（お名前.com）にある構成だけが、移管の完了によって足元をすくわれる、というわけです。
ステップ5：ネームサーバーの切り替えを「移管の前に」済ませる
危ないケースだと分かったので、対策は順番です。鍵は、ネームサーバーの切り替えを、レジストラ移管の「前」に済ませておくことです。今回、実際に取った順番は次のとおりです。
はじめに、移管先であるさくら側に、現在と同じレコードが用意されている状態を整えます。この時点ではネームサーバーはまだお名前.comを向いているので、表示には影響しません。準備を先に整える段階です。
次に、ネームサーバーをさくら（ns1.dns.ne.jp / ns2.dns.ne.jp）へ切り替えます。両方のDNSが同じ答えを返す状態を先に作っておくことで、どちらが参照されても表示は変わりません。切り替え後、さくら側で正しく名前解決できていることを確認します。今回は、この切り替えまでをダウンタイムなしで完了できました。
レコードを移すうえで見落としやすいのが、Aレコード以外の存在です。ドメインには、メールの宛先を指定するMXレコードや、送信ドメイン認証に使うTXTレコード（SPFやDKIMなど）が設定されている場合があります。これらを複製し忘れたまま切り替えると、サイトは正常に表示されているのに、メールだけが届かなくなる、という事態が起こり得ます。今回のドメインは、確認したところAレコードだけでMXもTXTもなく、しかもサイトがもともとさくらのサーバーで動いていたため、さくら側にはすでにAレコード（さくらのサーバーのIP）が用意されていました。ステップ1で触れたとおり、Webサーバー会社のネームサーバーを使う場合はAレコードがあらかじめ入っていることが多く、今回はそのおかげで、手でレコードをコピーする作業すら要らないシンプルな構成でした。
一方で、外部の別サーバーを指すAレコードや、メール用のMXレコードがある案件では、これらを自分で移管先へコピーして用意する必要が出てきます。その場合は、切り替え前にゾーン全体を洗い出し、主要なレコードを漏れなくコピーしておくことが大切です。
ステップ6：レジストラ移管を実行する
DNSをさくらへ独立させ、そちらで正しく表示されていることを確認できたら、最後にレジストラ移管を実行します。この時点でDNSはすでにお名前.comから独立しているため、移管が完了してお名前.com側のDNSが削除されても、影響を受けません。今回のケースも、この順番を踏めているので、移管の完了時にダウンタイムは発生しません。
移管の実務としては、移管元（お名前.com）でAuthCode（認証鍵）を取得し、移管ロックを解除して、移管先（さくら）で申し込みます。申込み後、登録者のメール宛に承認メールが届くので、これを承認します。承認しないと移管は進みません。完了までは通常5〜10日程度です。
ここで一つ、実務でよく出る疑問に触れておきます。「移管したら、移管先で改めてネームサーバーを設定し直す必要があるのでは」というものです。結論としては、設定し直す必要はありません。ネームサーバーの指定は、レジストラの中ではなく、その一つ上にあるレジストリ（.comならVerisign）の台帳に記録されているためです。レジストラの画面は、この台帳へ値を書き込む窓口にすぎず、移管で変わるのは「台帳を操作する窓口をどの事業者にするか」だけです。台帳に記録されたネームサーバーの値（今回ならさくら）は、移管によって書き換わったり消えたりせず、そのまま引き継がれます。
補足：TTLは「Aレコードの切り替え」に効く
DNSの切り替えでよく出てくるTTL（レコードがキャッシュされる時間）ですが、効く場面は限られます。TTLを短くしておくことが有効なのは、Aレコードの値そのものを切り替える場合です。一方、ネームサーバーの委任情報のTTLは、レジストリ側で固定されています（.comの場合は172800秒、およそ2日です）。そのため、自分のゾーンのTTLを短くしても、ネームサーバーそのものの切り替わりが速くなるわけではありません。TTLの短縮は、Aレコードを変更するときの備え、と整理しておくと正確です。
補足：移管前に確認しておきたい制約
段取りとは別に、そもそも移管が実行できるかどうかの制約も確認が必要です。代表的なのが60日ルールで、.comなどのドメインでは、登録の直後や前回の移管の直後の一定期間は、他社への移管が制限されます。加えて、登録者情報を変更した直後にも60日間の移管ロックがかかる場合があり、実務ではここで足止めされることが少なくありません。このほか、承認メールを受信できる状態の確保も必要です。WHOIS情報公開代行を利用している場合は、移管元によっては一時的な解除を求められます（お名前.comでは必要です）。また、ネームサーバーやレコードの切り替え作業に入る前に、サイトとメール設定のバックアップを確保しておくと、万一の切り戻しにも落ち着いて対応できます。バックアップの考え方はホームページのバックアップは取ってもらえますか？でも触れています。
よくある質問
移管したら、移管先で改めてネームサーバーを設定し直す必要がありますか？
いいえ。ネームサーバーの指定は、レジストラの中ではなくレジストリ（台帳）側に記録されているため、移管しても値は引き継がれます。変わるのは、その台帳を操作する窓口の事業者だけです。移管先で設定し直す作業は発生しません。
移管元のDNSを使っているかどうかは、どう見分けますか？
「dig 対象ドメイン NS +short」で現在のネームサーバーを確認します。返ってきた値が、たとえばお名前.comのDNS（01.dnsv.jp 〜 04.dnsv.jp）のように移管元の事業者のものであれば、移管の前に、レコードを移管先へコピーしてから、ネームサーバーを移管先へ切り替える、という作業が必要です。移管先や第三者のDNSを向いていれば、その作業は不要です。
ネームサーバーの切り替えは、移管の前と後のどちらが安全ですか？
移管の前です。先に移管先へネームサーバーを切り替えてDNSを移管元から独立させておけば、移管が完了して移管元のDNSが削除されても影響を受けません。移管の後に切り替えようとすると、その間に移管元のDNSが止まり、ダウンタイムが発生する可能性があります。
まとめ
今回の実例を振り返ると、ドメイン移管でサイトが止まるかどうかは、「DNSをどこで持っているか」で決まる、という一点に集約されます。お名前.comからさくらへレジストラを移すこの案件では、ネームサーバーがお名前.comのDNSを向いていたため、そのまま移管すると移管完了時に止まる構成でした。
そこで、さくら側のレコードを整え、ネームサーバーの切り替えをレジストラ移管の前に済ませ、名前解決を確認してから移管する、という順番で進めることで、表示を止めずに対応できました。ドメイン移管そのものは、レジストリの台帳を操作する窓口を切り替えるだけの手続きで、ネームサーバーの指定は移管しても引き継がれます。だからこそ、DNSを先に移管元から独立させておくことが、ゼロダウンタイムの鍵になります。ENVY DESIGNでは、保守・運用サポートの一環として、こうしたドメインやサーバーまわりの移管についても、構成の確認から順を追って、表示やメールを止めないことを前提に対応しています。
出典
- ICANN Transfer Policy（gTLDの移管ルール・60日制限の根拠）
- JPRS 用語辞典（DNS・ネームサーバー・レジストリの定義）
- さくらインターネット サポートサイト（ドメイン移管）
関連記事
- 301と302の使い分け｜判断基準は「SEO評価」ではなく正規URL
- ホームページの保守契約は必要ですか？
- 運用・保守｜ホームページ制作の流れ Step 7
- phpMyAdminが使えないWordPressのバックアップ方法｜Adminerを使った実際の対応事例
お問い合わせ
ドメイン移管やサーバー移転で、サイトやメールを止めずに進められるか不安がある場合は、お問い合わせフォームよりご相談ください。現在のネームサーバー構成を確認したうえで、安全な切り替え順序をご提案します。