〜暮らしの落書き帳〜

DNS設定変更前に記録する項目

DNS設定変更前に記録する項目 副業・Web制作
2026.08.25

なぜDNS設定を変更する前に「記録」が必要なのか

DNS設定の変更は、ドメイン移管、サーバー移転、メールサービスの切り替え、SSL証明書の設定変更など、さまざまな場面で発生します。しかし、DNSの管理画面上で既存のレコードを削除したり書き換えたりしてしまうと、変更前の値を確認する手段がなくなってしまうことがあります。変更履歴を確認できる機能を備えたサービスもありますが、保存期間や表示できる項目はサービスによって異なり、必要な情報がすべて残っているとは限りません。

DNS設定変更前に記録する項目 関連画像1

もし変更後にサイトが表示されなくなったり、メールが届かなくなったりした場合、元の設定に戻すことが最短の復旧手段になります。ところが、元の値を正確に把握していなければ、正しい復旧作業ができません。本記事では、DNS設定を変更する前に記録しておくべき代表的なレコードの種類と、記録すべき具体的な項目、記録の実例、復旧時の使い方、そして実際にありがちな失敗例までをまとめます。

DNSレコードとは何か(前提の整理)

DNSレコードとは、ドメイン名とサーバーやサービスの情報を結びつけるための設定情報です。ドメインに対して「どのサーバーに接続するか」「どのメールサーバーに配送するか」「所有権をどう証明するか」といった役割ごとに、異なる種類のレコードが用意されています。Cloudflareの公式ドキュメントでも、DNSレコードは種類ごとに目的と設定項目が明確に分かれていると説明されており、変更前に記録すべき対象もこの種類ごとに整理すると漏れが少なくなります。

変更前に記録しておきたい代表的なDNSレコード

Aレコード

Aレコードは、ドメイン名をIPv4アドレスに紐づけるレコードです。Webサイトの表示先サーバーを指定する、最も基本的なレコードの一つです。記録すべき項目は次のとおりです。

  • ホスト名(例:@、www、blog など、サブドメインの有無を含む)
  • 設定されているIPv4アドレスの値
  • TTL(秒数)
  • プロキシ設定の有無(Cloudflareなど、プロキシ機能を利用しているサービスの場合)

AAAAレコード

AAAAレコードはAレコードのIPv6版で、ドメイン名をIPv6アドレスに紐づけます。IPv6環境からのアクセスに対応しているサイトでは設定されていることが多いため、Aレコードと同様にホスト名・値・TTLを記録します。IPv6アドレスは表記ゆれ(省略記法)が発生しやすいため、管理画面に表示されている値をそのままコピーして残しておくことが重要です。

CNAMEレコード(別名レコード)

CNAMEレコードは、あるホスト名を別のドメイン名(正規名/カノニカル名)の別名として登録するレコードです。ここで注意したいのは、CNAMEはアクセスを別のサーバーへ「転送」する仕組みではないという点です。DNSの基本仕様を定めたRFC 1034では、CNAMEは正規名の「別名(alias)」であり、リゾルバはCNAMEに出会うと、そのRDATAに記載された正規名を使って名前解決をやり直すと定義されています。つまりCNAMEは、通信そのものを中継するのではなく、名前解決の段階で「このホスト名の実体は、あのホスト名である」と示すための仕組みです。実際にA/AAAAレコードで応答されるIPアドレスは、最終的に解決された正規名側に設定された値になります。

またRFC 1034は、あるノードにCNAMEレコードが存在する場合、そのノードには他の種類のレコードを併存させるべきではないとも定めています。これは、正規名とその別名とで参照先のデータが食い違うことを防ぐための規定です。CDNサービスや外部フォームサービス、サブドメインを使ったサービス連携などでCNAMEは多用されるため、見落としやすいレコードでもあります。記録すべき項目は以下のとおりです。

  • ホスト名(サブドメイン名)
  • 参照先(正規名)のドメイン名
  • TTL

