DNSは、普段はほとんど意識しません。

でもメールサーバーやWebサーバーを移行すると、一気に重要になります。

私は実際に、ドメイン管理、メールサーバー、Webサーバーが別々になっている構成を整理し、メール環境を切り替える準備をしたことがあります。

そこで感じたのは、DNSは「言われた値へ書き換えるだけ」と考えると危ないということです。

Contents
  1. 最初に「誰がDNSを管理しているか」を確認する
  2. 現在のレコードを全部保存する
  3. 変更目的を一つずつ整理する
  4. メールとWebを混同しない
  5. MXだけ見れば終わりとは限らない
  6. 反映には時間差がある前提で考える
  7. 切戻し値を準備する
  8. 作業者と確認者を分ける
  9. 変更日時を記録する
  10. 社員への影響を想定する
  11. ベンダーへ聞くときは構成図が役立つ
  12. 私の環境では、wwwあり・なしやSSLまで確認が必要でした
  13. まとめ

最初に「誰がDNSを管理しているか」を確認する

ドメインを契約している会社と、実際のDNS設定を管理している場所が同じとは限りません。

現在のレコードを全部保存する

変更対象だけでなく、A、MX、TXT、CNAMEなど現在値を記録します。

スクリーンショットとテキストの両方があると戻しやすくなります。

変更目的を一つずつ整理する

「メール移行のため」「Webの向き先変更のため」など、レコードごとの目的を明確にします。

メールとWebを混同しない

同じドメインでも、Webサイトとメールは別のサーバーへ向いていることがあります。

どの変更がどのサービスに影響するか確認します。

MXだけ見れば終わりとは限らない

メールでは認証用TXTレコードなど複数の設定が関係することがあります。

反映には時間差がある前提で考える

DNS変更後、全員が同時に新しい状態になるとは限りません。

切替日には確認時間を確保します。

切戻し値を準備する

新環境で問題が出たとき、どの値へ戻せばよいかを変更前に決めます。

作業者と確認者を分ける

可能なら、入力した人とは別の人が値を照合します。

変更日時を記録する

トラブル発生時刻とDNS変更時刻を比較できるようにします。

社員への影響を想定する

メール停止、Webアクセス、スマホ再設定など、変更当日に起こり得る問い合わせを整理します。

ベンダーへ聞くときは構成図が役立つ

「メールが届きません」だけでなく、ドメイン・DNS・旧環境・新環境の関係を図にすると話が早くなります。

私の環境では、wwwあり・なしやSSLまで確認が必要でした

実際に構成を整理したとき、Webサイトは過去に別サーバーへ移行していましたが、メールは旧環境側に残っていました。

さらに、名刺などではwwwありのURLを使っている一方、現在のWeb公開先はwwwなしを基準にしており、転送やSSLの関係も確認する必要がありました。

このような環境では、DNS変更の前に次の関係を図にしておくと安全です。

  • wwwありのアクセスは最終的にどこへ行くか
  • wwwなしはどのWebサーバーへ向いているか
  • SSL証明書はどのホスト名・環境で使われているか
  • メールのMXレコードはどこを向いているか
  • メール変更がWebのA/CNAMEへ影響しないか

メールをExchange Onlineへ切り替えるだけでも、DNS全体を見ずに作業するとWeb側まで影響させる可能性があります。

だから私は、変更するレコードだけを見るのではなく、変更しないレコードも含めて現在値を保存するようにしています。

実際のメール移行準備は、メールサーバー移行で総務が確認することでも整理しています。

まとめ

DNS変更では、管理先・現在値・変更目的・影響範囲・反映時間・切戻しを確認してから作業します。

メールサーバー移行で総務が確認することも参考にしてください。