【図解】DNSの仕組みとは？Webサイトがブラウザに表示されるまで

ブラウザのアドレスバーにURLを入力してEnterキーを押すと、わずか数秒でWebサイトが表示されます。この一瞬の間に裏側で重要な役割を果たしているのがDNS（Domain Name System）です。

DNSやネットワークの基礎は、Webエンジニアやインフラエンジニアを目指す上で避けて通れない必須知識です。未経験からネットワークやインフラの基礎を体系的に学び、CCNAなどの資格取得やエンジニア就職を目指したい方には、受講料・テキスト代が無料で手厚い就職支援が受けられるネットビジョンアカデミーがおすすめです。

この記事では、DNSの役割からURL入力後にブラウザがページを描画するまでの全プロセスを、初心者向けに図解を交えて丁寧に解説します。

1. 【全体像】URLを入力してからWebサイトが表示されるまでの流れ
1. Webサイト表示の全4フェーズ（DNS解決・接続・データ取得・描画）
2. 【図解1】ブラウザからWebサーバーまでの全体通信マップ
そもそもDNS（Domain Name System）とは？なぜ必要なのか
1. ドメイン（店名）とIPアドレス（住所・電話番号）のメタファー
2. DNSサーバーはインターネットの「総合案内所（電話帳）」
【図解で解説】DNS名前解決の4ステップ（IPアドレス特定までの裏側）
IPアドレス取得後、ブラウザがWebサイトを描画するまでの通信プロセス
実務で役立つDNSの必須知識とトラブルシューティング
DNSとWebサイト表示に関するよくある質問（FAQ）
まとめ：DNSの仕組みを理解してWebの基礎を押さえよう
1. インフラ・ネットワーク基礎知識をさらに深めるおすすめ記事
2. 未経験からネットワーク・インフラエンジニアを目指すなら

1. 【全体像】URLを入力してからWebサイトが表示されるまでの流れ

普段私たちが何気なく閲覧しているWebサイトですが、URLを入力してから画面が表示されるまでには、大きく分けて4つのフェーズが存在します。

Webサイト表示の全4フェーズ（DNS解決・接続・データ取得・描画）

フェーズ1（DNS名前解決）： 人間が読めるURL（ドメイン）を、コンピュータが通信先を特定できる「IPアドレス」に変換する最重要フェーズ。
フェーズ2（TCP/TLS接続）： クライアントとサーバー間で通信の信頼性を確認し（TCP 3ウェイハンドシェイク）、盗聴・改ざんを防ぐ暗号化通信（SSL/TLS）を確立。
フェーズ3（データ取得）： ブラウザがWebサーバーに対して必要なリソース（HTML、画像、スクリプトなど）をリクエストし、サーバーがそれに応答。
フェーズ4（レンダリング）： 届いたソースコードをブラウザのレンダリングエンジンが解析し、視覚的なレイアウトを作成して画面に描画。

【図解1】ブラウザからWebサーバーまでの全体通信マップ

URLを入力してからページが手元に届くまでの全体像を、関係するサーバーや通信の流れで整理したマップが以下です。

このように、Webサイトが表示される第一歩は必ず「DNSサーバーにIPアドレスを教えてもらうこと」から始まります。

そもそもDNS（Domain Name System）とは？なぜ必要なのか

DNS（Domain Name System）を一言で表すと、「インターネット上の住所録（電話帳）」のような仕組みです。

インターネット上で通信を行うコンピュータ同士は、すべて「IPアドレス（例: 192.0.2.1 や 2001:0db8::1）」と呼ばれる数字や記号の羅列を使って相手を識別しています。しかし、人間にとって数字の羅列を何十個も覚えるのは非常に困難です。

そこで、人間が扱いやすい「ドメイン名（例: example.com）」と、コンピュータが認識する「IPアドレス」を相互に変換（名前解決）するためにDNSが誕生しました。

ドメイン（店名）とIPアドレス（住所・電話番号）のメタファー

DNSの働きを日常生活に例えると、「行きたいお店の名前から、正確な住所や電話番号を調べるプロセス」と全く同じです。

