DNS 伝播の基本と移行手順
最終更新: 2026-04-24 · 所要 6 分
結論
- 移行前に TTL を短く(300 秒程度)しておく
- 複数 resolver で確認 — 1 台だけ見ても判断できない
- dig +trace で権威側まで遡って真実を見る
どういう場面で必要か
DNS サービス変更 / レジストラ移管 / サーバ切り替え / DNS レコード追加時に、いつ / どの resolver から見えるかを見極めたい時。
実務で見るポイント
- TTL: 直前 1-2 週間前から 3600 → 300 に短縮しておく
- dig: ローカル resolver でなく 8.8.8.8 / 1.1.1.1 / 権威 NS を指定
- dig +trace: 親 NS → 子 NS を追跡し、権威側が正しい値を返しているか確認
- /tools/dns-propagation: 6 resolver 同時並列確認で全体像把握
- 変更後も TTL を 3600 に戻さず、しばらく短いまま監視
よくある失敗
- TTL を短くせずに移行して、誤レコードが数時間 cache されて事故
- ローカル DNS の cache を見て「反映された!」と思う(flush していない)
- 権威 NS 変更(NS レコード移行)時に古い NS を先に削除して到達不能に
- レジストラ側と DNS サービス側の NS 設定不一致
チェックリスト
- [ ] 変更 24h 以上前に TTL を 300 に下げた
- [ ] /tools/dns-propagation で複数 resolver の一致確認
- [ ] dig +trace で権威 NS に正しい値
- [ ] 切り戻し手順と条件を事前合意
- [ ] メール送受信テスト(MX 変更時)
よくある質問
TTL 短縮はどれくらい前から?
理想は 1 週間、最低 24 時間前。それ以前から TTL が長いと、短い TTL 自体が伝播するまで待つ必要があります。
dig +trace が途中で止まる
ファイアウォール / NAT の問題が多いです。別ネットワーク / クラウド上の踏み台から dig を叩いて再確認してください。
DNSSEC 移行で気をつけるポイントは?
子ゾーンの DS と親ゾーンの DNSKEY の整合性が失われると全面解決不能になります。両方の変更タイミングをマニュアルで同期し、事前にテストゾーンで練習してください。
CDN(Cloudflare 等)経由での CNAME フラット化は?
ルートドメインは CNAME 不可ですが、Cloudflare や一部 DNS サービスは ANAME / ALIAS / CNAME フラット化で対応可能です。