DNSの向き先の変更について

DNSの向き先変更とは、ドメイン名でアクセスしたときに、どのサーバーやサービスへ接続させるかを変更する作業です。

たとえば、example.com というドメインがある場合、利用者はこの文字列を見てアクセスしますが、実際の通信ではDNSが「このドメインはどのIPアドレスを使うか」「メールはどのサーバーで受信するか」などの情報を返しています。

つまりDNSは、ドメイン名と接続先を対応づける仕組みです。

DNSの向き先を変更するというのは、この対応関係を書き換えることを指します。

この変更によって、次のようなことができます。

• Webサイトを新しいサーバーへ切り替える
• www やサブドメインを別サービスへ向ける
• メールサーバーを変更する
• CDNや各種SaaSとドメインを接続する

DNS変更には大きく2種類ある

DNSの向き先変更には、大きく分けて2つの考え方があります。

ネームサーバーを変更する

これは、そのドメインのDNS情報をどこで管理するか自体を切り替える作業です。

たとえば、これまである事業者でDNSを管理していたものを、別のDNSサービスへ移すようなケースです。

この場合は、個別レコードを1件ずつ変更するというより、ドメイン全体のDNS管理先を切り替えることになります。

注意したいのは、ネームサーバー変更は影響範囲が広いことです。

Webサイトだけでなく、メールや認証用レコード、サブドメインなども含めて、DNS設定全体が新しい管理先へ移る前提で考える必要があります。

DNSレコードを変更する

こちらは、現在のDNS管理先をそのまま使いながら、必要なレコードだけを書き換える方法です。

たとえば、

• example.com の接続先IPアドレスを変更する
• www.example.com の接続先を別ホストへ変える
• メール受信先を変更する

といったケースです。

一般的に「DNSの向き先変更」と言うと、こちらを指すことが多いです。

よく使うDNSレコードの種類

DNS変更では、どのレコードが何を意味するかを把握しておくことが重要です。

Aレコード

Aレコードは、ホスト名をIPv4アドレスへ対応づけるレコードです。

たとえば、example.com を特定のWebサーバーのIPアドレスへ向けるときに使います。

Webサイトの移転で最もよく出てくるレコードのひとつです。

AAAAレコード

AAAAレコードは、ホスト名をIPv6アドレスへ対応づけるレコードです。

IPv6対応の環境で使用します。

考え方はAレコードとほぼ同じですが、対応するのがIPv6アドレスである点が異なります。

CNAMEレコード

CNAMEレコードは、あるホスト名を別のホスト名に向けるレコードです。

たとえば、www.example.com を別のドメイン名へ向けるようなときに利用されます。

サブドメインを外部サービスへ接続するときにもよく使われます。

ただし注意点があります。

ルートドメイン（zone apex）には、DNS標準上CNAMEを置くことはできません。

これは、ルートドメインには通常SOAやNSなど他の必須情報が存在するためです。

CNAMEは同じ名前に他のデータを併存させない前提があるため、標準的なDNSではルートドメインに設定できません。

ただし実際の運用では、DNS事業者が独自機能として、

• ALIAS
• ANAME
• CNAME flattening

などを提供しており、見かけ上はルートドメインでもCNAMEに近い運用ができる場合があります。

ただしこれは標準のCNAMEそのものではなく、各社の拡張機能です。

MXレコード

MXレコードは、メール受信先サーバーを指定するレコードです。

Webサイトの移転とは別管理であることが多いため、Webの向き先だけを変更したいときにMXレコードを不用意に変更すると、メール障害につながる可能性があります。

そのため、DNS変更時はWebとメールを別の論点として扱うことがとても重要です。

TXTレコード

TXTレコードは、テキスト情報を登録するためのレコードです。

実務では次のような用途によく使われます。

• SPF
• DKIM
• DMARC
• サービスの所有権確認
• 各種外部サービスの認証情報

TXTレコードは地味に見えますが、メール配信や認証に深く関わるため、削除や上書きのミスが起こると大きな影響が出ます。

NSレコード

NSレコードは、そのゾーンを管理する権威DNSサーバーを示すレコードです。