インターネットの世界	日常生活の例え	役割・特徴
ドメイン名（`example.com`）	店舗名・施設名（例: 渋谷の〇〇カフェ）	人間にとって直感的で覚えやすい名前。ただし、そのままでは通信相手の場所を特定できない。
IPアドレス（`192.0.2.1`）	正確な住所・緯度経度（例: 東京都渋谷区〇〇 1-2-3）	コンピュータや通信機器がネットワーク上でサーバーの物理的な場所を特定するための識別番号。
DNSサーバー	電話帳・案内所・地図アプリ	「店舗名（ドメイン）」から「住所（IPアドレス）」を即座に検索して教えてくれるシステム。

もしDNSが存在しなければ、私たちはGoogleで検索したいときにブラウザのアドレスバーへ 142.250.207.46 と打ち込み、別のサイトを見たいときはその都度別の数字の羅列を入力しなければなりません。

DNSサーバーはインターネットの「総合案内所（電話帳）」

私たちがWebブラウザにexample.comと打ち込んだ瞬間、ブラウザはまずDNSサーバーという名の総合案内所へ向かいます。

[ ブラウザ ] ──► 「example.com に行きたいのですが、住所（IPアドレス）はどこですか？」
                      │
                      ▼
[ DNSサーバー ] ──► 「そのお店の住所（IPアドレス）は【 192.0.2.1 】ですよ！」
                      │
                      ▼
[ ブラウザ ] ──► 「ありがとうございます！【 192.0.2.1 】へアクセスします！」

この「ドメイン名からIPアドレスを突き止める一連の処理」のことを、技術用語で名前解決（Name Resolution）と呼びます。

次章では、この名前解決がどのようなステップで実際に行われているのか、DNSサーバーの階層構造とやり取りを図解で詳しく見ていきましょう。

【図解で解説】DNS名前解決の4ステップ（IPアドレス特定までの裏側）

ドメインからIPアドレスを調べる「名前解決」は、1台のDNSサーバーがすべてのデータを丸抱えしているわけではありません。世界中に分散されたDNSサーバーが階層構造（ツリー構造）を作り、バケツリレーのように連携してIPアドレスを特定しています。

名前解決が行われる具体的な流れを4つのステップで解説します。

ステップ0：手元の「キャッシュ（ブラウザ・OS・ルーター）」を確認

ブラウザにURLを入力した際、いきなりインターネット上のDNSサーバーへ問い合わせに行くわけではありません。まずは通信の負荷を減らし高速化するために、最も近い場所にある「キャッシュ（過去の問い合わせ履歴）」を順番にチェックします。

[URL入力]
  │
  ├─► ① ブラウザのキャッシュを確認（過去に開いた履歴があるか？）
  ├─► ② OS（Windows/Mac）のDNSキャッシュ・hostsファイルを確認
  └─► ③ 自宅ルーター等のローカルキャッシュを確認

過去にそのサイトを訪れたことがあり、キャッシュの有効期限（TTL）が残っていれば、外部との通信を行わずに0.001秒未満で即座にIPアドレスを取得できます。

キャッシュが存在しなかった場合のみ、次のステップ1（外部DNSへの問い合わせ）へ進みます。

ステップ1：専属調査員「キャッシュDNSサーバー（フルリゾルバ）」へ問い合わせ

手元のキャッシュで見つからない場合、パソコンやスマホは契約しているプロバイダ（OCN、NURO、SoftBank等）やパブリックDNS（Google 8.8.8.8 等）の「キャッシュDNSサーバー（フルリゾルバ）」へ問い合わせを送ります。

[クライアントPC] ──(「example.jp のIPを教えて！」)──► [ キャッシュDNSサーバー ]

クライアントからの依頼： 「IPアドレスが分かるまで最後まで調べて答えてください（再帰的問い合わせ）」
キャッシュDNSサーバーの役割： ユーザーに代わって世界中のネームサーバーを巡回し、答えを突き止めてくれる「専属の調査員」

ステップ2：階層構造をたどる「ルートDNS → TLD（.jp/.com） → 権威DNS」

キャッシュDNSサーバーは、ドメインの右側（上位階層）から順番に「反復問い合わせ（次はどこへ行けばいいですか？）」を繰り返します。

                       【 ルートDNSサーバー (.) 】
                                  │ 「次は .jp を管理するサーバーへ行け」
                                  ▼
                      【 TLDネームサーバー (.jp) 】
                                  │ 「次は example.jp を管理する権威サーバーへ行け」
                                  ▼
                    【 権威DNSサーバー (example.jp) 】
                                    「example.jp のIPアドレスは 192.0.2.1 だ！」

