2026年6月7日

DNSMadeEasy から他の DNS へ移行する手順｜レコードの書き出し、ANAME・リダイレクト・フェイルオーバーの置き換え、解約まで

DNS・名前解決

DNS Made Easy から別の DNS 事業者へ移るときは、「API などでレコードを漏れなく書き出す → DNS Made Easy 独自の機能を洗い出して移行先での置き換え方を決める → 移行先に作って直接問い合わせて比べる → DNSSEC を整理してからネームサーバーを切り替える → 数日たってから解約する」という順で進めます。とくに ANAME、HTTP リダイレクト、DNS フェイルオーバーは標準の DNS レコードではないため、そのままでは移りません。この記事では、DNS Made Easy を移行元として扱うときに必要な作業を、つまずきやすい点とあわせて説明します。

他社から DNS Made Easy へ移す手順は、同じシリーズの別記事で扱っています。DNS Made Easy の管理画面の構成やメニュー名、API の仕様は変わることがあるため（2026年10月現在）、この記事では操作を目的で説明します。実際の表記は DNS Made Easy のサポートサイトと API ドキュメントで確認してください。料金や契約条件は扱いません。

移行の全体像

現在のレコードを書き出す
DNS Made Easy 独自の機能を使っているレコードを洗い出す
移行先にゾーンを作り、DNS Made Easy と答えを比べる
DNSSEC とバニティネームサーバーの扱いを決める
TTL を下げ、レジストラでネームサーバーを切り替える
数日様子を見てから、DNS Made Easy のゾーンと契約を整理する

作業そのものは1日で終わることもありますが、TTL の待ち時間と切り替え後の様子見を含めて、1〜2週間の余裕を見ておくと慌てずに済みます。

手順1：DNS Made Easy のレコードを書き出す

管理画面にゾーンを書き出す機能があれば、まずそれでファイルを保存します。ただし、独自のレコード（後述）は標準のゾーンファイル形式では正しく表せないことがあるため、書き出したファイルだけに頼らず、API でも中身を取っておくと安心です。

DNS Made Easy の REST API（V2.0）では、API キーと秘密鍵を使い、リクエストの日時を秘密鍵で署名したヘッダーを付けて認証します。次の例は、管理しているドメインごとにレコードを JSON で保存するものです。キーはスクリプトに書かず、環境変数から読み込みます。

import hashlib, hmac, json, os, urllib.request
from email.utils import formatdate

API = "https://api.dnsmadeeasy.com/V2.0"
KEY = os.environ["DME_API_KEY"]
SECRET = os.environ["DME_SECRET_KEY"]

def get(path):
    date = formatdate(usegmt=True)
    sig = hmac.new(SECRET.encode(), date.encode(), hashlib.sha1).hexdigest()
    req = urllib.request.Request(API + path, headers={
        "x-dnsme-apiKey": KEY,
        "x-dnsme-requestDate": date,
        "x-dnsme-hmac": sig,
        "Accept": "application/json",
    })
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)

for d in get("/dns/managed/")["data"]:
    recs = get(f"/dns/managed/{d['id']}/records")
    with open(f"{d['name']}.json", "w", encoding="utf-8") as f:
        json.dump(recs, f, ensure_ascii=False, indent=2)
    print(d["name"], len(recs.get("data", [])), "records")

署名に使う日時がずれていると認証に失敗するため、実行するマシンの時計を NTP で合わせておきます。応答が複数ページに分かれる場合があるので、ページ数の項目を確認し、件数が管理画面の表示と合うかを見比べます。保存した JSON は、移行が終わるまで消さずに残しておきます。

種類ごとの件数を数えておくと、移行先との比較に使えます。

jq -r '.data[].type' example.com.json | sort | uniq -c

手順2：DNS Made Easy 独自の機能を洗い出す

書き出したレコードのうち、次のものは移行先で別の方法に置き換える必要があります。

ANAME レコード：ゾーンの頂点（example.com）を CDN やロードバランサーのホスト名に向けるための仕組みです。移行先に ALIAS・ANAME・CNAME フラットニングなど同等の機能があるかを確かめます。無い場合は、向け先が固定の IP アドレスを案内していればそれを A レコードで登録し、無ければ頂点は www へリダイレクトする構成を検討します。
HTTP リダイレクトのレコード：特定の名前へのアクセスを別の URL へ転送する機能です。DNS の標準のレコードではないため、移行先の転送機能を使うか、Web サーバー側で 301 リダイレクトを設定します。移した後は、転送元の名前の A レコードが転送を処理するサーバーを向いているかも確かめます。
DNS フェイルオーバーと監視：監視に失敗したときに答えを予備の IP アドレスへ切り替える設定です。移行先にヘルスチェック付きの切り替え機能があればそこで作り直し、無ければ外部の監視サービスで検知して手で切り替える手順を用意します。設定が漏れると、障害時に切り替わらないことに気づかないまま運用することになるので、一覧にして移行先での担当を決めます。
地域別に答えを変える設定：問い合わせ元の地域で答えを変えている場合は、移行先の位置情報によるルーティングで作り直します。対応していない事業者もあります。
テンプレートや一括設定：複数ドメインに共通のレコードをテンプレートで配っている場合、移行先では各ドメインに展開された実際のレコードが必要です。

