📌 この記事は旧記事の改良版（2025年版）です
2013年に書いた「ネームサーバ移行〜虎の巻〜」をベースに、現代の運用で踏みやすい地雷（DNSSEC / レコード多様化 / 家庭用ルーターDNS挙動など）を追加して再構成しました。
旧記事：ネームサーバ移行〜虎の巻〜

冬休み、ふと目に入る「放置された独自ドメイン」…🎄

DNSの管理画面が古い
TTLが触れない/反映が遅い
TXTが謎に増殖してる（SPF/DKIM/検証用…）
そもそも誰がどこで管理してるか分からない 😇

そして一番怖いのがこれ👇
DNS移行で事故る＝「名前が引けない」＝Webもメールも全部死ぬ 💥

この記事は、Cloudflare / Route 53 みたいな“モダンDNS”を例にしつつ、どこへ移しても通じる「権威DNS（ネームサーバ）移行の型」 をまとめたランブックです ✅
小規模（個人〜数人運用）向けに、止めない・迷わない・戻せるを優先します 🧯

想定読者 👤

個人ブログ / 小規模サービス（1〜数人）
DNSに詳しくないけど、止めたくない
冬休みメンテで「老朽化ドメイン」を健康診断したい人ｗ

この記事でやること / やらないこと 🎯

やること ✅

権威DNS（ネームサーバ）の移行手順（新DNSへ複製 → NS切替 → 検証 → 片付け）
事故ポイント（TTL / キャッシュ / ネガティブキャッシュ / DNSSEC / 切り戻し判断）
当日の“嘘防止”コマンド（dig +trace と権威DNS直叩き）

やらないこと ❌

Webサーバ移行・CDN切替・メールサーバ移行の詳細
（DNS移行と同時にやると火力が上がりすぎます🔥 小規模は分割推奨）

まずは用語3つだけ（これで迷子が減る 🧭）

レジストラ：ドメインの戸籍係（例：お名前系、ムームー系、各社…）
権威DNS（Authoritative）：そのドメインの“正解”を答えるDNS（この記事の主役）
再帰DNS（リカーシブ / キャッシュ）：利用者側のDNS（ISP/社内/8.8.8.8/家庭用ルーターなど）

事故る理由のほとんどはこれ👇
権威DNSを切り替えても、再帰DNSのキャッシュが残る 😇

全体像：小規模はこの3フェーズで勝てる 🥇

棚卸し（現状把握）
複製（新DNSに“完全コピー”）
切替（NS変更）→ 検証 → 片付け

コツはシンプルで、ずっとこれです👇
「切替前に新旧を同じ状態にする」 ✅

フェーズ1：棚卸し（冬休みのメインイベント🎄）

ここが雑だと、移行日に死にます 😇
特に小規模は「誰も覚えてない設定」が混じりがち…。

レコード棚卸しのコツ 🧾（2013→2025で地雷の中身が変わった）

DNS移行で事故る原因は雑に言うと2つです👇

“見える/忘れにくい”のに、単純にコピー漏れ（これは注意力の問題）
“存在に気づきにくい/増殖しがち”で、漏れると痛い（こっちが地雷💣）

2013の虎の巻は「TTL/キャッシュ/委任」の地雷が主役でしたが、2025はここに
DNSSEC / TXT多用途化 / CAA / レコード多様化が乗ってきます 🔥

なので棚卸しは、次の3カテゴリで舐めるのが一番ラクです ✅

① 当然枠（忘れにくい・見える）🧱

ここは移行で真っ先に触るので、“まぁ頑張ってね枠” です（でも漏れると死ぬ）。CNAMEもここ（当然枠）です 👍

A / NS / SOA / CNAME

② 地雷枠（忘れやすい・漏れると痛い）💣 ← ここに注力

「存在に気づきにくい」「勝手に増えがち」「平時は気づかない」系。

レコード	なぜ漏れやすい？	漏れると何が起きる？
`TXT`	検証トークンが増殖しがち	メール認証/外部連携/ドメイン検証が壊れる
`CAA`	平時は意識しない	証明書更新/再発行が突然こける
`MX`	「メール使ってないつもり」で漏れる	メールが即死（転送/受信だけ残ってた等）
`DNSSEC（DS周り）`	手順が別格で抜けやすい	ミスると解決失敗（SERVFAILなど）になりやすく、ユーザー側から“落ちた”に見える

③ 条件付き（忘れやすいけど、影響は環境依存）🫧

ここは「存在してたらコピー対象」くらいでOK。

AAAA（IPv6を使ってる/レコードがあるなら最優先で一致確認）
SRV（使ってるサービスだけ狙って死ぬ）
HTTPS（SVCB/HTTPS, Type65：最近ある。存在してたらコピー対象。多くは最適化系なので「設定解説」はしない）

要するに👇
②（地雷枠）を最優先で潰し、③は“あったらコピー”、①は当然やる。これが小規模の勝ち筋です 🥇

フェーズ2：新DNSへ複製（“同じ状態”を作る 🧬）

方針はこれ👇

新DNSに先に全部作る
旧DNSは「切替されるまで現役」なので、基本触らない（触るならルール化）

やり方は2択：

エクスポート/インポート（できるなら最強）
手作業（できないなら、差分確認の仕組みを作る：チェックリスト・スクショ・GitメモでもOK）

TTLとキャッシュ（ここを舐めると“効かない切り戻し”が起きる 🧯）

TTLざっくり

TTLが短いほど、切替の反映は早い
ただし短すぎると問い合わせ増（とはいえ小規模なら切替期間だけ短くてOK）

小規模の現実的ムーブ