ただし実務で重要なのは、ドメイン全体の委任先変更は、単にゾーン内のNSレコードを書き換えるだけではなく、通常はレジストラ側で設定されているネームサーバー情報の変更が関係するという点です。

そのため、「ネームサーバー変更」と「ゾーンファイル内のNSレコード」は同じように見えて、運用上は区別して理解したほうが安全です。

DNSの向き先変更が必要になる主な場面

DNS変更は、主に次のような場面で発生します。

Webサイトのサーバー移転

旧サーバーから新サーバーへ切り替えるケースです。

この場合は、AレコードやCNAMEレコードの変更が中心になります。

サブドメインを外部サービスに接続する場合

たとえばキャンペーンページやLPを外部SaaSで運用する場合、サブドメインをそのサービス指定の接続先へ向ける必要があります。

CDNやWAFの導入

CDNやWAFの導入では、レコード変更だけで済む場合もあれば、ネームサーバー自体を切り替える方式になる場合もあります。

メールサービスの移行

Google Workspace や Microsoft 365 などへ移行する場合は、MXレコードだけでなく、TXTレコードを使ったSPF・DKIM・DMARCの設定も重要になります。

実際の変更作業の流れ

DNSの向き先変更は、単にレコードを書き換えるだけではなく、事前準備と確認が非常に重要です。

現在のDNS設定を必ず控える

まず、変更前の状態を記録します。

控えておきたい主な情報は次の通りです。

• A
• AAAA
• CNAME
• MX
• TXT
• NS
• TTL

変更対象だけでなく、できればゾーン全体の設定一覧を保存しておくと安心です。

これにより、設定漏れの防止や、トラブル時のロールバックがしやすくなります。

何を変えて、何を変えないかを明確にする

DNS変更では、変更対象を曖昧にしないことが重要です。

たとえばWebサイト移転でも、

• ルートドメインだけ変えるのか
• www も変えるのか
• サブドメインはそのままなのか
• MXやTXTは変更しないのか

を明確に切り分ける必要があります。

特に危険なのは、Web移転だけのつもりでネームサーバーまで変更し、結果としてメール設定や認証設定を引き継ぎ忘れるケースです。

TTLを事前に調整する

TTLは、DNSレコードがどれくらいキャッシュされるかの基準になる値です。

TTLを短くしておくと、変更後の浸透を早めやすくなります。

ただし、ここで重要なのは、短いTTLへの変更は切替直前ではなく、もともとの長いTTLが一巡するだけ前倒しで行う必要があるという点です。

たとえば、もともとのTTLが24時間なら、切替の直前に300秒へ変更しても、すでに古いTTLでキャッシュされている環境にはすぐ効きません。

そのため、実務では前日あるいはそれより前にTTLを下げておくことが多いです。

なお、TTLはあくまでキャッシュ時間の主要な目安であり、すべての利用者に対して同時刻に切り替わることを保証するものではありません。

新しい接続先を先に準備する

DNS変更前に、新しいサーバーやサービス側が利用可能な状態になっていることを確認します。

たとえばWebサイト移転なら、

• サイト表示
• リダイレクト
• 画像やCSSの読み込み
• フォーム送信
• CMS動作
• noindex の有無
• SSL証明書の状態

などを事前に確認します。

なお、SSL証明書については発行方式によって条件が異なります。

DNS変更前でも準備できる場合と、DNS切替後でないと発行しにくい場合があるため、この点は環境ごとに確認が必要です。

DNSレコードまたはネームサーバーを変更する

準備が整ったら、実際に設定を変更します。

Webサーバー切替ならAレコードやCNAMEの変更、DNS管理先移行ならネームサーバー変更が中心になります。

反映確認を行う

変更後は、ブラウザ表示だけでなくDNSの解決結果も含めて確認します。

確認したい主なポイントは次の通りです。

• 権威DNSで新しい値が返っているか
• 自分の環境で正しい接続先が見えているか
• www と非www の両方が正常か
• メールに影響が出ていないか
• SSLやCDNの挙動に問題がないか

反映時間についての考え方

DNS変更後の反映時間は、一律ではありません。