これらは「どのレコードが、どの機能を使い、移行先で何に置き換えるか」を表にしておくと、確認漏れを防げます。

手順3：移行先に作り、DNS Made Easy と答えを比べる

移行先にゾーンを作ってレコードを登録したら、レジストラを変える前に、両方のネームサーバーへ直接問い合わせて答えを比べます。

OLD=ns0.dnsmadeeasy.com          # 今の NS（dig example.com NS +short で確認したもの）
NEW=ns1.new-provider.example     # 移行先で割り当てられた NS

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の JSON から「名前種類」を1行ずつ作ります。ANAME を A レコードに変えた場合など、手順2で意図的に変えたものは差が出て当然なので、個別に新しい値が正しいかを確かめます。メールについては、MX の向け先だけでなく SPF・DKIM・DMARC の TXT の値が一字一句同じかを見ておきます。

手順4：DNSSEC とバニティネームサーバーを整理する

DNSSEC を有効にしている場合は、dig example.com DS +short で親ゾーンに DS が登録されているかを確認します。DS が残ったまま署名の鍵が違う移行先へ切り替えると、DNSSEC を検証するリゾルバーで名前解決に失敗します。単純で安全なのは、レジストラで DS を外し、DS の TTL が切れて dig example.com DS +short が空になってからネームサーバーを切り替え、落ち着いてから移行先で署名を有効にして新しい DS を登録する順序です。

自社ドメイン名のネームサーバー（ns1.example.com のようなバニティネームサーバー）を使っている場合は、レジストラに登録したホスト（グルーレコード）が DNS Made Easy のアドレスを指しています。移行先の事業者が同じ仕組みに対応しているかを確かめ、対応していなければ移行先の標準のネームサーバー名に切り替えます。ほかのドメインが同じバニティネームサーバーを使っていないかも確認してから変更します。

手順5：TTL を下げてネームサーバーを切り替える

切り替えの1〜2日以上前に、DNS Made Easy 側で主要なレコードの TTL を300秒程度に下げておきます。下げた TTL が効くのは、それまでの TTL が切れてからです。レジストラに登録した NS の情報は TLD 側の TTL で保持されるため、こちらからは短くできず、切り替え後もしばらくは DNS Made Easy に問い合わせが届きます。

準備ができたら、レジストラで NS を移行先のものに変更し、委任が変わったことを確かめます。

dig example.com NS +trace
for ns in $(dig example.com NS +short); do echo "$ns $(dig @"$ns" example.com SOA +short)"; done

手順6：解約の前に確かめること

切り替え後の数日は、DNS Made Easy のゾーンを消さずに残します。この期間にレコードを変える場合は、両方に同じ変更を入れます。そのうえで、次の項目を確かめてからゾーンの削除と解約に進みます。

Web サイトの表示、メールの送受信、DNS で認証している証明書の更新が問題なく動いている
手順2の表の項目（リダイレクト・フェイルオーバー・地域別の答え）がすべて移行先で動いている
DNS Made Easy のネームサーバーへの依存が残っていない（サブドメインを委任する NS レコードや、別のドメインの NS 指定に DNS Made Easy のネームサーバー名が残っていないかを dig 名前 NS +short で確認する）
同じアカウントにある他のドメインを、誤って一緒に消さない

解約するとアカウント内のゾーンが使えなくなる可能性があるため、ドメインが複数ある場合は、すべての移行が終わってから最後に契約を整理します。

まとめ

DNS Made Easy から移るときは、画面の書き出しに加えて API でもレコードを取得し、件数を確かめます。
ANAME・HTTP リダイレクト・DNS フェイルオーバー・地域別の答え・テンプレートは標準のレコードではないため、移行先での置き換え方を表にして決めます。
移行先と DNS Made Easy に直接問い合わせて答えを比べ、メール関連は値まで照合します。
DNSSEC は DS を外して TTL が切れてから切り替えます。バニティネームサーバーはグルーレコードの扱いを先に決めます。
切り替え後も数日はゾーンを残し、依存が残っていないことを確かめてから解約します。