可能なら、切替の数日前に主要レコードのTTLを下げる
できないDNSなら、「反映が遅い前提」で計画する（当日特攻しない）🏃‍♂️💨

フェーズ3：切替当日ランブック（ここが本体🔥）

目標

“今どこが正解を答えているか”を、キャッシュ抜きで確認する ✅

やることは最短でこれ👇

新旧の権威DNSに直で問い合わせて、応答が一致してるか確認
レジストラでNS切替
dig +trace で委任が切り替わったことを確認
外形（ブラウザ/監視）で最終確認
事故ったら切り戻し（判断基準は事前に決める）

“嘘防止”コマンド：そのまま貼れる例（結果つき🧪）

重要：+trace は「辿るための最初の問い合わせ先」が必要です。
家庭用ルーター配下のDNSが怪しい時は、@1.1.1.1 など 明示すると安定しやすいです 🙌

1) 親から辿って「いまの委任先NS」を見る（`+trace`）

dig @1.1.1.1 +trace example.org NS

（マスク済み・抜粋）

.        ... IN NS a.root-servers.net.
...（root列挙は省略）...

org.     ... IN NS a0.org.afilias-nst.info.
...（TLD列挙は省略）...

example.org. 3600  IN NS  <ns1>.ns.cloudflare.com.
example.org. 3600  IN NS  <ns2>.ns.cloudflare.com.

;; UDP setup with 2606:...#53(<ns1>...) failed: network unreachable.
;; no servers could be reached
...（IPv6到達不可っぽいログ）...

example.org. 86400 IN NS  <ns1>.ns.cloudflare.com.
example.org. 86400 IN NS  <ns2>.ns.cloudflare.com.
;; Received ... bytes from <ns1>.ns.cloudflare.com in ... ms

ここで分かること👇

+trace は「親（TLD）→委任先NS」を辿るので、**“レジストラ側のNS変更が反映されたか”**を見るのに強い 💪
network unreachable は「IPv6で権威NSに当たりに行ったけど経路が無い」系のログのことがある（最後に成功してるなら IPv6だけ死んでるパターン）🧯
- 迷ったらIPv4固定：
```
dig -4 @1.1.1.1 +trace example.org NS
```

2) 権威DNSへ“直に”聞く（SOAでゾーン生存確認）

dig @<ns1>.ns.cloudflare.com example.org SOA

（マスク済み・抜粋）

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ...
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; ANSWER SECTION:
example.org. 1800 IN SOA <ns1>.ns.cloudflare.com. dns.cloudflare.com. <serial> 10000 2400 604800 1800

ここでの読み方👇

aa（Authoritative Answer）が立ってる＝権威が答えてる ✅
WARNING: recursion requested but not available は正常（権威DNSは再帰しない）🟢
SOAが返る＝ゾーンが生きてる ✅

👉 当日やるべきは、これを 旧権威 / 新権威の両方で叩いて、答えが一致してるかを見ることです。

トラブル時の考え方（切り戻しが効かない…？😇）

“戻したのに直らない”の正体あるある

ネガティブキャッシュ（NXDOMAINなどが「無い」という結果でキャッシュされる）
つまり、戻しても「しばらくダメ」に見えることがある 🌀

小規模の現実的な判断基準 🧠

権威DNSに直で聞いて一致してるのにユーザーから引けない → キャッシュ要因の可能性が高い
権威DNSで答えが一致してない / レコード欠落 → それは本当に危険。切り戻し検討 🚑

ついでに：レジストラも“モダン寄せ”すると平和 🕊️

NS切替の最後はだいたい レジストラ操作になります。
なので、レジストラが地雷UIだと、DNSが正しくても事故りやすい 😇

冬休みにやる価値があるのは👇

権限管理（2FA/複数人管理/監査）をちゃんとしたい
更新漏れ/支払い/管理者メール問題を減らしたい
APIやログが欲しい（将来IaCしたい）

「DNS移行」と「レジストラ移管」は別レイヤですが、小規模ほど“運用の楽さ”が効きます 💪

片付け（移行後にやること 🧹）

TTLを戻す（必要なら）
旧DNSは“念のため保持期間”を決めてから解約
ドキュメント化（これが一番効く）
- どこがレジストラで、どこが権威DNSで、何をどこで変えるのか

付録：チェックリスト（前日 / 当日 / 翌日）✅

前日まで

レコード棚卸し（A/AAAA/CNAME/TXT/MX/CAA/必要ならSRV…）
（あれば）HTTPS(SVCB/HTTPS, Type65) も棚卸し対象に含める
新DNSに完全コピー（差分ゼロ）
DNSSECの有無を確認（使ってるならDS周りの段取り確定）
可能ならTTLを下げる（できないなら待ち時間込みで計画）

当日（切替手順）

旧権威NSへ SOA（または代表レコード）を直叩き → 正常確認
新権威NSへ同じ問い合わせ → 旧と一致
レジストラでNS切替
dig @1.1.1.1 +trace example.org NS で委任先が新NSになったことを確認
外形確認（Web/メールなど、影響範囲に合わせて）

翌日以降

TTLを戻す（切替のために下げてた場合）
旧DNS停止のタイミングを決める（即解約しない）
手順・管理先・連絡先をメモ（未来の自分を救う）

まとめ（虎の巻 🐯）

✅ 勝ち筋は 「切替前に新旧を同じ状態にする」
✅ 当日は +trace（委任確認）＋権威直叩き（キャッシュ排除）
✅ 事故ったら 権威で答えが一致してるかで切り分ける
✅ DNSSECは別格の地雷（使ってるなら段取り必須）
✅ 冬休みはレジストラも棚卸しして“地雷UI”を卒業しよう 🎄✨