この記事の読み方7のポイント
DNSリゾルバーがルート、TLD、権威DNSへ問い合わせる図 拡大して見る ↗
図 01キャッシュがない場合の代表的な問い合わせモデル。3つの管理先はリゾルバーと個別にやり取りし、Web本文はこの図の通信に含まれません。
  1. 端末:名前を質問
  2. リゾルバー:調べる役
  3. ルート:TLDの管理先を案内
  4. TLD:ドメインの管理先を案内
  5. 権威DNS:管理するレコードを回答
働く順番をたどる

名前の答えは、誰が探す?

質問 → 調査 → 回答

調べる主体はリゾルバーです。キャッシュに答えがなければ、名前の管理先へそれぞれ質問していきます。

端末名前を質問する
リゾルバーキャッシュを確認
必要なら管理先へ質問
① ルートDNS次の管理先の案内
② TLD権威DNSの案内
③ 権威DNS管理するレコードの回答

期限内の答えがない場合、リゾルバーが名前の管理先をたどって調べます。

  1. 01

    端末が問い合わせる

    端末やブラウザが名前の情報を必要とし、設定されたDNSリゾルバーへ質問します。ローカルに答えがある場合は省略されます。

  2. 02

    キャッシュを確認する

    リゾルバーは期限内の答えを持っていれば利用します。答えがなければ名前の管理階層をたどります。

  3. 03

    管理先をたどる

    典型的にはリゾルバーがルート、TLD、権威DNSへそれぞれ問い合わせます。途中では次に問い合わせる管理先が案内されます。

  4. 04

    答えを端末へ返す

    権威DNS等から得たレコードを返します。端末はその情報を使って接続します。DNSがWeb本文を取得して返すわけではありません。

ルート→TLD→権威が質問を順に転送する図ではありません。質問するのはリゾルバーです。

名前と接続先を分けるためのしくみ

人は example.com のような名前を使います。通信にはIPアドレスなどの情報が必要です。DNSは、名前に対応する情報を調べるための分散したしくみです。一台の巨大な一覧表だけで、世界中の名前を管理しているわけではありません。

名前を使うことで、読者が覚える呼び名と、通信先の構成を分けられます。ただし「名前は必ず一つの固定IPと一対一」というわけでもありません。複数の答えや別名などを利用できます。

リゾルバーと権威DNSは、仕事が違う

リゾルバーは端末の質問を受け、必要な答えを調べる役です。権威DNSは、その名前について自分が管理するレコードを回答する役です。前者が調査の窓口、後者が管理している情報の提供元、と考えると違いがつかめます。

同じ「DNSサーバー」と呼ばれても、何を担当しているかは分けて確認する必要があります。端末が質問する相手と、対象ドメインの記録を持つ相手は、通常同じとは限りません。

キャッシュがないとき、管理の階層をたどる

代表的な例では、リゾルバーがルートへ質問し、次に問い合わせるTLDの管理先を受け取ります。TLDは .com などの部分に対応する管理を担当します。そこから対象ドメインの権威DNSの情報を得て、最後に必要なレコードを問い合わせます。

ルートがTLDへ質問を転送し、TLDが権威DNSへ転送する一列の中継ではありません。 リゾルバーがそれぞれの案内を受け取り、次の質問を行います。図でリゾルバーを中央に置いたのは、この役割を区別するためです。

DNSレコードはIPアドレスだけではない

DNSには目的別のレコードがあります。AはIPv4アドレス、AAAAはIPv6アドレス、CNAMEは別名、MXはメールの配送先に関わる情報、という具合です。名前からWebサーバーを見つける用途だけに限定されません。

↔ 表が収まらない場合は、横にスクロールして比較できます。

名前から調べる、目的別のレコード例
レコード例 主な意味
A 名前に対応するIPv4アドレス
AAAA 名前に対応するIPv6アドレス
CNAME 別の名前への対応
MX メールの配送先に関わる情報

Webページを開く場面では、ブラウザ等が必要な情報を得た後、その接続先と別の通信を行います。DNSの答えにHTMLや画像そのものが入っている、という意味ではありません。

DNSから名前に対応する情報を得た後、WebサーバーからHTMLや画像を受け取って表示する図 拡大して見る ↗
図 02DNSが返すのは名前に対応する情報です。Web本文や画像は、その後のWebサーバーとの通信で取得します。基本的な流れを示し、キャッシュがある場合には一部の問い合わせ・取得を省けます。
  1. 名前の情報をDNSで調べる。
  2. その情報を使ってWebサーバーへ接続し、データを要求する。
  3. 受け取ったHTMLや画像などをブラウザが表示する。

TTLは、同じ答えを使える期間の手掛かり

