ネームサーバー切替の実用フロー ― DNS伝播トラブルを起こさない6ステップ

ドメインのネームサーバー(NS)切替は，たった数クリックの操作なのに，油断するとサイト停止やメール不達を生む．本記事では，DNS伝播トラブルを起こさない6ステップを整理する．

この記事では，個人開発者・スモールチーム・学生エンジニアの方を主な読み手として書いています．10分で読み終わって，明日から動ける具体的な行動が1つ見つかる状態を目指しています．

なぜネームサーバー切替で事故が起きるのか

DNSは「設定したら即時反映」ではなく，世界中のキャッシュサーバーに浸透するまで最大48時間かかります．旧NSと新NSでレコードが食い違うと，一部ユーザーには旧サイト，一部には新サイトが見える「分断」状態が発生する．

もっと厄介なのはメール．MXレコードが見えなくなる時間帯のメールは，送信者にエラーが返ることなくそのまま消滅することがある．取引先からの重要メールが「届かなかった」と後で発覚するのが最悪のシナリオです．

切替前に，旧NS側のすべてのレコード(A / AAAA / CNAME / MX / TXT / SRV)をエクスポートします．スクリーンショットではなく，テキストとして残すこと．後で grep できる形が望ましい．

dig @旧NS example.com ANY や dig +noall +answer example.com で照合する習慣を持つと，「見落とし」を最小化できる．

TTL(Time To Live)は，各DNSキャッシュがレコードを保持する秒数．デフォルトの3600〜86400秒のまま切り替えると，問題が起きてもキャッシュが切れるまで戻せない．

切替の3日前に旧NSの全レコードのTTLを300(5分)に下げる．こうしておけば，万一の切り戻しが5分で効く．切替が安定したら通常値に戻せばよい．

NSを切り替えた瞬間，新NSに登録されていないレコードは世界から消える．サブドメインやメール用TXT(SPFなど)を忘れるのが定番の事故．

ステップ1のバックアップを基準に，新NS側に全レコードを反映．切替前にdig @新NSで新NSの応答を直接叩いて検証する．レジストラ側のNS切替ボタンは，検証が終わるまで押さない．

ここでようやくレジストラ管理画面でNSを変更．切替直後から世界中で順次伝播が始まる．国内のISPは早ければ数十分，海外含めると24-48時間が目安．

重要なのは，旧NSのレコードを「即削除しない」こと．48時間は両系で同じ内容のレコードを保持する．これだけで「分断」事故の8割は防げる．

自分の環境(自宅・会社)だけで dig しても，それは1点の観測に過ぎない．世界中のDNS解決を多地点で確認するには whatsmydns.net や dnschecker.org が便利．

CLI派は dig @8.8.8.8(Google) @1.1.1.1(Cloudflare) @208.67.222.222(OpenDNS)を順に叩いて差を見る．全部が新IPを返したら，伝播は実質完了．

切替から48時間が経過し，多地点でも新NSの応答が確認できたら，旧NSを停止．そしてTTLを3600以上に戻す(キャッシュ効率のため)．

このタイミングで，変更履歴を必ず残す．「いつ・どのレコードを・何から何に変えたか」をテキストで保存．次回の切替で過去の自分が助けてくれる．

ネームサーバー切替の事故が怖いのは，ドメインが本人の資産であり，事業の核だからです．SNSは仕様変更で振り回されますが，独自ドメインの上に積み上げた信頼は永続資産として残ります．

これからドメインを取るなら，取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ が国内最安級．管理画面でレコードの一括エクスポート／インポートに対応しており，本記事の6ステップをそのまま実行できるのが個人開発者向きです．

ドメインに紐づけるサーバーは，同じペパボグループのロリポップ！がコスト・操作性ともに個人開発者向き．切替時に問い合わせると切替手順書まで案内してくれることが多く，初心者でも事故りにくい．

金曜の夜は避ける．何かあったとき土日に対応する羽目になる．火曜の午前あたりがリカバリ余地がある．

ルートドメイン(example.com)にCNAMEは原則NG．ALIAS / ANAMEレコードに対応するDNSサービスを選ぶ．

個人サイトなら任意．有効化する場合はNS切替時に一度OFF→新NSで再ON．切替中はOFFが鉄則．

大事なのは，「正解を完璧に押さえる」ことではなく「動き始める」ことです．TTLを下げる，バックアップを取る，旧NSを48時間残す．この3つを守るだけで，事故率は劇的に下がります．