なお、MXレコードやNSレコードの参照先には、CNAMEで定義された別名を指定できません。DNS仕様を補足するRFC 2181は、NSレコードの値やMXレコードが指すホスト名はエイリアス(別名)であってはならず、A/AAAAレコードを直接持つホスト名を指定する必要があると明記しています。これに反してCNAME先を指定すると、メールサーバーやネームサーバーの名前解決で余計な問い合わせが発生したり、一部のメールサーバーがそのドメインへの配送を拒否したりする原因になります。DNS変更を記録・再設定する際は、MXやNSの参照先が正しくA/AAAAレコードを持つホスト名になっているかも合わせて確認しておくと安全です。

MXレコード

MXレコードは、そのドメイン宛のメールをどのメールサーバーへ配送するかを指定するレコードです。Google Workspaceのヘルプ記事では、複数のMXレコードを設定できる場合、それぞれに優先度(プリファレンス値)を設定でき、値が小さいレコードほど優先的に使用されると説明されています。メールが届かなくなるトラブルは業務影響が大きいため、特に慎重な記録が必要です。

  • ホスト名(通常は@、ドメイン直下)
  • メールサーバーのホスト名(メールエクスチェンジャ。前述のとおりA/AAAAレコードを持つ実在のホスト名である必要がある)
  • 優先度の数値(複数ある場合はすべて)
  • TTL

TXTレコード

TXTレコードは、ドメインに任意のテキスト情報を関連付けるレコードです。Cloudflareの公式ドキュメントでは、TXTレコードはメール認証(SPFやDKIMなど)や、サービスの所有権確認に使われることが多いと説明されています。Google Workspaceでも、ドメインの所有権確認はTXTレコードを使って行う方法が案内されており、管理側が該当のTXTレコードを検出できた時点で検証が完了する仕組みになっています。TXTレコードは1つのホスト名に複数存在することが多く、内容が長い文字列であるため、次の点を漏れなく記録します。

  • ホスト名
  • レコードの内容(文字列全体。前後の引用符やスペースを含めて正確に)
  • 用途がわかる場合はメモ(SPF、DKIM、所有権確認など)
  • TTL

NSレコードなど、あわせて確認したいレコード

ネームサーバー自体を変更する場合は、現在設定されているNSレコードの値も必ず記録します。加えて、SRVレコードやCAAレコードなど、サービス固有の設定を利用している場合はそれらも対象になります。使っているサービスの管理画面で、現在どのレコードが登録されているかを一覧表示し、抜け漏れがないか確認したうえで記録範囲を決めることが望ましい進め方です。

スクリーンショットだけでなく、テキストでも記録する

DNS設定を記録する際、多くの人は管理画面のスクリーンショットを撮って済ませがちです。しかし、スクリーンショットだけでは次のような問題が起こり得ます。

  • 画像内の文字が小さく、値を正確に読み取れないことがある
  • コピー&ペーストができないため、復旧作業時に手入力が必要になり、入力ミスが起きやすい
  • IPv6アドレスやTXTレコードの長い文字列など、視認性の低い値で誤読が起きやすい

そのため、スクリーンショットに加えて、テキスト形式(メモ帳やスプレッドシートなど)でホスト名・種別・値・TTL・優先度をそのままコピーして保存しておくことを推奨します。テキストであれば検索もでき、復旧作業のときにそのまま貼り付けて再設定できるため、作業時間の短縮とミスの防止につながります。

記録の実例(テンプレート)

実際の記録は、以下のような一覧形式で残しておくと復旧作業がスムーズです。

種別ホスト名値TTL優先度備考
A@203.0.113.103600–本番サーバー
Awww203.0.113.103600–本番サーバー
CNAMEblogexample-cdn.net3600–外部CDN連携(正規名)
MX@mail1.example-mail.com360010メイン
MX@mail2.example-mail.com360020バックアップ
TXT@“v=spf1 include:example-mail.com ~all”3600–SPF

この形式で記録しておけば、変更後に問題が発生した際も、同じ表を見ながら一つずつ元の値に戻すだけで復旧作業を進められます。あわせて「記録した日時」「記録者」「変更予定の内容」もメモしておくと、後から見返したときに状況を把握しやすくなります。