答えにはTTLというキャッシュ期限に関わる値があります。期限内に保存した答えを使えば、毎回管理階層を調べ直す負荷を減らせます。端末やブラウザ、リゾルバーなど、複数の場所でキャッシュが関わる場合があります。

DNS設定を変更しても、すでに保存されている答えが直ちに一斉更新されるとは限りません。一方で、すべての利用者が常にTTLの全時間だけ待つとも限りません。取得時刻や残り期限が違うからです。

TTL300秒の単一キャッシュで120秒後に残り180秒となり300秒後に期限に達する例 拡大して見る ↗
図 03TTL300秒の答えを取得後、再取得しない単一のキャッシュの例です。使うたびに期限が延びるわけではありません。通常の期限管理を示し、取得時刻や残り期限が異なるキャッシュが一斉に切り替わることを意味しません。
  1. 取得時:残り300秒。数値は説明用の仮の条件。
  2. 120秒後:残り180秒。利用だけで期限はリセットされない。
  3. 300秒後:期限に達する。通常は期限切れとして扱い、必要なら調べ直す。

よくある誤解:DNSを変えれば回線が速くなる?

名前を調べる待ち時間が変わる可能性はあります。しかしDNSが動画やページ本文を運ぶわけではありません。データ取得の速度、サーバー処理、Wi-Fiの状態などは別の要因です。

DNSの役割を「名前を調べる」と限定して見ると、Webページの取得やルーターの転送と混同せずに理解できます。

メールでもDNSを使います。一般的な配送では、宛先ドメインのMXレコードからメールを受けるサーバー名を調べ、その名前のIPアドレスも調べます。その後、実際のメールはSMTPで受け渡します。電子メールが届くまででは、行き先を調べる通信と本文の配送、保存後の閲覧を分けて追えます。

「ページが開かない」とDNSの問題は同じ?

ページが開かないという結果だけでは、DNSの問題とは決められません。 名前を調べる、接続先と通信する、ページのデータを受け取る、という別々の仕事があるからです。

  • 名前の答えを得られない: リゾルバーへの通信や名前の情報を調べる段階で止まっている可能性があります。接続先のWebサーバー自体が停止したと、この結果だけで判断はできません。
  • 名前は分かったが、接続できない: 接続先までの通信や、接続を受け付ける側の状態を分けて考えます。DNSの答えが得られたことと、その接続先が応答することは別です。
  • 接続後に警告やエラーが出る: HTTPSの相手の確認やWebページの要求・応答など、DNSの後に行う仕事を見ます。DNS設定を変えるだけで、証明書の警告やページ側のエラーが直るとは限りません。

キャッシュや既存の接続を使うこともあるため、毎回すべての仕事を最初から行うとは限りません。大切なのは、「どこまで答えが得られたか」と「どの段階で止まったか」を分けることです。DNSは名前を調べる役であり、通信全体の成否を一人で決める役ではありません。

説明をもう一歩深く

よくある疑問

DNSはURL全体を調べる?

主にホスト名に対応する情報を調べます。ページのパスや画面内容の指定は、その後のWeb通信等の役割です。

一つの名前は一つのIPアドレス?

複数のアドレスを持つこともあり、別名を経由する場合もあります。答えが場所や条件で変わる構成もあります。

変更後すぐ全員に同じ答えが返る?

期限内のキャッシュが残る場合があります。どこで何が保持されているかにより、変更が利用される時刻はそろわないことがあります。

DNSで名前を調べられないと、サイトが停止している?

名前の答えを得られないことと、接続先のサイトが停止していることは別です。名前を調べる段階、接続する段階、ページを受け取る段階を分けて考えます。

参考資料・出典

原理の説明と図解の確認に使った資料です。特定製品の機能は一般原理と区別して扱っています。

  1. Cloudflare:What is DNS? ↗

    リゾルバー、ルート、TLD、権威DNSとキャッシュの関係。 確認:2026-10-07

  2. Cloudflare Developers:What is DNS? ↗

    名前を接続先情報へ対応させる役割。 確認:2026-10-01

  3. MDN:How the web works ↗

    DNSとその後のHTTPによる取得の違い。 確認:2026-10-01

  4. RFC 5321:Simple Mail Transfer Protocol ↗

    宛先ドメインのMXとメールサーバーのアドレス解決。DNSは本文の配送を担当しない。 確認:2026-10-04

  5. RFC 1035:DNSの実装と仕様 ↗

    3.2.1および7.1:TTLによるキャッシュ期限と経過時間の管理。図の300秒は説明用の仮の条件。 確認:2026-10-04

説明・図解に気になる点がありましたか?

この記事の誤りを報告する ↗