DNSサーバーの移行の注意点について

DNSサーバーの移行は、単にネームサーバーやDNSレコードを書き換える作業ではありません。

実際には、Webサイト、メール、SSL証明書、自動更新、外部SaaS連携、各種認証レコードなどに幅広く影響するため、事前準備と切り替え後の監視が非常に重要です。

特に、権威DNSそのものを別サービスへ移す場合は、設定漏れや仕様差による障害が起きやすくなります。

DNS移行でまず区別したい2つのケース

DNS移行といっても、実務では主に次の2種類があります。

権威DNSの移行

例

• さくらのDNSからCloudflare DNSへ移す
• オンプレミスDNSからRoute 53へ移す

この場合は、ドメインに設定されているネームサーバー（NS）の委任先を変更します。

影響範囲が広く、もっとも慎重な対応が必要です。

同じDNS基盤内でレコードだけ切り替える

例

• www.example.com のAレコードを旧Webサーバーから新Webサーバーへ変更する
• メールのMXを新サービスへ切り替える

こちらはネームサーバー自体は変えないため、権威DNS移行よりは影響範囲を限定しやすいですが、それでもTTLや依存サービスへの配慮は必要です。

最重要ポイント

現在のDNSレコードを漏れなく棚卸しする

移行前に最優先で行うべきなのは、現在使われているDNSレコードの完全な洗い出しです。

よくある失敗は、Webサイト用のAレコードやCNAMEだけを確認して安心してしまい、実際には次のような重要レコードを見落とすことです。

• A
• AAAA
• CNAME
• MX
• TXT
• NS
• CAA
• SRV
• DKIM用TXTまたはCNAME
• SPF用TXT
• DMARC用TXT
• ACME challenge用TXT
• 各種認証用TXT
• SaaS連携用サブドメイン

見落としやすい具体例としては、次のようなホスト名があります。

• mail.example.com
• smtp.example.com
• autodiscover.example.com
• _dmarc.example.com
• selector1._domainkey.example.com
• _acme-challenge.example.com
• _sip._tcp.example.com
• api.example.com
• lp.example.com
• dev.example.com
• stg.example.com

なお、PTRレコード（逆引き）は、正引きゾーンとは別の管理主体になっていることが多く、移行対象外の場合もあります。

ただし、メール送信基盤などでは逆引き整合性が重要になるため、必要な環境では別途確認が必要です。

実務でおすすめの整理項目

• ホスト名
• レコード種別
• 値
• TTL
• 用途
• 利用サービス
• 移行要否
• 切り替え後の確認方法

TTLは事前に下げる

DNS移行では、TTL（Time To Live） の扱いがとても重要です。

TTLは、そのDNSレコードを再帰リゾルバなどがどれだけキャッシュしてよいかを示す値です。

たとえばTTLが86400秒なら、変更後もしばらく古い情報が使われる可能性があります。

ただしこれは「必ず24時間全員が古い情報を見る」という意味ではなく、実際の見え方は以下に左右されます。

• 変更前にいつ取得されたか
• 利用している再帰リゾルバ
• リゾルバのキャッシュ状態
• ネガティブキャッシュの影響

そのため、切り替えをなめらかにしたい場合は、移行の24〜72時間前にはTTLを短くしておくのが一般的です。

よくあるTTLの考え方

• 通常運用: 3600〜86400秒
• 移行前: 300〜600秒程度
• 安定後: 通常値へ戻す

注意点

TTLを切り替え直前に下げても、すでに長いTTLでキャッシュされている情報にはすぐ反映されません。

そのため、TTL短縮は余裕を持って先に実施する必要があります。

新DNSに設定を再現してからネームサーバーを切り替える

権威DNSを移行する場合は、新しいDNSサービス側に現在のゾーン情報を先に再現してから、最後にNSを切り替えるのが基本です。

やってはいけない順序は次の通りです。

• 先にNSを変更する
• その後、新DNSへ必要なレコードを追加していく

このやり方だと、切り替え直後に問い合わせが来たとき、新しい権威DNSに必要なレコードが存在せず、障害になります。

安全な順序

1. 現行レコードを棚卸しする
2. 新DNSへ必要なレコードを投入する
3. 旧環境との差分を確認する
4. テストする
5. NSを切り替える
6. 切り替え後に監視する

DNS事業者ごとの仕様差に注意する

DNSは標準化された仕組みですが、各DNSサービスの管理画面や実装には差があります。

「同じに見える設定」がそのまま同じ意味になるとは限りません。

代表的な注意点は以下です。