復旧時に記録をどう使うか

DNS変更後に不具合が発生した場合、復旧の基本的な流れは次のようになります。

  1. 現在のDNS設定を確認し、記録しておいた値との差分を特定する
  2. 差分のあるレコードだけを、記録していた値に戻す
  3. 変更を保存した後、反映を待ちながら状態を確認する
  4. 正常に戻ったことを確認できたら、原因を整理してから再度変更に着手する

ここで記録が重要になるのは、「どこを変更したか」が明確であれば、疑わしい箇所を絞り込んで対処できる点です。記録がなければ、どのレコードが原因かを切り分けるところから始めなければならず、復旧までの時間が大きく伸びてしまいます。特にMXレコードやTXTレコード(SPFなど)は、メール不達という気づきにくい形で問題が表面化することもあるため、事前記録の有無が復旧スピードを大きく左右します。

DNS変更でよくある失敗例

失敗例1:TXTレコードの上書き忘れによるメール認証エラー

SPFレコードなどのTXTレコードは、1つのホスト名に対して複数の送信元をまとめて1つの値に記述する必要がある場合があります。既存のTXTレコードの内容を確認せずに新しい値だけを追加・上書きしてしまうと、既存の認証設定が壊れ、正規のメールが迷惑メール扱いになったり届かなくなったりすることがあります。事前にすべてのTXTレコードの内容を記録しておけば、どの値を残し、どの値を統合すべきかを判断しやすくなります。

DNS設定変更前に記録する項目 関連画像2

失敗例2:MXレコードの優先度を記録せずに再設定し、メール配送順が変わる

MXレコードには優先度の数値があり、値が小さいほど優先して使用されます。優先度を記録せずに再設定してしまうと、意図しないサーバーが優先的に使われる状態になり、メールの配送経路が変わってしまうことがあります。設定前に、すべてのMXレコードの優先度をセットで記録しておくことが欠かせません。

失敗例3:CNAMEの参照先を書き換え、外部サービス連携が切れる

フォームサービスやCDNとの連携でCNAMEレコードを使っている場合、参照先(正規名)のドメイン名を正確に控えていないと、再設定時にタイプミスや古い値の入力が起こり、名前解決の段階で連携先を見失ってサービスとの連携が切断されることがあります。CNAMEの参照先は文字列が長く読み間違えやすいため、テキストでのコピー保存が特に有効です。

失敗例4:MXやNSの参照先をCNAMEの別名に向けてしまう

移行作業の中で、MXレコードやNSレコードの参照先に、CNAMEで定義された別名ホスト名をそのまま指定してしまうケースがあります。RFC 2181が定めるとおり、MX・NSの参照先はA/AAAAレコードを直接持つホスト名でなければならず、別名を指定すると想定どおりに機能しない、あるいは一部のサーバーで配送や名前解決が拒否される可能性があります。変更前に、MX・NSの参照先が実在のホスト名(別名でないもの)であることを記録・確認しておくと、再設定時にこの種の設定ミスを避けられます。

失敗例5:TTLの長いレコードを直前に変更し、切り戻しに時間がかかる

TTLが長く設定されているレコードを変更した直後に問題が発覚し、慌てて元に戻しても、キャッシュしているリゾルバがすぐには新しい値を反映してくれないことがあります。Cloudflareの公式ドキュメントでは、TTLはレコードがキャッシュされる長さを制御するフィールドであり、TTLが長いほど更新の反映に時間がかかると説明されています。重要な変更を行う前に、あらかじめTTLを短く設定しておく運用が推奨される理由はここにあります。

DNSの反映時間について

DNS変更がインターネット全体に反映されるまでの時間は、単純に「何時間」と言い切れるものではありません。反映時間に幅が生まれる主な要因は、次のとおりです。

  • 変更したレコードに設定されていたTTLの長さ(TTLが長いほど、古い値がキャッシュされ続ける時間も長くなる)
  • 利用しているISPやリゾルバの挙動(TTLの指定どおりに更新されない、独自の間隔でキャッシュを保持するケースがある)
  • ドメインのレジストリ側の反映(ネームサーバー自体を変更する場合、上位のサーバーへの反映にも時間がかかる)

