DNSとは、名前に対応する情報を分散して管理・検索する仕組み
DNS（Domain Name System）は、階層化された名前空間と分散データベースを使い、ドメイン名に対応するIPアドレス、メール配送先、ネームサーバーなどの情報を問い合わせる仕組みです。
ブラウザでexample.comを開くとき、端末は通常、キャッシュDNS（再帰リゾルバー）へ問い合わせます。有効な答えがなければ、リゾルバーがDNSの階層をたどり、対象ゾーンの権威ネームサーバーから答えを得ます。求める情報はレコードタイプで区別されます。
RFC 1034「Domain names - concepts and facilities」で仕組みを確認するDNSが答えるもの
名前とIPv4アドレスを結ぶA、IPv6のAAAA、別名を示すCNAME、メール配送先を示すMX、委任先を示すNS、文字列情報を持つTXTなどです。問い合わせる名前とタイプの組み合わせで答えが変わります。
DNSだけでは完了しないもの
DNSは接続先を示しますが、接続先サーバーにWebサイトがあるか、HTTPS証明書が有効か、メールサーバーが受信できるかまでは保証しません。DNS応答とアプリケーション動作を別々に確認します。
DNSの名前解決に関わる4者
「ネームサーバーを変えた」「DNSが反映されない」という言葉だけでは、どこを見ているか分かりません。管理元、権威サーバー、キャッシュ、利用端末を分けると原因を絞れます。
レジストラ・親ゾーン
ドメイン登録と委任情報を管理します。ネームサーバー変更では、親側のNS委任や必要なグルーレコードが対象になります。ゾーン内のAレコード変更とは操作場所も影響も異なります。
権威ネームサーバー
対象ゾーンの正規データを回答します。複数台ある場合は、すべてが同じ新しい値を返すか確認します。一台だけ古いゾーンを返す状態は、単なる利用者側キャッシュとは別の不整合です。
キャッシュDNS・再帰リゾルバー
利用者の代わりに問い合わせ、応答をTTLの範囲でキャッシュします。社内DNS、ISP、パブリックDNSで保持状況が異なるため、変更直後は新旧の答えが併存し得ます。
OS・ブラウザ・アプリ
端末やブラウザ、VPN、ルーター、セキュリティ製品も名前解決へ関与する場合があります。DNSツールでは新値でも特定端末だけ古いなら、端末から上流まで層を分けて確認します。
主なDNSレコードと、変更時に確認する影響
同じドメインでも、変更するレコードによって止まり得る機能が違います。Web移行でMXやTXTを消す、メール移行でWeb用Aを変える、といった巻き込みを避けるため、ゾーン全体を退避して差分を限定します。
表は横にスクロールして、用途・影響・確認方法を比較できます。
| 種類 | 主な役割 | 誤設定時の主な影響 | 変更後の確認 |
|---|---|---|---|
| A / AAAA | ホスト名をIPv4 / IPv6アドレスへ対応付ける | WebやAPIが旧サーバー・誤ったサーバーへ接続する、または接続できない | AとAAAAを別々に問い合わせ、両方の接続先とHTTPSを確認する |
| CNAME | 名前を別の正規名へ対応付ける | 別名の連鎖先が解決できない、意図しないサービスへ向く | CNAMEの答えだけでなく、最終到達名のA / AAAAまで確認する |
| MX | メールを受け取るサーバー名と優先度を示す | 受信遅延、配送失敗、旧メール環境への配送が起こり得る | 優先度と配送先名、その配送先のA / AAAA、実送受信を確認する |
| NS | ゾーンの権威ネームサーバーを示し、親から委任する | ゾーン全体のWeb・メール・検証用TXTなどが参照不能になり得る | 親の委任と新旧の権威サーバーを分け、各権威が同じゾーンを返すか確認する |
| TXT | ドメイン所有確認、SPFなど用途別の文字列情報を持つ | サービス認証やメール認証が失敗する。既存値の上書きで別用途を壊す場合がある | ホスト名と値を完全一致で確認し、複数用途のTXTを一括置換しない |
| SOA | ゾーンの管理情報を示し、シリアルや負の応答のキャッシュにも関係する | 権威サーバー間の更新不整合や、存在しない応答の保持判断に影響する | 権威ごとのSOAシリアルと、NXDOMAIN時のSOAを確認する |
TTLは「変更が必ず完了する時刻」ではなく、そのリソースレコードをキャッシュできる時間の上限です。変更前の値がすでにキャッシュされていれば、その残存時間中は古い答えが返ることがあります。存在しない名前やデータもSOAに基づいてキャッシュされ得るため、追加直後の確認ではNXDOMAINの履歴も考慮します。
RFC 9520でDNS解決失敗のキャッシュ要件を確認するDNS変更で直接変わることと、別途確認すること
DNSを変えればサイト移行がすべて終わるわけではありません。接続先の案内と、接続先で動くWeb・メール・証明書を分けて受け入れ確認します。
DNS変更が直接決める
- 接続先のアドレスA・AAAA・CNAMEを変更すると、名前解決で返るWebやAPIの接続先が変わります。IPv4だけ変えてIPv6が旧環境を向く状態に注意します。
- メールの配送先MXは受信先候補と優先度を示します。SPF、DKIM、DMARCなど関連TXTは別レコードなので、メール移行時は一式をサービス仕様と照合します。
- 権威DNSの委任先NS変更は、ゾーン全体を回答する事業者・サーバーを切り替えます。新しいゾーンへ既存レコードを複製し、回答可能にしてから委任を変えます。
DNSだけでは保証しない
- Webコンテンツとアプリ新サーバーにファイル、データベース、環境変数、リダイレクトが正しく移ったかはHTTPで確認します。DNSが正しくても500エラーや空サイトは起こり得ます。
- TLS証明書とHTTPS新しい接続先で対象ホスト名の証明書が提示されるか、期限、チェーン、HTTPSリダイレクトを確認します。DNSレコードの存在だけでは証明書は有効になりません。
- DNSSECの署名連鎖DNSSECを利用中のネームサーバー移行では、親側DSと新しいゾーン署名の不一致が解決失敗を招きます。事業者手順に従い、検証リゾルバーで確認します。
「DNS伝播中」という一言で止めず、どの層が旧値かを記録する
変更直後に新旧の答えが混在するのは、各キャッシュが異なる時刻に取得した値をTTL内で保持しているためです。ただし、権威ネームサーバー自身が異なる値を返す、親の委任が誤っている、ゾーンに必要なレコードがない場合は、待つだけでは直りません。問い合わせた名前、タイプ、問い合わせ先、答え、TTL、確認時刻をセットで残してください。
DNSを安全に変更する4段階
変更画面で新しい値を入力する前に、戻す材料と受け入れ条件を作ります。ネームサーバー変更はゾーン全体、単一レコード変更は対象名とタイプの差分として扱います。
現行値と担当範囲を退避する
ゾーンのエクスポートまたは全レコードの記録を取り、変更対象、旧値、TTL、権威NS、SOA、Web・メール担当を残します。管理画面の画像だけでなくコピー可能な値も保存し、機密情報は共有画像でマスクします。
変更前にTTLと新環境を確認する
予定変更なら事業者の許容範囲で事前にTTLを下げ、少なくとも旧TTLが経過してから切り替えます。新サーバーはホスト名を固定するなどDNS切替前の方法で、Web、HTTPS、メールを確認します。
差分だけを変更して時刻を残す
対象のFQDN、タイプ、値、優先度、TTLを再確認して保存します。末尾ドット、ルートを示す@、空欄、相対名の扱いは管理画面ごとに異なるため、契約先マニュアルを優先します。無関係なMXやTXTを削除しません。
切り戻し条件を決めて監視する
権威DNSが誤値を返す、Web・HTTPS・メールの主要機能が失敗する、DNSSEC検証が失敗する場合は、待機ではなく旧値へ戻すか事業者へ連絡します。戻した後も誤値のTTL分は観測が続き得るため、経過を記録します。
変更後を3段階で確認し、完了を判定する
一つのWebツールが新値を返しただけでは完了にしません。正規データ、外部キャッシュ、実際のサービスの順に確認し、どこで不一致が生じたかを記録します。
- 確認 1
権威DNSを直接確認する
委任先NSを調べ、それぞれへ対象名・タイプを直接問い合わせます。digを使える環境なら「dig @権威NS FQDN A」「dig @権威NS FQDN MX」「dig @権威NS ゾーン名 SOA」のように確認します。全権威で値とSOAシリアルが整わなければ、キャッシュ待ちではなくゾーン配布を直します。
- 確認 2
複数の再帰リゾルバーを比較する
通常利用する社内・ISPのDNSと、Google Public DNSなど別経路を同じ名前・タイプで比較します。旧値が返る場合は残りTTL、新値が返る経路、NXDOMAINならSOAと負のTTLを記録します。キャッシュ消去は検証先だけを変える手段で、世界中のキャッシュを一括更新するものではありません。
- 確認 3
Web・HTTPS・メールを受け入れ確認する
主要ページ、ログイン、フォーム、API、HTTPS証明書、送受信を実際に確認します。IPv4とIPv6、ルートドメインとwww、必要なサブドメインを分けます。監視期間中に旧値・新値の両方へ到達しても安全なよう、旧環境を急いで停止しません。
完了条件
すべての権威ネームサーバーが意図した同一値を返し、主要な再帰リゾルバーで旧値のTTLが失効し、Web・HTTPS・メールなど影響する機能が新旧経路から正常に動作した時点で完了とします。待機時間だけで判定せず、問い合わせ結果と受け入れ試験を証拠にしてください。
確認した一次資料・公式ツール
定義、TTL、負のキャッシュ、確認操作は次の標準資料と公式ツールで確認しました。作業時は契約先DNSの手順も併せて確認してください。確認日は2026年7月25日です。
- RFC 1034「Domain names - concepts and facilities」
- RFC 1035「Domain names - implementation and specification」
- RFC 2308「Negative Caching of DNS Queries」
- RFC 9520「Negative Caching of DNS Resolution Failures」
- Google Admin Toolbox「Dig」
- Google Public DNS「Troubleshooting」
- Google Public DNS「Flush Cache」
- IANA「Example Domains」
DNS変更と確認のよくある質問
DNSとネームサーバーは同じものですか？
同じではありません。DNSは名前に対応する情報を管理・問い合わせる仕組み全体です。ネームサーバーはDNS問い合わせへ応答するサーバーで、正規データを持つ権威サーバーや、結果を取得・キャッシュする再帰リゾルバーなど役割が異なります。
DNS変更は必ず48時間待てば反映しますか？
一律には決まりません。変更前のTTL、各キャッシュが旧値を取得した時刻、負のキャッシュ、親ゾーンの委任、事業者の処理によって観測は変わります。権威DNSが誤値を返す場合は待っても直らないため、問い合わせ先とTTLを記録して判断します。
Aレコードを変えるとメールも止まりますか？
メールのMXが別のホストを指し、そのホストの接続先も変わらなければ、A変更だけで必ず止まるとは限りません。ただしMXの配送先が変更対象名へ依存する構成や、SPF・DKIM・DMARCを含む移行では影響します。ゾーン全体と実送受信を確認してください。
Webツールで新しいIPが出ればDNS変更は完了ですか？
まだ完了とは限りません。まず全権威ネームサーバーの回答を確認し、次に複数の再帰リゾルバーを比較し、最後にWeb、HTTPS、メールなど実際の機能を確認します。一つのツールは一つの観測点です。
DNS変更を失敗したら元の値へ戻せばすぐ直りますか？
元へ戻す操作は必要ですが、誤った値を取得したキャッシュはそのTTL中残る場合があります。変更前の値を正確に保存し、旧環境を維持し、戻した時刻と各応答のTTLを記録しながら収束を確認します。DNSSECや委任の問題は事業者への連絡も検討します。
DNS変更と同時に確認する記事
DNS変更は、正規データ・キャッシュ・実サービスを分けて確認する
DNSはドメイン名をIPへ変えるだけでなく、メール配送先、委任先、検証情報などを分散管理する仕組みです。変更前にゾーン、旧値、TTL、権威NSを退避し、差分だけを変更してください。変更後は全権威DNS、複数の再帰リゾルバー、Web・HTTPS・メールの順に確認します。旧値が見えたときは問い合わせ先と残りTTLを、誤値や不一致が見えたときは待機ではなく修正・切り戻しを選ぶことが安全な運用につながります。
この記事の確認体制
Finite Field 編集部
DNSの標準仕様、TTL、負のキャッシュ、Googleの公式確認ツールを照合し、「伝播待ち」と設定不整合を混同しない安全手順として編集しています。
Finite Fieldへ相談
DNS・ドメイン・サーバー移行の設計を相談する
現行レコードの意味が分からない、Webとメールを止めずにネームサーバーを移したい、DNSSECが絡み切り戻し条件を決められない場合は、現在のゾーン情報、変更予定、希望日時を準備してください。
DNSとサーバー移行を相談する設定内容を確認したうえで対応可否をご案内します。無停止、反映時刻、復旧時間、見積額を事前に保証するものではありません。