① ルートDNSサーバー（最上位 .）： 世界に13系統存在するDNSの起点。「example.jp のIPアドレスは知らないが、トップレベルドメインである .jp の案内所（TLDサーバー）の場所なら知っている」と回答します。
② TLDネームサーバー（.jp や .com）： 国別やジャンル別のドメインを管理するサーバー。「example.jp のゾーン情報を管理している『権威DNSサーバー』へ行け」と案内します。
③ 権威DNSサーバー（ドメインの管理元）： ドメインの所有者がネームサーバーとして設定している最終目的地（ゾーンファイルを保持するサーバー）。

ステップ3：権威DNSサーバーがIPアドレスを特定して回答

目的の権威DNSサーバーに到達すると、設定されているレコード情報（Aレコードなど）を参照し、最終的な答えを返します。

権威DNSサーバーがキャッシュDNSサーバーへ「example.jp のIPアドレスは 192.0.2.1 です」と回答。
キャッシュDNSサーバーはその情報を自身のメモリに一時保存（キャッシュ）しつつ、元のクライアントPCへ回答。
クライアントPCのブラウザがIPアドレスを受け取り、名前解決が完了します。

【図解2】バケツリレー方式でIPアドレスを突き止める仕組み

ここまでのステップ0〜3の全体通信の流れをまとめた図が以下です。

このように、DNSは「専属調査員（キャッシュDNS）が階層ごとの案内所をたらい回しになりながら、最終的な持ち主（権威DNS）を探し当てる」という仕組みで成り立っています。

IPアドレス取得後、ブラウザがWebサイトを描画するまでの通信プロセス

DNSの名前解決によってWebサーバーのIPアドレス（例: 192.0.2.1）が判明したら、いよいよブラウザとWebサーバー間で直接データの送受信が始まります。

ここからWebサイトが画面に表示されるまでには、大きく分けて4つの通信・処理工程が行われます。

① TCP 3ウェイハンドシェイク（通信の確立）

IPアドレスが分かったからといって、いきなりデータを送りつけることはできません。まずはクライアント（ブラウザ）とサーバーの間で「お互いにデータを受け取る準備ができているか」を確認し、信頼性の高い通信路を確立します。

この手続きをTCP 3ウェイハンドシェイク（3-way Handshake）と呼びます。

[ ブラウザ ]                                [ Webサーバー ]
     │                                             │
     │ ──── ① SYN（接続してもいいですか？） ──────► │
     │                                             │
     │ ◄─── ② SYN/ACK（了解！こちらからもOK？） ── │
     │                                             │
     │ ──── ③ ACK（了解しました！接続開始） ──────► │
     │                                             │
     ▼                                             ▼
               【 TCPコネクション確立 】

SYN（接続要求）： ブラウザがサーバーへ「通信を開始したい」という合図を送る。
SYN/ACK（接続許可と応答）： サーバーが「接続を許可します。こちらも準備OKです」と返信する。
ACK（確認応答）： ブラウザが「確認しました。では始めます」と返し、接続が完了する。

この3往復のやり取りによって、通信パケットの欠落や順序のズレを防ぐ安全な通信経路が作られます。

TCP/IPの階層モデルやHTTPプロトコルとの関係性をさらに詳しく学びたい方は、以下の記事も参考にしてください。

関連記事：Webエンジニア向けネットワーク基礎！HTTP/2とTCP/IPの違いをわかりやすく解説

② SSL/TLSハンドシェイク（HTTPS暗号化通信の開始）

現代のWebサイトのほとんどは、通信内容を暗号化して盗聴や改ざんを防ぐ「HTTPS（HTTP over SSL/TLS）」を採用しています。

TCPの接続が完了した直後、暗号化通信を安全に行うための共通鍵をやり取りするSSL/TLSハンドシェイクが実行されます。

[ ブラウザ ]                                [ Webサーバー ]
     │                                             │
     │ ──── ① Client Hello（対応する暗号方式など）─► │
     │                                             │
     │ ◄─── ② Server Hello ＋ SSLサーバー証明書 ─── │
     │                                             │
     │ （証明書の有効性を検証し、共通鍵を暗号化して送信）
     │ ──── ③ 鍵交換 ─────────────────────────────► │
     │                                             │
     ▼                                             ▼
                 【 暗号化通信の確立 】