Cloudflareの公式ドキュメントでは、ゾーンファイルへの変更自体は通常5分以内に全世界へ反映されるとしつつも、以前のレコードに設定されていたTTLが長い場合は、そのTTLが切れるまで古い情報がキャッシュされ続ける可能性があると説明しています。Google Workspaceのヘルプでは、設定変更中はTTLを3600秒(1時間)程度に設定しておき、変更が完了して安定した後にTTLを86400秒(24時間)に戻すことで、クエリの負荷と反映の速さのバランスを取れると案内されています。Microsoft 365のDNSレコード作成手順では、MX・Autodiscover CNAME・SPF TXTのいずれもTTLは3600（1時間）で案内されており、さらに「Exchange Onlineがサポートするのは6時間（21,600秒）未満のTTLのみ」と明記されています。いずれの場合も、反映までの時間は変更前後のTTL値に依存します。いずれにしても、「必ず◯時間で反映される」と断定せず、TTLと利用環境によって幅があることを前提に計画を立てることが大切です。

DNS変更前チェックリスト

  • 現在登録されているA/AAAA/CNAME/MX/TXT/NSレコードをすべて洗い出したか
  • 各レコードのホスト名・値・TTL・優先度をテキストで記録したか
  • MX・NSの参照先が、CNAMEの別名ではなくA/AAAAを持つ実在のホスト名になっているか確認したか
  • スクリーンショットとテキストの両方で記録を残したか
  • 重要な変更の前に、対象レコードのTTLを一時的に短くしたか
  • 記録した日時と変更内容の予定をあわせてメモしたか

あわせて読みたい：SSL証明書の期限切れ確認と復旧手順｜有効期間短縮への備えも解説

よくある質問

管理画面のスクリーンショットだけで記録は足りますか？

スクリーンショットだけでは、細かい文字の誤読や、復旧時の手入力ミスが起きやすくなります。ホスト名・種別・値・TTL・優先度を、メモ帳や表計算ソフトにテキストでも残しておきましょう。

TTLとは何ですか？変更前に何をすればよいですか？

TTLは、ほかのサーバーがその値を覚えておく時間（秒数）です。TTLが長いと、元に戻してもすぐには反映されません。重要な変更の前は、対象のレコードのTTLを一時的に短くしておくと切り戻しやすくなります。

MXレコードの参照先にCNAMEの別名を指定してもよいですか？

指定できません。RFC 2181では、MXやNSの参照先は別名ではなく、A・AAAAレコードを持つ実在のホスト名である必要があるとされています。

DNSの変更はどのくらいで反映されますか？

一律に何時間とは言えません。変更前のTTLの長さ、利用しているプロバイダーのキャッシュの持ち方、ネームサーバー自体を変える場合は上位への反映など、いくつかの要因で幅が出ます。

まとめ

DNS設定の変更は、一見単純な作業に見えても、メールの不達やサイトの表示不良など、業務に直結するトラブルにつながりやすい作業です。A・AAAA・CNAME・MX・TXTといった代表的なレコードについて、ホスト名・値・TTL・優先度をあらかじめテキストで記録しておくことで、万が一の際にも落ち着いて元の状態へ戻すことができます。特にCNAMEは通信を転送する仕組みではなく名前解決上の別名であること、MX・NSの参照先は別名であってはならないことを正しく理解したうえで記録・再設定することが、設定ミスを防ぐポイントです。スクリーンショットだけに頼らず、コピー&ペーストできる形で正確な値を残しておくこと、そしてDNSの反映時間を固定的に捉えず、TTLや利用環境によって幅があることを理解したうえで計画的に変更を進めることが、安全なDNS運用の基本になります。

次に読むならこの1本ドメイン移管前の確認事項DNSを触る前後で関わってくる、ドメインを移す前の確認事項をまとめています。

参考情報・出典

⚡ いま読まれているトレンド

→ トレンド記事をもっと見る

広告

コメント

タイトルとURLをコピーしました