• 末尾ドットの扱い
• ルートドメインの表記方法（@、空欄など）
• MX priorityの入力方式
• TXTレコードの分割表示
• ワイルドカードの扱い
• CAAレコード入力方式
• ALIAS / ANAME / CNAME flattening の有無
• DNSSEC対応手順
• API仕様の違い

特に注意したいのが、ルートドメイン（apex）へのCNAME相当設定です。

DNSの標準仕様上、ゾーン頂点にはSOAやNSなど他のレコードが必要になるため、通常のCNAMEをそのまま置けないケースがあります。

一方で、DNSプロバイダによっては ALIAS、ANAME、CNAME flattening などの独自実装で同等の運用を可能にしています。

つまり、旧DNSで成立していた設定が、新DNSでは別方式に置き換えないと再現できないことがあります。

CNAMEまわりの制約を理解しておく

DNS移行でよく起きるトラブルのひとつが、CNAMEの扱いミスです。

注意点

• ある名前にCNAMEを置く場合、その名前に他のレコードを共存させてはいけない
• MXやNSの参照先にCNAMEを使うのは避けるべき
• apexでのCNAME運用は、標準CNAMEではなく事業者独自実装の場合がある

一見すると管理画面上では設定できそうに見えても、仕様上問題がある組み合わせはあります。

DNSサービスを変えるときは、この制約が顕在化しやすいです。

メール関連レコードは最優先で確認する

Webサイトの停止はすぐ気づきますが、メール障害は気づくのが遅れやすいため、DNS移行では特に注意が必要です。

確認対象は以下です。

• MX
• SPF
• DKIM
• DMARC
• autodiscover
• smtp
• imap
• pop
• Google Workspace / Microsoft 365 などの認証レコード

よくある事故

• MX未設定で受信できない
• SPF崩れで迷惑メール扱いされる
• DKIM未移行で署名に失敗する
• DMARC不整合でメールが拒否される
• autodiscover不足でクライアント自動設定が失敗する

BtoB運用では、Web停止よりもメール不達のほうが事業影響が大きい場合もあります。

そのため、メール関連はWebレコード以上に慎重な確認が必要です。

DNSSEC利用中なら慎重に進める

DNSSECを利用しているドメインでは、移行難易度が一段上がります。

権威DNS側の署名状態と、レジストラ側に登録されているDSレコードの整合が崩れると、名前解決障害につながる可能性があります。

確認したいこと

• 新DNSがDNSSECに対応しているか
• DNSSECを継続利用するか、一時的に無効化するか
• DSレコード更新手順
• 新権威DNS側で署名が正しく提供されるか

DNSSECは理解があいまいなまま本番切り替えをすると危険です。

利用している場合は、事前検証を強く推奨します。

SSL証明書更新と _acme-challenge を確認する

Let’s Encrypt などの証明書更新がDNSに依存している場合、移行後すぐではなく、数日後や更新タイミングで障害が表面化することがあります。

典型例

• DNS-01で使う _acme-challenge TXTレコードの移行漏れ
• HTTP-01の参照先が旧環境のまま
• CAAレコードの不整合で発行不可
• CDNやロードバランサ側の証明書発行条件変更

表示は正常でも、後から更新失敗で証明書エラーになることがあるため、現在の証明書発行方式を事前に確認しておくべきです。

CDN・WAF・SaaS連携の依存関係を確認する

DNSは、単なる名前解決だけでなく、多くの外部サービスとの接点にもなっています。

特に次のようなサービスを利用している場合は要確認です。

• Cloudflare
• Akamai
• Fastly
• CloudFront
• Azure Front Door
• Google Cloud Load Balancer
• Shopify
• HubSpot
• Salesforce
• Marketo
• Zendesk
• 各種MA・CRM・フォーム・計測サービス

よくある影響

• LP用サブドメインだけ表示されない
• トラッキング用CNAMEが止まる
• フォーム送信ドメイン認証が切れる
• CDN/WAFの向き先が不整合になる

NS切り替え後は旧・新の経路がしばらく混在しうる

ネームサーバーを変更しても、全世界で同時に一斉切り替えされるわけではありません。

しばらくの間は、再帰リゾルバごとのキャッシュ差 によって、

• 旧権威DNSへ問い合わせる経路
• 新権威DNSへ問い合わせる経路

が混在する可能性があります。

このため、移行中は理想的には 旧環境と新環境の両方で問題なく応答できる状態 を維持できると安全です。

ただし、すべての構成で完全な並行稼働が可能とは限りません。

もし二重稼働が難しい場合は、次の対策が必要です。

