2026年6月8日
2026年6月8日
DNSMadeEasy を使った DNS 移行手順|ゾーンの取り込み、独自レコードの置き換え、DNSSEC とネームサーバー切り替えの順序
他社の DNS サービスから DNS Made Easy への移行は、「現在のレコードを漏れなく書き出す → TTL を下げる → DNS Made Easy にゾーンを取り込む → 移行元に独自のレコードを置き換える → DNS Made Easy のネームサーバーに直接問い合わせて比べる → レジストラでネームサーバーを切り替える」という順で進めます。DNSSEC を使っているドメインでは、ネームサーバーを切り替える前に DS レコードの扱いを決めておかないと、移行中に名前解決ができなくなるおそれがあります。この記事では、移行元の調べ方から切り替え後の後片付けまでを、つまずきやすい点とあわせて説明します。
DNS Made Easy は DigiCert のグループが提供するマネージド DNS サービスです(2026年10月現在)。管理画面の構成やメニューの名前、ドキュメントの置き場所は変わることがあるため、この記事では操作を目的で説明します。実際の画面の表記や取り込み機能の条件は、DNS Made Easy のサポートサイトで確認してください。料金やプランごとの機能の違いもここでは扱いません。
移行の全体像と所要時間
作業そのものは数時間で終わりますが、TTL が切れるのを待つ時間が必要なため、全体では数日の余裕を見ておきます。
- 移行元のレコードとドメインの状態を調べる(当日)
- 移行元で TTL を短くする(切り替えの1〜2日以上前)
- DNS Made Easy にドメインを追加してレコードを取り込む
- 移行元に独自のレコードを置き換える
- DNS Made Easy のネームサーバーに直接問い合わせて比べる
- レジストラでネームサーバーを切り替える
- 数日は移行元を残し、落ち着いてから DNSSEC の再設定や TTL の戻しを行う
手順1:移行元のレコードとドメインの状態を調べる
まず、移行元の管理画面にゾーンファイル(BIND 形式)を書き出す機能があるかを確認します。多くのサービスには書き出しの機能があり、これが最も漏れの少ない方法です。書き出せない場合は、管理画面の一覧を見ながら、名前と種類を表に起こします。外から dig で調べる方法では、存在を知らない名前は見つけられないため、補助的な確認にとどめます。
書き出したレコードの中で、特に確認したいのは次のものです。
- メールに関わるレコード:MX、SPF(TXT)、DKIM(
selector._domainkeyの TXT や CNAME)、DMARC(_dmarcの TXT)。漏れるとメールの不達やなりすまし判定につながります。 - 長い TXT レコード:DKIM の公開鍵など255文字を超える値は、複数の文字列に分けて登録されています。取り込み後に値が欠けていないかを確認します。
- SRV・CAA レコード:Microsoft 365 などのサービス連携や、証明書の発行元の制限に使われています。
- サブドメインの委任:別のネームサーバーに委任している NS レコードがあれば、それも移します。
あわせて、ドメインの DNSSEC の状態を調べます。
# 親ゾーンに DS レコードが登録されているか(何か返れば DNSSEC が有効)
dig example.com DS +short
# 現在のネームサーバーと、その TTL
dig example.com NS +noall +answer
手順2:移行元で TTL を短くする
切り替えの直後に問題が見つかったとき、元に戻すまでの影響を短くするため、移行元で主要なレコードの TTL を300秒程度に下げておきます。下げた TTL が効くのは、それまでの TTL が切れてからです。たとえば86400秒(1日)だったレコードは、下げてから1日以上待ってから切り替えます。
レジストラに登録されたネームサーバーの情報(親ゾーンの NS)は、TLD の運営者が決めた TTL で保持されるため、こちらからは短くできません。ネームサーバーを切り替えたあと、しばらくは移行元にも問い合わせが届くことを前提に計画します。
手順3:DNS Made Easy にゾーンを取り込む
DNS Made Easy の管理画面でドメインを追加すると、そのドメインに割り当てられたネームサーバーが表示されます。この一覧は手順6で使うので控えておきます。
レコードの登録には、次の方法があります(2026年10月現在の公式ドキュメントの説明に基づきます)。
- ゾーンファイルの取り込み:BIND 形式のゾーンファイルを貼り付けて取り込む方法です。SOA と NS は DNS Made Easy 側のものが使われるため、移行元の SOA と自ドメインの NS の行は取り込み後に残っていないかを確認します。
- ゾーン転送(AXFR)での取り込み:移行元がゾーン転送に対応していれば、DNS Made Easy が移行元から直接レコードを受け取れます。移行元で、DNS Made Easy のドキュメントに記載された取り込み元のアドレスからの転送を許可する必要があります。作業が終わったら、移行元の転送の許可を元に戻します。
- API での登録:ドメインの数が多い場合は、DNS Made Easy の REST API でまとめて登録する方法もあります。API キーと秘密鍵はスクリプトに直接書かず、環境変数などから読み込み、Git などのバージョン管理に入れないようにします。
どの方法でも、取り込んだあとは件数を比べます。移行元で書き出したファイルのレコード数と、DNS Made Easy の一覧の件数が合わない場合は、どの種類のレコードが欠けたかを確認します。
# 書き出したゾーンファイルの、種類ごとの件数
awk '!/^[;$]/ && NF>=4 {for(i=1;i<=NF;i++) if($i ~ /^(A|AAAA|CNAME|MX|TXT|SRV|CAA|NS)$/){print $i; break}}' example.com.zone \
| sort | uniq -c
手順4:移行元に独自のレコードを置き換える
DNS サービスの中には、標準の DNS には無い独自の仕組みを持つものがあります。ゾーンファイルには正しく書き出されないか、書き出されても別の意味になるため、手で置き換えます。
- ゾーンの頂点(example.com)の別名:Route 53 のエイリアスレコードや、Cloudflare の CNAME フラットニングで頂点に CDN やロードバランサーの名前を向けていた場合、そのままでは移せません。DNS Made Easy では ANAME レコードがこの用途に当たります。向け先の名前と動き(答えるアドレスの更新間隔など)をドキュメントで確認してから設定します。
- Cloudflare のプロキシ:プロキシを有効にしていたレコードは、プロキシの設定そのものを他社に移すことはできません。書き出したファイルにどの値が入っているかを確認し、移行後も Cloudflare の CDN を使うのか、元のサーバーに直接向けるのかを決めて値を入れ直します。
- URL 転送(HTTP リダイレクト):レジストラの DNS などで提供される転送機能は DNS のレコードではないため、取り込まれません。DNS Made Easy の転送機能を使うか、Web サーバー側でリダイレクトを設定します。
手順5:DNS Made Easy のネームサーバーに直接問い合わせて比べる
切り替える前に、移行元と DNS Made Easy のネームサーバーに同じ問い合わせを送り、答えが一致するかを確かめます。ネームサーバー名は、手順3で控えたものに置き換えます。
OLD=ns1.old-provider.example # 移行元のネームサーバー
NEW=ns-assigned.dnsmadeeasy.example # DNS Made Easy で割り当てられたネームサーバー
while read -r name type; do
a=$(dig @"$OLD" "$name" "$type" +norec +short | sort)
b=$(dig @"$NEW" "$name" "$type" +norec +short | sort)
[ "$a" = "$b" ] || printf 'DIFF: %s %s\n old: %s\n new: %s\n' "$name" "$type" "$a" "$b"
done < names.txt
names.txt には「名前 種類」を1行ずつ書きます(例:example.com MX、_dmarc.example.com TXT)。手順1で書き出したレコードから作ると漏れが減ります。手順4で意図的に変えたレコード(ANAME など)は、差が出て当然なので、新しい値が正しいかを個別に確かめます。メールについては、MX の向け先だけでなく、SPF の include の内容と DKIM の値が一字一句同じかも見ておきます。
手順6:DNSSEC の扱いを決めてからネームサーバーを切り替える
手順1で DS レコードが見つかった場合、移行元で署名されたゾーンの DS が親ゾーンに残ったまま、署名の無い(または別の鍵で署名された)DNS Made Easy に切り替えると、DNSSEC を検証するリゾルバーで名前解決に失敗します。最も単純で安全な順序は次のとおりです。
- レジストラで DS レコードを削除する
- DS の TTL(TLD によって異なり、1日程度のことが多い)が切れるのを待つ。
dig example.com DS +shortで何も返らなくなったことを確かめる - ネームサーバーを DNS Made Easy に切り替える
- 切り替えが落ち着いたら、DNS Made Easy 側で DNSSEC の署名を有効にし、新しい DS をレジストラに登録する
DNS Made Easy で DNSSEC の署名を使えるかどうかや設定の手順は、プランや時期によって異なる可能性があるため、移行を始める前にサポートサイトで確認しておきます。DNSSEC を使っていないドメインなら、この手順は不要です。
準備ができたら、レジストラの管理画面でネームサーバーを DNS Made Easy で割り当てられたものに変更します。登録できるネームサーバーの数に上限があるレジストラもあるので、その場合は案内されている台数の範囲で登録します。
手順7:切り替え後の確認と後片付け
# 親ゾーンから順にたどって、新しいネームサーバーが返るか
dig example.com NS +trace
# 各ネームサーバーで SOA のシリアルがそろっているか
for ns in $(dig example.com NS +short); do
echo "$ns $(dig @"$ns" example.com SOA +short)"
done
切り替え後の数日は、移行元のゾーンを消さずに残します。古いネームサーバーの情報をキャッシュしているリゾルバーが、まだ移行元に問い合わせてくるためです。この期間にレコードを変える場合は、両方に同じ変更を入れます。メールの送受信、Web サイトの表示、証明書の更新(DNS で認証している場合)が問題なく動くことを確認できたら、TTL を元の値に戻し、移行元のゾーンと契約を整理します。
まとめ
- 移行元のゾーンファイルを書き出し、メール関連・長い TXT・SRV・CAA・委任の NS を重点的に確認します。
- TTL を先に下げ、元の TTL が切れるのを待ってから切り替えます。親ゾーンの NS の TTL は短くできません。
- 取り込みはゾーンファイルか AXFR で行い、件数を比べます。エイリアスやプロキシ、URL 転送は手で置き換えます。
- DNSSEC を使っている場合は、DS を外して TTL が切れてからネームサーバーを切り替え、落ち着いてから署名と DS を設定し直します。
- 切り替え後も数日は移行元を残し、両方を同じ内容に保ちます。