管理画面上では変更直後に設定が反映されたように見えても、利用者側の環境では古い情報がキャッシュされていることがあります。

そのため、ある人には新サイトが見え、別の人には旧サイトが見えるという状態が一定時間続くことがあります。

ここで重要なのは、「DNS設定を保存した時刻」と「すべての利用者に新設定が見える時刻」は一致しないということです。

TTLを短くしていれば比較的早く浸透しやすくなりますが、それでも完全な同時反映にはなりません。

よくある失敗

メールが受信できなくなる

非常によくあるトラブルです。

原因としては、

• ネームサーバー変更時にMXレコードを移していない
• SPFやDKIM、DMARCのTXTレコードを引き継いでいない
• 旧メール設定を誤って削除した

といったものがあります。

Web移転とメール設定は分けて考えることが重要です。

www だけ、またはルートドメインだけ表示されない

よくあるのは、片方のレコードだけ変更して、もう片方を旧設定のまま残してしまうケースです。

たとえば、

• ルートドメインのAレコードだけ変更した
• www のCNAMEが旧環境のまま

という状態だと、利用者によっては一部だけ正常に見えないことがあります。

旧サイトと新サイトが混在して見える

これはDNSキャッシュに起因する典型例です。

切替直後には珍しくありません。

SSLエラーが出る

新サーバー側で証明書準備が整う前に切り替えた場合や、ホスト名の扱いが新環境と一致していない場合などに起こります。

外部サービス連携が切れる

TXTやCNAMEを不用意に削除すると、

• 所有権確認
• メール認証
• SaaS連携
• サブドメイン接続

などが失敗することがあります。

レジストラとDNS管理先は同じとは限らない

実務ではこの点で混乱しやすいです。

• レジストラは、ドメインを取得・更新している事業者
• DNS管理先は、実際にレコードを編集している事業者
• 接続先サーバーは、Webやメールを提供している事業者

これらは同じ会社の場合もあれば、別々の場合もあります。

たとえば、

• ドメインはA社で取得
• DNSはB社で管理
• WebサーバーはC社
• メールはD社

という構成も珍しくありません。

そのため、DNSの向き先変更をするときは、どこの管理画面で何を変更するべきかを最初に整理する必要があります。

Aレコード変更とネームサーバー変更の違い

この2つは混同されやすいですが、影響範囲が大きく異なります。

Aレコード変更

• 接続先の一部だけを変更する
• 既存のDNS管理を維持しやすい
• Webだけを切り替えたいときに向いている

ネームサーバー変更

• DNS全体の管理先を変更する
• Web、メール、サブドメイン、認証設定も含めて移行が必要
• 影響範囲が広く、慎重な設計が必要

そのため、単純なWeb移転であれば、まずはAレコードやCNAME変更で済むかを検討するほうが安全なことが多いです。

安全に進めるための考え方

DNS変更では、次の考え方が非常に重要です。

• 変更前の設定を必ず保存する
• Webとメールを分けて考える
• 変更対象を明確にする
• TTLは前倒しで調整する
• 新環境を先に確認する
• 切替後の確認項目を事前に決めておく
• 問題時のロールバック手順を用意する

ロールバックとは

ロールバックとは、トラブルが発生したときに元の設定へ戻すことです。

たとえば、

• Aレコードを元のIPアドレスへ戻す
• ネームサーバー設定を元へ戻す
• MXやTXTを旧設定へ復元する

といった対応です。

DNSではロールバックしても即座に全利用者へ一斉反映されるわけではありませんが、元設定を正確に控えておくことで復旧をかなり早められます。

まとめ

DNSの向き先変更とは、ドメイン名が案内する先を、新しいサーバーやサービスへ切り替えるための設定変更です。

基本的な考え方としては、

• Web表示先は主にAレコードやCNAMEレコード
• メールはMXやTXTが重要
• ネームサーバー変更はレコード変更より影響範囲が広い
• TTLは反映速度に関係するが、即時反映を保証するものではない
• 変更前の控えとロールバック準備が非常に重要

という点を押さえておくと、実務で大きなミスを避けやすくなります。

以上、DNSの向き先の変更についてでした。

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