ブラウザはサーバーから受け取った「SSL/TLSサーバー証明書」が信頼できる認証局から発行されたものかを確認し、安全性が証明された段階で暗号化通信へと移行します。

サーバー証明書の認証方式やWebサーバーへの適用手順について知りたい方は、以下の記事で解説しています。

関連記事：SSL/TLS証明書の仕組みとWebサーバーへの設定手順まとめ

③ HTTP/HTTPSリクエスト＆レスポンス（HTML・CSS・画像データの取得）

安全な通信路が整ったところで、ブラウザはWebサーバーに対して具体的なデータ要求（HTTPリクエスト）を送信します。

[ ブラウザ ] ──( HTTP GET /index.html )──► [ Webサーバー (Apache / Nginx) ]
                                                    │
                                                    ▼ HTMLファイルを読み込み
[ ブラウザ ] ◄──( HTTP 200 OK + HTMLデータ )───── [ レスポンス返却 ]

HTTPリクエスト: ブラウザが「トップページのHTMLをください（GET / HTTP/1.1）」と要求。
Webサーバー側の処理: ApacheやNginxなどのWebサーバーソフトウェアがリクエストを受け取り、該当するファイルをストレージから読み込む（またはバックエンドプログラムを実行）。
HTTPレスポンス: サーバーがステータスコード（正常なら 200 OK）とともにHTMLファイルの中身を返信。

ブラウザは受け取ったHTMLを上から読み進め、途中に書かれているCSSファイル、JavaScriptファイル、画像ファイル（JPEG/PNG/SVG等）のURLを見つけるたびに、追加でリクエストを送信して必要なリソースを揃えていきます。

リクエストを処理するWebサーバーソフト（ApacheやNginx）の特徴や使い分けについては、以下の記事で詳しく比較しています。

関連記事：【Webサーバー構築】ApacheとNginxの違いと選び方を比較

④ ブラウザレンダリング（DOMツリー生成から画面描画まで）

必要なファイルが手元に届いたら、ブラウザの内部にある「レンダリングエンジン」がソースコードを解析し、視覚的なピクセルデータへと変換します。

レンダリングは以下の4つの内部ステップで高速に実行されます。

DOMツリー / CSSOMツリーの構築:
- HTMLを解析してタグの入れ子関係を整理した「DOMツリー」を作る。
- CSSを解析してスタイル情報を整理した「CSSOMツリー」を作る。
レンダーツリー（Render Tree）の作成:
- DOMとCSSOMを合体させ、実際に画面へ表示すべき要素（display: none 等を除外）とそのスタイルを紐付ける。
レイアウト（Layout / Reflow）:
- 画面上のどの位置に、どのサイズ（横幅・高さ・マージン）で配置するかを計算する。
ペイント（Painting）:
- 色、ボーダー、背景、テキストなどをピクセル単位で画面に塗り、最終的に合成（Composite）してディスプレイへ表示する。

【図解3】データ受信から画面がピクセルとして描画されるまでの流れ

データを受信してから画面にページが現れるまでのレンダリング工程をまとめると、以下のようになります。

ここまでの工程がすべてミリ秒単位で連鎖的に行われることで、ユーザーはストレスなくWebサイトを閲覧することができます。

こういったTCP/IPやHTTP、DNSといったネットワークの基礎構造は、フロントエンド・バックエンド・インフラを問わず、すべてのITエンジニアにとってトラブルシューティングや設計の土台となる重要知識です。

インフラやネットワークを基礎からしっかり固め、実務レベルのスキルを身につけたいと考えている方は、専門のスクールで体系的に学習を進めるのも効率的な選択肢です。

実務で役立つDNSの必須知識とトラブルシューティング

Webサイトの運営やサーバー移行、ドメイン設定を行う実務現場では、DNSレコードやキャッシュの仕組みを正しく把握しておく必要があります。

ここでは、エンジニアやWeb担当者が知っておくべき必須知識を整理します。

主要なDNSレコードの種類（A、AAAA、CNAME、NS、MX）

権威DNSサーバーの「ゾーンファイル」には、ドメイン名とIPアドレスや別名を紐付けるためのDNSレコードが設定されています。代表的なレコードは以下の通りです。