• 切り戻し手順を明確にしておく
• 旧DNSや旧サーバーをすぐ削除しない
• 監視を厚くする
• 障害時の連絡体制を決めておく

ネガティブキャッシュにも注意する

DNSでは、存在しないという応答も一定時間キャッシュされる場合があります。

そのため、新しいレコードを追加したのに、一部環境ではしばらく見えないことがあります。

これは通常のTTL短縮だけでは説明しきれない現象なので、移行時には「存在しなかった名前を新たに作るケース」にも注意が必要です。

変更を同時に重ねすぎない

DNS移行時にトラブルが増えるのは、複数の変更を同時に実施した場合です。

危険な例

• DNS基盤変更
• Webサーバー移転
• CDN導入
• SSL更新
• メール基盤変更
• WAF変更
• ルートドメインの向き先変更

これらを同日にまとめて行うと、障害発生時に原因切り分けが非常に難しくなります。

理想的な進め方

• 先にDNS基盤だけ移す
• 安定確認後にWebの向き先を変える
• メールは別タイミングで切り替える

移行前チェックリスト

現行調査

• 全レコードを一覧化したか
• サブドメインを棚卸ししたか
• メール関連を確認したか
• 各種認証TXT/CNAMEを確認したか
• DNSSEC利用有無を確認したか
• TTLを事前に短縮したか
• レジストラ管理権限を確認したか

新環境準備

• 新DNSへ必要レコードを投入したか
• 旧環境との差分確認を行ったか
• apex設定方式を確認したか
• ワイルドカードを確認したか
• CAAの影響を確認したか

テスト

• 権威DNSを直接指定して確認したか
• Web、メール、API、サブドメインを確認したか
• 証明書や自動更新方式を確認したか
• 外部SaaS認証や計測用ドメインを確認したか

切り替え当日の注意点

作業時間を選ぶ

アクセスが少なく、かつ関係者がすぐ動ける時間帯が望ましいです。

単純に深夜がよいとは限らず、障害時に対応できる体制があるかが重要です。

作業記録を残す

• 変更時刻
• 変更内容
• NS変更時刻
• テスト結果
• 問題発生時刻
• 切り戻し判断

これを残しておくと、障害時の切り分けが速くなります。

切り戻し条件を先に決める

たとえば以下のように明確にします。

• 主要サイトが一定時間以上到達不可
• メール送受信異常が確認された
• APIエラー率が閾値を超えた
• SaaS認証障害が発生した

切り替え後にやること

DNS移行は、設定を書き換えた時点では完了ではありません。

監視して安定を確認するまでが移行です。

最低限の確認項目

• ルートドメインが開くか
• www が開くか
• 主要サブドメインが開くか
• HTTPS証明書が正常か
• メール受信できるか
• メール送信できるか
• SPF / DKIM / DMARC が整合しているか
• フォーム送信が正常か
• API接続が正常か
• CDN / WAF が正常か
• 計測用ドメインが機能しているか

監視期間

少なくとも24〜72時間は注意深く監視するのが安全です。

TTLやキャッシュの影響で、問題が遅れて表面化することがあります。

よくある障害

Webサイトが表示されない

• A / AAAA設定ミス
• CNAME向き先ミス
• apex設定方式の不整合
• 旧サーバー停止が早すぎた
• CDN設定不足

一部ユーザーだけつながらない

• 再帰リゾルバのキャッシュ差
• TTL未調整
• AAAAの設定漏れ
• 古い経路の残存

メールが届かない

• MX未設定
• 優先度設定ミス
• 関連ホスト名不足
• 外部メールサービス認証漏れ

送信メールが迷惑メール扱い

• SPF崩れ
• DKIM未移行
• DMARC不整合
• 送信経路変更への対応不足

証明書更新が失敗する

• _acme-challenge 移行漏れ
• CAA不整合
• 参照先が旧環境
• 自動更新設定の前提崩れ

まとめ

DNSサーバー移行で重要なのは、次の5点です。

1. 現在のDNSレコードを用途込みで漏れなく棚卸しする
2. TTLを余裕を持って事前に下げる
3. 新DNSへ完全に再現してからNSを切り替える
4. メール、DNSSEC、証明書、自動更新、SaaS連携を軽視しない
5. 切り替え後もしばらく監視し、旧環境をすぐ止めない

DNS移行は、成功していればユーザー影響を最小化できます。

一方で、準備不足だとWeb、メール、証明書、計測、外部連携に同時に影響が出ます。

そのため、設定変更そのものよりも、棚卸し・検証・監視の精度 が成否を分けます。

以上、DNSサーバーの移行の注意点についてでした。

最後までお読みいただき、ありがとうございました。