📌 この記事は旧記事の改良版（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”を卒業しよう 🎄✨