レコード種別	役割・概要	具体的な設定例
Aレコード	ドメイン名をIPv4アドレスに紐付ける（最も基本）	`example.com` → `192.0.2.1`
AAAAレコード	ドメイン名をIPv6アドレスに紐付ける	`example.com` → `2001:db8::1`
CNAMEレコード	ドメイン名に別名（エイリアス）を設定する	`[www.example.com](https://www.example.com)` → `example.com`
NSレコード	そのドメインのゾーン情報を管理する権威DNSサーバーを指定	`example.com` → `ns1.dnsprovider.jp`
MXレコード	そのドメイン宛てのメール送信用サーバーを指定（優先度付き）	`example.com` → `mail.example.com` (優先度: 10)
TXTレコード	テキスト情報を保持（SPF/DKIMによる送信元認証や所有権確認）	`v=spf1 include:_spf.google.com ~all`

「DNSの浸透待ち」は誤用？キャッシュの有効期限「TTL（Time To Live）」の正体

サーバー移行やネームサーバー変更時によく「DNSが世界中に浸透するまで24〜72時間かかる」と言われますが、技術的には「浸透」という概念は存在しません。

DNS情報がすぐに切り替わらない原因は、各キャッシュDNSサーバーやPCが保持しているTTL（Time To Live：キャッシュの有効期限）が切れていないためです。

【 サーバー切り替え前の状態 】
  キャッシュDNS ──( TTL: 86400秒 / 24時間 )──► 旧サーバーのIPをキャッシュ中
                                                       │
                                                       ▼ TTLが切れるまで旧IPを返し続ける

【 TTLが満了した後の状態 】
  キャッシュDNS ──( キャッシュ破棄 )──► 権威DNSへ再問い合わせ ──► 新サーバーのIPを取得！

TTLが24時間（86400秒）の場合： 一度問い合わせたキャッシュDNSサーバーは、24時間経過するまで権威DNSへ再問い合わせを行わず、古いIPアドレスを返し続けます。
スムーズなサーバー移行のコツ： ドメイン切り替えの数日前〜1週間前に、あらかじめTTLを「300秒（5分）」など短く設定しておきます。切り替えが完了し安定した後に、再び元のTTLに戻すのが実務上の定石です。

ドメイン変更後にサイトが表示されない時のチェックリスト（キャッシュクリア・nslookup/digコマンド）

設定変更後に自分だけサイトが開かない、あるいは新サーバーへ切り替わらない場合は、以下の手順でトラブルシューティングを行います。

1. クライアント側のキャッシュを消去する

ブラウザキャッシュのクリア: ブラウザ自体のDNSキャッシュ（Chromeの場合は chrome://net-internals/#dns から「Clear host cache」）を削除。
OSのDNSキャッシュクリア:
- Windows: コマンドプロンプトで ipconfig /flushdns を実行
- Mac: ターミナルで sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder を実行

2. コマンドで名前解決の状態を確認する

手元のPCからコマンドを実行し、どのDNSサーバーがどのIPを返しているかを特定します。

Windows / Mac 共通（nslookupコマンド）：

Bash

# デフォルトのDNSサーバーで名前解決を確認
nslookup example.com

# GoogleのパブリックDNS(8.8.8.8)を指定して確認（キャッシュの影響を排除）
nslookup example.com 8.8.8.8

Mac / Linux（digコマンド）：

Bash

# Aレコードの問い合わせとTTLの確認
dig example.com A

# ルートDNSからの階層問い合わせルートを追跡
dig example.com +trace

+trace オプションを使うと、ルートDNSから権威DNSまでのバケツリレーがどの階層で止まっているか（名前解決エラーの原因）を正確に突き止めることができます。

DNSとWebサイト表示に関するよくある質問（FAQ）

DNSやWebサイト表示の仕組みについて、学習中の方や実務初心者がつまずきやすい疑問をFAQ形式でまとめました。

Q1. パソコンを再起動するとDNSキャッシュは消える？

A. OSやブラウザのメモリ上に保持されているキャッシュは消去されますが、ルーターやプロバイダ側のキャッシュは残ります。

パソコンを再起動すると、OS（WindowsやmacOS）および起動していたブラウザのDNSキャッシュはクリアされます。しかし、自宅のWi-Fiルーターや、インターネット接続事業者（ISP）のキャッシュDNSサーバーに蓄積されたキャッシュまでは消えません。

そのため、ローカルPCを再起動してもドメインの反映が確認できない場合は、ルーターの再起動や、コマンドからのDNS指定問い合わせ（nslookup ドメイン名 8.8.8.8 など）を試す必要があります。

Q2. パブリックDNS（Google 8.8.8.8など）を使うと何が変わる？

A. 名前解決の応答速度向上、キャッシュ反映の早さ、セキュリティの強化などのメリットがあります。

通常はプロバイダ（ISP）から自動割り当てされたキャッシュDNSサーバーが使われますが、設定を手動で「パブリックDNS」に変更することができます。

主な代表例:
- Google Public DNS: 8.8.8.8 / 8.8.4.4（高速性・可用性に優れる）
- Cloudflare: 1.1.1.1 / 1.0.0.1（プライバシー保護・世界最速水準の応答速度）
主なメリット:
- 世界規模のCDNネットワークや高速インフラを利用しているため、名前解決のレイテンシ（遅延）が短縮される。
- プロバイダ側のDNSキャッシュ障害や遅延を回避できる。
- ドメイン変更時の最新情報反映が比較的早い。

Q3. DNSサーバーがダウンするとどうなる？

A. サーバー自体が生きていても、ユーザーはWebサイトやメールサービスにアクセスできなくなります。

DNSサーバーは「住所を教える案内所」であるため、ここが停止するとブラウザは接続先のIPアドレスを特定できなくなります。結果として、ブラウザには「サーバーが見つかりません（DNS_PROBE_FINISHED_NXDOMAIN や ERR_NAME_NOT_RESOLVED）」といったエラーが表示されます。

権威DNSサーバーが停止した場合:
- 世界中のどのユーザーも、そのドメイン配下のWebサイトやメール送受信が行えなくなります（事業影響が極めて甚大）。
- 対策として、通常はプライマリDNSとセカンダリDNSのように冗長構成（複数台運用）を組むのが一般的です。
特定のキャッシュDNSサーバーが停止した場合:
- そのキャッシュDNSを利用している特定のプロバイダ加入者や社内ネットワークの端末のみ、名前解決に失敗します。別のDNS（パブリックDNS等）に切り替えれば閲覧可能です。

まとめ：DNSの仕組みを理解してWebの基礎を押さえよう

URLを入力してからWebサイトが表示されるまでの一連の流れは、インターネット通信の根幹を支える重要な仕組みです。

DNSの役割: ドメイン名（店名）をコンピュータが通信できるIPアドレス（住所）へ変換（名前解決）する
名前解決のフロー: キャッシュ確認 → キャッシュDNS（フルリゾルバ） → ルートDNS → TLD → 権威DNSへとバケツリレーで問い合わせる
サイト表示までの工程: DNS名前解決 → TCP/TLS接続確立 → HTTPリクエスト/レスポンス → ブラウザレンダリング

これらのプロセスを正しく把握しておくと、ドメイン設定やサーバー移行時のトラブル発生時にも迅速に原因を特定できるようになります。

インフラ・ネットワーク基礎知識をさらに深めるおすすめ記事

Webエンジニアやインフラエンジニアとして実務力を高めるためには、DNSだけでなくサーバーOS（Linux）やネットワーク全体の構造理解が欠かせません。ステップアップを目指す方は、ぜひ以下の記事もあわせてチェックしてみてください。

関連記事：Webエンジニアにネットワーク知識は必要？CCNAを取得するメリット
関連記事：WebエンジニアにLinux知識はどこまで必要？インフラ基礎の重要性

未経験からネットワーク・インフラエンジニアを目指すなら

「DNSやTCP/IPなどのネットワークをもっと本格的に学びたい」「独学だけでなく実務で通用するインフラのスキルを身につけたい」という方には、受講料・テキスト代が無料でIT資格「CCNA」の取得から就職までを一括サポートしてくれるネットビジョンアカデミーがおすすめです。

基礎知識のインプットから実践的な実機演習まで体系的に学べるため、未経験からITエンジニアへのキャリアチェンジを目指す方は、まずは無料説明会に参加してみてはいかがでしょうか。